1.zookeeper功能
檔案系統
通知機制
2.分布式程式協調服務
節點擊主
配置管理
粗粒度分布式鎖
主備高可用切換
服務註冊
服務發現
3.各服務發現產品比較
最合適的產品一般最好是cp， eureka 2.0不提供更新了，eureka 1.x 仍可用， 如果在幾百台集群時使用zk還行，如果上千臺，zk就不能支撐。
4.註冊中心是cp還是ap？
4.1.資料一致性需求分析
4.2.如果不一致會導致什麼影響
影響：節點流量不均衡
4.3. zk的寫單點
zk的寫只能是主，所以zk的寫只能是單點，不能水平擴充套件，所以當集群超過一定大小1000，就吃不消，
這時 只能通過集群拆分，按照業務進行zk集群的拆分。也就不同業務有不同的註冊中心，但是當不同業務之前有相互呼叫需要業務合併時就會出現問題。
4.4.不需要儲存
1）、最核心的資料，實時健康的服務列表
zk leader ->follower 乙個請求到zk leader後，同步到每個follower都是使用的2pc提交且還需要寫每乙份事務日誌，所以同 步速度慢
2）、zab協議對每個寫請求在節點上保持寫乙個事務日誌
3）、定期將記憶體資料映象dump到磁碟，保持資料一致性和永續性
4）、呼叫方並不關心服務的歷史位址列表、過去健康狀態
4.5.需要儲存
服務的元資料資訊
服務的版本、分組、所在的機房、權重、鑑權策略資訊、服務標籤等元資訊
4.6.探活機制
1）、服務的健康檢測常利用zk session活性track機制以及結合ephemeral znode的機制
2）、繫結在tcp長鏈結活性探測
3）、存在問題：
服務健康情況無法真正探測
服務假死問題
4）、理想方案
廢除tcp活性檢測
提供更豐富的健康監測方案
服務的健康與否的邏輯開放給服務提供方自己定義
4.7.註冊中心容災考慮
1）、註冊中心不能因為自身的任何原因破壞服務之間本身的可連通性
服務呼叫鏈路需要弱依賴註冊中心，必須僅在服務發布，機器上下線，服務擴縮容等必要時才依賴。
2）、客戶端設計考慮容災
快取資料機制（zk原生客戶端沒有）
zk節點全乾掉，應用服務是否正常work
原生zk客戶端並不具備 netflex 提供的curater比原生 好些
5.zk適用場景
5.1.the king of coordination for big data
1）、 在粗粒度分布式鎖，分布式選主，主備高可用切換等不需要高tps支援的場景下有不可替代的作用
2）、這些需求往往多集中在大資料、離線任務等相關的業務領域，因為大資料領域講究分割資料集，並且大部分時間分任務多程序/執行緒並行處理這些資料集，但是總是有一些點上需要將這些任務和程序統一協調，這時候就是zookeeper發揮巨大作用的用武之地。
5.2. 適用場景
1）、大資料
2）、分布式協調
5.3.不適用場景
大規模交易
大規模服務發現
Android NSD註冊服務，發現服務
import android.content.context import android.net.nsd.nsdmanager import android.net.nsd.nsdserviceinfo import android.util.log public class nsdhelper ...
服務註冊與服務發現
應用場景 多台伺服器提供同乙個服務 是儲存服務名稱與ip和埠對應關係的伺服器 服務只會註冊ip,埠這些資訊，至於服務提供什麼介面，consul不管,需要消費者知道這些細節.安裝執行 consul agent dev 監控頁面 新建2個專案，分別提供兩個服務 給專案隨便新建乙個控制器提供健康檢查使用 ...
服務註冊與發現
在分布式系統中，各個子系統都是多個例項存在，這個時候必須要引入乙個服務協調器，用於給呼叫方提供可用的呼叫提供者的命名訊息。服務協調器，如zookeeper，etcd，eureka 他們必須要有的特性 本身高可用，由多個服務節點構成，就算有些節點掛掉也不影響正常執行，避免了單點故障。本身是乙個分布式，...