zookeeper到底是什麼？
zookeeper實際上是yahoo開發的，用於分布式中一致性處理的框架。最初其作為研發hadoop時的副產品。由於分布式系統中一致性處理較為困難，其他的分布式系統沒有必要 費勁重複造輪子，故隨後的分布式系統中大量應用了zookeeper，以至於zookeeper成為了各種分布式系統的基礎元件，其地位之重要，可想而知。著名的hadoop，kafka，dubbo 都是基於zookeeper而構建。
要想理解zookeeper到底是做啥的，那首先得理解清楚，什麼是一致性。
所謂的一致性，實際上就是圍繞著「看見」來的。誰能看見？能否看見？什麼時候看見？舉個例子：**後台賣家，在後台上架一件大促的商品，通過伺服器a提交到主資料庫，假設剛提交後立馬就有使用者去通過應用伺服器b去從資料庫查詢該商品，就會出現乙個現象，賣家已經更新成功了，然而買家卻看不到；而經過一段時間後，主資料庫的資料同步到了從資料庫，買家就能查到了。
假設賣家更新成功之後買家
立馬就能看到賣家的更新，則稱為
強一致性
；如果賣家更新成功後買家不能看到賣家更新的內容，則稱為
弱一致性
；而賣家更新成功後，買家經過一段時間最終能看到賣家的更新，則稱為最終一致性
。分布式事務處理模式
一般分布式事務處理模式包括：2階段提交、3階段提交、tcc（try-confirm-cancel）、可靠訊息（訊息佇列、資料庫表）、sagas長事務、補償性事務。具體採用哪一種分布式事務處理模式，需要根據自己業務場景來選擇合適的機制。
duboo、spring cloud都可以算作是soa框架，分布式事務控制支援依賴其他元件，例如通過jta（2階段、3階段）、activemq訊息中介軟體、bytetcc（tcc）等。
zookeeper、redis可以支援分布式鎖，分布式鎖是分布式事務的核心，但分布式鎖不等同於分布式事務。
redis對分布式鎖的支援主要通過setnx，在使用redis分布式鎖時候，一定要注意處理加鎖客戶端異常導致鎖資源沒有正常釋放的情況（例如呼叫端down掉），在呼叫setnx時候需要加上對鎖超時時間的判斷。
zookeeper對分布式鎖的支援可以直接使用zookeeper curator-recipes客戶端。
具體的分布式事務處理
目前解決的辦法有基於xa的2pc兩階段提交，實際上就是整個事務過程由事務管理器和資源管理器來共同參與。這麼一說可能題主就明白了這是位於資源層面的解決方案，說白了就是你的資料庫或者mq要支援兩階段提交協議，由於在整個事務過程中會一直鎖定資源，而且涉及到網路操作，那這個東西就不太可靠，而且會影響效能，擴充套件性和可用性都不友好，同時對於服務層面的分布式它是搞定不定的。所以後面又搞出來個tcc，這個類似2pc，只是它是位於業務層面，基本的思路是把比較長的分布式事務拆分成本地的短事務。這需要結合業務的特點去設計，比如買10塊錢的東西，針對支付這個服務，在進行扣費的時候先有個凍結使用者10塊錢的動作，這個就是try。等到後面tcc框架發起confirm操作時才真正把10塊錢扣掉，如果tcc框架發起cancel操作則把10塊錢解凍。需要注意的是由於confirm和cancel可能失敗，因此可以結合全域性事務id設計成冪等性的介面。
上面兩種從某種程度上來講都能提供比較強的一致性，但是有很多場景是不需要這種強一致性的。根據cap（一致性、可用性、可靠性）的理論，魚和熊掌不可兼得，可靠性是必須要的，所以需要在c和a之間做平衡，實際上在網際網路領域ａ也是必須的，因此就不得不在ｃ上做文章。於是有了弱一致或者最終一致，它不要求你在做完乙個操作後能立馬看到效果，只要在可接受的時間內看到正確的結果即可。這方面的內容epay的架構師有過介紹，目前業界用這種的比較多，sina visitor system 這篇文章講解的比較詳細。其解決分布式事務的思路就是避免分布式事務，具體來說就是利用本地事務+非同步訊息+重試+冪等去保證整個系統資料的最終一致性。
分布式隨筆1 分布式概述
分布式，好寬泛的話題，來來咱扯兩句。你乙個人再強壯，也扛不了100袋大公尺，單機的資源也很有限，大 的大資料量 高併發以及各種業務需求 童鞋們的web應用，伺服器 rdb mq 服務 快取以及各類基礎設施，更別說還有安全 大資料方面的需求 於是，我們常見的面向服務的dubbo springcloud...
zookeeper（3）分布式鎖
在乙個分布式系統中，如何保證乙個操作，同一時間只有乙個執行緒可以執行，這就是分布式鎖的使用場景，同一時間，只有乙個執行緒可以獲得鎖的使用權。實現乙個分布式鎖，可以有以下3種方法。1 在mysql中，使用悲觀鎖 select from t where id for update 可以對行資料進行加鎖，...
Zookeeper場景實踐 （8） 分布式佇列
按照zookeeper典型應用場景一覽 裡的說法，分布式佇列有兩種，一種是常規的先進先出佇列，另一種是要等到佇列成員聚齊之後的才統一按序執行。第二種佇列可以先建立乙個 queue，賦值為n，表達佇列的大小。然後每個佇列成員加入時，就判斷是否達到佇列要求的大小，如果是可以進行下一步動作，否則繼續等待佇...