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 這篇文章講解的比較詳細。其解決分佈式事務的思路就是避免分佈式事務，具體來說就是利用本地事務+異步消息+重試+冪等去保證整個系統數據的最終一致性。