《深入了解apache dubbo》讀書筆記
一，註冊中心概述
dubbo通過註冊中心實現了分布式環境中各服務之間的註冊和發現，是各個分布式節點之間的紐帶，主要作用：
註冊功能在核心原始碼元件中給的registry元件中，裡面包含了5各子模組 ：
dubbo-registry-api
包含了註冊中心所有的api和抽象實現類
dubbo-registry-zookeeper
使用zk作為註冊中心的實現
dubbo-registry-redis
使用redis作為註冊中心的實現
dubbo-registry-default
dubbo自己基於記憶體的預設實現
dubbo-registry-multicast
multicast模式的服務註冊與發現
這裡總結出來了，四種註冊中心的實現方式，那麼常用的是zookeeper的方式，因為它本來就是管理者，就很符合！
zookeeper原理概述：
首先zk本質是什麼？它就是乙個資料庫，只不過和redis不同的是，它的內部是使用樹形結構存放資料的，根是'/'，它的節點有四種類項：持久節點（重啟也存在），持久順序節點（增加了先後順序），臨時節點（連線丟失，session超時則會丟失），臨時順序節點（那麼說了半天，就是兩個維度，是否持久，和是否有序）
dubbo對建立的節點順序無要求，只存在持久節點和臨時節點（kafka貌似對是否有序有要求），它在zookeeper中，服務存入的節點結構是：
/dubbo
/service全名稱
/providers ：包含多個服務者的url元資料資訊
/consumers ：包含多個消費者的url元資料資訊
/routers ：包含多個消費者路由策略元資料資訊
/configurators ：伺服器動態配置url元資料資訊
二，訂閱/發布（zookeeper）
發布的實現：
服務的提供者的上線，只需要在zk中建立乙個目錄，節點就ok了，
訂閱的實現：
訂閱通常有pull,push兩種方式（客戶端到zk拉取，和zk主動推送訊息到客戶端），dubbo使用的是主動拉取模式，服務端註冊的時候，會訂閱configurators監聽動態配置，消費端呼叫時，會訂閱providers,routers,configurators三個目錄。
zk的客戶端有三個，有乙個是原生zk官方推出的，但是呼叫介面複雜，後面產生了封裝過後的client，分別是curator,zkclient，dubbo對這兩個客戶端進行了封裝，定義了統一的client api，使用者需要配置registry中的client屬性，表明使用哪種客戶端，不配置，預設使用curator（這也是為什麼入門demo中，配置了zkclient報錯，需要加入curator的原因，因為沒有配置zk客戶端）
三，緩衝機制
緩衝的存在是用空間換取時間，如果每次遠端呼叫都從zk中獲取，那麼zk的訪問量會特別高，降低了整體的效率，所以dubbo節點會緩衝zk的資料，這也是為什麼（當zk掛了的時候，dubbo節點任能正常的工作）dubbo會把資料在記憶體中緩衝乙份，儲存在properties中，在磁碟中持久化乙份file。
Dubbo註冊中心
分享一下我老師大神的人工智慧教程！零基礎，通俗易懂！推薦使用zookeeper註冊中心,不需要啟動任何中心節點，只要廣播位址一樣，就可以互相發現 組播受網路結構限制，只適合小規模應用或開發階段使用。組播位址段 224.0.0.0 239.255.255.255 提供方啟動時廣播自己的位址。消費方啟動...
dubbo註冊中心
register 註冊，寫乙份 subscribe訂閱 可以理解為一種監視 一有風吹草動 及時聯絡 服務時效 臨時節點刪除 臨時節點與客戶端會話繫結，會話失效節點自動刪除 provider廣播自己位址，consumer廣播訂閱請求 provider收到訂閱請求，單播自己位址給consumer，如un...
Dubbo註冊中心介紹
dubbo的註冊中心有好多種，包括 multicast zookeeper redis 和 等。dubbo官方推薦使用zookeeper註冊中心，我所使用過的也只是zookeeper註冊中心。首先介紹一下zookeeper zookeeper是乙個分布式的，開放原始碼的分布式應用程式協調服務，是go...