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