共計 3777 個字符，預計需要花費 10 分鐘才能閱讀完成。
這篇文章主要介紹了 RocketMQ 有哪些特性，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓丸趣 TV 小編帶著大家一起了解一下。
一 nameserver
相對來說，nameserver 的穩定性非常高。原因有二：
1 nameserver 互相獨立，彼此沒有通信關系，單臺 nameserver 掛掉，不影響其他 nameserver，即使全部掛掉，也不影響業務系統使用，這點類似于 dubbo 的 zookeeper。
2 nameserver 不會有頻繁的讀寫，所以性能開銷非常小，穩定性很高。
二 broker
1 與 nameserver 關系
連接
單個 broker 和所有 nameserver 保持長連接
心跳
心跳間隔：每隔 30 秒（
此時間無法更改）向所有 nameserver 發送心跳，心跳包含了自身的 topic 配置信息。
心跳超時：nameserver 每隔 10 秒鐘（
此時間無法更改），掃描所有還存活的 broker 連接，若某個連接 2 分鐘內（
當前時間與最后更新時間差值超過 2 分鐘，此時間無法更改）沒有發送心跳數據，則斷開連接。
斷開
時機：broker 掛掉；心跳超時導致 nameserver 主動關閉連接
動作：一旦連接斷開，nameserver 會立即感知，更新 topc 與隊列的對應關系，但不會通知生產者和消費者
2 負載均衡
一個 topic 分布在多個 broker 上，一個 broker 可以配置多個 topic，它們是多對多的關系。
如果某個 topic 消息量很大，應該給它多配置幾個隊列，并且盡量多分布在不同 broker 上，減輕某個 broker 的壓力。
topic 消息量都比較均勻的情況下，如果某個 broker 上的隊列越多，則該 broker 壓力越大。
3 可用性
由于消息分布在各個 broker 上，一旦某個 broker 宕機，則該 broker 上的消息讀寫都會受到影響。所以 rocketmq 提供了 master/slave 的結構，salve 定時從 master 同步數據，如果 master 宕機，則 slave 提供消費服務，但是不能寫入消息，此過程對應用透明，由 rocketmq 內部解決。
這里有兩個關鍵點：
一旦某個 broker master 宕機，生產者和消費者多久才能發現？受限于 rocketmq 的網絡連接機制，默認情況下，最多需要 30 秒，但這個時間可由應用設定參數來縮短時間。這個時間段內，發往該 broker 的消息都是失敗的，而且該 broker 的消息無法消費，因為此時消費者不知道該 broker 已經掛掉。
消費者得到 master 宕機通知后，轉向 slave 消費，但是 slave 不能保證 master 的消息 100% 都同步過來了，因此會有少量的消息丟失。但是消息最終不會丟的，一旦 master 恢復，未同步過去的消息會被消費掉。
4 可靠性
所有發往 broker 的消息，有同步刷盤和異步刷盤機制，總的來說，可靠性非常高
同步刷盤時，消息寫入物理文件才會返回成功，因此非?？煽?
異步刷盤時，只有機器宕機，才會產生消息丟失，broker 掛掉可能會發生，但是機器宕機崩潰是很少發生的，除非突然斷電
5 消息清理
掃描間隔
默認 10 秒，由 broker 配置參數
cleanResourceInterval
決定
空間閾值
物理文件不能無限制的一直存儲在磁盤，當磁盤空間達到閾值時，不再接受消息，broker 打印出日志，消息發送失敗，閾值為固定值 85%
清理時機
默認每天凌晨 4 點，由 broker 配置參數
deleteWhen 決定；或者磁盤空間達到閾值
文件保留時長
默認 72 小時，由 broker 配置參數
fileReservedTime
決定
6 讀寫性能
文件內存映射方式操作文件，避免 read/write 系統調用和實時文件讀寫，性能非常高
永遠一個文件在寫，其他文件在讀
順序寫，隨機讀
利用 linux 的 sendfile 機制，將消息內容直接輸出到 sokect 管道，避免系統調用
7 系統特性
大內存，內存越大性能越高，否則系統 swap 會成為性能瓶頸
IO 密集
cpu load 高，使用率低，因為 cpu 占用后，大部分時間在 IO WAIT
磁盤可靠性要求高，為了兼顧安全和性能，采用 RAID10 陣列
磁盤讀取速度要求快，要求高轉速大容量磁盤
三 消費者
1 與 nameserver 關系
連接
單個消費者和一臺 nameserver 保持長連接，定時查詢 topic 配置信息，如果該 nameserver 掛掉，消費者會自動連接下一個 nameserver，直到有可用連接為止，并能自動重連。
心跳
與 nameserver 沒有心跳
輪詢時間
默認情況下，消費者每隔 30 秒從 nameserver 獲取所有 topic 的最新隊列情況，這意味著某個 broker 如果宕機，客戶端最多要 30 秒才能感知。該時間由
DefaultMQPushConsumer 的
pollNameServerInteval 參數決定，可手動配置。
2 與 broker 關系
連接
單個消費者和該消費者關聯的所有 broker 保持長連接。
心跳
默認情況下，消費者每隔 30 秒向所有 broker 發送心跳，該時間由 DefaultMQPushConsumer 的 heartbeatBrokerInterval 參數決定，可手動配置。broker 每隔 10 秒鐘（此時間無法更改），掃描所有還存活的連接，若某個連接 2 分鐘內（當前時間與最后更新時間差值超過 2 分鐘，此時間無法更改）沒有發送心跳數據，則關閉連接，并向該消費者分組的所有消費者發出通知，分組內消費者重新分配隊列繼續消費
斷開
時機：消費者掛掉；心跳超時導致 broker 主動關閉連接
動作：一旦連接斷開，broker 會立即感知到，并向該消費者分組的所有消費者發出通知，分組內消費者重新分配隊列繼續消費
3 負載均衡
集群消費模式下，一個消費者集群多臺機器共同消費一個 topic 的多個隊列，一個隊列只會被一個消費者消費。如果某個消費者掛掉，分組內其它消費者會接替掛掉的消費者繼續消費。
4 消費機制
本地隊列
消費者不間斷的從 broker 拉取消息，消息拉取到本地隊列，然后本地消費線程消費本地消息隊列，只是一個異步過程，拉取線程不會等待本地消費線程，這種模式實時性非常高。對消費者對本地隊列有一個保護，因此本地消息隊列不能無限大，否則可能會占用大量內存，本地隊列大小由
DefaultMQPushConsumer 的
pullThresholdForQueue 屬性控制，默認 1000，可手動設置
。
輪詢間隔
消息拉取線程每隔多久拉取一次？間隔時間由
DefaultMQPushConsumer 的
pullInterval
屬性控制，默認為 0，可手動設置。
消息消費數量
監聽器每次接受本地隊列的消息是多少條？這個參數由
DefaultMQPushConsumer 的
consumeMessageBatchMaxSize
屬性控制，默認為 1，可手動設置。
5 消費進度存儲
每隔一段時間將各個隊列的消費進度存儲到對應的 broker 上，該時間由
DefaultMQPushConsu
mer 的
persistConsumerOffsetInterval 屬性控制，默認為 5 秒，可手動設置。
6 如果一個 topic 在某 broker 上有 3 個隊列，一個消費者消費這 3 個隊列，那么該消費者和這個 broker 有幾個連接？
一個連接，消費單位與隊列相關，消費連接只跟 broker 相關，事實上，消費者將所有隊列的消息拉取任務放到本地的隊列，挨個拉取，拉取完畢后，又將拉取任務放到隊尾，然后執行下一個拉取任務
四 生產者
1 與 nameserver 關系
連接
單個生產者者和一臺 nameserver 保持長連接，定時查詢 topic 配置信息，如果該 nameserver 掛掉，生產者會自動連接下一個 nameserver，直到有可用連接為止，并能自動重連。
輪詢時間
默認情況下，生產者每隔 30 秒從 nameserver 獲取所有 topic 的最新隊列情況，這意味著某個 broker 如果宕機，生產者最多要 30 秒才能感知，在此期間，發往該 broker 的消息發送失敗。該時間由 DefaultMQProducer 的 pollNameServerInteval 參數決定，可手動配置。
心跳
與 nameserver 沒有心跳
2 與 broker 關系
連接
單個生產者和該生產者關聯的所有 broker 保持長連接。
心跳
默認情況下，生產者每隔 30 秒向所有 broker 發送心跳，該時間由 DefaultMQProducer 的 heartbeatBrokerInterval 參數決定，可手動配置。broker 每隔 10 秒鐘（此時間無法更改），掃描所有還存活的連接，若某個連接 2 分鐘內（當前時間與最后更新時間差值超過 2 分鐘，此時間無法更改）沒有發送心跳數據，則關閉連接。
連接斷開
移除 broker 上的生產者信息
3 負載均衡
生產者時間沒有關系，每個生產者向隊列輪流發送消息
感謝你能夠認真閱讀完這篇文章，希望丸趣 TV 小編分享的“RocketMQ 有哪些特性”這篇文章對大家有幫助，同時也希望大家多多支持丸趣 TV，關注丸趣 TV 行業資訊頻道，更多相關知識等著你來學習!
