直屏旗艦來了 iQOO 12和K70 Pro同臺競技
旗艦機基本上使用的都是雙曲面屏幕，這就讓很多喜歡直屏的愛好者在苦等一款直屏旗艦，這次，你們等到了。據博主數碼閑聊站帶來的最新爆料稱，Redmi下代旗艦K70 Pro和iQOO 12兩款手
NameServer 是專為 RocketMQ 設計的輕量級名字服務，它的源碼非常精簡，八個類 ，少于1000行代碼。
圖片
這篇文章， 筆者會從基礎概念、Broker發送心跳包、NameServer 維護路由、Zookeeper vs NameServer 四個模塊揭秘名字服務的設計精髓。
圖片
NameServer 是一個非常簡單的 Topic 路由注冊中心，其角色類似 Dubbo 中的 zookeeper ，支持 Broker 的動態注冊與發現。
RocketMQ 集群工作流程：
1、NameServer 啟動服務，監聽 TCP 端口 ， 集群多節點之間無任何信息交互，然后等待 Broker、Producer 、Consumer 連上來；
2、Broker 啟動后，每隔 30 秒向所有的 NameServer 發送心跳命令 ；
3、NameServer 接收到請求之后，保存路由信息在本地內存里 ，將響應結果返給 Broker 服務；
4、Producer 啟動之后，會隨機的選擇一個 NameServer ，并從 NameServer 中獲取當前發送的 Topic 存在哪些 Broker 上，輪詢從隊列列表中選擇一個隊列，然后與隊列所在的 Broker 建立長連接從而向 Broker 發消息；
5、Consumer 跟 Producer 類似，跟其中一臺 NameServer 建立長連接，獲取當前訂閱 Topic 存在哪些 Broker 上，然后直接跟 Broker 建立連接通道，開始消費消息。
我們貼一段 Broker 發送心跳命令的源碼：
圖片
1、Broker 會每隔 30 秒向所有的 NameServer 發送心跳命令 ；
使用 CountDownLatch 實現多線程同步，可以獲取發往所有的 NameServer 的心跳命令的響應結果
2、心跳命令包含兩個部分：請求頭和請求體
圖片
NameServer 在接收到 Broker 發送的心跳請求之后，通過默認的處理器來處理請求，保存路由信息成功后，注冊成功狀態返回給 Broker 服務。
源碼中，我們可以看到路由信息保存在 HashMap 中 。
圖片
1、topicQueueTable：Topic 消息隊列路由信息，包括 topic 所在的 broker 名稱，讀隊列數量，寫隊列數量，同步標記等信息，rocketmq 根據 topicQueueTable 的信息進行負載均衡消息發送。
2、brokerAddrTable：Broker 節點信息，包括 brokername，所在集群名稱，還有主備節點信息。
3、clusterAddrTable：Broker 集群信息，存儲了集群中所有的 Brokername。
4、brokerLiveTable：Broker 狀態信息，NameServer 每次收到 Broker 的心跳包就會更新該信息。
當 Broker 向 NameServer 發送心跳包（路由信息），NameServer 需要對 HashMap 進行數據更新，但我們都知道 HashMap 并不是線程安全的，高并發場景下，容易出現 CPU 100% 問題，所以更新 HashMap 時需要加鎖，RocketMQ 使用了 JDK 的讀寫鎖 ReentrantReadWriteLock 。
下面我們看下路由信息如何更新和讀取：
1、寫操作：更新路由信息，操作寫鎖
圖片
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.www897cc.com/showinfo-26-5193-0.html聊聊 RocketMQ 名字服務
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號