1.分散式配置

要點：配置資訊儲存在db與zk中(保險起見，資料安全性更高)，弄一個後臺管理介面，對配置修改後，先儲存到db，然後同步寫入zk的節點中。應用啟動時，先連到zk上讀取節點中的配置，同時監聽節點的資料變化，當配置變化時，得到實時通知。

2.消除單點故障(Single Point of Failure，SPOF)

└── ./OrderNoService
        ├── A0000001
                10.0.0.1:8001
        └── A0000002
                10.0.0.2:8001
複製程式碼

多個服務例項，啟動時在zk上臨時順序節點，服務的呼叫方約定取最小節點為Master

，當master掛掉後，節點自動刪除，呼叫方得到事件通知，取新的最小節點來呼叫(相當於slave提升為master)

3.分散式服務註冊與訂閱

在分散式環境中，為了保證高可用性，通常同一個應用或同一個服務的提供方都會部署多份，達到對等服務。而消費者就須要在這些對等的伺服器中選擇一個來執行相關的業務邏輯，比較典型的服務註冊與訂閱，代表：dubbo。

4、分散式鎖

Order
    └── 3456890
        ├── 000001
        ├── 000002
        └── 000003
複製程式碼

原理：以多個程式執行例項同時在處理訂單3456890為例，每個程式執行例項處理前，建立一個臨時順序節點，然後檢查自己建立的節點是否為最小，如果不是，表明沒搶到鎖，如果是，表示搶到了鎖，搶到鎖的程式處理完以後，刪除該節點表示釋放鎖。同時，其它處於等候狀態的程式，為了實時得到鎖的釋放通知，均監聽父節點Order/3456890

的子節點變化，發現子節點變化時，重複剛才的檢測過程，直到自己建立的節點變成最小為止。 與redis SETNX之類的分散式鎖相比，zk的分散式鎖，還能實現解決Top N之類的有限資源競爭問題（類似併發中的訊號量)。比如：一堆程式要列印，但是隻有2臺印表機(或者列印佇列的長度只有2，最多同時只能允許2個程式提交列印任務）, 類似剛才的思路 ，可以檢測最小的前2個節點，只有建立最小前2個節點的程式，才認為是拿到了訊號，允許提交列印任務。

5、分散式佇列

Queue
    └── Queue1
        ├── 000001
        ├── 000002
        └── 000003
複製程式碼

如上圖，建立Queue/Queue1

做為一個佇列(或Topic)，然後每建立一個順序節點，視為一條訊息(節點儲存的資料即為訊息內容)，生產者每次建立一個新節點，做為訊息傳送，消費者監聽Queue1的子節點變化（或定時輪詢)，每次取最小節點當做消費訊息，處理完後，刪除該節點。相當於實現了一個FIFO(先進先出)的佇列。 注：zk框架強制的是CP（一致性)，而非專為高併發、高效能場景設計的，如果在高併發，qps很高的情況下，分散式佇列需酌情考慮。

6、生成分散式唯一id

Order
      └── OrderId
        ├── 000001
        ├── 000002
        └── 000003
複製程式碼

思路：每次要生成一個新Id時，建立一個持久順序節點，建立操作返回的節點序號，即為新Id，然後把比自己節點小的刪除即可。

7.命名服務

在分散式系統中，通過使用命名服務，客戶端應用能夠根據指定名字來獲取資源或服務的地址，提供者等資訊。被命名的實體通常可以是叢集中的機器，提供的服務地址，程序物件等等——這些我們都可以統稱他們為名字（Name）。其中較為常見的就是一些分散式服務框架中的服務地址列表。通過呼叫ZK提供的建立節點的API，能夠很容易建立一個全域性唯一的path，這個path就可以作為一個名稱。