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 他們必須要有的特性 本身高可用,由多個服務節點構成,就算有些節點掛掉也不影響正常執行,避免了單點故障。本身是乙個分布式,...