主从复制的概念

redis为了实现?可?（?如解决单点故障的问题），会把数据复制多个副本部署到其他节点上，通过复制，实现Redis的?可?性，实现对数据的冗余备份，保证数据和服务的可靠性。?如：

如何配置的：

• 配置?件： 在从服务器的配置?件中加?：slaveof
• 启动命令： redis-server启动命令后加? --slaveof
• 客户端命令： Redis服务器启动后，直接通过客户端执?命令：slaveof ，则该Redis实例成为从节点
• PS : 通过 info replication 命令可以看到复制的?些信息

文章福利：现在C++程序员面临的竞争压力越来越大。那么，作为一名C++程序员，怎样努力才能快速成长为一名高级的程序员或者架构师，或者说一名优秀的高级工程师或架构师应该有怎样的技术知识体系，这不仅是一个刚刚踏入职场的初级程序员，也是工作三五年之后开始迷茫的老程序员，都必须要面对和想明白的问题。为了帮助大家少走弯路，技术要做到知其然还要知其所以然。以下redis以及C/C++服务器高级架构相关视频获取私信免费领取

主从复制的作?

• 数据冗余：主从复制实现了数据的热备份，是持久化之外的?种数据冗余?式。
• 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是?种服务的冗余。
• 负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应?连接主节点，读Redis数据时应?连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以??提?Redis服务器的并发量。
• 读写分离：可以?于实现读写分离，主库写、从库读，读写分离不仅可以提?服务器的负载能?，同时可根据需求的变化，改变从库的数量；
• ?可?基?：除了上述作?以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis?可?的基础。

主从复制的机制

Redis的主从复制功能除了?持?个Master节点对应多个Slave节点的同时进?复制外，还?持Slave节点向其它多个Slave节点进?复制。这样就使得架构师能够灵活组织业务缓存数据的传播，例如使?多个Slave作为数据读取服务的同时，专门使??个Slave节点为流式分析?具服务。Redis的主从复制功能分为两种数据同步模式进?：全量数据同步和增量数据同步。

• 全量数据同步（full resyncchrozation）

先执??次全同步 — 请求master BgSave出??的?个RDB Snapshot?件发给slave，slave接收完毕后，清除掉??的旧数据，然后将RDB载?内存。

上图简要说明了Redis中Master节点到Slave节点的全量数据同步过程。当Slave节点给定的replication id和Master的replication id不?致时，或者Slave给定的上?次增量同步的offset的位置在Master的环形内存内(replication backlog)?法定位时（后?会提到），Master就会对Slave发起全量同步操作。这时?论您是否在Master打开了RDB快照功能，它和Slave节点的每?次全量同步操作过程都会更新/创建Master上的RDB?件。在Slave连接到Master，并完成第?次全量数据同步后，接下来Master到Slave的数据同步过程?般就是增量同步形式了（也称为部分同步）。增量同步过程不再主要依赖RDB?件，Master会将新产?的数据变化操作存放在replication backlog这个内存缓存区，这个内存区域是?个环形缓冲区，也就是说是?个FIFO的队列。

• 增量同步

进?增量同步 — master作为?个普通的client连?slave，将所有写操作转发给slave，没有特殊的同步协议。具体过程如下：

为什么在Master上新增的数据除了根据Master节点上RDB或者AOF的设置进??志?件更新外，还会同时将数据变化写??个环形内存结构（replication backlog），并以后者为依据进?Slave节点的增量更新呢？主要原因有以下?个：

1. 由于?络环境的不稳定，?络抖动/延迟都可能造成Slave和Master暂时断开连接，这种情况要远远多于新的Slave连接到Master的情况。如果以上所有情况都使?全量更新，就会??增加Master的负载压?——写RDB?件是有?量I/O过程的，虽然Linux Page Cahe特性会减少性能消耗。
2. 另外在数据量达到?定规模的情况下，使?全量更新进?和Slave的第?次同步是?个不得已的选择——因为要尽快减少Slave节点和Master节点的数据差异。所以只能占?Master节点的资源和?络带宽资源。
3. 使?内存记录数据增量操作，可以有效减少Master节点在这??付出的I/O代价。?做成环形内存的原因，是为了保证在满?数据记录需求的情况下尽可能减少内存的占?量。这个环形内存的??，可以通过repl-backlog-size参数进?设置。

Slave重连后会向Master发送之前接收到的Master replication id信息和上?次完成部分同步的offset的位置信息。如果Master能够确定这个replication id和??的replication id(有两个)?致且能够在环形内存中找到这个offset的位置，Master就会发送从offset的位置开始向Slave发送增量数据。那么连接正常的各个Slave节点如何接受新数据呢？连接正常的Slave节点将会在Master节点将数据写?环形内存后，主动接收到来?Master的数据复制信息。

这?就有?个问题了，我们的replication backlog的size设置为多?合适？

redis为replication backlog设置的默认??为1M（repl-backlog-size），但是这个值是可以调整的， 如果主服务器需要执??量的写命令，?或者主从服务器之间断线后重连的时间?较?，那么这个??也许并不合适。如果replication backlog的??设置不恰当，那么PSYNC命令的复制同步模式就不能正常发挥作?，因此，正确估算和设置replication backlog的size?常重要。

reconnect_time_second * write_size_per_second*2

reconnect_time_second : 重连时间，以秒为单位

write_size_per_second : 每秒写?的命令??

主从复制的实现

先来看?段log：

上?的log是我在从机器上输?slaveof 192.168.1.127 6379后，master机器上的?段?志。下?这段是slava机器上的log

?先，在redis内部，所有的命令都维护在?张表格?：

PS：当然所有的这些command，在启动的时候会调?populateCommandTable函数进?分析，然后把所有的redis command放在server.commands，它是?个字典。

dict commands; / Command table */

当我们在客户端执?slaveof 的，在客户端这?侧会调?replicaofCommand这个函数。

• 主从关系的建?

主从复制建?的?式有三种：

1. 在redis.conf?件中配置slaveof 选项，然后指定该配置?件启动Redis?效。
2. 在redis-server启动命令后加上--slaveof 启动?效。
3. 直接使? slaveof 命令在从节点执??效。

?论是通过哪?种?式来建?主从复制，都是从节点来执?slaveof命令，那么从节点执?了这个命令到底做了什么，我们上源码：

?SLAVEOF命令做的操作并不多，主要以下三步：

1. 判断当前环境是否在集群模式下，因为集群模式下不?执?该命令。
2. 是否执?的是SLAVEOF NO ONE命令，该命令会断开主从的关系，设置当前节点为主节点服务器。
3. 设置从节点所属主节点的IP和port。调?了replicationSetMaster()函数。

由代码知，replicationSetMaster()函数执?操作的也很简单，总结为两步：

1. 清理之前所属的主节点的信息。
2. 设置新的主节点IP和port等。 因为，当前从节点有可能之前从属于另外的?个主节点服务器，因此要清理所有关于之前主节点的缓存、关闭旧的连接等等。然后设置该从节点的新主节点，设置了IP和port，还设置了以下状态：

// 设置复制必须重新连接主节点的状态 server.repl_state = REPL_STATE_CONNECT; // 初始化全局复制的偏移量 server.master_repl_offset = 0;

slaveof命令是?个异步命令，执?命令时，从节点保存主节点的信息，确?主从关系后就会?即返回，后续的复制流程在节点内部异步执?。那么，如何触发复制的执?呢？

周期性执?的函数：replicationCron()函数，该函数被服务器的时间事件的回调函数serverCron()所调

?，?serverCron()函数在Redis服务器初始化时，被设置为时间事件的处理函数。

replicationCron这个函数每秒才执??次，以下代码执?到serverCron函数的实现：

主从关系建?后，从节点服务器的server.repl_state被设置为REPL_STATE_CONNECT，? replicationCron()函数会被每秒执??次，该函数会发现我（从节点）现在有主节点了，?且我要的状态是要连接主节点（REPL_STATE_CONNECT）。

replicationCron()函数处理这一情况的代码如下：

replicationCron()函数根据从节点的状态，调?connectWithMaster()?阻塞连接主节点。代码如下：

connectWithMaster()函数执?的操作可以总结为：

根据IP和port?阻塞的?式连接主节点，得到主从节点进?通信的?件描述符fd，并保存到从节点服务器server.repl_transfer_s中，并且将刚才的REPL_STATE_CONNECT状态设置为REPL_STATE_CONNECTING。 监听fd的可读和可写事件，并且设置事件发?的处理程序syncWithMaster()函数。 ?此，主从?络建?就完成了，逐步进?了协商交互阶段，使?的是状态机处理的，详见syncWithMaster函数的处理，这些状态机的定义如下：

就不再那么啰嗦了，我们主要关注以下点：

1. 在PSYNC阶段之前，master主节点都是调?replconfCommand去处理的
2. 收到PSYNC命令时，调?syncCommand函数去处理。