作 者: 陳珙
出 處:http://www.cnblogs.com/skychen1218/
背景
本公司是.Net項目,在.Net可選的MQ比較少,主要Kafka和RabbitMQ,RabbitMQ我也是使用多年了,最近的Kafka廣告與流行度打得使我也是無法無視,是以也是花了點時間收集了資料做了些對比。
此外有個小插曲,當我形成了文檔讓老闆兼CTO對比決策後,他打算上阿裡雲買MQ服務。我當時給他開了個玩笑:您這價錢把我請回來,而且公司還有運維,其實完全可以自己維護,要不我來負責,你把這每個月的MQ費用給我加工資得了。當我下樓買了支維他檸檬茶後,他決定由我們自己搭建RabbitMQ。這個決定跟我的想法差不多,原因主要兩點:運維起來友善,吞吐沒有特别高。
如果下文有總結不到位的,或者差錯的,可以在下方評論回報給我
RabbitMQ模型
![](https://img.laitimes.com/img/__Qf2AjLwojIjJCLyojI0JCLicmbw5iMkBDOyYWZwUmZyYmM4MWZkNGOkBjNmNWMzgjZ5ATM08CX0JXZ252bj91Ztl2Lc52YucWbp5GZzNmLn9Gbi1yZtl2Lc9CX6MHc0RHaiojIsJye.png)
- Exchange在聲明時會綁定Queue和Binding Key,當Exchange收到消息會根據消息的
- Routing Key與Exchange Type、Binding Key進行比對,最後會路由到相關的隊列當中。Fanout,将消息發送到與該交換器所綁定的所有隊列中,與Routing Key、Bind Key無關,這就是廣播模式。Topic,通過對消息的Routing Key和Exchange、Queue進行比對,将消息路由給一個或多個隊列,以此來達到釋出/訂閱模式。Direct,把消息路由到哪些Bind Key和Routing Key完全比對的隊列中。Headers,不依賴與路由鍵的比對規則,基本用不上。
- 消費者會直接訂閱Queue裡的消息進行消費,多個消費者訂閱同個Queue會形成消息競争狀态,以此達到負載均衡作用。
Kafka模型
- Kafka與RabbitMQ比沒有Exchange的概念,生産者直接發消息Topic(隊列)。
- Kafka的訂閱者是通過消費組(Consumer Group)來展現的,每個消費組都可以重複消費Topic一份完整的消息,不同消費組之間消費進度彼此不受影響。例如Message1能被Consumer Group 1和Consumer Group2裡的消費者都消費一次。
- 消費組中包含多個消費者,同個Group的消費者之間是競争消費的關系。例如Message2隻能夠被Consumer Group裡某一個Consumer隻消費一次。
- Kafka具有消息存儲的功能,消息被消費後不會被立即删除,因為需要被不同的Consumer Group多次消費同個消息,是以會在Topic維護一個Consumer Offset,每消費成功Offset自增1.
功能對比
對比描述
共同點
RabbitMQ與Kafka都有很好的用戶端語言支援、安全機制與生态支援。
性能
Kafka的誕生的是處理高并發日志的,吞吐量比較高,每秒請求數達到數十萬量級,而RabbitMQ每秒請求數則為萬級别,有測試報告指出Kafka是RabbitMQ的10倍以上性能。
運維便捷
RabbitMQ相對比較友善,可以使用yum或者docker安裝,自帶Web管理UI,沒有額外的依賴,除了需要做鏡像隊列外需要引入HAproxy。
Kafka則需要依賴Zookeeper,也沒有自帶的管理工具,可以使用第三方的Kafka Eagle代替,Kafka Manager過于難用,另外Kafka沒有yum安裝,docker鏡像也是社群人員自己建的。
有序性
RabbitMQ理論上是全局有序性的,但是由于【發後既忘】+【自動确認】機制的原因,如果在同個隊列的多個消費者做相同的業務處理時,他們的各自的執行任務無法保證有序完成。如果確定100%有序可以使用【非自動确認】,但會影響消費性能。
Kafka支援分區有序性,如果對有序性有嚴格要求可以設定單個Partition,可是單個Partition并發性比較低,是以在多個Partition情況下可以根據業務指定key把相關的消息路由到同一個Partition,例如相同UserId行為資訊可以到Partition 1進行處理。
時效性
Kafka基本上無論在用戶端還是服務端都是以【異步批量】的機制進行處理,通俗的講就是先攢起來一堆消息,到了某個閥值再發送,也會導緻一些消息可靠性與消息有時效上的問題,當然可以通過各種配置政策進行解決。
消息回溯
Kafka在消費完了消息後不會立即删除,隻會修改offset,如果之前部分業務消費失敗了可以重新設定offset進行重新消費。
RabbitMQ則是[發後既忘]的機制,一但消費者确認消息則删除,但是可以通過死信進行補償消費。此外RabbitMQ在隊列消息堆積多的情況下性能表現不佳,是以盡可能的及時消費消息。
特色功能
RabbitMQ具有死信的功能,可以通過死信形成重複消費與延時發送。
Kafka具有流處理功能,可以收集使用者的行為日志進行存儲與分析。
Kafka為什麼快?
關鍵核心技術點:
- 異步批量處理
- 磁盤順序讀寫
- 作業系統PageCache緩存資料
- 零拷貝加速消費
Kafka的誕生就是為了高并發日志處理的,那麼在他整個機制裡使用了很多批量、異步、緩存。例如生産者用戶端,他會積累一定量(條數、大小)的消息,再批量的發給kafka broker,如果在這段時間用戶端服務挂了,就等于消息丢失了。當broker接受到了消息後,還有一堆騷操作-異步刷盤,也就是生産者發送給broker之後他是記錄在緩存的,每隔一段時間才會持久化到磁盤,假如這段真空期broker挂了,消息也是丢了。
Kafka是否消息不可靠?
Kafka快是因為犧牲了消息可靠換取回來的性能,在最早期版本的确沒提供消息可靠的政策,經過多個版本疊代後的功能完善,已經不存在這種舊觀念。那麼可靠的關鍵點有以下:
生産者
設定ack:
- 0:producer不等待broker的ack,broker一接收到還沒有寫入磁盤就已經傳回,可靠性最低;
- 1:producer等待broker的ack,partition的leader刷盤成功後傳回ack,如果在follower同步成功之前leader故障,那麼将會丢失資料,可靠性中;
- -1:producer等待broker的ack,partition的leader和follower全部落盤成功後才傳回ack,資料一般不會丢失,延遲時間長但是可靠性高
消費者
設定enable.auto.commi true,不管執行結果如何,消費者會自動送出offset。
false,需要使用者需要手動送出offset,可以根據執行結果具體處理offset
RabbitMQ單節點部署
安裝
yum install -y rabbitmq-server
開放相關端口
firewall-cmd --permanent --add-port=15672/tcpfirewall-cmd --permanent --add-port=5672/tcpfirewall-cmd --reload
啟動服務
service rabbitmq-server start
啟動web管理界面
rabbitmq-plugins enable rabbitmq_management
增加通路admin使用者,預設使用者guest隻能本地通路。
rabbitmqctl add_user admin 123456
設定admin使用者為管理者角色
rabbitmqctl set_user_tags admin administrator
設定預設admin使用者通路權限
rabbitmqctl set_permissions -p "/" admin "." "." ".*"
重新開機服務
service rabbitmq-server restart
浏覽器通路: http://IP:15672
Kafka單節點部署
Zookeeper部署
下載下傳Zookeeper并啟動
docker run -d --restart always --name zookeeper -p 2181:2181 -v /root/zookeeper/data:/data -v /root/zookeeper/conf:/conf -v /root/zookeeper/logs:/logs zookeeper:3.6.1
開放2181端口
firewall-cmd --permanent --add-port=2181/tcpfirewall-cmd --reload
Kafka服務部署
下載下傳kafka 鏡像并啟動
docker run -d --name kafka -p 9092:9092 -e KAFKA_BROKER_ID=1 -e KAFKA_ZOOKEEPER_CONNECT=192.168.88.139:2181 -e KAFKA_ADVERTISED_HOST_NAME=192.168.88.141 -e KAFKA_ADVERTISED_PORT=9092 wurstmeister/kafka:2.12-2.5.0
建立目錄并拷貝
mkdir /root/kafkadocker cp kafka:/opt/kafka/config /root/kafka/config
删除原有的容器并重新建立
docker stop kafkadocker rm kafkadocker run -d --name kafka -p 9092:9092 -e KAFKA_BROKER_ID=1 -e KAFKA_ZOOKEEPER_CONNECT=192.168.88.139:2181 -e KAFKA_ADVERTISED_HOST_NAME=192.168.88.141 -e KAFKA_ADVERTISED_PORT=9092 -v /root/kafka/config: /opt/kafka/config wurstmeister/kafka:2.12-2.5.0
開放9092端口
firewall-cmd --permanent --add-port=9092/tcpfirewall-cmd --reload
Kafka-eagle
下載下傳jdk依賴
yum -y install java-1.8.0-openjdk*
下載下傳kafka-eagle-bin包
wget -o kafka-eagle-bin.tar.gz https://codeload.github.com/smartloli/kafka-eagle-bin/tar.gz/v2.0.1
解壓
tar -zxvf kafka-eagle-bin.tar.gztar -zxvf kafka-eagle-bin-2.0.1/kafka-eagle-web-2.0.1-bin.tar.gzmv kafka-eagle-web-2.0.1 kafka-eagle
添加環境變量
vim /etc/profileexport JAVA_HOME=/usrexport KE_HOME=/etc/kafka-eagleexport PATH=$PATH:$KE_HOME/bin:$JAVA_HOME/bin
生效環境變量
source /etc/profile
修改
Kafka-eagle
配置
cd /etc/kafka-eagle/confvim system-config.properties#注釋#cluster2.zk.list=xdn10:2181,xdn11:2181,xdn12:2181#cluster2.kafka.eagle.offset.storage=zk#cluster1.zk.acl.enable=false#cluster1.zk.acl.schema=digest#cluster1.zk.acl.username=test#cluster1.zk.acl.password=test123修改kafka.eagle.zk.cluster.alias=cluster1cluster1.zk.list=192.168.88.139:2181kafka.eagle.metrics.charts=truekafka.eagle.driver=org.sqlite.JDBCkafka.eagle.url=jdbc:sqlite:/etc/kafka-eagle/db/ke.dbkafka.eagle.username=rootkafka.eagle.password=root
啟動kafka-eagle服務
cd /etc/kafka-eagle/binchmod +x ke.shke.sh start
開啟防火牆
firewall-cmd --permanent --add-port=8048/tcp firewall-cmd --reload
浏覽器通路: http://IP: 8048
作 者: 陳珙
出 處:http://www.cnblogs.com/skychen1218/