假设我们将 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 再做操作，否则会导致主库拒绝写，影响到业务。

其实我不太关心脑裂，但是我对于发现数据丢失之后的故障排查思路比较感兴趣。 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 的时候，运维操作注意事项的提醒很有价值。