6月iOS設備好評榜：第一蟬聯榜首近一年
作為安兔兔各種榜單里變化最小的那個，2023年6月的iOS好評榜和上個月相比沒有任何排名上的變化，僅僅是部分設備好評率的下降，長年累月的用戶評價和逐漸退出市場的老款機器讓這
NameServer 是專為 RocketMQ 設計的輕量級名字服務，它的源碼非常精簡，八個類 ，少于1000行代碼。
圖片
這篇文章， 筆者會從基礎概念、Broker發送心跳包、NameServer 維護路由、Zookeeper vs NameServer 四個模塊揭秘名字服務的設計精髓。
圖片
1、Broker 會每隔 30 秒向所有的 NameServer 發送心跳命令 ；
使用 CountDownLatch 實現多線程同步，可以獲取發往所有的 NameServer 的心跳命令的響應結果
2、心跳命令包含兩個部分：請求頭和請求體
圖片
NameServer 在接收到 Broker 發送的心跳請求之后，通過默認的處理器來處理請求，保存路由信息成功后，注冊成功狀態返回給 Broker 服務。
源碼中，我們可以看到路由信息保存在 HashMap 中 。
圖片
2、讀操作：查詢主題信息，操作讀鎖
圖片
我們可以將 NameServer 實現注冊中心的方式總結為：RPC 服務 + HashMap 存儲容器 + 讀寫鎖 + 定時任務 。
1、NameServer 監聽固定的端口，提供 RPC 服務
2、HashMap 作為存儲容器
3、讀寫鎖控制鎖的顆粒度
4、定時任務
那為什么 RocketMQ 不用 Zookeeper 做為注冊中心呢 ？
我們先溫習下 CAP 理論。
圖片
CAP 理論是分布式架構中重要理論。
1、一致性( Consistency ) ：所有節點在同一時間具有相同的數據 ;
2、可用性( Availability ) ：保證每個請求不管成功或者失敗都有響應 (某個系統的某個節點掛了，但是并不影響系統的接受或者發出請求) ;
3、分隔容忍( Partition tolerance ) ：系統中任意信息的丟失或失敗不會影響系統的繼續運作。 (在整個系統中某個部分，掛掉了，或者宕機了，并不影響整個系統的運作或者說使用) 。
Zookeeper 是一個典型的 CP 注冊中心 ，通過使 ZAB 協議來保證節點之間數據的強一致性。
筆者曾經遇到過一起神州專車服務宕機事故，zookeeper 集群不堪重負，一直在選主 。架構負責人修改了 zookeeper 的 jvm 參數，重啟集群后 , 才臨時解決了問題。
因為 MetaQ 集群和服務治理共用一組 zookeeper 集群 。
為了減少 zookeeper 集群的性能壓力，架構團隊將 MetaQ 使用的 zookeeper 集群獨立出來。
這次事故讓我認識到：Zookeeper 作為 CP 注冊中心，大規模使用場景下，它就變得很脆弱，我們要非常小心的使用。
淘寶中間件博客出了一篇文章 : 阿里巴巴為什么不用 ZooKeeper 做服務發現 ？
文章有兩個觀點，筆者認為非常有借鑒意義。
1、當數據中心服務規模超過一定數量 ( 服務規模=F{服務 pub 數,服務 sub 數} )，作為注冊中心的 ZooKeeper 很快就會像下圖的驢子一樣不堪重負。
2、可以使用 ZooKeeper，但是大數據請向左，而交易則向右，分布式協調向左，服務發現向右。
相比 ZooKeeper ，NameServer 是一個典型的 AP 注冊中心，它有如下優點：
1、代碼不到 1000 行，實現簡單，易于維護 ;
2、性能極好，除了網絡消耗，基本都是本地內存操作 ;
3、服務都是無狀態，且節點之間并不交互，運維簡單；
RocketMQ 的設計者之所以選擇自研名字服務，遵循著架構設計的準則，筆者總結為：簡單、高效、適當妥協。
本文鏈接：http://www.tebozhan.com/showinfo-26-5193-0.html聊聊 RocketMQ 名字服務
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號