柚子快報邀請碼778899分享：分布式中間件之RocketMq

http://yzkb.51969.com/

文章目錄

前言一、有序性二、Broker和NameServer的關系三、消費方式四、持久化五、MQ如何進行topic對應的隊列縮小六、事務消息七、消費方式總結

前言

本文主要是列舉一下學習RocketMq的過程中比較重要的概念及實現(xiàn)原理。

一、有序性

在使用MQ的過程中，大家關心的第一點應該是就是有序性，尤其是在分布式的環(huán)境中。RocketMq的有序性可以分為全局有序、局部有序。在分布式的環(huán)境下，全局有序的實現(xiàn)為：保證需要有序的Topic有且僅有一個隊列；而局部有序則是需要用戶在發(fā)送消息時，將需要有序的消息發(fā)送到同一個隊列上來保證有序。

二、Broker和NameServer的關系

RocketMq的整體架構分為Producer、Consumer、Broker、NameServer，大家對Broker和NameServer的關系及作用比較容易混淆。這里我們可以從微服務的角度來看，NameServer可以看作是一個“注冊中心”而Broker可以看做是一個“工做節(jié)點”。Broker啟動之后會主動向NameServer匯報自己的信息，NameServer則捏合奈各個Broker的數(shù)據(jù)，捏合后的結果就是整個集群元數(shù)據(jù)的體現(xiàn)。并支持Producer｜Consumer獲取路由信息（也就是Topic存在于哪一個Broker中）。 這里我們可以做一個小實驗，準備兩臺服務器，兩臺機器分別啟動一個Broker和NameServer，機器1的broker注冊到本機的NameServer上，機器2的Broker也注冊到機器1的NameServer上。 此時我們通過命令或者java客戶端去連接NameServer可以發(fā)現(xiàn)，如果連接機器1的NameServer可以讀取到兩個Broker內(nèi)的數(shù)據(jù)，但如果連接到機器2的NamerServer上則讀取不到數(shù)據(jù)。

三、消費方式

RocketMq的消費方式與其他同類型的MQ一樣，支持廣播消息和一對一消息。這里需要注意的是：集群模式的：offset偏移量是有集群來管理的；而廣播模式的偏移量是有Consumer自己來管理的。

四、持久化

任何中間件都逃不開的一個問題，就是持久化，RocketMq的持久化是通過一個commitLog文件來進行。所有的數(shù)據(jù)都會線性的append到這個commitLog文件中。既然是文件那就主要是有兩個問題，第一個數(shù)據(jù)是如何寫入文件；第二個consumer是如何讀取文件。我們先來說數(shù)據(jù)是如何寫入的，這里要結合相關系統(tǒng)IO的知識；首先我們需要根據(jù)配置判斷是是否開啟了堆外內(nèi)存，如果開啟了則封裝后的數(shù)據(jù)會首先寫入堆外內(nèi)存，然后會先執(zhí)行commit操作將數(shù)據(jù)提交到mappedFile中；如果沒有開啟堆外內(nèi)存則會直接寫入到MappedFile。 數(shù)據(jù)提交到內(nèi)存中以后，rocketMq會有特定的線程，將數(shù)據(jù)刷寫道磁盤中。 這里提一下SWAP，SWAP在內(nèi)存不足時時用硬盤的一部分空間作為緩存，如果開啟了，可能會導致數(shù)據(jù)還沒有寫入磁盤時被放到緩沖區(qū)中，當你準備寫入磁盤則需要從緩沖區(qū)再拿到內(nèi)存中，可能會降低效率。接下來講講如何讀?。? 當文件數(shù)據(jù)存儲到對應的commitLog后，broker也會consumerQueue來存儲消息在commit的偏移量，以及Index。consumer消費消息時，會先從自己對應的consumerQueue中讀取偏移量，然后去CommitLog中查找對應的消息。

五、MQ如何進行topic對應的隊列縮小

在使用過程中，一開始我們存在3個producer、3個consumer，隨著需求變化消息量減少，如何安全平穩(wěn)的進行縮小producer、consumer從而釋放資源。

六、事務消息

RocketMQ采用了兩段式提交來保證了最終一致性，Producer首先會向Broker發(fā)送半消息，此時Consumer是無法獲取到該消息的，半消息發(fā)送成功，用戶可以開始執(zhí)行本地的事務處理，如果事務處理失敗，則發(fā)送回滾消息、如果本地處理成功則發(fā)送提交消息。如果服務器此時當機，broker觸發(fā)check機制，主動調用用戶接口，來判斷是否本地事務處理成功，如果成功，則提交消息consumer可以消費到，反之則回滾消息。

七、消費方式

RocketMQ的消費方式分為推和拉兩種方式，但其實本質上都是拉的方式，推的方式只是由consumer主動定時去broker拉取消息。但是如果拉去到消息后邏輯處理失敗會怎辦？ Consumer拉去到消息以后如果本地邏輯處理失敗，Consumer會主動把消息發(fā)送回道broker中，broker利用延時隊列，重新將消息放回對應topic，由consumer繼續(xù)消費，沖過超過一定次數(shù)后，消息最終會放到死信隊列。

總結

以上就是在我學習RocketMQ的過程中遇到的一些問題，已經(jīng)個人認為比較重要的點。如果有什么不對的地方，希望大家一起評論探討一下。

柚子快報邀請碼778899分享：分布式中間件之RocketMq

http://yzkb.51969.com/

相關閱讀