数据库层面上，我们一般使用redis + MySQL比较多，主从复制在项目或网站设计中都是比较成熟的方案，所以了解其基本原理还是很有必要的。
下面我们首先来看下redis的主从复制。
redis主从复制的具体流程如下。
1）若启动一个Slave机器进程，则它会向Master机器发送一个“sync command”命令，请求同步连接。
2）无论是第一次连接还是重新连接，Master机器都会启动一个后台进程，将数据快照保存到数据文件中（执行rdb操作），同时Master还会记录修改数据的所有命令并缓存在数据文件中。
3）后台进程完成缓存操作之后，Maste机器就会向Slave机器发送数据文件，Slave端机器将数据文件保存到硬盘上，然后将其加载到内存中，接着Master机器就会将修改数据的所有操作一并发送给Slave端机器。若Slave出现故障导致宕机，则恢复正常后会自动重新连接。
4）Master机器收到Slave端机器的连接后，将其完整的数据文件发送给Slave端机器，如果Mater同时收到多个Slave发来的同步请求，则Master会在后台启动一个进程以保存数据文件，然后将其发送给所有的Slave端机器，确保所有的Slave端机器都正常。
支持断点续传吗？
从redis 2.8开始，如果在主从复制过程中遭遇连接断开，则重新连接之后可以从中断处继续进行复制，而不必重新同步。
断点续传的工作原理具体如下。
主服务器端为复制流维护一个内存缓冲区（in-memory backlog）。主从服务器都维护一个复制偏移量（replication offset）和master run id。当连接断开时，从服务器会重新连接上主服务器，然后请求继续复制，假如主从服务器的两个master run id相同，并且指定的偏移量在内存缓冲区中还有效，则复制就会从上次中断的点开始继续。如果其中一个条件不满足，就会进行完全重新同步（在2.8版本之前就是直接进行完全重新同步）。
因为主运行id不保存在磁盘中，因此如果从服务器重启了的话就只能进行完全同步了。
对于部分重新同步这个新特性，redis 2.8版本内部使用PSYNC命令，旧版本的实现中使用的是SYNC命令。redis2.8版本可以检测出它所连接的服务器是否支持PSYNC命令，若不支持则使用SYNC命令。
redis主从复制的效果是很不错的，在很多跨机房的业务中其稳定性也很不错。另外，如果业务需要采用redis集群的话，则生产环境下不建议使用redis-cluster，建议采用codis、zookeeper来保证各节点之间的数据一致性。
网友评论