深入剖析 redis 主从复制.docxVIP

主从概述redis 支持 master-slave（主从）模式，redis server 可以设置为另一个 redis server 的主机（从机），从机定期从主机拿数据。特殊的，一个从机同样可以设置为一个 redis server 的主机，这样一来 master-slave 的分布看起来就是一个有向无环图 DAG，如此形成 redis server 集群，无论是主机还是从机都是 redis server，都可以提供服务）。在配置后，主机可负责读写服务，从机只负责读。redis 提高这种配置方式，为的是让其支持数据的弱一致性，即最终一致性。在业务中，选择强一致性还是若已执行，应该取决于具体的业务需求，像微博，完全可以使用弱一致性模型；像淘宝，可以选用强一致性模型。redis 主从复制的实现主要在 replication.c 中。这篇文章涉及较多的代码，但我已经尽量删繁就简，达到能说明问题本质。为了保留代码的原生性并让读者能够阅读原生代码的注释，剖析 redis 的几篇文章都没有删除代码中的英文注释，并已加注释。积压空间在《深入剖析 redis AOF 持久化策略》中，介绍了更新缓存的概念，举一个例子：客户端发来命令：set name Jhon，这一数据更新被记录为：*3rn$3rnSETrn$4rnnamern$3rnJhonrn，并存储在更新缓存中。同样，在主从连接中，也有更新缓存的概念。只是两者的用途不一样，前者被写入本地，后者被写入从机，这里我们把它成为积压空间。更新缓存存储在 server.repl_backlog，redis 将其作为一个环形空间来处理，这样做节省了空间，避免内存再分配的情况。struct?redisServer?{????/*?Replication?(master)?*/????//?最近一次使用（访问）的数据集????int?slaveseldb;?????????????????/*?Last?SELECTed?DB?in?replication?output?*/????//?全局的数据同步偏移量????long?long?master_repl_offset;???/*?Global?replication?offset?*/????//?主从连接心跳频率????int?repl_ping_slave_period;?????/*?Master?pings?the?slave?every?N?seconds?*/????//?积压空间指针????char?*repl_backlog;?????????????/*?Replication?backlog?for?partial?syncs?*/????//?积压空间大小????long?long?repl_backlog_size;????/*?Backlog?circular?buffer?size?*/????//?积压空间中写入的新数据的大小????long?long?repl_backlog_histlen;?/*?Backlog?actual?data?length?*/????//?下一次向积压空间写入数据的起始位置????long?long?repl_backlog_idx;?????/*?Backlog?circular?buffer?current?offset?*/????//?积压数据的起始位置，是一个宏观值????long?long?repl_backlog_off;?????/*?Replication?offset?of?first?byte?in?the???????????????????????????????????????backlog?buffer.?*/????//?积压空间有效时间????time_t?repl_backlog_time_limit;?/*?Time?without?slaves?after?the?backlog???????????????????????????????????????gets?released.?*/}积压空间中的数据变更记录是什么时候被写入的？在执行一个 redis 命令的时候，如果存在数据的修改（写），那么就会把变更记录传播。redis 源码中是这么实现的：call()-propagate()-replicationFeedSlaves()注释：命令真正执行的地方在 call() 中，call() 如果发现数据被修改（dirty），则传播 propagrate()，replicationFeedSlaves() 将修改记录写入积压空间和所有已连接的从机。这里可能会有疑问：为什么把数据添加入积压空间，又把数据分发给所有的从机？为什么不仅仅将数据分发给所有从