98
技術社區[雲棲]
ONS(RocketMQ)為什麼能夠比Kafka支持更多的分區數量？
簡述: Kafka模型產生自日誌記錄場景，受到場景所限，Kafka不需要太高的並發度。而在阿裏這樣的大規模應用中，我們經過實踐發現，原有模型已經不能滿足阿裏的實際需要。ONS(RocketMQ)則比較好的解決了並發數問題，已經是內部非常廣泛使用的一套產品。
分區數量在Kafka中有什麼作用？
- Producer(消息發送者)的往消息Server的寫入並發數與分區數成正比。
- Consumer(消息消費者)消費某個Topic的並行度與分區數保持一致，假設分區數是20，那麼Consumer的消費並行度最大為20。
- 每個Topic由固定數量的分區數組成，分區數的多少決定了單台Broker能支持的Topic數量，Topic數量又決定了支持的業務數量。
為什麼Kafka不能支持更多的分區數？
- 每個分區存儲了完整的消息數據，雖然每個分區寫入是磁盤順序寫，但是多個分區同時順序寫入在操作係統層麵變為了隨機寫入。
- 由於數據分散為多個文件，很難利用IO層麵的Group Commit機製，網絡傳輸也會用到類似優化算法。
Alibaba ONS（Also RocketMQ）如何支持更多分區數?
- 所有數據單獨存儲到一個Commit Log，完全順序寫，隨機讀。
- 對最終用戶展現的隊列實際隻存儲消息在Commit Log的位置信息，並且串行方式刷盤。
這樣做的好處如下：
- 隊列輕量化，單個隊列數據量非常少。
- 對磁盤的訪問串行化，避免磁盤竟爭，不會因為隊列增加導致IOWAIT增高。
每個方案都有缺點，它的缺點如下：
- 寫雖然完全是順序寫，但是讀卻變成了隨機讀。
- 讀一條消息，會先讀Consume Queue，再讀Commit Log，增加了開銷。
- 要保證Commit Log與Consume Queue完全的一致，增加了編程的複雜度。
以上缺點如何克服：
-
隨機讀，盡可能讓讀命中PAGECACHE，減少IO讀操作，所以內存越大越好。如果係統中堆積的消息過多，讀數據要訪問磁盤會不會由於隨機讀導致係統性能急劇下降，答案是否定的。
- 訪問PAGECACHE時，即使隻訪問1k的消息，係統也會提前預讀出更多數據，在下次讀時，就可能命中內存。
- 隨機訪問Commit Log磁盤數據，係統IO調度算法設置為NOOP方式，會在一定程度上將完全的隨機讀變成順序跳躍方式，而順序跳躍方式讀較完全的隨機讀性能會高5倍以上，可參見以下針對各種IO方式的性能數據。 https://stblog.baidu-tech.com/?p=851 另外4k的消息在完全隨機訪問情況下，仍然可以達到8K次每秒以上的讀性能。
-
由於Consume Queue存儲數據量極少，而且是順序讀，在PAGECACHE預讀作用下，Consume Queue的讀性能幾乎與內存一致，即使堆積情況下。所以可認為Consume Queue完全不會阻礙讀性能。
- Commit Log中存儲了所有的元信息，包含消息體，類似於Mysql、Oracle的redolog，所以隻要有Commit Log在，Consume Queue即使數據丟失，仍然可以恢複出來。
聯係本文作者
該文章轉載自：
最後更新：2017-04-01 13:37:06