高可用-主从同步
主从同步分为 2 个步骤：同步和命令传播
主从复制原理
首先，Redis 的复制分为 同步 (sync) 和 **命令传播 **(command propagate) 两个操作：
同步（rdb全量同步）
一般用做新从节点加入集群时的首次数据同步
从服务器向主服务器发送
sync命令收到
sync命令后，主服务器执行bgsave命令，用来生成rdb文件bgsave执行完成后，将生成的rdb文件发送给从服务器，用来给从服务器更新数据发送
rdb文件、从库重放rdb文件都比较耗时。因此期间，主节点需要在一个缓冲区中记录从现在开始执行的写命令。复制积压缓冲区是一个固定长度、先进先出的队列，默认
1MB，大小可配置。如果缓冲区溢出，将导致同步中断。
主服务器再将缓冲区记录的写命令发送给从服务器，从服务器执行完这些写命令后，此时的数据库状态便和主服务器一致了。
bgsave会耗 CPU、内存、磁盘，发给从节点会耗费网络。发送期间，从节点不可用。
命令传播
主服向从发送写命令（推）
这个其实是上面 同步 部分的第4步。首次数据同步完成后，对后续增量命令的同步，就叫命令传播。
在客户端发来写命令后，Redis 采用的是 ANY/ONE 的做法， 只要 master 处理完该请求，就立马返回客户端，不会等待从节点响应。而是异步的把这些命令转发给所有的 slave 节点。（因此 Redis 是 AP 只保证高可用性的，因为主挂掉后从升主，这个从可能少数据）
转发的过程中可能因为网络问题导致数据丢失。于是 Redis 的 master 节点在内存中开辟一个默认大小为 1M 的环形缓冲区。在转发给 slave 节点用户请求的同时把该请求写入环形缓冲区。每个 slave 节点接收到一个命令之后会自增 repl_offset 值用来记录复制偏移量。同时 master 节点也会记录当前缓冲区的最新命令的 repl_offset。salve 节点会定期的向 master 节点发送心跳命令，告知其偏移量，请求同步复制，master 节点会检查 slave 节点的复制偏移量是否在当前 master 节点的缓冲区中，如果在则从缓冲区中发送命令，否则触发全量复制。
断线重连
2.8 之前，重连会直接全量重新同步数据
2.8 开始，用
psync代替sync，以实现同步进度检查，以及部分同步。向主服务器发送
PSYNC [主服务器ID] [上次复制偏移量]如果从节点最近的复制偏移量在这个缓冲区里，就从复制偏移量之后开始同步
否则还是全量同步
Run id
在进行初次复制时，主服务器将会将自己的运行 id 发送给从服务器，让其保存起来。
当从服务器断线重连后，从服务器会将这个运行 id 发送给刚连接上的主服务器。
若当前服务器的运行 id 与之相同，说明从服务器断线前复制的服务器就是当前服务器，主服务器可以尝试执行部分同步；若不同则说明从服务器断线前复制的服务器不是当前服务器，主服务器直接执行完整重同步。
心跳
完成了同步之后，主从服务器就会进入命令传播阶段，此时从服务器会以每秒 1 次的频率，向主服务器发送命令：REPLCONF ACK <replication_offset> 。其中 replication_offset 是从服务器当前的复制偏移量
发送这个命令主要有三个作用：
检测主从服务器的网络状态
辅助实现 min-slaves 选项
上报自身的复制偏移量
min-slaves 选项
redis的配置文件中，存在两个参数：
如果从节点与主节点的最后交互时间，距离当前时间小于 min-slaves-max-lag 的值，则认为该从节点状态是连接的。
主节点定期统计连接状态的从节点数目，如果该数目小于 min-slaves-to-write 的值，则主节点会拒绝执行写数据库的命令，类似于 kafka 里 ISR 的概念。
min-slaves-to-write 3 // 要求保持同步状态的 slave 数量
min-slaves-max-lag 10 // slave 连接到 master 的最大延迟时间，超过这个时间视为失去连接按照上面的配置，要求至少3个 slave 节点保持连接，数据同步的延迟不能超过10秒，否则 master 就会拒绝写请求。
参考
袁秀龙 - Raft协议(1)——Raft协议与Redis集群中的一致性协议的异同
Last updated