Redis split-brain 脑裂

为什么 Redis 会脑裂 ？极客时间《Redis 核心技术与实战》专栏学习笔记 19，部分已经作为留言发布，但是留言太多，排在后面的一般很难被大家看到，所以集中发布在这里，欢迎讨论。

题图来自网络

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

其实我不太关心脑裂，但是我对于发现数据丢失之后的故障排查思路比较感兴趣。

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 的时候，运维操作注意事项的提醒很有价值。

34 | 第 23~33 讲课后思考题答案及常见问题答疑     

对答案的时候总是忐忑。

第 24 课的课后题我完全想错了，使用 Redis 缓存，将脏数据写回数据库，因为是“脏数据”，所以缓存中的数据被修改了，对应了读写缓存模式。而脏数据是在被替换出缓存的时候写回数据库的，这就对应了异步写回策略的读写缓存模式。

如果把这道题当做面试题，估计很多候选人爬不出这个坑。

第 25 课，直接在缓存中更新，好处是下次访问时可以直接从缓存读；缺点是数据更新时的一致性问题。

第 27 课，@yeek：“极端情况下，LFU 策略使用的计数器可能会在短时间内达到一个很大值，而计数器的衰减配置项设置的很大，导致计数器值衰减的很慢，这种情况下，数据就有可能在缓存中长期驻留。”——不明觉厉

第 31 课，老师分三种情况分析了采用 RDB 机制时，Redis 实例发生故障的情况下，能否保证事务完整性，而我自己的答案只考虑了其中一种情况。

第 33 课，老师和课代表都认为在原主库回复之后 12s-15s 接收到的请求是无法同步到新主库的，我错了。

关于 Redis 属于旁路缓存，本篇讲的很清楚，就是需要在业务代码中显式的增加缓存操作逻辑。记住这一条，不光是 Redis，所有的旁路缓存问题应该都可以面试了。

另外提到了，在使用 Redis 是一般不使用 异步写回策略的读写缓存模式，因为 Redis 没法实现在脏数据被淘汰时，自行写回数据库。