分布式中的網路是不可靠的。
解決四大問題
1.客戶端怎麼訪問這麼多服務
2.服務之間怎麼通訊
1.同步通訊-httpclient，rpc通訊框架
2.非同步通訊-mq訊息佇列
3.這麼多服務如何管理（高可用，高併發，高效能）副本解決
這個服務上線下線情況以及ip埠等資訊
服務註冊與發現
基於客戶端的服務註冊與發現–zookeeper
基於服務端的服務治理與發現–eureka
4.服務掛了怎麼辦
重試機制，服務降級，服務限流
分布式協調問題–主要用來解決多個程序之間的同步控制問題，讓他們有序的訪問臨界資源，防止造成髒資料的後果。
為防止分布式系統中多個程序之間的相互干擾，我們需要一種分布式協調技術來對這些程序進行排程，分布式協調技術主要實現了分布式鎖。
在分布式系統環境下，乙個方法在同一時間只能被乙個機器的乙個執行緒執行
高可用的獲取鎖與釋放鎖
高效能的獲取鎖與釋放鎖
具備可重入特性（可理解為重新進入，由多於乙個任務併發使用，而不必擔心資料錯誤）
具備鎖失效機制，防止死鎖
具備非阻塞鎖特性，即沒有獲取到鎖將直接返回獲取鎖失敗
加鎖，解鎖，鎖超時
1.加鎖所超時需要寫成原子性操作。即寫在乙個操作中（防止出現死鎖）
2.刪除鎖時防止誤刪別人的鎖，需要判斷是不是自己的鎖
3.需要給獲得鎖的執行緒開啟乙個守護執行緒，用來給快要過期的鎖「續航」。
zookeeper 的資料模型是什麼樣子呢？它很像資料結構當中的樹，也很像檔案系統的目錄。
樹是由節點所組成，zookeeper 的資料儲存也同樣是基於節點，這種節點叫做 znode
但是，不同於樹的節點，znode 的引用方式是路徑引用，類似於檔案路徑：
1./動物/貓
2./汽車/寶馬
建立節點
create
刪除節點
delete
判斷節點是否存在
exists
獲得乙個節點的資料
getdata
設定乙個節點的資料
setdata
獲取節點下的所有子節點
getchildren
這其中，exists，getdata，getchildren 屬於讀操作。zookeeper 客戶端在請求讀操作的時候，可以選擇是否設定 watch
事件通知（觀察者模式）
單機環境下的zookeeper如何實現高可用
zookeeper基於docker容器，多個zookeeper服務（埠號不同）
當前主節點掛了，進入崩潰恢復階段，節點之間會根據zab協議會進行選舉主節點
broadcast
zab 的資料寫入涉及到 broadcast 階段，簡單來說，就是 zookeeper 常規情況下更新資料的時候，由 leader 廣播到所有的 follower。其過程如下：
客戶端發出寫入資料請求給任意 follower。
follower 把寫入資料請求**給 leader。
leader 採用二階段提交方式，先傳送 propose 廣播給 follower。
follower 接到 propose 訊息，寫入日誌成功後，返回 ack 訊息給 leader。
leader 接到半數以上ack訊息，返回成功給客戶端，並且廣播 commit 請求給 follower
節點型別：
持久節點，持久節點順序節點，臨時節點，臨時節點順序節點
基於臨時節點做加鎖，解鎖
基於順序節點和事件通知（觀察者模式）做類似於redis對共享資源的有序訪問
python分布式架構 分布式架構
1.分布式架構 採用centos mongodb windows2012 python redis進行分布式架構搭建，mongodb的框架最核心的設計就是 mongodb和mapreduce。mongodb為海量的資料提供了儲存，則mapreduce為海量的資料提供了計算，windows2012作為...
分布式5 zookeeper分布式
一 為什麼需要zookeeper 大部分分布式應用需要乙個主控 協調器或控制器來管理物理分布的子程序 如資源 任務分配等 大部分應用需要開發私有的協調程式，缺乏乙個通用的機制 協調程式的反覆編寫浪費，且難以形成通用 伸縮性好的協調器 zookeeper可以提供通用的分布式鎖服務，用以協調分布式應用，...
zookeeper分布式鎖
方案1 演算法思路 利用名稱唯一性，加鎖操作時，只需要所有客戶端一起建立 test lock節點，只有乙個建立成功，成功者獲得鎖。解鎖時，只需刪除 test lock節點，其餘客戶端再次進入競爭建立節點，直到所有客戶端都獲得鎖。特點 這種方案的正確性和可靠性是zookeeper機制保證的，實現簡單。...