基本對比資訊

而談到訊息系統的設計，就回避不了兩個問題：

1、訊息的順序問題

2、訊息的重複問題

關於這兩方面，RocketMQ的測試結果如下：

一、訊息順序讀寫

參考文章：http://www.jianshu.com/p/453c6e7ff81c

1、常規的理解是：在同一個佇列（分割槽）的訊息是按順序排列的。但測試結果如下：

單伺服器單個執行緒的Producer非同步生產資料，生產的資料都用同一個字串做hash，資料都分配在同一臺機器的同一個佇列。

單伺服器單Consumer配置1個或者10個執行緒一起消費，每次最多抓取1條或者1014條資料，結果：同一個執行緒同一批次取回來的資料，順序卻不一致。

例如，取回來的資料預期順序是：12、13、14、15、16……但結果卻是：13、14、15、16、12……

同一批次測試，所有環境都一樣，有一定機率（大概15%）會出現該情況。

原因：Producer非同步生產資料會導致資料亂序。即使是單執行緒的Producer。

解決方案：為保證生產的訊息順序一致，Producer需採用同步傳送資料，但是效能會大大下降（實測1851條/秒，同等情況下比kafka慢45%，不過一般情況下這效能也足夠了）。

二、訊息不丟失、不存在重複傳送

根據阿里的測試結論，RocketMQ和Kafka在 訊息不丟失 方面，做得差不多，伺服器基本上不會丟失資料。結論如下：

1、在Broker程序被Kill的場景（在訊息收發過程中，利用Kill -9 命令使Broker程序終止）， Kafka和RocketMQ都不丟訊息，可靠性都比較高。

2、在宿主機掉電的場景，在“同步刷盤”策略下，Kafka與RocketMQ均能做到不丟訊息，在“非同步刷盤”策略下，Kafka和RMQ都無法保證掉電後不丟訊息。

參考來源：http://jm.taobao.org/2016/04/28/kafka-vs-rocktemq-4/

在 訊息不重複 方面，RocketMQ和Kafka估計都差不多，在kill或者宕機時，都會存在資料重複，而且RocketMQ官方說明，RocketMQ無法保證資料不重複，建議通過業務手段來保證。

實際應用場景分析（RocketMQ）

1、保證訊息按順序寫入和讀取

1)順序寫入（前提：單機，或者 叢集但是每個節點來源資料不同）

原理：

  在同一個佇列（分割槽）的訊息是按順序排列的。（跟Kafka一樣，只不過kafka的分割槽為物理分割槽，rocketMQ的佇列是邏輯分割槽）

故，要保證訊息按順序處理，必須把它們放在同一個佇列中。

實現方式：但producer同步傳送資料，按orderid hash來區分佇列存放資料。

單執行緒版：RocketMQ使用單執行緒同步寫入訊息到topic裡面，topic使用訊息型別區分，appid用tags區分，可以在訊息中新增orderid關鍵字。

例如：

Message(topic->"abc", tags->"appid11111", keys->"M324343ef", content);

Message(topic->"cdb", tags->"appid33333", keys->"M684343ef", content);

多執行緒版：每個執行緒操作不同appId的資料。實測單機普通CPU多執行緒無益於提高producer的效率。（i7-CPU測試結果為：兩執行緒比單執行緒提高36%，三執行緒比兩執行緒提高12%，三執行緒CPU已爆滿）

2）按順序消費

RocketMQ的消費方式有兩種，一種是傳統的自動化的push推模式（對應的DefaultMQPushConsumer），伺服器端主動推送訊息。另一種是pull拉模式（對應的DefaultMQPullConsumer），客戶端從指定位置主動去伺服器拉取資料。

RocketMQ 的 推 模式原理：原始碼分析（略）

問題：Consumer可以設定消費執行緒的數量，但是在順序消費的模式（MessageListenerOrderly）下，多個消費執行緒對於同一佇列的資料，無法並行執行，仍然是序列執行，以達到順序處理資料的目的。對多個不同佇列的資料，消費執行緒可以並行執行。

例如：producer同步傳送資料，按orderid hash來區分佇列存放資料。假設一個topic，有999個orderid分配到999個佇列，

假設consumer端有50個消費執行緒，那麼這50個執行緒就可以並行的消費999個佇列裡面的資料。

3）與kafka對比

順序寫入：kafka producer同步傳送資料，按orderid hash來區分佇列存放資料。假設一個topic，有999個orderid分配到8個分割槽，

順序消費：kafka consumer都訂閱所有topics，但是consumer執行緒受制於partition數量的限制，假設為8，那麼最多8個執行緒並行消費資料，這8個執行緒並行的消費8個partition裡面的資料。

關鍵之處，kafka和rocketMQ的區別在於一個用物理分割槽來存放資料，一個按虛擬佇列的存放資料，都能保證佇列或分割槽裡面資料的有序性。

據阿里中介軟體 官方給出的測試結論，RocketMQ虛擬佇列的效率 高於kafka 物理分割槽的效率，當kafka的分割槽數大於8時，kafka效能快速下降，而rocketMQ支援1萬佇列而不會降低效能。

叢集模式：

假設有4臺master的RocketMQ ，

每臺RocketMQ 的consumer都訂閱所有topic，

假設一個topic，有999個appid分配到999個佇列，

假設每臺RocketMQ consumer端有50個消費執行緒，那麼這4*50=200個執行緒就可以並行的消費999個佇列裡面的資料。

假設有4臺broker的Kafka，

每臺kafka的consumer都訂閱所有topic，

假設一個topic，有999個orderid分配到8個分割槽，

總的consumer執行緒受制於partition數量的限制，假設為8，那麼最多8個執行緒（4*2，每臺broker2個執行緒）並行消費8個partition裡面的資料。

顯然，RocketMQ 更佔優勢，如果kafka要達到RocketMQ 這種效果，需要擴充套件到200個分割槽才能使200個執行緒同時消費。

開源版本RocketMQ存在的問題

1、主從不能自動切換，導致了一系列小問題。

     1）普通訊息當主掛了，會拉取從上面的訊息，最後如果主又活過來了，會導致重複消費（之前消費的進度在從上面）。

    2）主down，順序訊息不能寫入，不能消費（順序消費不能消費slave上面的訊息）。順序訊息是寫入特定的queue，這個queue所在的機器掛了，就不能寫了，手動寫入其他的queue，在業務來看，也是有問題。

2、rocketmq 對於訊息重複的處理能力是不足且沒有保障的，文件中也明確說明需要業務去重。

3、對於指定位置消費，RocketMQ 的PushAPI比較低階，需要自己實現消費位置的儲存、節點的拉取和維護等。

Github上有300多個issues，坑很多，而且看評論，都沒有及時解決。

相比Kafka，在Apache下，有完善的測試，能看到存在的bug和fix狀態，以及比較詳細的說明。比如：

https://issues.apache.org/jira/browse/KAFKA-4189?jql=project%20%3D%20KAFKA%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20consumer%20ORDER%20BY%20priority%20DESC

推薦一篇關於RocketMQ非常棒的文章：

http://www.jianshu.com/p/453c6e7ff81c#