在日常系統(tǒng)里會系統(tǒng)解耦、異步調(diào)用、流量削峰的時候使用消息中間件，在系統(tǒng)里被使用到的MQ主要有：RocketMQ、kafka，考慮到避免引入多種中間件，降低業(yè)務的下游系統(tǒng)需要同時接入多種消息中間，想討論是否可以選擇一種消息中間件，后續(xù)大家都盡量使用統(tǒng)一的MQ作為技術(shù)棧。
簡單介紹：
RocketMQ
RocketMQ是一款阿里巴巴開源的消息中間件，在2017年9月份成為Apache的頂級項目，是國內(nèi)首個互聯(lián)網(wǎng)中間件在 Apache 上的頂級項目。
RocketMQ的起源受到另一款消息中間件Kafka的啟發(fā)。最初，淘寶內(nèi)部的交易系統(tǒng)使用了淘寶自主研發(fā)的Notify消息中間件，使用Mysql作為消息存儲媒介，可完全水平擴容。為了進一步降低成本和提升寫入性能，需要在存儲部分可以進一步優(yōu)化，2011年初，Linkin開源了Kafka這個優(yōu)秀的消息中間件，淘寶中間件團隊在對Kafka做過充分Review之后，被Kafka無限消息堆積，高效的持久化速度所吸引。
不過當時Kafka主要定位于日志傳輸，對于使用在淘寶交易、訂單、充值等場景下還有諸多特性不滿足，例如：延遲消息，消費重試，事務消息，消息過濾等，這些都是一些企業(yè)級消息中間件需要具備的功能。為此，淘寶中間件團隊重新用Java語言編寫了RocketMQ，定位于非日志的可靠消息傳輸。不過隨著RocketMQ的演進，現(xiàn)在也支持了日志流式處理。
目前RocketMQ經(jīng)過了阿里多年雙十一大促的考驗，性能和穩(wěn)定性得到了充分的嚴重。目前在業(yè)界被廣泛應用在訂單，交易，充值，流計算，消息推送，日志流式處理，binlog分發(fā)等場景。
Kafka
Kafka是由Apache軟件基金會開發(fā)的一個開源流處理平臺，由Scala和Java編寫。Kafka是一種高吞吐量的分布式發(fā)布訂閱消息系統(tǒng)，它可以處理消費者在網(wǎng)站中的所有動作流數(shù)據(jù)。 這種動作（網(wǎng)頁瀏覽，搜索和其他用戶的行動）是在現(xiàn)代網(wǎng)絡(luò)上的許多社會功能的一個關(guān)鍵因素。 這些數(shù)據(jù)通常是由于吞吐量的要求而通過處理日志和日志聚合來解決。 對于像Hadoop一樣的日志數(shù)據(jù)和離線分析系統(tǒng)，但又要求實時處理的限制，這是一個可行的解決方案。Kafka的目的是通過Hadoop的并行加載機制來統(tǒng)一線上和離線的消息處理，也是為了通過集群來提供實時的消息
對比維度
數(shù)據(jù)可靠性
RocketMQ支持異步實時刷盤，同步刷盤，同步復制，異步復制
Kafka使用異步刷盤方式，異步復制/同步復制
總結(jié)：RocketMQ的同步刷盤在單機可靠性上比Kafka更高，不會因為操作系統(tǒng)Crash，導致數(shù)據(jù)丟失。Kafka同步Replication理論上性能低于RocketMQ的同步Replication，原因是Kafka的數(shù)據(jù)以分區(qū)為單位組織，意味著一個Kafka實例上會??有幾百個數(shù)據(jù)分區(qū)，RocketMQ一個實例上只有一個數(shù)據(jù)分區(qū)，RocketMQ可以充分利用IO組Commit機制，批量傳輸數(shù)據(jù)，配置同步Replication與異步Replication相比，性能損耗約20%~30%，Kafka沒有親自測試過，但是個人認為理論上會低于RocketMQ
性能對比
Kafka單機寫入TPS約在百萬條/秒，消息大小10個字節(jié)
RocketMQ單機寫入TPS單實例約7萬條/秒，單機部署3個Broker，可以跑到最高12萬條/秒，消息大小10個字節(jié)
多Topic對性能穩(wěn)定性的影響
當topic的數(shù)量從64上升到256，Kafka的吞吐量下降了98.37%
當topic的數(shù)量從64上升到256，RocketMQ的吞吐量下降了16%
When the number of topics increases from 64 to 256, the throughput of Kafka dropped by 98.37%.
這種差異是由于Kafka的每個主題和分區(qū)對應于一個物理文件。當主題數(shù)量增加時，將消息分散存儲到磁盤的策略將導致磁盤IO競爭，從而導致性能瓶頸。相反，Apache RocketMQ中的所有消息存儲在同一物理文件中。主題和分區(qū)的數(shù)量只是Apache RocketMQ的邏輯劃分?. 所以越來越多的主題不會對ApacheRocketMQ產(chǎn)生巨大的影響性能
消費失敗重試
卡夫卡消費失敗不支持重試。
RocketMQ消費失敗支持定時重試，每次重試間隔時間順延
總結(jié)：例如充值類應用，當前時刻調(diào)用運營商網(wǎng)關(guān)，充值失敗，可能是對方壓力過多，稍后再調(diào)用就會成功，如支付寶到銀行扣款也是類似需求。這里的重試需要可靠的重試，即失敗重試的消息不因為Consumer宕機導致丟失
嚴格的消息順序
卡夫卡支持消息順序，但是一臺代理宕機后，就會產(chǎn)生消息亂序
RocketMQ支持嚴格的消息順序，在順序消息場景下，一臺Broker宕機后，發(fā)送消息會失敗，但是不會亂序
開源社區(qū)活躍度和開源技術(shù)支持
卡夫卡社區(qū)人氣火爆
RocketMQ的GitHub更新較慢
|
|
Reference:
https://www.confluent.io/blog/how-choose-number-topics-partitions-kafka-cluster/
https://www.alibabacloud.com/blog/kafka-vs-rocketmq--multiple-topic-stress-test-results_69781
