rabbitMQ、activeMQ、zeroMQ、Kafka、Redis 比較

時間 2020-06-08

標籤 rabbitmq activemq zeromq kafka redis 比較欄目 RabbitMQ 简体版

原文原文鏈接

Kafka做爲時下最流行的開源消息系統，被普遍地應用在數據緩衝、異步通訊、聚集日誌、系統解耦等方面。相比較於RocketMQ等其餘常見消息系統，Kafka在保障了大部分功能特性的同時，還提供了超一流的讀寫性能。

針對Kafka性能方面進行簡單分析，相關數據請參考：http://www.javashuo.com/article/p-haqipkqc-ks.html，下面介紹一下Kafka的架構和涉及到的名詞：html

Topic：用於劃分Message的邏輯概念，一個Topic能夠分佈在多個Broker上。java
Partition：是Kafka中橫向擴展和一切並行化的基礎，每一個Topic都至少被切分爲1個Partition。數據庫
Offset：消息在Partition中的編號，編號順序不跨Partition。apache
Consumer：用於從Broker中取出/消費Message。segmentfault
Producer：用於往Broker中發送/生產Message。api
Replication：Kafka支持以Partition爲單位對Message進行冗餘備份，每一個Partition均可以配置至少1個Replication(當僅1個Replication時即僅該Partition自己)。服務器
Leader：每一個Replication集合中的Partition都會選出一個惟一的Leader，全部的讀寫請求都由Leader處理。其餘Replicas從Leader處把數據更新同步到本地，過程相似你們熟悉的MySQL中的Binlog同步。網絡
Broker：Kafka中使用Broker來接受Producer和Consumer的請求，並把Message持久化到本地磁盤。每一個Cluster當中會選舉出一個Broker來擔任Controller，負責處理Partition的Leader選舉，協調Partition遷移等工做。架構
ISR(In-Sync Replica)：是Replicas的一個子集，表示目前Alive且與Leader可以「Catch-up」的Replicas集合。因爲讀寫都是首先落到Leader上，因此通常來講經過同步機制從Leader上拉取數據的Replica都會和Leader有一些延遲(包括了延遲時間和延遲條數兩個維度)，任意一個超過閾值都會把該Replica踢出ISR。每一個Partition都有它本身獨立的ISR。併發

更多關於Kafka的數據，參考：http://www.javashuo.com/article/p-haqipkqc-ks.html

****************************************************

Kafka是一種分佈式的，基於發佈/訂閱的消息系統。主要設計目標以下：
以時間複雜度爲O(1)的方式提供消息持久化能力，即便對TB級以上數據也能保證常數時間複雜度的訪問性能。
高吞吐率。即便在很是廉價的商用機器上也能作到單機支持每秒100K條以上消息的傳輸。
支持Kafka Server間的消息分區，及分佈式消費，同時保證每一個Partition內的消息順序傳輸。
同時支持離線數據處理和實時數據處理。
Scale out：支持在線水平擴展。

RabbitMQ
RabbitMQ是使用Erlang編寫的一個開源的消息隊列，自己支持不少的協議：AMQP，XMPP, SMTP, STOMP，也正因如此，它很是重量級，更適合於企業級的開發。同時實現了Broker構架，這意味着消息在發送給客戶端時先在中心隊列排隊。對路由，負載均衡或者數據持久化都有很好的支持。

Redis
Redis是一個基於Key-Value對的NoSQL數據庫，開發維護很活躍。雖然它是一個Key-Value數據庫存儲系統，但它自己支持MQ功能，因此徹底能夠當作一個輕量級的隊列服務來使用。對於RabbitMQ和Redis的入隊和出隊操做，各執行100萬次，每10萬次記錄一次執行時間。測試數據分爲128Bytes、512Bytes、1K和10K四個不一樣大小的數據。實驗代表：入隊時，當數據比較小時Redis的性能要高於RabbitMQ，而若是數據大小超過了10K，Redis則慢的沒法忍受；出隊時，不管數據大小，Redis都表現出很是好的性能，而RabbitMQ的出隊性能則遠低於Redis。

ZeroMQ
ZeroMQ號稱最快的消息隊列系統，尤爲針對大吞吐量的需求場景。ZeroMQ可以實現RabbitMQ不擅長的高級/複雜的隊列，可是開發人員須要本身組合多種技術框架，技術上的複雜度是對這MQ可以應用成功的挑戰。ZeroMQ具備一個獨特的非中間件的模式，你不須要安裝和運行一個消息服務器或中間件，由於你的應用程序將扮演這個服務器角色。你只須要簡單的引用ZeroMQ程序庫，可使用NuGet安裝，而後你就能夠愉快的在應用程序之間發送消息了。可是ZeroMQ僅提供非持久性的隊列，也就是說若是宕機，數據將會丟失。其中，Twitter的Storm 0.9.0之前的版本中默認使用ZeroMQ做爲數據流的傳輸（Storm從0.9版本開始同時支持ZeroMQ和Netty做爲傳輸模塊）。

ActiveMQ
ActiveMQ是Apache下的一個子項目。相似於ZeroMQ，它可以以代理人和點對點的技術實現隊列。同時相似於RabbitMQ，它少許代碼就能夠高效地實現高級應用場景。

Kafka/Jafka
Kafka是Apache下的一個子項目，是一個高性能跨語言分佈式發佈/訂閱消息隊列系統，而Jafka是在Kafka之上孵化而來的，即Kafka的一個升級版。具備如下特性：快速持久化，能夠在O(1)的系統開銷下進行消息持久化；高吞吐，在一臺普通的服務器上既能夠達到10W/s的吞吐速率；徹底的分佈式系統，Broker、Producer、Consumer都原生自動支持分佈式，自動實現負載均衡；支持Hadoop數據並行加載，對於像Hadoop的同樣的日誌數據和離線分析系統，但又要求實時處理的限制，這是一個可行的解決方案。Kafka經過Hadoop的並行加載機制統一了在線和離線的消息處理。Apache Kafka相對於ActiveMQ是一個很是輕量級的消息系統，除了性能很是好以外，仍是一個工做良好的分佈式系統。

以上轉自：http://www.infoq.com/cn/articles/kafka-analysis-part-1/

****************************************************

什麼是Kafka？

引用官方原文：「 Kafka is a distributed, partitioned, replicated commit log service. 」

它提供了一個很是特殊的消息機制，不一樣於傳統的mq。

官網：https://kafka.apache.org

它與傳統的mq區別？

更快！單機上萬TPS
傳統的MQ，消息被消化掉後會被mq刪除，而kafka中消息被消化後不會被刪除，而是到配置的expire時間後，才刪除
傳統的MQ，消息的Offset是由MQ維護，而kafka中消息的Offset是由客戶端本身維護
分佈式，把寫入壓力均攤到各個節點。能夠經過增長節點下降壓力

基本術語

爲方便理解，我用對比傳統MQ的方式闡述這些基本術語。

Producer

Consumer

這兩個與傳統的MQ同樣，不解釋了

Topic

Kafka中的topic其實對應傳統MQ的channel，即消息管道，例如同一業務用同一根管道

Broker

集羣中的KafkaServer，用來提供Partition服務

Partition

假如說傳統的MQ，傳輸消息的通道(channel)是一條雙車道公路，那麼Kafka中，Topic就是一個N車道的高速公路。每一個車道均可以行車，而每一個車道就是Partition。

一個Topic中能夠有一個或多個partition。
一個Broker上能夠跑一個或多個Partition。集羣中儘可能保證partition的均勻分佈，例如定義了一個有3個partition的topic，而只有兩個broker，那麼一個broker上跑兩個partition，而另外一個是1個。可是若是有3個broker，必然是3個broker上各跑一個partition。
Partition中嚴格按照消息進入的順序排序
一個從Producer發送來的消息，只會進入Topic的某一個Partition（除非特殊實現Producer要求消息進入全部Partition）
Consumer能夠本身決定從哪一個Partition讀取數據

Offset

單個Partition中的消息的順序ID，例如第一個進入的Offset爲0，第二個爲1，以此類推。傳統的MQ，Offset是由MQ本身維護，而kafka是由client維護

Replica

Kafka從0.8版本開始，支持消息的HA，經過消息複製的方式。在建立時，咱們能夠指定一個topic有幾個partition，以及每一個partition有幾個複製。複製的過程有同步和異步兩種，根據性能須要選取。正常狀況下，寫和讀都是訪問leader，只有當leader掛掉或者手動要求從新選舉，kafka會從幾個複製中選舉新的leader。

Kafka會統計replica與leader的同步狀況。當一個replica與leader數據相差不大，會被認爲是一個"in-sync" replica。只有"in-sync" replica纔有資格參與從新選舉。

ConsumerGroup

一個或多個Consumer構成一個ConsumerGroup，一個消息應該只能被同一個ConsumerGroup中的一個Consumer消化掉，可是能夠同時發送到不一樣ConsumerGroup。

一般的作法，一個Consumer去對應一個Partition。

傳統MQ中有queuing（消息）和publish-subscribe（訂閱）模式，Kafka中也支持：

當全部Consumer具備相同的ConsumerGroup時，該ConsumerGroup中只有一個Consumer能收到消息，就是 queuing 模式
當全部Consumer具備不一樣的ConsumerGroup時，每一個ConsumerGroup會收到相同的消息，就是 publish-subscribe 模式

基本交互原理

每一個Topic被建立後，在zookeeper上存放有其metadata，包含其分區信息、replica信息、LogAndOffset等
默認路徑/brokers/topics/<topic_id>/partitions/<partition_index>/state

Producer能夠經過zookeeper得到topic的broker信息，從而得知須要往哪寫數據。

Consumer也從zookeeper上得到該信息，從而得知要監聽哪一個partition。

基本CLI操做

1. 建立Topic

./kafka-create-topic.sh --zookeeper 10.1.110.21:2181 --replica 2 --partition 3 --topic test

2. 查看Topic信息

./kafka-list-topic.sh --topic test --zookeeper 10.1.110.24:2181

3. 增長Partition

./kafka-add-partitions.sh --partition 4 --topic test --zookeeper 10.1.110.24:2181

建立一個Producer

Kafka提供了java api，Producer特別的簡單，舉傳輸byte[] 爲例

Properties p = new Properties(); props.put("metadata.broker.list", "10.1.110.21:9092"); ProducerConfig config = new ProducerConfig(props); Producer producer = new Producer<String, byte[]>(config); producer.send(byte[] msg);

更具體的參見: https://cwiki.apache.org/confluence/display/KAFKA/0.8.0+Producer+Example

建立一個Consumer

Kafka提供了兩種java的Consumer API：High Level Consumer和Simple Consumer

看上去前者彷佛要更牛B一點，事實上，前者作了更多的封裝，比後者要Simple的多……

具體例子我就不寫了，參見

High Level Consumer: https://cwiki.apache.org/confluence/display/KAFKA/Consumer+Group+Example

Simple Consumer: https://cwiki.apache.org/confluence/display/KAFKA/0.8.0+SimpleConsumer+Example

摘自：http://www.tuicool.com/articles/ruUzum

****************************************************

如何保證kafka的高容錯性？

producer不使用批量接口，並採用同步模型持久化消息。
consumer不採用批量化，每消費一次就更新offset

	ActiveMq	RabbitMq	Kafka
producer容錯，是否會丟數據		有ack模型，也有事務模型，保證至少不會丟數據。ack模型可能會有重複消息，事務模型則保證徹底一致	批量形式下，可能會丟數據。非批量形式下， 1. 使用同步模式，可能會有重複數據。 2. 異步模式，則可能會丟數據。
consumer容錯，是否會丟數據		有ack模型，數據不會丟，但可能會重複處理數據。	批量形式下，可能會丟數據。非批量形式下，可能會重複處理數據。（ZK寫offset是異步的）
架構模型	基於JMS協議	基於AMQP模型，比較成熟，但更新超慢。RabbitMQ的broker由Exchange,Binding,queue組成，其中exchange和binding組成了消息的路由鍵；客戶端Producer經過鏈接channel和server進行通訊，Consumer從queue獲取消息進行消費（長鏈接，queue有消息會推送到consumer端，consumer循環從輸入流讀取數據）。rabbitMQ以broker爲中心；有消息的確認機制	producer，broker，consumer，以consumer爲中心，消息的消費信息保存的客戶端consumer上，consumer根據消費的點，從broker上批量pull數據；無消息確認機制。
吞吐量		rabbitMQ在吞吐量方面稍遜於kafka，他們的出發點不同，rabbitMQ支持對消息的可靠的傳遞，支持事務，不支持批量的操做；基於存儲的可靠性的要求存儲能夠採用內存或者硬盤。	kafka具備高的吞吐量，內部採用消息的批量處理，zero-copy機制，數據的存儲和獲取是本地磁盤順序批量操做，具備O(1)的複雜度，消息處理的效率很高
可用性		rabbitMQ支持miror的queue，主queue失效，miror queue接管	kafka的broker支持主備模式
集羣負載均衡		rabbitMQ的負載均衡須要單獨的loadbalancer進行支持	kafka採用zookeeper對集羣中的broker、consumer進行管理，能夠註冊topic到zookeeper上；經過zookeeper的協調機制，producer保存對應topic的broker信息，能夠隨機或者輪詢發送到broker上；而且producer能夠基於語義指定分片，消息發送到broker的某分片上