訊息中介軟體(RabbitMq、Kafka)分析比較

一、前言
最近在使用公司訊息中介軟體的時候，對不同版本的選型：RabbitMq和Kafka，有點困惑，具體使用哪一種跟能滿足自身業務需求，特查閱相關資料進行對比。
訊息中介軟體指利用高效可靠的訊息傳遞機制進行平臺無關的資料交流，並基於資料通訊來進行分散式系統的整合。通過提供訊息傳遞和訊息排隊模型，它可以在分散式環境下擴充套件程式間的通訊。
目前開源的訊息中介軟體可謂是琳琅滿目，能讓大家耳熟能詳的就有很多，比如ActiveMQ、RabbitMQ、Kafka、RocketMQ、ZeroMQ等。不管是哪一款，都會存在與自身不匹配或者使用不趁手的地方，畢竟不是為自己量身定製的。不管是直接採用市場上，或者進行二次開發的，都會存在一個選項的過程。下來我們對目前主流的訊息中介軟體（RabbitMq和Kafka）
進行一個對比分析。

二、中介軟體介紹
RabbitMQ：是採用Erlang語言實現的AMQP協議的訊息中介軟體，最初起源於金融系統，用於在分散式系統中儲存轉發訊息。可支援“點-點”、“請求-應答”和“釋出-訂閱”等多種通訊模式。

通訊可以按需設定為同步或非同步。釋出者將訊息傳送到交換區，消費者從佇列中檢索訊息。利用交換區將生產者與佇列解耦，可確保生產者沒有硬編碼路由決策的負擔

Kafka：起初是由LinkedIn公司採用Scala語言開發的一個分散式、多分割槽、多副本且基於zookeeper協調的分散式訊息系統，現已捐獻給Apache基金會。它是一種高吞吐量的分散式釋出訂閱訊息系統，以可水平擴充套件和高吞吐率而被廣泛使用。目前越來越多的開源分散式處理系統如Cloudera、Apache Storm、Spark、Flink等都支援與Kafka整合。擅長處理大量釋出-訂閱訊息和資料流，具有持久、快速和可擴充套件的特點。

訊息的釋出描述為producer，訊息的訂閱描述為consumer，將中間的儲存陣列稱作broker(代理)。kafka對訊息儲存時根據Topic進行歸類，傳送訊息者就是Producer，訊息接受者就是Consumer，每個kafka例項稱為broker。然後三者都通過Zookeeper進行協調。kafka儲存是基於硬碟儲存的，通過線性讀寫的方式實現快速地讀寫。

三、對比
1）、應用場景
RabbitMQ,遵循AMQP協議，由內在高併發的erlanng語言開發，用在實時的對可靠性要求比較高的訊息傳遞上。
Kafka是Linkedin於2010年12月份開源的訊息釋出訂閱系統,它主要用於處理活躍的流式資料,大資料量的資料處理上。
2）、架構設計
RabbitMQ遵循AMQP協議，RabbitMQ的broker由Exchange,Binding,queue組成，其中exchange和binding組成了訊息的路由鍵；客戶端Producer通過連線channel和server進行通訊，Consumer從queue獲取訊息進行消費（長連線，queue有訊息會推送到consumer端，consumer迴圈從輸入流讀取資料）。rabbitMQ以broker為中心；有訊息的確認機制。
Kafka遵從一般的MQ結構，producer，broker，consumer，以consumer為中心，訊息的消費資訊儲存的客戶端consumer上，consumer根據消費的點，從broker上批量pull資料；無訊息確認機制。

3）、吞吐量
Kafka具有高的吞吐量，內部採用訊息的批量處理，zero-copy機制，資料的儲存和獲取是本地磁碟順序批量操作，具有O(1)的複雜度，訊息處理的效率很高。
RabbitMQ在吞吐量方面稍遜於Kafka，他們的出發點不一樣，rabbitMQ支援對訊息的可靠的傳遞，支援事務，不支援批量的操作；基於儲存的可靠性的要求儲存可以採用記憶體或者硬碟。

4）、可用性
RabbitMQ支援miror的queue，主queue失效，miror queue接管。
Kafka的broker支援主備模式。

5）、擴充套件性
Kafka採用zookeeper對叢集中的broker、consumer進行管理，可以註冊topic到zookeeper上；通過zookeeper的協調機制，producer儲存對應topic的broker資訊，可以隨機或者輪詢傳送到broker上；並且producer可以基於語義指定分片，訊息傳送到broker的某分片上。
RabbitMQ的負載均衡需要單獨的loadbalancer進行支援。

訊息中介軟體市場上琳琅滿目，這比如猶如小馬過河，要貼合自身業務需求，選擇合適的最重要，不管是選項什麼技術元件，一定要問自己是否需要？引入能帶來什麼樣的提升？技術服務於業務，不能盲目的只為了引入而限制了業務的開展。

四、Kafka叢集搭建
1）、前期準備
scala-2.12.6.tgz
zookeeper-3.4.13.tar.gz
kafka_2.12-2.0.0.tgz
jdk版本可以1.8，對應前期需要的軟體，可以直接去官網下載。Scala官網下載會超時，可參考一下連結，修改對應版本號即可。
http://downloads.typesafe.com/scala/2.12.6/scala-2.12.6.tgz
Scala和Zk已提前安裝，具體方法可以參考網上資料。
ZK如下：
192.168.xxx.1:2181
192.168.xxx.2:2181
192.168.xxx.3:2181
2）、Kafka叢集搭建
針對master主機伺服器(192.168.xxx.1)，其他主機伺服器類似
2.1）、上傳kafka包到指定目錄/opt/software_lw，並解壓並拷貝至/usr/local/kafka;
tar -zxvf kafka_2.10-0.10.1.0.tgz
mv kafka_2.12-2.0.0 /usr/local/kafka

2.2）、修改叢集配置檔案config/server.properties;
broker.id=0 #主鍵ID，必須保持唯一
listeners=PLAINTEXT://192.168.xxx.1:9092 #本機IP
log.dirs=/tmp/kafka-logs #日誌目錄
zookeeper.connect=192.168.xxx.1:2181,192.168.xxx.2:2181,192.168.xxx.3:2181 #zk叢集地址

2.3）、其他伺服器搭建;
拷貝master伺服器的kafka至slave01和slave02的 /usr/local/目錄，scp -r kafka_2.12-2.0.0 root@192.168.xxx.2:/usr/local/kafka/，另一臺伺服器（192.168.xxx.3）
類似master伺服器，修改對應config/server.properties檔案

3）、Kafka叢集測試
3.1）、zookeeper叢集啟動
3.2）、kafka叢集啟動
三臺機分別執行開啟命令：bin/kafka-server-start.sh -daemon config/server.properties
jps檢視程式

3.3）、建立主題和檢視主題
建立(replication-factor一定要大於1，否則kafka只有一份資料，leader一旦崩潰程式就沒有輸入源了，分割槽數目視輸入源而定)
bin/kafka-topics.sh --create --zookeeper 192.168.xxx.1:2181,192.168.xxx.2:2181,192.168.xxx.3:2181 --replication-factor 3 --partitions 3 --topic topic_LwTest

檢視
bin/kafka-topics.sh --list --zookeeper 192.168.xxx.1:2181,192.168.xxx.2:2181,192.168.xxx.3:2181

3.4）、開啟生產者和消費者
master伺服器輸入資訊，slave01或slave02會顯示master輸的的資訊
生產者（master）
bin/kafka-console-producer.sh --broker-list 192.168.xxx.1:9092,192.168.xxx.2:9092,192.168.xxx.3:9092 --topic topic_LwTest

消費者（slave01或slave02伺服器）
bin/kafka-console-consumer.sh --bootstrap-server 192.168.xxx.1:9092,192.168.xxx.2:9092,192.168.xxx.3:9092 --topic topic_LwTest --from-beginning
注意：高版本已經廢棄原bin/kafka-console-consumer.sh --zookeeper 消費方式