怎么進(jìn)行Kafka、RabbitMQ、RocketMQ等消息中間件的介紹和對(duì)比

怎么進(jìn)行Kafka、RabbitMQ、RocketMQ等消息中間件的介紹和對(duì)比，針對(duì)這個(gè)問(wèn)題，這篇文章詳細(xì)介紹了相對(duì)應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問(wèn)題的小伙伴找到更簡(jiǎn)單易行的方法。

前言

在分布式系統(tǒng)中,我們廣泛運(yùn)用消息中間件進(jìn)行系統(tǒng)間的數(shù)據(jù)交換,便于異步解耦?，F(xiàn)在開(kāi)源的消息中間件有很多,前段時(shí)間產(chǎn)品 RocketMQ (MetaQ的內(nèi)核) 也順利開(kāi)源,得到大家的關(guān)注。

概念

MQ簡(jiǎn)介

MQ,Message queue,消息隊(duì)列，就是指保存消息的一個(gè)容器。具體的定義這里就不類似于數(shù)據(jù)庫(kù)、緩存等，用來(lái)保存數(shù)據(jù)的。當(dāng)然，與數(shù)據(jù)庫(kù)、緩存等產(chǎn)品比較，也有自己一些特點(diǎn)，具體的特點(diǎn)后文會(huì)做詳細(xì)的介紹。

現(xiàn)在常用的MQ組件有ActiveMQ、RabbitMQ、RocketMQ、ZeroMQ、MetaMQ，當(dāng)然近年來(lái)火熱的kafka,從某些場(chǎng)景來(lái)說(shuō)，也是MQ，當(dāng)然kafka的功能更加強(qiáng)大，雖然不同的MQ都有自己的特點(diǎn)和優(yōu)勢(shì)，但是，不管是哪種MQ，都有MQ本身自帶的一些特點(diǎn)，下面，介紹MQ的特點(diǎn)。

MQ特點(diǎn)

1、先進(jìn)先出

不能先進(jìn)先出，都不能說(shuō)是隊(duì)列了。消息隊(duì)列的順序在入隊(duì)的時(shí)候就基本已經(jīng)確定了，一般是不需人工干預(yù)的。而且，最重要的是，數(shù)據(jù)是只有一條數(shù)據(jù)在使用中。這也是MQ在諸多場(chǎng)景被使用的原因。

2、發(fā)布訂閱

發(fā)布訂閱是一種很高效的處理方式，如果不發(fā)生阻塞，基本可以當(dāng)做是同步操作。這種處理方式能非常有效的提升服務(wù)器利用率，這樣的應(yīng)用場(chǎng)景非常廣泛。

3、持久化

持久化確保MQ的使用不只是一個(gè)部分場(chǎng)景的輔助工具，而是讓MQ能像數(shù)據(jù)庫(kù)一樣存儲(chǔ)核心的數(shù)據(jù)。

4、分布式

在現(xiàn)在大流量、大數(shù)據(jù)的使用場(chǎng)景下，只支持單體應(yīng)用的服務(wù)器軟件基本是無(wú)法使用的，支持分布式的部署，才能被廣泛使用。而且，MQ的定位就是一個(gè)高性能的中間件。

應(yīng)用場(chǎng)景

那么,消息中間件性能究竟哪家強(qiáng)?

帶著這個(gè)疑問(wèn),我們中間件測(cè)試組對(duì)常見(jiàn)的三類消息產(chǎn)品(Kafka、RabbitMQ、RocketMQ)做了性能比較。

Kafka

Kafka是LinkedIn開(kāi)源的分布式發(fā)布-訂閱消息系統(tǒng)，目前歸屬于Apache頂級(jí)項(xiàng)目。Kafka主要特點(diǎn)是基于Pull的模式來(lái)處理消息消費(fèi)，追求高吞吐量，一開(kāi)始的目的就是用于日志收集和傳輸。0.8版本開(kāi)始支持復(fù)制，不支持事務(wù)，對(duì)消息的重復(fù)、丟失、錯(cuò)誤沒(méi)有嚴(yán)格要求，適合產(chǎn)生大量數(shù)據(jù)的互聯(lián)網(wǎng)服務(wù)的數(shù)據(jù)收集業(yè)務(wù)。

RabbitMQ

RabbitMQ是使用Erlang語(yǔ)言開(kāi)發(fā)的開(kāi)源消息隊(duì)列系統(tǒng)，基于AMQP協(xié)議來(lái)實(shí)現(xiàn)。AMQP的主要特征是面向消息、隊(duì)列、路由（包括點(diǎn)對(duì)點(diǎn)和發(fā)布/訂閱）、可靠性、安全。AMQP協(xié)議更多用在企業(yè)系統(tǒng)內(nèi)，對(duì)數(shù)據(jù)一致性、穩(wěn)定性和可靠性要求很高的場(chǎng)景，對(duì)性能和吞吐量的要求還在其次。

RocketMQ

RocketMQ是阿里開(kāi)源的消息中間件，它是純Java開(kāi)發(fā)，具有高吞吐量、高可用性、適合大規(guī)模分布式系統(tǒng)應(yīng)用的特點(diǎn)。RocketMQ思路起源于Kafka，但并不是Kafka的一個(gè)Copy，它對(duì)消息的可靠傳輸及事務(wù)性做了優(yōu)化，目前在阿里集團(tuán)被廣泛應(yīng)用于交易、充值、流計(jì)算、消息推送、日志流式處理、binglog分發(fā)等場(chǎng)景。

測(cè)試目的

對(duì)比Kafka、RabbitMQ、RocketMQ發(fā)送小消息(124字節(jié))的性能。這次壓測(cè)我們只關(guān)注服務(wù)端的性能指標(biāo),所以壓測(cè)的標(biāo)準(zhǔn)是:

不斷增加發(fā)送端的壓力,直到系統(tǒng)吞吐量不再上升,而響應(yīng)時(shí)間拉長(zhǎng)。這時(shí)服務(wù)端已出現(xiàn)性能瓶頸,可以獲得相應(yīng)的系統(tǒng)最佳吞吐量。

測(cè)試場(chǎng)景

在同步發(fā)送場(chǎng)景中，三個(gè)消息中間件的表現(xiàn)區(qū)分明顯：

Kafka

Kafka的吞吐量高達(dá)17.3w/s，不愧是高吞吐量消息中間件的行業(yè)老大。這主要取決于它的隊(duì)列模式保證了寫(xiě)磁盤(pán)的過(guò)程是線性IO。此時(shí)broker磁盤(pán)IO已達(dá)瓶頸。

RocketMQ

RocketMQ也表現(xiàn)不俗，吞吐量在11.6w/s，磁盤(pán)IO %util已接近100%。RocketMQ的消息寫(xiě)入內(nèi)存后即返回ack，由單獨(dú)的線程專門(mén)做刷盤(pán)的操作，所有的消息均是順序?qū)懳募?/p>

RabbitMQ

RabbitMQ的吞吐量5.95w/s，CPU資源消耗較高。它支持AMQP協(xié)議，實(shí)現(xiàn)非常重量級(jí)，為了保證消息的可靠性在吞吐量上做了取舍。我們還做了RabbitMQ在消息持久化場(chǎng)景下的性能測(cè)試，吞吐量在2.6w/s左右。

測(cè)試結(jié)論

在服務(wù)端處理同步發(fā)送的性能上，Kafka>RocketMQ>RabbitMQ。

附錄：

測(cè)試環(huán)境

服務(wù)端為單機(jī)部署，機(jī)器配置如下：

應(yīng)用版本：

測(cè)試腳本

消息隊(duì)列優(yōu)點(diǎn)對(duì)比

前面我們對(duì)比了最簡(jiǎn)單的小消息發(fā)送場(chǎng)景,Kafka暫時(shí)勝出。但是,作為經(jīng)受過(guò)歷次雙十一洗禮的RocketMQ,在互聯(lián)網(wǎng)應(yīng)用場(chǎng)景中更有它優(yōu)越的一面。

RabbitMQ

是使用Erlang編寫(xiě)的一個(gè)開(kāi)源的消息隊(duì)列，本身支持很多的協(xié)議：AMQP，XMPP, SMTP, STOMP，也正是如此，使的它變的非常重量級(jí)，更適合于企業(yè)級(jí)的開(kāi)發(fā)。同時(shí)實(shí)現(xiàn)了一個(gè)經(jīng)紀(jì)人(Broker)構(gòu)架，這意味著消息在發(fā)送給客戶端時(shí)先在中心隊(duì)列排隊(duì)。對(duì)路由(Routing)，負(fù)載均衡(Load balance)或者數(shù)據(jù)持久化都有很好的支持。

Redis

是一個(gè)Key-Value的NoSQL數(shù)據(jù)庫(kù)，開(kāi)發(fā)維護(hù)很活躍，雖然它是一個(gè)Key-Value數(shù)據(jù)庫(kù)存儲(chǔ)系統(tǒng)，但它本身支持MQ功能，所以完全可以當(dāng)做一個(gè)輕量級(jí)的隊(duì)列服務(wù)來(lái)使用。對(duì)于RabbitMQ和Redis的入隊(duì)和出隊(duì)操作，各執(zhí)行100萬(wàn)次，每10萬(wàn)次記錄一次執(zhí)行時(shí)間。測(cè)試數(shù)據(jù)分為128Bytes、512Bytes、1K和10K四個(gè)不同大小的數(shù)據(jù)。實(shí)驗(yàn)表明：入隊(duì)時(shí)，當(dāng)數(shù)據(jù)比較小時(shí)Redis的性能要高于RabbitMQ，而如果數(shù)據(jù)大小超過(guò)了10K，Redis則慢的無(wú)法忍受；出隊(duì)時(shí)，無(wú)論數(shù)據(jù)大小，Redis都表現(xiàn)出非常好的性能，而RabbitMQ的出隊(duì)性能則遠(yuǎn)低于Redis。

ZeroMQ

號(hào)稱最快的消息隊(duì)列系統(tǒng)，尤其針對(duì)大吞吐量的需求場(chǎng)景。ZMQ能夠?qū)崿F(xiàn)RabbitMQ不擅長(zhǎng)的高級(jí)/復(fù)雜的隊(duì)列，但是開(kāi)發(fā)人員需要自己組合多種技術(shù)框架，技術(shù)上的復(fù)雜度是對(duì)這MQ能夠應(yīng)用成功的挑戰(zhàn)。ZeroMQ具有一個(gè)獨(dú)特的非中間件的模式，你不需要安裝和運(yùn)行一個(gè)消息服務(wù)器或中間件，因?yàn)槟愕膽?yīng)用程序?qū)缪萘诉@個(gè)服務(wù)角色。你只需要簡(jiǎn)單的引用ZeroMQ程序庫(kù)，可以使用NuGet安裝，然后你就可以愉快的在應(yīng)用程序之間發(fā)送消息了。但是ZeroMQ僅提供非持久性的隊(duì)列，也就是說(shuō)如果down機(jī)，數(shù)據(jù)將會(huì)丟失。其中，Twitter的Storm中使用ZeroMQ作為數(shù)據(jù)流的傳輸。

ActiveMQ

Apache ActiveMQ 是最受歡迎且功能最強(qiáng)大的開(kāi)源消息傳遞和Integration Patterns服務(wù)器。

Apache ActiveMQ速度快，支持許多跨語(yǔ)言客戶端和協(xié)議，帶有易于使用的企業(yè)集成模式和許多高級(jí)功能，同時(shí)完全支持JMS 1.1和J2EE 1.4。Apache ActiveMQ是在Apache 2.0許可下發(fā)布

特征

支持Java消息服務(wù)(JMS) 1.1 版本

Spring Framework

集群 (Clustering)

支持的編程語(yǔ)言包括：C、C++、C#、Delphi、Erlang、Adobe Flash、Haskell、Java、JavaScript、Perl、PHP、Pike、Python和Ruby

協(xié)議支持包括：OpenWire、REST、STOMP、WS-Notification、MQTT、XMPP以及AMQP [1]

Jafka/Kafka

Kafka是Apache下的一個(gè)子項(xiàng)目，是一個(gè)高性能跨語(yǔ)言分布式Publish/Subscribe消息隊(duì)列系統(tǒng)，而Jafka是在Kafka之上孵化而來(lái)的，即Kafka的一個(gè)升級(jí)版。具有以下特性：快速持久化，可以在O(1)的系統(tǒng)開(kāi)銷(xiāo)下進(jìn)行消息持久化；高吞吐，在一臺(tái)普通的服務(wù)器上既可以達(dá)到10W/s的吞吐速率；完全的分布式系統(tǒng)，Broker、Producer、Consumer都原生自動(dòng)支持分布式，自動(dòng)實(shí)現(xiàn)復(fù)雜均衡；支持Hadoop數(shù)據(jù)并行加載，對(duì)于像Hadoop的一樣的日志數(shù)據(jù)和離線分析系統(tǒng)，但又要求實(shí)時(shí)處理的限制，這是一個(gè)可行的解決方案。Kafka通過(guò)Hadoop的并行加載機(jī)制來(lái)統(tǒng)一了在線和離線的消息處理，這一點(diǎn)也是本課題所研究系統(tǒng)所看重的。Apache Kafka相對(duì)于ActiveMQ是一個(gè)非常輕量級(jí)的消息系統(tǒng)，除了性能非常好之外，還是一個(gè)工作良好的分布式系統(tǒng)。

其他對(duì)比

Rabbitmq比kafka可靠，kafka更適合IO高吞吐的處理，比如ELK日志收集

Kafka和RabbitMq一樣是通用意圖消息代理，他們都是以分布式部署為目的。但是他們對(duì)消息語(yǔ)義模型的定義的假設(shè)是非常不同的。我對(duì)"AMQP 更成熟"這個(gè)論點(diǎn)是持懷疑態(tài)度的。讓我們用事實(shí)說(shuō)話來(lái)看看用什么解決方案來(lái)解決你的問(wèn)題。

　　a) 以下場(chǎng)景你比較適合使用Kafka。你有大量的事件(10萬(wàn)以上/秒)、你需要以分區(qū)的，順序的，至少傳遞成功一次到混雜了在線和打包消費(fèi)的消費(fèi)者、你希望能重讀消息、你能接受目前是有限的節(jié)點(diǎn)級(jí)別高可用或則說(shuō)你并不介意通過(guò)論壇/IRC工具得到還在幼兒階段的軟件的支持。

　　b) 以下場(chǎng)景你比較適合使用RabbitMQ。你有較少的事件（2萬(wàn)以上/秒）并且需要通過(guò)復(fù)雜的路由邏輯去找到消費(fèi)者、你希望消息傳遞是可靠的、你并不關(guān)心消息傳遞的順序、你需要現(xiàn)在就支持集群-節(jié)點(diǎn)級(jí)別的高可用或則說(shuō)你需要7*24小時(shí)的付費(fèi)支持（當(dāng)然也可以通過(guò)論壇/IRC工具）。

redis 消息推送是基于分布式 pub/sub，多用于實(shí)時(shí)性較高的消息推送，并不保證可靠。

redis 消息推送（基于分布式 pub/sub）多用于實(shí)時(shí)性較高的消息推送，并不保證可靠。其他的mq和kafka保證可靠但有一些延遲（非實(shí)時(shí)系統(tǒng)沒(méi)有保證延遲）。redis-pub/sub斷電就清空，而使用redis-list作為消息推送雖然有持久化，但是又太弱智，也并非完全可靠不會(huì)丟。另外一點(diǎn)，redis 發(fā)布訂閱除了表示不同的 topic 外，并不支持分組，比如kafka中發(fā)布一個(gè)東西，多個(gè)訂閱者可以分組，同一個(gè)組里只有一個(gè)訂閱者會(huì)收到該消息，這樣可以用作負(fù)載均衡。比如，kafka 中發(fā)布：topic = “發(fā)布帖子” data=“文章1” 這個(gè)消息，后面有一百臺(tái)服務(wù)器每臺(tái)服務(wù)器都是一個(gè)訂閱者，都訂閱了這個(gè) topic，但是他們可能分為三組，A組50臺(tái)，用來(lái)真的做發(fā)布文章，A組50臺(tái)里所有 subscriber 都訂閱了這個(gè)topic。由于在同一組，這條消息 （topic=“發(fā)布帖子”, data=“文章1”）只會(huì)被A組里面一臺(tái)當(dāng)前空閑的機(jī)器收到。而B(niǎo)組25臺(tái)服務(wù)器用于統(tǒng)計(jì)，C組25臺(tái)服務(wù)器用于存檔備份，每組只有一臺(tái)會(huì)收到。用不同的組來(lái)決定每條消息要抄送出多少分去，用同組內(nèi)哪些訂閱者忙，哪些訂閱者空閑來(lái)決定消息會(huì)被分到哪臺(tái)服務(wù)器去處理，生產(chǎn)者消費(fèi)者模型嘛。redis完全沒(méi)有這類機(jī)制，這兩點(diǎn)是最大的區(qū)別。

redis主要做內(nèi)存數(shù)據(jù)庫(kù)

redis作者做內(nèi)存數(shù)據(jù)庫(kù)基礎(chǔ)上增加了消息pub/sub。mq一般都采用訂閱～發(fā)布模型，如果你考慮性能，主要關(guān)注點(diǎn)就放在消費(fèi)模型是pull還是push。影響最大的，應(yīng)該是存儲(chǔ)結(jié)構(gòu)。kafka的性能要在topic數(shù)量小于64的時(shí)候，才能發(fā)揮威力。partition決定的。極限情況下丟消息，例如：主寫(xiě)入消息后，主機(jī)器宕機(jī)，并硬盤(pán)損壞。review代碼的時(shí)候發(fā)現(xiàn)的。rabbit不知道，但是rocket的性能是（萬(wàn)條每秒），并且能夠橫向無(wú)限擴(kuò)展，單機(jī)topic數(shù)量在256時(shí)，性能損失較小。rocket可以說(shuō)是kafka的變種，是阿里在充分reviewkafka代碼后，開(kāi)發(fā)的metaQ。在不斷更新，修補(bǔ)以后，阿里把metaQ3.0更名為rocket，并且rocket是java寫(xiě)的易于維護(hù)。另外就是rocket和kafka有類似無(wú)限堆積的能力。想想，斷電不丟消息，積壓兩億條消息毫無(wú)壓力，niubility kafka和rocket mq性能根本不需要考慮的問(wèn)題。

1）在應(yīng)用場(chǎng)景方面，

RabbitMQ

RabbitMQ遵循AMQP協(xié)議，由內(nèi)在高并發(fā)的erlanng語(yǔ)言開(kāi)發(fā)，用在實(shí)時(shí)的對(duì)可靠性要求比較高的消息傳遞上，適合企業(yè)級(jí)的消息發(fā)送訂閱，也是比較受到大家歡迎的。

kafka

kafka是Linkedin于2010年12月份開(kāi)源的消息發(fā)布訂閱系統(tǒng),它主要用于處理活躍的流式數(shù)據(jù),大數(shù)據(jù)量的數(shù)據(jù)處理上。常用日志采集，數(shù)據(jù)采集上。

ActiveMQ

異步調(diào)用

一對(duì)多通信

做多個(gè)系統(tǒng)的集成，同構(gòu)、異構(gòu)

作為RPC的替代

多個(gè)應(yīng)用相互解耦

作為事件驅(qū)動(dòng)架構(gòu)的幕后支撐

為了提高系統(tǒng)的可伸縮性

2）在架構(gòu)模型方面，

RabbitMQ

RabbitMQ遵循AMQP協(xié)議，RabbitMQ的broker由Exchange,Binding,queue組成，其中exchange和binding組成了消息的路由鍵；客戶端Producer通過(guò)連接channel和server進(jìn)行通信，Consumer從queue獲取消息進(jìn)行消費(fèi)（長(zhǎng)連接，queue有消息會(huì)推送到consumer端，consumer循環(huán)從輸入流讀取數(shù)據(jù)）。rabbitMQ以broker為中心；有消息的確認(rèn)機(jī)制。

kafka

kafka遵從一般的MQ結(jié)構(gòu)，producer，broker，consumer，以consumer為中心，消息的消費(fèi)信息保存的客戶端consumer上，consumer根據(jù)消費(fèi)的點(diǎn)，從broker上批量pull數(shù)據(jù)；無(wú)消息確認(rèn)機(jī)制。

3）在吞吐量，

kafka

kafka具有高的吞吐量，內(nèi)部采用消息的批量處理，zero-copy機(jī)制，數(shù)據(jù)的存儲(chǔ)和獲取是本地磁盤(pán)順序批量操作，具有O(1)的復(fù)雜度，消息處理的效率很高。

rabbitMQ

rabbitMQ在吞吐量方面稍遜于kafka，他們的出發(fā)點(diǎn)不一樣，rabbitMQ支持對(duì)消息的可靠的傳遞，支持事務(wù)，不支持批量的操作；基于存儲(chǔ)的可靠性的要求存儲(chǔ)可以采用內(nèi)存或者硬盤(pán)。

4）在可用性方面，

rabbitMQ

rabbitMQ支持miror的queue，主queue失效，miror queue接管。

kafka

kafka的broker支持主備模式。

5）在集群負(fù)載均衡方面，

kafka

kafka采用zookeeper對(duì)集群中的broker、consumer進(jìn)行管理，可以注冊(cè)topic到zookeeper上；通過(guò)zookeeper的協(xié)調(diào)機(jī)制，producer保存對(duì)應(yīng)topic的broker信息，可以隨機(jī)或者輪詢發(fā)送到broker上；并且producer可以基于語(yǔ)義指定分片，消息發(fā)送到broker的某分片上。

rabbitMQ

rabbitMQ的負(fù)載均衡需要單獨(dú)的loadbalancer進(jìn)行支持。

6）其他

Kafka是可靠的分布式日志存儲(chǔ)服務(wù)。用簡(jiǎn)單的話來(lái)說(shuō)，你可以把Kafka當(dāng)作可順序?qū)懭氲囊淮缶泶艓В?可以隨時(shí)倒帶，快進(jìn)到某個(gè)時(shí)間點(diǎn)重放。先說(shuō)下日志的定義：日志是數(shù)據(jù)庫(kù)的核心，是對(duì)數(shù)據(jù)庫(kù)的所有變更的嚴(yán)格有序記錄，“表”是變更的結(jié)果。日志的其他名字有：Changelog, Write Ahead Log, Commit Log, Redo Log, Journaling.Kafka的特征如下：高寫(xiě)入速度：Kafka能以超過(guò)1Gbps NIC的速度寫(xiě)這盤(pán)磁帶（實(shí)際可以到SATA 3速度，參考Benchmarking Apache Kafka: 2 Million Writes Per Second (On Three Cheap Machines))，充分利用了磁盤(pán)的物理特性，即，隨機(jī)寫(xiě)入慢（磁頭沖停），順序?qū)懭肟欤ù蓬^懸?。８呖煽啃裕和ㄟ^(guò)zookeeper做分布式一致性，同步到任意多塊磁盤(pán)上，故障自動(dòng)切換選主，自愈。高容量：通過(guò)橫向擴(kuò)展，LinkedIn每日通過(guò)Kafka存儲(chǔ)的新增數(shù)據(jù)高達(dá)175TB，8000億條消息，可無(wú)限擴(kuò)容，類似把兩條磁帶粘到一起。

傳統(tǒng)業(yè)務(wù)數(shù)據(jù)庫(kù)的根本缺陷在于：

1.太慢，讀寫(xiě)太昂貴，無(wú)法避免的隨機(jī)尋址。（磁盤(pán)最快5ms尋址，固態(tài)又太昂貴。）

2. 根本無(wú)法適應(yīng)持續(xù)產(chǎn)生的數(shù)據(jù)流，越用越慢。（索引效率問(wèn)題）

3. 無(wú)法水平scale。（多半是讀寫(xiě)分離，一主多備。另: NewSQL通過(guò)一致性算法，有多主。）

針對(duì)這些問(wèn)題，Kafka提出了一種方法: “l(fā)og-centric approach（以日志為中心的方法）?！睂鹘y(tǒng)數(shù)據(jù)庫(kù)分為兩個(gè)獨(dú)立的系統(tǒng)，即日志系統(tǒng)和索引系統(tǒng)。“持久化和索引分開(kāi)，日志盡可能快的落地，索引按照自己的速度追趕。”在數(shù)據(jù)可靠性在得到Kafka這種快速的，類似磁帶順序記錄方式保障的大前提下。數(shù)據(jù)的呈現(xiàn)，使用方式變得非常靈活，可以根據(jù)需要將數(shù)據(jù)流同時(shí)送入搜索系統(tǒng)，RDBMS系統(tǒng)，數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)， 圖數(shù)據(jù)庫(kù)系統(tǒng)，日志分析等這些各種不同的數(shù)據(jù)庫(kù)系統(tǒng)。這些不同的系統(tǒng)只不過(guò)是一種對(duì)Kafka磁帶數(shù)據(jù)的一種詮釋，一個(gè)側(cè)面，一個(gè)索引，一個(gè)快照。數(shù)據(jù)丟了，沒(méi)關(guān)系，重放一遍磁帶即可，更多的時(shí)候，對(duì)這些各式數(shù)據(jù)庫(kù)系統(tǒng)的維護(hù)只是需要定期做一個(gè)快照，并拷貝到一個(gè)安全的對(duì)象存儲(chǔ)(如S3) 而已。一句話：“日志都是相同的日志，索引各有各的不同?！?/p>

關(guān)于流計(jì)算：在以流為基本抽象的存儲(chǔ)模型下，數(shù)據(jù)流和數(shù)據(jù)流之間，可以多流混合處理，或者流和狀態(tài)，狀態(tài)和狀態(tài)的JOIN處理，這就是Kafka Stream提供的功能。一個(gè)簡(jiǎn)單的例子是，在用戶觸發(fā)了某個(gè)事件后，和用戶表混合處理，產(chǎn)生數(shù)據(jù)增補(bǔ)（Augment)，再進(jìn)入數(shù)據(jù)倉(cāng)庫(kù)進(jìn)行相關(guān)性分析，一些簡(jiǎn)單的窗口統(tǒng)計(jì)和實(shí)時(shí)分析也很容易就能滿足，比如 在收到用戶登錄消息的時(shí)候，在線人數(shù)+1， 離線的時(shí)候-1，反應(yīng)出當(dāng)前系統(tǒng)的在線用戶總數(shù)。

關(guān)于怎么進(jìn)行Kafka、RabbitMQ、RocketMQ等消息中間件的介紹和對(duì)比問(wèn)題的解答就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，如果你還有很多疑惑沒(méi)有解開(kāi)，可以關(guān)注億速云行業(yè)資訊頻道了解更多相關(guān)知識(shí)。