Zookeeper的應用場景

• Zookeeper用例：ready znode與配置改變

• ZooKeeper中，新的leader可以將某個path指定為ready znode。 其他節點將僅在該znode存在時使用配置。

• 當leader 重建配置之后，會通知其他副本重建配置，并新建ready znode.

• 副本為了防止出現不一致，必須在重建配置時，處理完其之前的所有事務。保證所有服務的狀態一致。

• 任何一個副本更新失敗，都不能夠應用都需要進行重試。

Zookeeper用例：鎖

• 下面的偽代碼向我們鎖的實現。通過create試圖持有鎖，如果鎖已經被其他的client持有，則通過watch方式監控鎖的釋放。

acquire lock:
   retry:
     r = create("app/lock", "", empheral)
     if r:
       return
     else:
       getData("app/lock", watch=True)

    watch_event:
       goto retry

  release lock:
    delete("app/lock")

• 由于上面的偽代碼可能會出現羊群效應，可以嘗試下面的方式

• znode下方的children中，序號最低的的是持有鎖的

• 其他在等待的client只watch前一個znode的變化，避免了羊群效應

  acquire lock:
     n = create("app/lock/request-", "", empheral|sequential)
   retry:
     requests = getChildren(l, false)
     if n is lowest znode in requests:
       return
     p = "request-%d" % n - 1
     if exists(p, watch = True)
       goto retry

    watch_event:
       goto retry

Zookeeper簡化程序構建但其不是最終的解決方案

• 應用程序還有許多需要解決的問題

• 例如如果我們要在GFS中使用Zookeeper，那么我們還需要

  • chunks的副本方案

  • primary失敗的協議

  • …

• 但是使用了Zookeeper，至少可以使master容錯，不會發生網絡分區腦裂的問題

Zookeeper實現細節

• 和lab3相似，具有兩層

  • ZooKeeper 服務層  (K/V 層)

  • ZAB 層 (Raft 層)

• Start() 在底層執行插入操作

• 隨后，ops從每個副本服務器的底層彈出，這些操作按照彈出的順序提交(commited),在lab3中使用apply channel，在ZAB層中，通過調用abdeliver()

挑戰：處理重復的客戶端請求

• 場景：primary收到客戶端請求后，返回失敗，客戶端進行重試

• 在lab3中，我們使用了map來解決重復的請求問題，但是每一個客戶端是堵塞的，只能夠等待完成才能進行下一個

• 在Zookeeper中，在一段時間內的操作是冪等的，以最后一次操作為準

挑戰： 讀取操作的效率

• 大部分的操作都是讀取操作，他們不修改狀態

• 讀取操作是否必須通過ZAB層？

• 任何副本服務器都可以執行讀取操作？

• 如果讀取操作通過Raft/ZAB層，則性能會降低

• 讀取操作如果不通過Raft/ZAB層、可能會返回過時的數據

Zookeeper解決方案：允許返回過時的數據

• 讀取可以由任何副本執行

• 讀取吞吐量隨著服務器數量的增加而增加

• 讀取返回它看到的最后一個zxid

• 只有sync-read() 保證數據不過時

• read操作會返回zxid,zxid包含了部分客戶端對于此read請求相對應的write請求的順序，從而客戶端能夠了解此server操作是否落后于client。

• 心跳檢測以及建立session時都會返回zxid，當客戶端連接服務器時，通過zxid對比保證client與server的狀態足夠接近

總結

• Zookeeper通過將wait-free對象（znode對象）暴露給客戶端解決分布式系統中的進程協調問題

• Zookeeper保證了write操作的線性一致性以及客戶端操作的FIFO順序

• Zookeeper通過允許讀取操作返回過時數據實現了每秒數十萬次操作的吞吐量值，適用于多讀而少些的場景

• Zookeeper仍然提供了保證讀一致性的sync操作

• Zookeeper具有強大的API功能用于多樣的應用場景，并且內在提供主從容錯機制，在包括雅虎在內的多家公司廣泛應用