Kafka
Kafka早在5年前就已經非常流行。4年前用Kafka做日志緩存，數據平台接入緩沖，經過Kafka的數據量有100TB級別。
Kafka本身非常強壯，前提是：
1、topic不多，最好一個topic；
2、分區多個沒關系，但是分區副本不多，最好只有一個；
3、zookeeper只有一個節點
這樣的前提下，Kafaka能支持高並發的消息數據接入。
如果副本較多就會不斷的同步數據文件，性能急劇下降；
如果zk多個節點，元數據信息在zk節點中，數據量大的時候，zk不能穩定，導致節點不一致的問題。一旦不一致，kafka集群就會出現數據紊亂，數據丟失的問題。
topic比較多，topic信息也是zk來管理和更新，瓶頸還是在zk上。
阿里巴巴多年前有個叫dubbo的服務在業內出名，但是為什么用着用着內部也不用dubbo呢，因為dubbo必須依賴zookeeper，dubbo官方文檔干脆說內部dubbo使用自研的注冊組件，zk是個小公司生產用還行的組件，有嚴重性能瓶頸。
RocketMQ
RocketMQ是阿里巴巴模仿了Kafka的設計和特性，使用Java語言進行改良的消息中間件
主要改良：
1、注冊中心不使用zk，而是重寫了一個叫nameserver的模塊，專門負責消息路由，消息管理，注冊和消費
2、取消Kafka的分區機制，在RocketMQ里面對應Tag和消息隊列機制，也就是說一個topic和Tag組合對應kafka的一個分區，這個組合或者分區里的消息是有序的。
3、RocketMQ完全支持順序消費，支持事務消息功能，Kafaka要順序消費也可以，使用一個分區就可以。
不足：
1、nameserver依然是單點，如果nameserver master掛掉需要重新選舉，依然會有短暫的消息丟失。這一點和kafka用到zk的情形一樣。
2、rocketMQ雖然是apache頂級項目，在IT圈里面使用的人並不多，技術生態比Kafka差遠了。代碼bug比Kafka多，有問題也難查。
其他方面的功能RocketMQ和Kakfa都基本相同。
RocketMQ基本用法參考：
https://www.cnblogs.com/520playboy/p/6750023.html
