RocketMQ如何支援更多佇列（翻譯）

kafka是乙個分布式流處理平台，它誕生自日誌聚合案例。它不需要太高的併發性。在阿里的大規模案例中，我們發現

原始模式不能滿足我們的事件需求。因此，我們開發了乙個名為rocketmq的訊息中介軟體，來解決更廣泛的使用場景，從傳統的發布/訂閱情景到超大容量的不容忍訊息丟失的事物系統。現在，在阿里，rocketmq集群每天處理超過5000億次事件，為3000多核心應用提供服務。

生產者的並行寫受分割槽數量的限制。

消費者的消費並行級別同樣受到消費分割槽數量的限制。假設最大分割槽數量是20，當前消費中的消費者最大數量也只能是20.

每個主題由固定數量的分割槽組成。分割槽數量決定單個broker可能擁有的最大主題數，而不會顯著的影響效能。

更多詳情請參考這裡

每個分割槽都儲存著所有的訊息資料。儘管每個分割槽都按照順序寫盤，但隨著併發寫入分割槽的數量增加，從作業系統層面來說，寫入就變的隨機。

由於資料檔案的分散，使用linux io組提交機制會比較困難。

所有的訊息資料儲存在提交日誌檔案。所有的寫操作都是完全有序的，而讀操作是隨機的。

消費佇列儲存使用者實際消費位置資訊，這些訊息也可以以順序方式刷到磁碟。

優勢每個訊息佇列都是輕量級的，並且包含有限的元資料。

訪問磁碟是完全按序的，這也會避免磁碟鎖的爭奪，當大量佇列被建立也不會引發高磁碟io等待。

劣勢訊息消費會首先讀取消費佇列，然後是提交日誌。這個過程將會帶來一定的成本，在最壞的情況下。

提交日誌和消費佇列需要保證邏輯一致，這將會給程式設計模型帶來額外的複製性。

動機隨機讀。盡可能多的讀取以提高頁面快取的命中率，減少讀取io操作。因此大容量記憶體依然是更可取的。如果大量訊息堆積，讀效能會不會下降很嚴重？答案是否定的，理由如下：

1,即使訊息的大小只有1kb，系統也會提前讀取更多資料。這意味著後續資料的讀取，這將訪問主儲存器，而不是緩慢的磁碟io讀取。 2,從磁碟隨機訪問提交日誌。在ssd情況下將i/o調動程式設定為noop，讀qps將顯著提速，這樣會比電梯排程演算法更快。

鑑於消費佇列僅儲存固定大小的元資料，主要用來記錄消費進度，因此會很好的支援隨機讀。擁有頁面快取預取的優勢，訪問消費佇列同訪問主記憶體一樣快，即使在大量訊息堆積的情況下。作為結果，消費佇列不會對讀效能帶來明顯的損失。

提交日誌儲存幾乎所有的資訊，包括訊息資料。類似關聯式資料庫的重做日誌，只要提交日誌存在，消費佇列，訊息健索引和所有其他所需資料都能被完全恢復。