标签：lan 同步 tin red 解决 不一致 异步 proposal leader
zookeeper 使用的是zab协议，类似 raft 的 Strong Leader 模式
redis 的哨兵 在 崩溃选举的时候采用的是 raft的那一套term。
因为redis 采用的是异步数据副本的节点同步方式，所以在做分布式锁的时候可能会存在 setNx之后，没有同步到从节点，主节点崩溃，而这时客户端又从从节点读取数据，导致同步锁设置失败（写入都是master节点）。当然作者提供了redLock 在时间内 挨个节点设置锁的形式。具体意思及实现可以参考redssion中的。
反观zk不会出现这个问题，因为zk的主节点节后到请求后，会保证各个从节点数据写入完毕后，返回客户端。
ZAB 协议的消息广播过程使用的是一个原子广播协议，类似一个 二阶段提交过程。对于客户端发送的写请求，全部由 Leader 接收，Leader 将请求封装成一个事务 Proposal，将其发送给所有 Follwer ，然后，根据所有 Follwer 的反馈，如果超过半数成功响应，则执行 commit 操作（先提交自己，再发送 commit 给所有 Follwer）。
当超过半数成功回应，则执行 commit ，同时提交自己。同时每个事物都有一个zxid 还有一个消息队列 解决异步，同时，针对各个节点的数据不一致性问题还有选举过程。
所以，在设置分布式锁的时候需要考虑这点，当然是极高并发的情况下才会出现这种情况。那出现了，就是呵呵。
网上有人说zookpeer的数据一致性协议是从paxos中演化出来的，其实无论raft还是paxos，解决的业务场景都是一样的。
在redis中的主从节点的数据同步应该是也是2PC，如果我没记错的话。
其实现在蚂蚁也出了java办的jraft工具包，但是这些很有意思的，不是吗？
有两篇我觉得写的很好的，redis和zk的相关协议，也是我参考的。
写的很垃圾，后期有，再写，这三篇写的都很好
zab协议：https://www.cnblogs.com/stateis0/p/9062133.html
zookpeer 和 redis 集群内一致性协议 及 选举 对比
标签：lan 同步 tin red 解决 不一致 异步 proposal leader
原文地址：https://www.cnblogs.com/yidiandhappy/p/10981243.html
