俄羅斯：將審查iPhone等外國公司設(shè)備 保數(shù)據(jù)安全
iPhone和特斯拉都屬于在各自領(lǐng)域領(lǐng)頭羊的品牌，推出的產(chǎn)品也也都是數(shù)一數(shù)二的，但對于一些國家而言，它們的產(chǎn)品可靠性和安全性還是在限制范圍內(nèi)。近日，俄羅斯聯(lián)邦通信、信息技術(shù)
NameServer 是專為 RocketMQ 設(shè)計的輕量級名字服務(wù)，它的源碼非常精簡，八個類 ，少于1000行代碼。
圖片
這篇文章， 筆者會從基礎(chǔ)概念、Broker發(fā)送心跳包、NameServer 維護路由、Zookeeper vs NameServer 四個模塊揭秘名字服務(wù)的設(shè)計精髓。
圖片
NameServer 是一個非常簡單的 Topic 路由注冊中心，其角色類似 Dubbo 中的 zookeeper ，支持 Broker 的動態(tài)注冊與發(fā)現(xiàn)。
RocketMQ 集群工作流程：
1、NameServer 啟動服務(wù)，監(jiān)聽 TCP 端口 ， 集群多節(jié)點之間無任何信息交互，然后等待 Broker、Producer 、Consumer 連上來；
2、Broker 啟動后，每隔 30 秒向所有的 NameServer 發(fā)送心跳命令 ；
3、NameServer 接收到請求之后，保存路由信息在本地內(nèi)存里 ，將響應(yīng)結(jié)果返給 Broker 服務(wù)；
4、Producer 啟動之后，會隨機的選擇一個 NameServer ，并從 NameServer 中獲取當前發(fā)送的 Topic 存在哪些 Broker 上，輪詢從隊列列表中選擇一個隊列，然后與隊列所在的 Broker 建立長連接從而向 Broker 發(fā)消息；
5、Consumer 跟 Producer 類似，跟其中一臺 NameServer 建立長連接，獲取當前訂閱 Topic 存在哪些 Broker 上，然后直接跟 Broker 建立連接通道，開始消費消息。
我們貼一段 Broker 發(fā)送心跳命令的源碼：
圖片
1、Broker 會每隔 30 秒向所有的 NameServer 發(fā)送心跳命令 ；
使用 CountDownLatch 實現(xiàn)多線程同步，可以獲取發(fā)往所有的 NameServer 的心跳命令的響應(yīng)結(jié)果
2、心跳命令包含兩個部分：請求頭和請求體
圖片
NameServer 在接收到 Broker 發(fā)送的心跳請求之后，通過默認的處理器來處理請求，保存路由信息成功后，注冊成功狀態(tài)返回給 Broker 服務(wù)。
源碼中，我們可以看到路由信息保存在 HashMap 中 。
圖片
1、topicQueueTable：Topic 消息隊列路由信息，包括 topic 所在的 broker 名稱，讀隊列數(shù)量，寫隊列數(shù)量，同步標記等信息，rocketmq 根據(jù) topicQueueTable 的信息進行負載均衡消息發(fā)送。
2、brokerAddrTable：Broker 節(jié)點信息，包括 brokername，所在集群名稱，還有主備節(jié)點信息。
3、clusterAddrTable：Broker 集群信息，存儲了集群中所有的 Brokername。
4、brokerLiveTable：Broker 狀態(tài)信息，NameServer 每次收到 Broker 的心跳包就會更新該信息。
當 Broker 向 NameServer 發(fā)送心跳包（路由信息），NameServer 需要對 HashMap 進行數(shù)據(jù)更新，但我們都知道 HashMap 并不是線程安全的，高并發(fā)場景下，容易出現(xiàn) CPU 100% 問題，所以更新 HashMap 時需要加鎖，RocketMQ 使用了 JDK 的讀寫鎖 ReentrantReadWriteLock 。
下面我們看下路由信息如何更新和讀取：
1、寫操作：更新路由信息，操作寫鎖
圖片
2、讀操作：查詢主題信息，操作讀鎖
圖片
我們可以將 NameServer 實現(xiàn)注冊中心的方式總結(jié)為：RPC 服務(wù) + HashMap 存儲容器 + 讀寫鎖 + 定時任務(wù) 。
1、NameServer 監(jiān)聽固定的端口，提供 RPC 服務(wù)
2、HashMap 作為存儲容器
3、讀寫鎖控制鎖的顆粒度
4、定時任務(wù)
那為什么 RocketMQ 不用 Zookeeper 做為注冊中心呢 ？
我們先溫習下 CAP 理論。
圖片
CAP 理論是分布式架構(gòu)中重要理論。
1、一致性( Consistency ) ：所有節(jié)點在同一時間具有相同的數(shù)據(jù) ;
2、可用性( Availability ) ：保證每個請求不管成功或者失敗都有響應(yīng) (某個系統(tǒng)的某個節(jié)點掛了，但是并不影響系統(tǒng)的接受或者發(fā)出請求) ;
3、分隔容忍( Partition tolerance ) ：系統(tǒng)中任意信息的丟失或失敗不會影響系統(tǒng)的繼續(xù)運作。 (在整個系統(tǒng)中某個部分，掛掉了，或者宕機了，并不影響整個系統(tǒng)的運作或者說使用) 。
Zookeeper 是一個典型的 CP 注冊中心 ，通過使 ZAB 協(xié)議來保證節(jié)點之間數(shù)據(jù)的強一致性。
筆者曾經(jīng)遇到過一起神州專車服務(wù)宕機事故，zookeeper 集群不堪重負，一直在選主 。架構(gòu)負責人修改了 zookeeper 的 jvm 參數(shù)，重啟集群后 , 才臨時解決了問題。
因為 MetaQ 集群和服務(wù)治理共用一組 zookeeper 集群 。
為了減少 zookeeper 集群的性能壓力，架構(gòu)團隊將 MetaQ 使用的 zookeeper 集群獨立出來。
這次事故讓我認識到：Zookeeper 作為 CP 注冊中心，大規(guī)模使用場景下，它就變得很脆弱，我們要非常小心的使用。
淘寶中間件博客出了一篇文章 : 阿里巴巴為什么不用 ZooKeeper 做服務(wù)發(fā)現(xiàn) ？
文章有兩個觀點，筆者認為非常有借鑒意義。
1、當數(shù)據(jù)中心服務(wù)規(guī)模超過一定數(shù)量 ( 服務(wù)規(guī)模=F{服務(wù) pub 數(shù),服務(wù) sub 數(shù)} )，作為注冊中心的 ZooKeeper 很快就會像下圖的驢子一樣不堪重負。
2、可以使用 ZooKeeper，但是大數(shù)據(jù)請向左，而交易則向右，分布式協(xié)調(diào)向左，服務(wù)發(fā)現(xiàn)向右。
相比 ZooKeeper ，NameServer 是一個典型的 AP 注冊中心，它有如下優(yōu)點：
1、代碼不到 1000 行，實現(xiàn)簡單，易于維護 ;
2、性能極好，除了網(wǎng)絡(luò)消耗，基本都是本地內(nèi)存操作 ;
3、服務(wù)都是無狀態(tài)，且節(jié)點之間并不交互，運維簡單；
RocketMQ 的設(shè)計者之所以選擇自研名字服務(wù)，遵循著架構(gòu)設(shè)計的準則，筆者總結(jié)為：簡單、高效、適當妥協(xié)。
本文鏈接：http://www.tebozhan.com/showinfo-26-5193-0.html聊聊 RocketMQ 名字服務(wù)
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網(wǎng)安備 12010102000574號