33 | 脑裂：一次奇怪的数据丢失

穿插使用 CAP 理论来分析一下课程的内容： 1. redis 集群允许脑裂存在，其实是一种可用性高的特征，但不保证数据一直。 2. redis 通过设置两个参数，一定程度上其实是在降低可用性，以提供数据一致性。 3. 为什么愿意降低可用性？因为那部分的数据会因为主从切换而丢失，所以宁愿不可用。

老师用的画图工具叫什么？

假设我们将 min-slaves-to-write 设置为 1，min-slaves-max-lag 设置为 15s，哨兵的 down-after-milliseconds 设置为 10s，哨兵主从切换需要 5s。主库因为某些原因卡住了 12s，此时，还会发生脑裂吗？主从切换完成后，数据会丢失吗？ 主库卡住 12s，达到了哨兵设定的切换阈值，所以哨兵会触发主从切换。但哨兵切换的时间是 5s，也就是说哨兵还未切换完成，主库就会从阻塞状态中恢复回来，而且也没有触发 min-slaves-max-lag 阈值，所以主库在哨兵切换剩下的 3s 内，依旧可以接收客户端的写操作，如果这些写操作还未同步到从库，哨兵就把从库提升为主库了，那么此时也会出现脑裂的情况，之后旧主库降级为从库，重新同步新主库的数据，新主库也会发生数据丢失。 由此也可以看出，即使 Redis 配置了 min-slaves-to-write 和 min-slaves-max-lag，当脑裂发生时，还是无法严格保证数据不丢失，它只能是尽量减少数据的丢失。 其实在这种情况下，新主库之所以会发生数据丢失，是因为旧主库从阻塞中恢复过来后，收到的写请求还没同步到从库，从库就被哨兵提升为主库了。如果哨兵在提升从库为新主库前，主库及时把数据同步到从库了，那么从库提升为主库后，也不会发生数据丢失。但这种临界点的情况还是有发生的可能性，因为 Redis 本身不保证主从同步的强一致。 还有一种发生脑裂的情况，就是网络分区：主库和客户端、哨兵和从库被分割成了 2 个网络，主库和客户端处在一个网络中，从库和哨兵在另一个网络中，此时哨兵也会发起主从切换，出现 2 个主库的情况，而且客户端依旧可以向旧主库写入数据。等网络恢复后，主库降级为从库，新主库丢失了这期间写操作的数据。 脑裂产生问题的本质原因是，Redis 主从集群内部没有通过共识算法，来维护多个节点数据的强一致性。它不像 Zookeeper 那样，每次写请求必须大多数节点写成功后才认为成功。当脑裂发生时，Zookeeper 主节点被孤立，此时无法写入大多数节点，写请求会直接返回失败，因此它可以保证集群数据的一致性。 另外关于 min-slaves-to-write，有一点也需要注意：如果只有 1 个从库，当把 min-slaves-to-write 设置为 1 时，在运维时需要小心一些，当日常对从库做维护时，例如更换从库的实例，需要先添加新的从库，再移除旧的从库才可以，或者使用 config set 修改 min-slaves-to-write 为 0 再做操作，否则会导致主库拒绝写，影响到业务。

课后问题：仍然可能会发生数据丢失。究其原因是redis内部没有共识算法保证数据同步，写数据的时候只是写入主库即可返回成功，数据同步到从库是通过异步处理的。

最欣赏的是排查分析问题的过程。

老师您好，防止脑裂我认为有2点需要注意： 1可以考虑把多个sentinel节点部署到不同的机房，减少由于网络原因导致的误判。 2.redis master主节点主机，避免高负载，部署时留有一些冗余 关于min-slaves-to-write，min-slaves-max-lag这两个配置，主要是解决主从同步数据一致性问题的，尽量减少主从同步的数据不一致，我觉得不能从根本上通过这两个参数解决脑裂。比如master和slave的网络很好，那么这两个参数失效，如果这个时候3个sentinel节点的到master的网络都异常并且这些节点到slave网络良好，那么一样会触发主从切换，造成脑裂。我是这样理解的，希望老师指正！

其实我不太关心脑裂，但是我对于发现数据丢失之后的故障排查思路比较感兴趣。 1. 确认数据同步是否有问题，检查主从库复制进度差值（master_repl_offset 和 slave_repl_offset） 2. 排查客户端日志，发现脑裂 3. 发现原主库假故障导致脑裂 利用 min-slaves-to-write 和 min-slaves-max-lag 两个配置项搭配使用，可以避免脑裂。参考文中的例子，min-slaves-to-write 设置为 1，就是说只要有一个从库无法在 min-slaves-max-lag 的时间内发送代表主从复制完成的 ACK 消息，原主库就不能再接收客户端请求了。 假设从库有 K 个，那么 min-slaves-to-write 就设置为 K/2+1，其实超过半数的从库，再结合哨兵机制的 quorum，就可以避免脑裂。 对于课后题，按照题目的条件，min-slaves-to-write 设为 1，min-slaves-max-lag 设为 15s，哨兵 down-after-milliseconds 设置为 10s，哨兵主从切换 5s，主库卡住 12s，我觉的可能不会发生脑裂。 主库卡住 12s，哨兵已经判定原主库下线了，而因为 min-slave-to-write 和 min-slaves-max-lag 的设置，只有超过 15s，才会拒绝原主库接受客户端请求，也就是说从第 12s 到 15s 之间，原主库可以接受客户端请求，而 15s 后，主从切换完成，新主库开始接收客户端请求，而原主库在 12s 后接收的请求可以同步到新主库。 看了课代表的答案，其实我也纠结，原主库从 12s 到 15s 接收到的请求能否同步到新主库。 课代表对于只有一个从库，且设置了 min-slave-to-write 为 1 的时候，运维操作注意事项的提醒很有价值。

不太明白为什么需要引入min-slaves-to-write，min-slaves-max-lag这两个参数来避免脑裂，为什么不在哨兵认为主库客观下线的时候，就禁止主库的写操作。

min-slaves-max-lag是不是一般要设置成比down-after-milliseconds小的值最好？

redis执行slave of之后，就变成了只读实例，写入会报错