Redis 主从复制的原理、断点续传、哨兵工作原理及哨兵主备切换的数据丢失问题（异步复制、集群脑裂）

1、Redis replication基本原理

（1）复制的过程步骤

1. 从节点保存主节点的信息，redis.conf里面的slaveof配置的主节点的信息，并没有立即发起复制
2. 从节点通过定时任务，每秒检查是否有新的master node要连接和复制，如果发现，就跟master node建立socket网络连接、
3. slave node发送ping命令给master node
4. 口令认证，如果master设置了requirepass，那么salve node必须发送masterauth的口令过去进行认证
5. master node第一次执行全量复制，master node在生成rdb时，会将所有新的写命令缓存在内存中，将所有数据发给slave node
6. slave node接收到rdb之后，清空自己的旧数据，然后重新加载rdb到自己的内存
7. 当主节点把当前的数据同步给从节点后，便完成了复制的建立流程。接下来，主节点就会持续的把写命令异步复制发送给从节点，保证主从数据一致性。

（2）主从复制断点续传 

支持主从复制的断点续传，如果主从复制过程中，网络连接断掉了，那么可以接着上次复制的地方，继续复制下去，而不是从头开始复制一份。Master Node会在内存中建一个backlog，master和slave都会保存一个replication offset还有一个master id，offset就是保存在backlog中的。如果master和slave网络连接断掉了，slave会让master从上次的replication offset开始继续复制。

（3）无磁盘化复制

master在内存中直接创建rdb，然后发送给slave，不会在自己本地落地磁盘了

repl-diskless-sync no(默认没有开启)

repl-diskless-sync-delay，等待一定时长再开始复制，因为要等更多slave重新连接过来

2、数据同步相关的核心机制

指的就是第一次slave连接msater的时候，执行的全量复制，那个过程里面你的一些细节的机制

（1）master和slave都会维护一个offset

master会在自身不断累加offset，slave也会在自身不断累加offset

slave每秒都会上报自己的offset给master，同时master也会保存每个slave的offset

这个倒不是说特定就用在全量复制的，主要是master和slave都要知道各自的数据的offset，才能知道互相之间的数据不一致的情况

（2）backlog

master node有一个backlog，默认是1MB大小

master node给slave node复制数据时，也会将数据在backlog中同步写一份

backlog主要是用来做全量复制中断的增量复制

（3）master run id

info server，可以看到master run id

如果根据host+ip定位master node，是不靠谱的，如果master node重启或者数据出现了变化，那么slave node应该根据不同的run id区分，run id不同就做全量复制

如果需要不更改run id重启redis，可以使用redis-cli debug reload命令

（4）psync

Slave节点使用psync从master node进行复制，psync (runid +offset)

master node会根据自身的情况返回响应信息，可能是FULLRESYNC runid offset触发全量复制，可能是CONTINUE触发增量复制

3、哨兵工作原理

主要功能：三个定时监控任务完成对各个节点发现和监控：

（1）集群监控，负责监控redis master和slave进程是否正常工作

每隔10秒，每个Sentinel节点会向主节点和从节点发送info命令获取最新的拓扑结构。

 

定时执行info命令

每隔2秒，每个Sentinel节点会向Redis数据节点的sentinel频道上发送该Sentinel节点对于主节点的判断以及当前Sentinel节点的信息

每隔1秒，每个Sentinel节点会向主节点、从节点、其余Sentinel节点发送一条ping命令做一次心跳检测，来确认这些节点当前是否可达

（2）消息通知，如果某个redis实例有故障，那么哨兵负责发送消息作为报警

（3）故障转移，如果master node挂掉了，会自动转移到slave node上

（4）配置中心，如果故障转移发生了，通知client客户端新的master地址

哨兵的核心知识：

（1）哨兵至少需要3个实例，来保证自己的健壮性

（2）哨兵 + redis主从的部署架构，是不会保证数据零丢失的，只能保证redis集群的高可用性

（3）对于哨兵 + redis主从这种复杂的部署架构，尽量在测试环境和生产环境，都进行充足的测试和演练

 

4、哨兵主备切换的数据丢失问题：异步复制、集群脑裂

 

在主的数据异步复制情况下，主节点宕机，从节点根据哨兵监控，从节点更改为Master,数据丢失
（

联想MySQL复制，主机宕机的解决方案:

 问：

Mysql主从复制丢失通过什么来解决？？？对比学习

  答：

半同步复制，也叫 semi-sync 复制，指的就是主库写入 binlog 日志之后，就会将强制此时立即将数据同步到从库，从库将日志写入自己本地的 relay log 之后，接着会返回一个 ack 给主库，主库接收到至少一个从库的 ack 之后才会认为写操作完成了

）

集群脑裂：

由于网络故障，Slave node与Sentinal Cluster在一个网络环境故障分区，Master node在另一个分区，就会存在两个相同的Master主节点。

 

 

min-slaves-to-write 1：

要求至少有1个slave，数据复制和同步的延迟不能超过10秒

min-slaves-max-lag 10：

如果说一旦所有的slave，数据复制和同步的延迟都超过了10秒钟，那么这个时候，master就不会再接收任何请求了

上面两个配置可以减少异步复制和脑裂导致的数据丢失