常見消息引擎系統對比

1、RabbitMQ數據庫

RabbitMQ屬於比較傳統的消息隊列系統,支持標準的消息隊列協議(AMQP, STOMP,MQTT等),若是你的應用程序須要支持這些協議,那麼仍是使用RabbitMQ。另外RabbitMQ支持比較複雜的consumer Routing,這點也是Kafka不提供的。架構

普遍用於金融保險、政企、電商、新零售、物流、視頻互動、能源等行業業務的消息通信異步

 

2、Kafka分佈式

普遍用於日誌收集、監控數據聚合、網站行爲分析、流式數據處理、在線和離線分析等大數據領域,是大數據生態中不可或缺的產品之一;讓數據集成變得簡單:您能將 Kafka 中的消息導入到 ODPS、HBase、HBASE 等離線數據倉庫;可普遍的與流計算引擎集成,包括阿里雲平臺的 StreamCompute、E-MapReduce 和開源產品 Spark、Storm 等。oop

 

經典應用場景:性能

一、網站活動跟蹤大數據

成功的網站運營都會很是關注站點的用戶行爲並進行分析。經過消息隊列 Kafka,您能夠實時收集網站活動數據(包括用戶瀏覽頁面、搜索及其餘行爲等),並經過「發佈/訂閱」模型實現:網站

  • 根據不一樣的業務數據類型,將消息發佈到不一樣的 Topic;
  • 經過訂閱消息的實時投遞,將消息流用於實時監控與業務分析或者加載到 Hadoop、ODPS 等離線數據倉庫系統進行離線處理與業務報告。

二、日誌聚合搜索引擎

許多公司,好比淘寶、天貓平臺天天都會產生大量的日誌(通常爲流式數據,如搜索引擎 pv、查詢等),相較於日誌爲中心的系統,好比 Scribe 或者 Flume 來講,Kafka 在提供一樣高效的性能時,能夠實現更強的數據持久化以及更低的端到端響應時間。Kafka 的這種特性決定它很是適合做爲日誌收集中心:阿里雲

  • Kafka 忽略掉文件的細節,能夠將多臺主機或應用的日誌數據抽象成一個個日誌或事件的消息流,異步發送到 Kafka 集羣,從而作到很是低的 RT 時間;
  • Kafka 客戶端可批量提交消息和壓縮消息,對生產者而言幾乎感受不到性能的開支;
  • 消費者能夠使用 Hadoop、ODPS 等離線倉庫存儲和 Strom、Spark 等實時在線分析系統對日誌進行統計分析;
  • 應用與分析解耦:構建應用系統和分析系統的橋樑,並將它們之間的關聯解耦。

三、流計算處理

在不少領域,如股市走向分析、氣象數據測控、網站用戶行爲分析,因爲數據產生快、實時性強且量大,您很難統一採集這些數據並將其入庫存儲後再作處理,這便致使傳統的數據處理架構不能知足需求。

與傳統架構不一樣,Kafka 以及 Storm/Samza/Spark 等流計算引擎的出現,就是爲了更好地解決這類數據在處理過程當中遇到的問題,流計算模型能實如今數據流動的過程當中對數據進行實時地捕捉和處理,並根據業務需求進行計算分析,最終把結果保存或者分發給須要的組件。

四、數據中轉樞紐

近 10 多年來,諸如 KV 存儲(HBase)、搜索(ElasticSearch)、流式處理(Storm/Spark Streaming/Samza)、時序數據庫(OpenTSDB)等專用系統應運而生。這些系統是由於單一的目標而產生,也因其簡單性使得在商業硬件上構建分佈式系統變得更加容易且性價比更高。

一般,同一份數據集須要被注入到多個專用系統內。例如,當應用日誌用於離線日誌分析,搜索單個日誌記錄一樣不可或缺,而構建各自獨立的工做流來採集每種類型的數據再導入到各自的專用系統顯然不切實際,利用 Kafka 做爲數據中轉樞紐,同份數據能夠被導入到不一樣專用系統中。

3、Redis

4、ActiveMQ

相關文章
相關標籤/搜索