zookeeper作為分布式集群廣泛使用的應用程式協調服務集群。它的特點就不說了，很多人分析過。前段時間微博上說到zk有一些問題，其實只是某些場合下zk使用需要小心，這裡列舉一下：[list=1]
[*]zk不適合做大資料量的儲存，簡單來說就是不適合做公用儲存。原因很簡單，每個資料要同步到所有server才返回，既慢，而且消耗頻寬，client還容易阻塞。所以這種應用對zk來說太「重」了。
[*]watch機制是paxos所沒有的，是zk為了應用而自己加上的。這個功能有許多陷阱，最根本的原因就是zk的watch事件是單向傳遞的，並不保證通知一定能到達客戶端，因此網路不穩定或者client掛掉都會導致丟失watch事件。舉個例子，hbase使用zk來獲知rs是否掛掉。如果某台rs掛掉，master也跟著掛掉的話，是沒有辦法知道這個事件的。必須在**層做處理。
[*]另一種陷阱是client對於watch是一次性接收的，所以一次watch通知後，下一次watch接收必須等到client發出下一次watch請求。所以在處理期間如果有新的watch事件發生，會丟失這些事件。
[*]client提交請求時，有可能收到connection_loss的異常，很不幸收到這種異常的時候，client無從得知請求是否成功。因為這個異常的引起是因為連線斷開，而連線是在提交請求時斷開還是請求正在處理時斷開，無從獲知。所以應用層如果特別care一致性問題，就必須帶上sessionid重連或者重試。
[/list]
以後想到再繼續寫吧，因為最近越來越多的專案開始依賴zookeeper了，所以逐漸開始研究zk。不過進度還是遠遠趕不上前輩，大家可以在 看到更有質量的文章。
關於引用的討論
鄭飛龍 17 17 04 這個是一道面試題，不知道這題是什麼意思？beyond jzk 17 19 55 我也弄不明白.beyond jzk 17 20 15 我感覺輸出應該是false true 鄭飛龍 17 20 45 答案就是這樣 鄭飛龍 17 20 49 你是怎麼看出來的 beyond jz...
關於鎖的討論
一 背景 併發問題一直是企業架構不能忽視的問題，也就是說不可以高枕無憂，始終有些地方你是忽略掉的，對同一片資料庫，不同執行緒同時訪問就會出現併發，併發業務性併發和資料庫併發，事務系統的出現就是為了解決這種併發問題，事務也是利用鎖的原理，鎖定後只允許乙個請求獲得資源，當然事務中的鎖要視事務隔離性而定，...
技術討論 關於低耦合開發的討論
技術討論 關於低耦合開發的討論 丁丁 15 15 50 求知誰體會過低耦合帶來的好處我怎麼覺得現在接觸到的專案都是遷一發 動全身呢 青潤 15 17 03 你是全新專案，還是歷史專案改造？丁丁 15 17 19 新的繼承抽象和介面的方式完全體現不出多麼易於修改 丁丁 15 18 38 只要有變更涉及...