kafka是乙個分布式流平台，它源自於日誌聚合案例,它不需要太高的併發性.在阿里巴巴的一些大型案例中，發現原來的模式已經不能滿足的實際需求。因此，開發了乙個名為rocketmq的訊息中介軟體，它可以處理廣泛的場景，從傳統的發布/訂閱場景到要求高容量、不允許訊息丟失的實時事務系統等。
如何選擇kafka集群中topic分割槽數量
優勢:每個消費佇列都變得輕量化，並且包含有限數量的元資料（資料量變少）。
對磁碟的訪問是完全連續的，這樣可以避免磁碟鎖爭奪，並且在建立大量佇列時不會導致高磁碟io等待。
劣勢:消費訊息將首先讀取消費佇列，然後提交日誌，在最壞的情況下，過程會帶來一定的成本。
提交日誌和使用佇列需要邏輯一致，這會給程式設計模型帶來額外的複雜性。
隨機讀:盡可能多地讀取以增加頁面快取命中率，並減少讀取io操作。所以在大記憶體情況下是仍然是適合的。如果積壓了大量的訊息，讀取的效能會嚴重下降嗎？答案是否定的。
原因如下：
由於consumequeue只儲存固定大小的元資料，主要用於記錄消費過程，因此支援隨機讀取。利用頁面快取預取，即使是在大量訊息積累的情況下，訪問consumequeue的速度與訪問主記憶體一樣快。因此,consumequeue不會帶來明顯的讀取效能影響。
commitlog幾乎儲存所有資訊，包括訊息資料。與關聯式資料庫的重做日誌類似，只要存在提交日誌，就可以完全恢復使用佇列、訊息鍵索引和所有其他所需資料。
RocketMQ如何支援更多佇列（翻譯）
kafka是乙個分布式流處理平台，它誕生自日誌聚合案例。它不需要太高的併發性。在阿里的大規模案例中，我們發現 原始模式不能滿足我們的事件需求。因此，我們開發了乙個名為rocketmq的訊息中介軟體，來解決更廣泛的使用場景，從傳統的發布 訂閱情景到超大容量的不容忍訊息丟失的事物系統。現在，在阿里，ro...
rocketmq 訊息佇列
rocketmq 是乙個分布式的訊息佇列，主要有product,broker,consumer,nameserver組成，提供流量的削峰填谷，非同步通知，應用解耦的功能。rocketmq和kafka功能上比較相似，但是在底層架構上還是有很多不同，比如kafka中每個topic下的每個partitio...
訊息佇列（三）RocketMQ如何儲存訊息
rocket的訊息是有consume queue和commit log組成。consume queue consume queue是訊息的邏輯佇列，相當於字典目錄，用來指定訊息在物理檔案 commit log 上的位置，我們可以在配置中指定consumequeue和commitlog儲存的目錄。每乙...