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
redis 哨兵 选举:http://weizijun.cn/2015/04/30/Raft%E5%8D%8F%E8%AE%AE%E5%AE%9E%E6%88%98%E4%B9%8BRedis%20Sentinel%E7%9A%84%E9%80%89%E4%B8%BELeader%E6%BA%90%E7%A0%81%E8%A7%A3%E6%9E%90/
分布式锁的 ： http://weizijun.cn/2016/03/17/%E8%81%8A%E4%B8%80%E8%81%8A%E5%88%86%E5%B8%83%E5%BC%8F%E9%94%81%E7%9A%84%E8%AE%BE%E8%AE%A1/