rocketmq-remoting 模塊是 RocketMQ 中負(fù)責(zé)網(wǎng)絡(luò)通信的模塊，被其他所有需要網(wǎng)絡(luò)通信的模塊依賴。它是基于 Netty 實(shí)現(xiàn)的，避免了網(wǎng)絡(luò)編程很多 tricky 的問題。

首先來看下 RocketMQ NettyServer 的 Reactor 線程模型，一個 Reactor 主線程負(fù)責(zé)監(jiān)聽 TCP 連接請求，建立好連接后丟給 Reactor 線程池，它負(fù)責(zé)將建立好連接的 socket 注冊到 selector 上去（這里有兩種方式，NIO和Epoll，可配置），然后監(jiān)聽真正的網(wǎng)絡(luò)數(shù)據(jù)。拿到網(wǎng)絡(luò)數(shù)據(jù)后，再丟給 Worker 線程池。

Worker 拿到網(wǎng)絡(luò)數(shù)據(jù)后，就交給 Pipeline，從 Head 到 Tail 一個個 Handler 的走下去，這些 Handler 是在創(chuàng)建 Server 的時候指定的。NettyEncoder 和 NettyDecoder 負(fù)責(zé)網(wǎng)絡(luò)數(shù)據(jù)和 RemotingCommand 之間的編解碼。

NettyServerHandler 拿到解碼得到的 RemotingCommand 后，根據(jù) RemotingCommand.type 來判斷是 request 還是 response，如果是 request, 就根據(jù) RomotingCommand 的 code(code用來標(biāo)識不同類型的請求) 去 processorTable 找到對應(yīng)的 processor,然后封裝成 task 后，丟給對應(yīng)的 processor 線程池, 如果是 response 就根據(jù)RemotingCommand.opaque 去 responseTable 中拿到對應(yīng)的 ResponseFuture,把結(jié)果 set 給它。

對于 Client，經(jīng)過 Pipeline 的順序是從 Tail 到 Head。不管是 Server 和 Client，并不是每次數(shù)據(jù)流轉(zhuǎn)都得經(jīng)過所有的 Handler，而是會根據(jù) Context 中的一些信息去判斷。

整個數(shù)據(jù)流轉(zhuǎn)過程中還有很多hook, 比如處理 command 前，處理 command 后，發(fā)送數(shù)據(jù)前，發(fā)送數(shù)據(jù)后等。

關(guān)于 Netty 的一些關(guān)鍵知識點(diǎn)，Netty學(xué)習(xí)筆記?中做了些總結(jié)。

以上所有扯淡都是基于源碼?https://github.com/apache/incubator-rocketmq?(tag:rocketmq-all-4.1.0-incubating)所貼代碼有所刪減。

標(biāo)簽： 代碼 通信 網(wǎng)絡(luò)

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。