相對來說，nameserver的穩定性非常高。原因有二：

1 nameserver互相獨立，彼此沒有通信關系，單臺nameserver掛掉，不影響其他nameserver，即使全部掛掉，也不影響業務系統使用，這點類似于dubbo的zookeeper。

2 nameserver不會有頻繁的讀寫，所以性能開銷非常小，穩定性很高。

二 broker

1 與nameserver關系

• 連接

? ? ?單個broker和所有nameserver保持長連接

• 心跳

? ? ?心跳間隔：每隔30秒（此時間無法更改）向所有nameserver發送心跳，心跳包含了自身的topic配置信息。

? ? ?心跳超時：nameserver每隔10秒鐘（此時間無法更改），掃描所有還存活的broker連接，若某個連接2分鐘內（當前時間與最后更新時間差值超過2分鐘，此時間無法更改）沒有發送心跳數據，則斷開連接。

• 斷開

? ? ?動作：一旦連接斷開，nameserver會立即感知，更新topic與隊列的對應關系，但不會通知生產者和消費者

?

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機制，將消息內容直接輸出到socket管道，避免系統調用

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的consumeMessageBatchMaxSize屬性控制，默認為1，可手動設置。

?

5 消費進度存儲

? ? ?每隔一段時間將各個隊列的消費進度存儲到對應的broker上，該時間由DefaultMQPushConsumer的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上的生產者信息

?

? ? ?生產者時間沒有關系，每個生產者向隊列輪流發送消息