zookeeper中請求順序性問題的考慮

順序性保障

 

鏈接丟失時的順序性

zookeeper會取消等待的請求，同步方法會拋出異常，對於異步請求調用，回調函數會返回結果碼來標示鏈接丟失，這種狀況下依賴客戶端解決後續的操做，而不能依賴zk承擔這些操做

考慮鏈接丟失的影響，考慮如下順序事件

1應用程序提交請求，執行op1操做

2客戶端檢測到了鏈接丟失，取消op1操做請求

3客戶端在會話過時前從新鏈接

4應用程序提交請求，執行op2操做

5op2執行成功

6po1返回connectionloss事件

7應用程序從新提交op1請求

這種狀況下op2先與op1成功，若是op1重試，還有失敗的可能，不斷重試是不行的，因此要設置重試的次數；

若是op2的執行要在op1以後，須要保證執行請求的前後順序，這種可能會使應用程序性能 降低，程序並不能並行執行

 

擺脫connectionloss事件會怎麼樣

在zookeepere設計上，它標示一個鏈接丟失的事件，重連後，客戶端能夠從新查詢斷鏈以前提交請求的執行狀況，能夠從服務器緩存中獲取執行結果

 

 

同步api和多線程執行的問題

多線程中同步調用多個請求，這種狀況下，並不能保證順序性，可能後提交的請求先執行，在有執行順序的請求中，這種方式並不能直接使用

 

同步和異步混合調用的形式

異步調用了aop1,aop2,在aop1的異步回調中執行了sop1,若是這個同步調用阻塞了客戶端的分發線程，這樣線程的執行順序爲aop1,sop1,aop2;

而實際提交的順序爲aop1,aop2,sop1;

 

 

數據字典和子節點的限制

zookeeper上限制了能夠存儲的數據大小和一個父節點下的子節點數，這個值在數據量大的應用中能夠修改

應用中嵌入zookeeper服務，將服務的實例化放在應用當中，這樣會耦合到一塊兒，使系統複雜化