riserdb存储介绍(二)主从复制

汪雨田,现就职于暴风影音，负责后端的研发工作，平时专注于nosql，分布式的研究，热爱传统文化以及中医学, 热爱工作在代码的田间地头。

1. 主从复制
   对于一个存储系统来说，数据存在多个副本的功能应该是必须提供的，数据的安全性，扩展性，读写分离都是有好处。

2. riser主从复制简述
   在2015年6月份的时候我就已经开发完成了riser的主从主体功能，但是没经过大量的数据实践和验证，还不成熟还算不上真正的产品，都已经过去一年时间了，由于公司有个业务需要支持主从复制来跨机房的多台服务器读数据，所以我硬着头皮开始琢磨着riser的主从功能，大量数据的测试后，bug一个接一个的出现，经过几个星期的主从复制大量数据测试和bug修复，现在终于稳定了，各种内存泄漏等问题，搞得焦头乱耳，在这首先得谢谢婷婷同学一起帮忙修复bug。现已经在公司的大量数据下，主从复制稳定运行1个多月了。

3. riser主从复制配置
   riser主从复制配置比较简单，只用在riser的从服务器端的配置文件中，增加2行配置项：
   slaveof_ip=127.0.0.1 //主服务器的IP地址
   slaveof_port=3555 //主服务器的端口号
   slave_sync_all=true //true:同步所有数据,false:只同步现在的增量
   master_auth=xxxxxx //主从同步认证

4. 复制过程
   1). slave端启动时候，检查配置文件的slaveof_ip和slaveof_port配置项，如果二项目已经打开，slave会启动一个复制线程，复制线程会主动connect到master服务器；

   2). 如链接成功，slave会发送自己的ID号(在安装时生成一个唯一ID)到master服务，master会检查该slave认证情况，和注册情况，如没注册，会给slave启动一个数据队列。如果slave_sync_all=true，master会加载所有的数据到该slave的队列中，如果一切就绪，开始从队列中取得数据，传给slave端；

   3). 在传递每项数据时，会给该数据项打上正在同步给slave的标记，一旦同步到slave后，slave会发一条ack消息，确定成功或失败情况，如成功，会把同步的数据从队列中清除掉;

   4). 经过（3）数据的不断传递后，数据会同步完成，完成后，slave是不知道已经完成，这时候slave会主动向master要数据，master发现没数据，为了减少网络开销，master暂时hold住slave的链接，一旦有了数据，master会把数据发送给从；

5. 增量同步
   master会记录每个slave的同步时间和对应slave的队列写入时间，一旦master有重启，只要slave的同步时间和对应slave的队列写入时间一致，就不会进行全量同步；如果是slave服务重启，增量队列还是存在的，所以slave一旦启动还会是从增量队列中取得数据；

6. 查看同步情况
   在master的命令行中用 info rep命令查看
   
   其中参数含义：
   name:slave的name，唯一标识,
   ip: slave的IP地址,
   start:slave开始链接时间
   last:最后一次同步时间
   status:当前同步状态
   need_sync: 需要同步数量

7. 清除队列的命令

   如果一个slave不需要，这个时候master还保留着该slave的队列，为了不浪费内存，需要把该slave从master中摘除掉，需要用到： slave name clear
   如： slave BFG-OSER-2387-1471315241_6385 clear

8. master/slave同步原理

   为了不影响数据的写入和读取的性能，master会启动一个单独线程来处理slave的同步复制，一旦有slave有请求，主线程会把slave的该请求转交给同步复制线程,每次同步实际的命令为mset，相当于可以同步多条；

   slave端也会接受完成，回复ok。slave端启动的复制线程会每隔1秒钟检查当前slave同步的状态，状态包括: init:初始化,auth:认证阶段,wait:等待master回复,transmit：数据传输。

9. 总结
   代码还有些乱，需要重构，底层库leveldb还存在一些不足的地方，需要好的库来替换，发现rockdb有存在环境兼容问题。需要进一步研究。这次主要是总结一下我独特设计的主从同步的实现方式，和redis主从同步差别很大。