redis 高可用

主从模式

全量更新
1.主从复制期间的写操作写入replication buffer，如何避免缓冲区耗尽内存影响redis的稳定性
（1）对写操作限流，避免写操作过多耗尽内存
（2）使用高可用方案，主节点有故障及时切换到从节点
（3）全量复制和增量复制相结合，减少同步时间和带宽使用
（4）如果增量更新从节点请求的offset不在主节点的环形缓冲区，就会全量更新

分摊主服务器压力
生成和传输rdb文件是耗时的，从服务器也可以同步数据给从服务器来分担压力。

增量更新

2.增量更新触发的原因是什么？
主从服务器的网络连接断开，无法进行基于长链接的命令传播。

2.全量同步后，客户端的写操作都是写入环形缓冲区repl backlog buffer吗？
是的，基于长链接传播的同时也会写入repl backlog buffer

主从数据不一致
1.为什么会出现？
主从之间的命令复制是异步进行的。主节点并没有等从节点执行完命令后在把结果返回给客户端。这一点和kafka不同。
2.主从节点的数据不是强一致的，这个问题怎么解决？
监控master_repl_offset和slace_repl_offset之间的差值，让客户端不从同步进度差距大的节点读取数据。

主从切换数据损失
1.异步复制同步丢失
客户端的写请求，主节点会先回复客户端再异步同步。如果主节点还没来得及同步就断电，主节点内存数据就丢失了。
减少异步复制数据丢失的办法：
（1）设置min-slaves-max-lag。主从同步延迟时间超过10秒，就拒接新写请求。这个值是怎么算出来的TODO
（2）客户端发现不可写后进行降级，写入客户端内存或者磁盘。也可以发消息到kafka，master正常后再恢复数据到master。
只是能减少异步复制数据丢失。鉴于redis作用时缓存，我认为是可以接受的。
2.脑裂问题
由于网络问题，哨兵认为主节点下线了，选了一个新的主节点，而客户端认为旧主节点是正常的，还在写数据，并且旧主节点和所有从节点网络也不通，无法同步数据到从节点；当网络正常后，旧主节点会降级为从节点，第一次同步是全量同步，会清空内存数据，数据就丢失了。

解决办法：
当主节点发现下线的数量太多或者网络延迟太大时，禁止写操作，直接返回错误给客户端。
min-slaves-to-write x，主节点必须要有至少 x 个从节点连接，如果小于这个数，主节点会禁止写数据
min-slaves-max-lag x，主从数据复制和同步的延迟不能超过 x 秒，如果主从同步的延迟超过 x 秒，主节点会禁止写数据

这两个配置项组合后的要求是，主节点连接的从节点中至少有 N 个从节点，「并且」主节点进行数据复制时的 ACK 消息延迟不能超过 T 秒，否则，主节点就不会再接收客户端的写请求了。

即使原主节点是假故障，它在假故障期间也无法响应哨兵心跳，也不能和从节点进行同步，自然也就无法和从节点进行 ACK 确认了。这样一来，min-slaves-to-write 和 min-slaves-max-lag 的组合要求就无法得到满足，原主节点就会被限制接收客户端写请求，客户端也就不能在原主节点中写入新数据了。旧的数据还是会丢失。

等到新主节点上线时，就只有新主节点能接收和处理客户端请求，此时，新写的数据会被直接写到新主节点中。而原主节点会被哨兵降为从节点，即使它的数据被清空了，也不会有新数据丢失。我再来给你举个例子。

故障转移问题
主节点挂了，从节点无法自动升级为主节点，需要人工介入。
哨兵模式发现主节点有故障，会自动完成故障发现和故障转移，并通知应用方。

哨兵模式

为什么需要哨兵
主从模式下，主节点挂了，导致写不可用。要恢复的话需要人工介入，让其他从节点指向主节点，并通知客户端将配置中的主节点ip更新为新的主节点ip。
哨兵在主节点故障时选一个从节点切换为主节点，并通知响应信息给从节点和客户端。

哨兵机制如何工作

哨兵节点是如何监控节点的？又是如何判断主节点是否真的故障了？
哨兵的赞同票数达到哨兵配置文件中的 quorum 配置项设定的值后，这时主节点就会被该哨兵标记为「客观下线」

1.为什么需要多个哨兵？
避免单个哨兵因为自身网络不好导致误判主节点下线的情况。

2.什么情况下进行哨兵的选举？
将主节点标记为客观下线的哨兵节点会成为哨兵leader候选者，发起leader选举。
选举成功的条件：
第一，拿到半数以上的赞成票；
第二，拿到的票数同时还需要大于等于哨兵配置文件中的 quorum 值。

3.有多个哨兵判断主节点客观下线怎么办？
假设有三个候选者ABC。每位候选者都会先给自己投一票，然后向其他哨兵发起投票请求。如果投票者先收到「候选者 A」的投票请求，就会先投票给它，如果投票者用完投票机会后，收到「候选者 B」的投票请求后，就会拒绝投票。这时，候选者 A 先满足了上面的那两个条件，所以「候选者 A」就会被选举为 Leader。

4.哨兵时怎么部署的？部署在不同机房？
部署在不同机房，和主节点网络不通的概率会大一些？误判的概率也会大一些？TODO

5.为什么要求至少3个哨兵？
如果哨兵集群有两个哨兵，则选举leader必须有2票。如果挂了一个就没法选举，没法进行主从切换。三个哨兵挂了一个还有选举成功的可能性。

6.哨兵之间时基于协议什么进行通信的？
TODO

7.哨兵之间也要建立网络连接进行通信？什么时候建立的？
是的。创建哨兵集群，会将自己的ip端口发布到主节点的__sentinel__:hello频道

8.哨兵如何监控从节点
正是通过 Redis 的发布者/订阅者机制，哨兵之间可以相互感知，然后组成集群，同时，哨兵又通过 INFO 命令，在主节点里获得了所有从节点连接信息，于是就能和从节点建立连接，并进行监控了。

故障转移的过程

根据什么规则选择一个从节点切换为主节点？

怎么把新主节点的相关信息通知给从节点和客户端呢？
1.新主节点信息如何通知到客户端
每个哨兵提供发布/订阅机制，客户端可以从哨兵订阅消息。客户端和哨兵建立连接后，客户端会订阅哨兵提供的频道。

哨兵集群

哨兵节点之间是通过 Redis 的发布者/订阅者机制来相互发现的。

参考

https://juejin.cn/post/7226710109585834040
https://xiaolincoding.com/redis/cluster/master_slave_replication.html#%E5%91%BD%E4%BB%A4%E4%BC%A0%E6%92%AD