Redis复制与可扩张集群搭建

Posted by

上一篇文章钻探了Redis的常用数据类型与积累机制,本文少禽研讨一下Redis的复制作而成效以及Redis复制机制自己的利害以及集群搭建难题。

Redis的复制效能是一丝一毫建设构造在事先我们钻探过的凭仗内部存款和储蓄器快速照相的长久化战略基础上的,也等于说无论你的长久化计谋选拔的是如何,只要使用了redis的复制作而成效,就决然会有内部存款和储蓄器快速照相爆发,那么首先要留意你的种类内部存款和储蓄器体量规划,原因能够参见作者上一篇小说中涉及的Redis磁盘IO难题。

 

 

Redis复制流程概述

Redis的复制功效是全然创设在事先大家商酌过的依赖内部存款和储蓄器快速照相的悠久化战略基础上的,也正是说无论你的长久化攻略选取的是何等,只要使用了Redis的复制效率,就必然会有内部存款和储蓄器快速照相发生,那么首先要细心你的系列内存容量规划,原因能够参见小编上一篇小说中涉嫌的Redis磁盘IO问题。

Redis复制流程在Slave和Master端各自是一套状态机流转,涉及的动静新闻是:

Slave 端:

REDIS_REPL_NONE
REDIS_REPL_CONNECT
REDIS_REPL_CONNECTED 

Master端:

REDIS_REPL_WAIT_BGSAVE_START
REDIS_REPL_WAIT_BGSAVE_END
REDIS_REPL_SEND_BULK
REDIS_REPL_ONLINE

整套场馆机流程进程如下:

  1. Slave端在陈设文件中增添了slave
    of指令,于是Slave运营时读取配置文件,伊始状态为REDIS_REPL_CONNECT。
  2. Slave端在定期任务serverCron(Redis内部的机械漏刻触发事件)中连连Master,发送sync命令,然后阻塞等待master发送回其内部存款和储蓄器快速照相文件(最新版的Redis已经无需让Slave阻塞)。
  3. Master端收到sync命令轻巧判别是不是有正值开展的内存快速照相子进度,未有则马上早先内部存款和储蓄器快速照相,有则等待其得了,当快速照相完成后会将该公文发送给Slave端。
  4. Slave端接收Master发来的内部存款和储蓄器快速照相文件,保存到本地,待接到实现后,清空内部存款和储蓄器表,重新读取Master发来的内部存款和储蓄器快速照相文件,重城建总公司体内部存储器表数据结构,并最后状态置位为
    REDIS_REPL_CONNECTED状态,Slave状态机流转到位。
  5. Master端在发送快速照相文件进程中,接收的别的会转移数据集的一声令下都会有的时候先保存在Slave互联网连接的出殡缓存队列里(list数据结构),待快速照相完结后,依次发放Slave,之后接到的命令同样管理,并将气象置位为
    REDIS_REPL_ONLINE。

万事复制进度完毕,流程如下图所示:

图片 1

Redis复制流程在Slave和Master端各自是一套状态机流转,涉及的情事音讯是:

Redis复制机制的劣势

从地点的流程能够看出,Slave从库在连年Master主库时,Master会进行内存快速照相,然后把任何快速照相文件发给Slave,也正是未有象MySQL那样有复制地点的定义,即无增量复制,那会给任何集群搭建带来十分的多的主题素材。

举例一台线上正在周转的Master主库配置了一台从库进行轻松读写分离,那时Slave由于互联网恐怕其余原因与Master断开了接二连三,那么当Slave实行重复连接时,需求再行赢得整个Master的内部存款和储蓄器快照,Slave全体数据跟着整个解除,然后再一次创设全方位内部存款和储蓄器表,一方面Slave恢复生机的岁月会不快,另一方面也会给主库带来压力。

故而听闻上述原因,假设你的Redis集群须求主从复制,那么最棒事先布置好全数的从库,防止中途再去充实从库。

Slave 端:

Cache还是Storage

在我们剖判过了Redis的复制与长久化功用后,大家轻便得出二个定论,实际上Redis如今颁发的本子还都是二个单机版的思路,重要的主题材料聚焦在,长久化格局远远不足成熟,复制机制存在相当大的久治不愈的病痛,那时大家又初叶重复思量Redis的长久:Cache照旧Storage?

假若作为Cache的话,就如除了有些极度出格的事体场景,必须要动用Redis的某种数据结构之外,大家选用Memcached可能更方便,究竟Memcached无论客户端包和服务器本人更加持久经考验。

如尽管当做存款和储蓄Storage的话,大家面对的最大的标题是不管持久化还是复制都尚未章程减轻Redis单点难点,即一台Redis挂掉了,未有太好的点子能够快速的复苏,日常几十G的悠久化数据,Redis重启加载必要多少个钟头的时光,而复制又有弱点,如何消除吗?

Master端:

Redis可扩充集群搭建

 

1. 积极复制避开Redis复制缺欠。

既然Redis的复制功效有宿疾,那么大家无妨扬弃Redis自己提供的复制功效,大家得以行使主动复制的措施来搭建大家的集群遭遇。

所谓积极复制是指由业务端只怕通过代理中间件对Redis存款和储蓄的数额开始展览双写或多写,通过数量的多份存款和储蓄来到达与复制一样的指标,主动复制不止限于用在Redis集群上,近期游人如织公司使用主动复制的技艺来缓慢解决MySQL主从之间复制的延期难点,举例Facebook还特意开荒了用来复制和分区的中间件gizzard() 。

积极复制就算缓和了伤心复制的延迟难点,但也带动了新的主题素材,正是多少的一致性难点,数据写2次或频仍,怎么样保险多份数据的一致性呢?要是你的使用对数码一致性必要不高,允许最后一致性的话,那么一般简单的消除方案是能够透过时间戳大概vector
clock等艺术,让客户端同不时间取到多份数据并实行校验,如果您的运用对数据一致性须求极其高,那么就需求引进一些错综相连的一致性算法比方Paxos来有限帮忙数据的一致性,不过写入质量也会相应下跌相当多。

由此主动复制,数据多份积攒大家也就不再担忧Redis单点故障的标题了,倘诺一组Redis集群挂掉,大家得以让职业快捷切换来另一组Redis上,裁减业务风险。

一体处境机流程过程如下:

2. 经过presharding进行Redis在线扩大容积。

通过积极复制大家消除了Redis单点故障难点,那么还应该有叁个生死攸关的标题亟待解决:容积规划与在线扩容难题。

大家前段时间深入分析过Redis的适用场景是全部数额存款和储蓄在内部存款和储蓄器中,而内部存款和储蓄器体积有限,那么首先需求依靠作业数据量进行初始的体积规划,比方您的政工数据要求100G存款和储蓄空间,要是服务器内部存款和储蓄器是48G,那么依据上一篇大家谈谈的Redis磁盘IO的难点,大家大约必要3~4台服务器来积存。那几个实在是对现存专门的学业景况所做的多少个体量规划,尽管业务拉长比异常的快,极快就能够意识眼下的容积已经远远不足了,Redis里面储存的多寡急迅就能抢先物理内部存款和储蓄器大小,那么哪些开始展览Redis的在线扩大容积呢?

Redis的小编提议了一种名为presharding的方案来消除动态扩大体积和数码分区的题目,实际就是在平等台机械上配备七个Redis实例的艺术,当容积相当不足时将八个实例拆分到不一样的机器上,那样实在就完毕了扩大体积的效果。

拆分进度如下:

  1. 在新机器上运维好相应端口的Redis实例。
  2. 配备新端口为待迁移端口的从库。
  3. 待复制作而成功,与主库完结一块后,切换全部客户端配置到新的从库的端口。
  4. 布署从库为新的主库。
  5. 移除老的端口实例。
  6. 重复上述进程迁移好全体的端口到内定服务器上。

上述拆分流程是Redis小编建议的多个平坦迁移的进度,不过该拆分方法照旧很信赖Redis本人的复制功用的,假设主库快速照相数据文件过大,那几个复制的长河也会比较久,同不经常间会给主库带来压力。所以做那些拆分的进度最佳采纳为业务访谈低峰时段进行。

 

Redis复制的精雕细刻思路

咱俩线上的连串接纳了大家和睦立异版的Redis,首要消除了Redis未有增量复制的缺陷,能够不负职分相近Mysql
Binlog那样能够透过从库须要日志地方举办增量复制。

咱俩的长久化方案是率先写Redis的AOF文件,并对这几个AOF文件按文件大小举办活动分割滚动,同有时间关闭Redis的Rewrite命令,然后会在业务低峰时间举办内部存款和储蓄器快速照相存款和储蓄,并把当前的AOF文件地方一齐写入到快速照相文件中,那样大家能够使快速照相文件与AOF文件的地方保持一致性,那样我们获取了系统某一随时的内部存款和储蓄器快速照相,并且还要也能知晓这一每天对应的AOF文件的职位,那么当从库发送同步命令时,我们率先会把快速照相文件发送给从库,然后从库会收取该快速照相文件中存款和储蓄的AOF文件地方,并将该任务发给主库,主库会随着发送该职位然后的享有命令,今后的复制就都是以此地方然后的增量新闻了。

图片 2

  • Slave端在按时义务serverCron(Redis内部的停车计时器触发事件)中总是Master,发送sync命令,然后阻塞等待master发送回其内部存款和储蓄器快速照相文件(最新版的Redis已经无需让Slave阻塞)。
  • Master端收到sync命令轻易判别是不是有正值进展的内部存款和储蓄器快速照相子进度,没有则即时开头内部存储器快速照相,有则等待其得了,当快速照相实现后会将该文件发送给Slave端。
  • Slave端接收Master发来的内部存款和储蓄器快照文件,保存到地面,待收到达成后,清空内部存款和储蓄器表,重新读取Master发来的内部存款和储蓄器快速照相文件,重城建总公司体内存表数据结构,并最终状态置位为
    REDIS_REPL_CONNECTED状态,Slave状态机流转到位。
  • Master端在发送快照文件进度中,接收的别的会变动数据集的吩咐都会一时半刻先保存在Slave互连网连接的发送缓存队列里(list数据结构),待快速照相完毕后,依次发放Slave,之后接到的下令一样管理,并将气象置位为
    REDIS_REPL_ONLINE。

Redis与MySQL的结合

当下大多数网络商家利用MySQL作为数据的尤为重要持久化存款和储蓄,那么哪些让Redis与MySQL很好的整合在一块儿啊?我们第一行使了一种基于MySQL作为主库,Redis作为高速数据查询从库的异构读写分离的方案。

为此大家非常开垦了和谐的MySQL复制工具,能够一本万利的实时同步MySQL中的数据到Redis上。

图片 3

(MySQL-Redis 异构读写分离)

总结:

  1. Redis的复制功效未有增量复制,每一遍重连都会把主库整个内部存款和储蓄器快速照相发给从库,所以须要制止向在线服务的下压力一点都不小的主库上扩充从库。
  2. Redis的复制由于会动用快速照相持久化格局,所以只要您的Redis长久化方式采取的是日记追加方式(aof),那么系统有望在长久以来时刻既做aof日志文件的同步刷写磁盘,又做快速照相写磁盘操作,今年Redis的响应能力会受到震慑。所以若是采用aof持久化,则加从库供给更为严厉。
  3. 能够使用主动复制和presharding方法开始展览Redis集群搭建与在线扩大体量。

本文加上在此之前的2篇篇章基本将Redis的最常用效用和采用境况与优化实行了分析和座谈,实际Redis还会有比比较多另外帮扶的有个别效应,Redis的我也在时时刻刻尝试新的思绪,这里就不一一列举了,有意思味的爱侣能够讨论下,也很接待一齐探究

 

一切复制进程一鼓作气,流程如下图所示:

图片 4

从地点的流水生产线能够看看,Slave从库在一连Master主库时,Master会进行内部存款和储蓄器快速照相,然后把任何快照文件发放Slave,也正是未有象MySQL那么有复制地点的定义,即无增量复制,那会给任何集群搭建带来相当的多的主题素材。

 

诸如一台线上正在运维的Master主库配置了一台从库举行简易读写分离,那时Slave由于互连网也许别的原因与Master断开了连接,那么当Slave进行再一次连接时,需求重新获得整个Master的内部存款和储蓄器快速照相,Slave所有数据跟着整个拔除,然后再度确立全方位内部存储器表,一方面Slave复苏的时光会相当慢,另一方面也会给主库带来压力。

由此基于上述原因,假如你的Redis集群供给主从复制,那么最佳事先陈设好全体的从库,幸免中途再去充实从库。

在大家剖析过了Redis的复制与持久化成效后,我们轻易得出一个定论,实际上Redis近期公布的版本还都是三个单机版的笔触,重要的主题材料集中在,漫长化方式缺乏成熟,复制机制存在相当的大的症结,那时大家又起来重复记挂Redis的定点:Cache照旧Storage?

 

比如作为Cache的话,就好像除了有个别特别极度的业务场景,必须求使用Redis的某种数据结构之外,大家选用Memcached大概更适于,毕竟Memcached无论客户端包和服务器自个儿更加持久经考验。

如果是当做存款和储蓄Storage的话,我们面前遭逢的最大的标题是不管长久化依然复制都不曾办法缓和Redis单点难点,即一台Redis挂掉了,没有太好的点子能够急速的复原,平日几十G的悠久化数据,Redis重启加载要求多少个钟头的时光,而复制又有劣点,怎么着化解吗?

1.
能动复制避开Redis复制缺欠。

既然Redis的复制成效有劣点,那么大家不要紧抛弃Redis自个儿提供的复制功效,大家得以行使主动复制的诀要来搭建大家的集群境况。

所谓积极复制是指由业务端可能通过代办中间件对Redis存款和储蓄的数目举办双写或多写,通过数据的多份存款和储蓄来到达与复制一样的指标,主动复制不仅只限于用在Redis集群上,最近无数商厦使用主动复制的手艺来减轻mysql主干之间复制的推迟难题,比如脸书还极度开荒了用来复制和分区的中间件gizzard()

积极复制纵然缓慢解决了消沉复制的推迟难题,但也带动了新的主题材料,正是数量的一致性难题,数据写2次或频仍,怎么着确定保证多份数据的一致性呢?要是您的使用对数码一致性必要不高,允许最终一致性的话,那么一般简单的消除方案是足以透过时间戳只怕vector
clock等方法,让客户端同临时间取到多份数据并拓展校验,假若您的选拔对数码一致性供给相当高,那么就必要引进一些长短不一的一致性算法比如说Paxos来保险数据的一致性,可是写入质量也会相应狂跌相当多。

因而主动复制,数据多份储存大家也就不再顾虑Redis单点故障的题目了,假如一组Redis集群挂掉,我们得以让事情高速切换成另一组Redis上,裁减业务风险。

透过积极复制大家化解了Redis单点故障难题,那么还恐怕有四个人命关天的主题素材需求消除:体量规划与在线扩大容积难点。

 

大家最近剖析过Redis的适用场景是一切数量存款和储蓄在内部存款和储蓄器中,而内部存款和储蓄器体积有限,那么首先供给基于业务数据量实行开端的体积规划,比如您的事体数据须求100G存储空间,借使服务器内部存款和储蓄器是48G,那么依照上一篇我们谈谈的Redis磁盘IO的难题,我们大约须要3~4台服务器来积存。这么些实际是对现成业务意况所做的三个容积规划,要是业务做实快捷,不慢就能意识日前的体量已经非常不够了,Redis里面储存的数额神速就能抢先物理内部存储器大小,那么哪些进展Redis的在线扩大容积呢?

Redis的作者建议了一种名称叫presharding的方案来减轻动态扩大体量和数码分区的主题材料,实际正是在同样台机械上配备两个Redis实例的不二秘诀,当体量远远不够时将三个实例拆分到分歧的机械上,那样其实就达成了扩大容积的效用。

拆分进度如下:

  • 配置新端口为待迁移端口的从库。
  • 待复制作而成功,与主库完结一道后,切换全数客户端配置到新的从库的端口。
  • 配置从库为新的主库。
  • 移除老的端口实例。
  • 再度上述进度迁移好全体的端口到钦点服务器上。

如上拆分流程是Redis小编建议的一个平整迁移的历程,然而该拆分方法依然很注重Redis本人的复制作用的,如果主库快速照相数据文件过大,这么些复制的进度也会非常久,同有时候会给主库带来压力。所以做那么些拆分的进程最棒采用为职业访问低峰时段进行。

我们线上的体系使用了大家安危与共立异版的Redis,主要化解了Redis未有增量复制的瑕玷,能够一气浑成临近Mysql
Binlog这样能够通过从库需要日志地方张开增量复制。

 

我们的漫长化方案是率先写Redis的AOF文件,并对那一个AOF文件按文件大小实行活动分割滚动,同一时候关闭Redis的Rewrite命令,然后会在作业低峰时间实行内存快速照相存款和储蓄,并把当前的AOF文件地方一齐写入到快速照相文件中,这样我们得以使快速照相文件与AOF文件的职位保持一致性,那样大家获得了系统某一随时的内部存款和储蓄器快速照相,况且同一时候也能了然这一每二二十二日对应的AOF文件的职务,那么当从库发送同步命令时,大家首先会把快速照相文件发送给从库,然后从库会收取该快速照相文件中贮存的AOF文件地点,并将该岗位发给主库,主库会跟着发送该职责然后的持有命令,以往的复制就都以以此职位然后的增量新闻了。

图片 5

当下相当多网络厂商利用MySQL作为数据的第一悠久化存款和储蓄,那么哪些让Redis与MySQL很好的整合在一同啊?咱们第一利用了一种基于MySQL作为主库,Redis作为高速数据查询从库的异构读写分离的方案。

 

为此我们特地开荒了和煦的MySQL复制工具,能够一本万利的实时同步MySQL中的数据到Redis上。

图片 6

(MySQL-Redis 异构读写分离)

总结:

  • Redis的复制由于会利用快速照僵长久化方式,所以假设你的Redis长久化格局选用的是日记追加方式(aof),那么系统有异常的大希望在同一时刻既做aof日志文件的同步刷写磁盘,又做快速照相写磁盘操作,这一年Redis的响应技巧会师对震慑。所以假设选用aof悠久化,则加从库需求进一步严峻。
  • 能够利用主动复制和presharding方法实行Redis集群搭建与在线扩大体量。

 

 

[置顶] 基于redis分布式缓存达成

分类: 遍布式相关2012-11-17
20:59 11259人阅读 评论(24) 收藏 举报

简单表明下,写此文章终于对自个儿近一段专门的学问的总结,希望能对你有一点点扶持,同期也是友好的一点小积攒。

一.为何选择redis

在品种中利用redis做为缓存,还从未选拔memcache,思量要素至关心器重要有两点:

1.redis抬高的数据结构,其hash,list,set以及功用丰盛的String的援救,对于实际项目中的使用有异常的大的增派。(可参看官方网址redis.io)

2.redis单点的属性也十一分飞速(利用项目中的数据测试优于memcache).

据他们说上述想念,由此采纳了redis来做为缓存应用。

二.遍布式缓存的架构设计

1.架构划虚构计

鉴于redis是单点,项目中必要动用,必须团结完成分布式。基本架构图如下所示:

图片 7

2.分布式完毕

由此key做一致性哈希,达成key对应redis结点的遍布。

一致性哈希的贯彻:

l        hash值总结:通过支撑MD5与MurmurHash二种总计办法,暗中认可是接纳MurmurHash,高效的hash计算。

l        一致性的兑现:通过Java的TreeMap来模拟环状结构,完成均匀遍布

3.client的选择

对于jedis修改的重大是分区模块的改变,使其扶助了跟据BufferKey进行分区,跟据区别的redis结点信息,能够初阶化差异的ShardInfo,同一时候也修改了JedisPool的平底完毕,使其三番五次pool池援助跟据key,value的构造方法,跟据区别ShardInfos,成立不一样的jedis连接客户端,达到分区的功效,供应用层调用

4.模块的辨证

l        脏数据管理模块,管理战败施行的缓存操作。

l        屏蔽监控模块,对于jedis操作的异常监察和控制,当某结点出现万分可决定redis结点的切成条等操作。

全方位布满式模块通过hornetq,来切除卓殊redis结点。对于新结点的扩大,也能够透过reload方法实现扩大。(此模块对于新扩张结点也得以很有益完成)

对此上述遍布式架构的兑现满意了项指标须要。别的利用中对于部分相比首要用途的缓存数据能够独自设置有些redis结点,设定特定的先行级。别的对于缓存接口的安排,也足以跟据要求,实现核心接口与部分新鲜逻辑接口。对于cas相关操作,以及一些东西操作能够通过其watch机制来兑现。(参照他事他说加以考察笔者原先写的redis事物介绍)

上述是基于redis遍布式架构的牵线!然而使用中读写都以在联合的。相关写是在接纳操作后flush只怕update的,有一定的耦合。为了使读写分离,以及缓存模块跟应用的耦合更加小,考虑选取mysql
binlog来刷新缓存。以下是基于binlog刷新可性行解析以及落到实处进程中需求专注的地方。

三.采纳binlog架构刷新缓存可行性深入分析

1.Mysql日志格式介绍可参看笔者从前的的牵线。

2.对此利用MIXED日志格式,此日志格式,记录的是对应数据库操作的SQL语句,采纳此日志情势存在的标题:

l        对于有个别未任何更新操作的SQl语句,像条件不满足,对应的sql也会记录到binlog日志中。

l        SQL语句记录的不一定包涵全体的立异操作。

l        对于有些布满式数据库,对于SQL中的where条件钦命的长短均衡字段,恐怕会设有多条SQL,跟设计有关!

听别人说上述考虑,采纳MIXED的日志格式实行binlog深入分析是无用的。(官方网站给出的提示是failed
statementsare not logged
,但不富含语法没有错误,更新标准不合乎相应的SQL)

3.应用ROW日志格式

对此此日志格式,每行变化都有对应的记录,此日志格式,对于深入分析及搜聚数据都是充足有助于的,也唯有利用此日志格式,手艺基于binlog修改,做刷新缓存相关方案的筹算。不过依附此日志格式也设有部分标题:

l        要求考虑项目中是或不是有恢宏的批量的update操作,借使运用此日志格式,批量操作每一行修改都会记录一条日志,多量的批量操作所发生的日志量,以及所拉动的IO开支是不是足以承受。

透过以上深入分析,最后项目中可能惦念基于ROW日志格式实行缓存刷新,还只怕有二个标题亟需思虑,在使用层DB举办了对应的update操作后,所发出的Binlog是会推动一定的延期,借使Binlog管理模块符合规律运营,数据是的延迟会比非常少,MS品级以内,对用户体验是从未有过感知的,可是Binlog模块是多点,非常,以及对应的延期料定会是存在的,那样,缓存数据显著会存在脏数据。

但是经过以上方案,数据能达到最后一致性,由此how
to权衡,需求思索。

 通过以上深入分析,是不是使用Binlog来做缓存数据刷新相信大家有八个基本概念了

四.基于binlog刷新缓存的实现时注意的地点

1.只借使应用java做连锁支出,能够使用开源的tungstenAPI

2.Binlog日志分析是依据mysql
的master/slave同步流程来落到实处,即八个线程同步,叁个线程深入分析。

3.设计是可分Binlog管理模块以及缓存管理Sql伊夫nt两片段,个中Binlog管理分析好相应的SqlEvent,然后对应的缓存刷新拍卖SqlEvent,三个轻松的生产者-花费者格局。

4.对此多个Binlog管理模块能够是单点,也得以是通过有些体协会助实行工具来治本,看供给。可以应用ZooKeeper等。

5.对此分布式缓存中的数据,对于Binlog来刷新的缓存数据会存在load数据的主题素材,为了缓解DB的附加压力,flush操作可在get缓存数据处完结。看须求,借使读写完全分享的话此DB的附加压力足以收到的话也会有效。

6.对此缓存数据性一致性须要比较高的,能够通过版本号来支配,即在应用层引进一定的耦合,在DB操作时带mark
,缓存刷新是也mark,另外get操作时相比双版本号来达成数据的一致性。(此跟5斟酌的一定的关系,读写是还是不是完全分开,以及对应一致性完成的一部分格局)

五.一点心得

起讫,对redis达成调查研商,以及有关的一部分接纳,遍布式缓存的贯彻,基于binlog格局的修改等,接触有一年多了,这段时光下来,学了多数,以上算是一点小记,那部分干活的一点小记。落成进度中设有更加的多的主题材料。

对此应用研讨相关的一些工作,应当要做的明细,相应的细节一定要打听透顶,不然或许一此没不通常会促成整个方案的不可行,以致越来越大的的主题材料。连锁反应!

接下去一时间会写一篇有关BloomFilter的的篇章
,以及D-Left_BloomFilter,在此证实,只为本身有更加大的引力去做到它。项目中落到实处了D-Left_BloomFilter,但在互连网未有有关落到实处,在对其优化后,会在博文上做一些非常小的笔录。

上述假若有如何窘迫的地方请指正,有什么有关难点也能够跟自家交流,能够同步沟通学习!

相关文章

Leave a Reply

电子邮件地址不会被公开。 必填项已用*标注