RocketMQ(九)：消息發送（續）

匠心零度 轉載請註明原創出處，謝謝！

RocketMQ網絡部署圖

• NameServer：在系統中是作命名服務，更新和發現 broker服務。
• Broker-Master：broker 消息主機服務器。
• Broker-Slave： broker 消息從機服務器。
• Producer： 消息生產者。
• Consumer： 消息消費者。

說明： rocketmq系列都將會以rocketmq-4.1.0-incubating進行介紹。

在閱讀源碼時作了必定的註釋，公衆號【匠心零度】回覆：rocketmq，可得到基於rocketmq4.1.0加詳細中文代碼註釋 。歡迎你們 star、fork ！

上篇RocketMQ(八)：消息發送主要分析了下通常發送流程，本篇將會介紹下定時發送，順序發送，批量發送等狀況 。

消息發送概述

上面的圖大概就是producer發送message到broker的核心邏輯了。

備註：本篇將會介紹下定時發送，順序發送，批量發送狀況 ，這些狀況說明都是站在producer角度進行說明，涉及到broker的內容會在分析broker相關內容的時候進行分析。

定時發送

何爲定時消息

Producer 將消息發送到 MQ 服務端，但並不指望這條消息立馬投遞，而是延遲必定時間後才投遞到 Consumer 進行消費。

調用形式

與普通的調用發送基本沒有什麼區別，惟一就是多了一個消息設置setDelayTimeLevel便可。代碼調用如圖：

那麼這裏的級別應該填寫什麼呢？對應什麼呢？--->這塊後續會分析，今天這裏簡單說明下：

其餘的就和普通發送沒有任何區別了，關鍵處理在broker，後續分析。

順序發送

何爲順序發送

參考：https://help.aliyun.com/document_detail/49319.html?spm=a2c4g.11186623.2.3.21aKRd

調用形式

咱們來看看具體內容實現調用就明白怎麼回事了：

• 獲取到全部可發送的信息

• 發送內容

• 用來區分（好比訂單號，這一類的訂單號是有順序的，可是和其餘訂單號能夠無序）

sendResult = producer.send(msg, new MessageQueueSelector() {
                    @Override
                    public MessageQueue select(List<MessageQueue> mqs, Message msg, Object arg) {
                        Integer id = (Integer) arg;
                        int index = id % mqs.size();
                        return mqs.get(index);
                    }
                }, orderId);

這裏mqs就是獲取到全部可發送的信息，而orderId就是用來區分的，每次拿這個orderId和全部的進行取模（若是全部的沒有變化的狀況下面）那麼一種都是固定的那個隊列了（隊列就是先進先出了），後續消費在分析消費如何處理這塊。

備註：這裏的順序也是相對的，若是添加了broker或者broker減小了，那麼取模的信息勢必會不一致，因此須要明白下。

批量發送

何爲批量發送

批量這個概念我相信你們必定都很是熟悉了，在不少調優的時候，好比數據庫批量處理，有些請求進行合併發送等都是相似實現，那麼rocketmq批量發送也是爲了追求性能，特別在數量量級特別大的時候，批量效果就很是明顯了。

備註：既然是批量就是等一批以後發送，那麼實時性必定可能就稍微有點點延遲了（能夠忽略，特別數據量多的狀況）。我通常處理批量的就2個維度，達到一個就能夠觸發，1.達到給定條數 2.達到給定時間（好比3s一次，若是這個時候數據量仍是不夠也會進行發送）……

rocketmq只是提供接口，發送一批數據，那麼什麼時候發送這一批數據就是根據本身的選擇，就是上面說的兩條就是通常的作法：

• 達到給定條數 。
• 達到給定時間。

調用形式

rocketmq這裏有一個好處，就是在批量發送的時候，會作一個簡單的轉換，減小網絡傳輸，學習下：

把這些轉化爲a、b、c等形式。

咱們來看看rocketmq給咱們的批量發送的例子，爲何會給咱們2個例子呢？須要思考！！！，下面我會來爲你們講解下：

備註： 批量發送須要相同的topic以及相同的waitStoreMsgOK 和不支持定時發送。

Messages of the same batch should have: same topic, same waitStoreMsgOK and no schedule support。

這種發送就是批量（這裏的批量不是特別大），就本身發送走了。

這裏的批量（批量的數據太多），因此進行分割以後發送了。最後調用的方法仍是同樣的。

咱們知道目前rocketmq默認支持4M發送消息內容（無論是一條仍是批量），假如須要調整也能夠調整，那麼會一直沒有上限嗎？還有不少人說調整了10M爲何沒有生效（這裏是須要Producer和服務端broker都調整才行，後續說明解釋，還有因爲是基於netty網絡傳輸，可能你須要看看RocketMQ(二)：RPC通信，這裏進行了說明）

這裏決定了最大最大隻能是16M，若是須要就須要修改了，通常也不建議修改，就和批量發送的第二個方式同樣就行，進行拆開批量發送就是了。

---

若是讀完以爲有收穫的話，歡迎點贊、關注、加公衆號【匠心零度】，查閱更多精彩歷史！！！

加入知識星球，一塊兒探討！