哨兵(sentinel)模式下的脑裂

1个master与3个slave组成的哨兵模式(哨兵独立部署于其它机器)

刚开始时,2个应用服务器server1、server2都连接在master上

master与slave及哨兵之间的网络发生故障,但是哨兵与slave之间通讯正常,这时3个slave其中1个经过哨兵投票后,提升为新master

如果server1仍然连接的是旧的master,而server2连接到了新的master上

数据就不一致了,基于setNX指令的分布式锁,可能会拿到相同的锁

基于incr生成的全局唯一id,也可能出现重复

集群(cluster)模式下的脑裂

custer模式下,情况要更复杂

集群有6组分片,每个分片节点都有1主1从

出现网络分区时,各种节点之间的分区组合都有可能

情况A:

master1与slave4落到同1个分区,slave4经选举后可能会被提升为新的master4,而另一个分区里的slave1,可能会提升为新的master1

cluster中key的定位依赖slot,情况A经过这一翻折腾后,master1与master4上的slot,出现了重复,在二个分区里都有

类似的,如果依赖incr及setNX的应用场景,都会出现数据不一致的情况

情况B:

如果每给分片内部的逻辑(即:主从关系)没有乱,只是恰好分成二半,这时slot整体上看并没有出现重复,如果原来请求的key落在其它区,最多只是访问不到,还不致于发生数据不一致的情况。(即:宁可出错,也不要出现数据混乱)

主从迁移带来的不一致

1主1从,如果采用incr来生成全局唯一键,假如master上的值是4,但是尚未同步到slave上(slave上仍然是旧值3),这时候如果发生选举,slave被提升为新master,应用服务器server1切换到新主后,下次再incr获取的值,就可能重复了(3+1=4)

总结

虽然上面的情况都比较极端,但实际中还是有可能发生的,正如官方文档所言,redis并不能保证强一致性(Redis Cluster is not able to guarantee strong consistency. / In general Redis + Sentinel as a whole are a an eventually consistent system) 对于要求强一致性的应用,更应该倾向于相信RDBMS(传统关系型数据库)