消息隊列（三）常見消息隊列介紹

時間  2019-11-09
標籤 消息 隊列 常見 介紹 简体版
原文   原文鏈接

消息隊列是分佈式系統中重要的組件，在不少生產環境如商品搶購等須要控制併發量的場景下都須要用到。最近組內須要作流水server的選型升級，這裏對消息隊列及常見的消息隊列進行了一次調研，整理了相關資料，分享給你們。php

1、消息隊列(MQ)概述html

消息隊列（Message Queue），是分佈式系統中重要的組件，其通用的使用場景能夠簡單地描述爲：java

當不須要當即得到結果，可是併發量又須要進行控制的時候，差很少就是須要使用消息隊列的時候。python

消息隊列主要解決了應用耦合、異步處理、流量削鋒等問題。c++

當前使用較多的消息隊列有RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ、MetaMq等，而部分數據庫如Redis、Mysql以及phxsql也可實現消息隊列的功能。git

2、消息隊列使用場景web

消息隊列在實際應用中包括以下四個場景：redis

  • 應用耦合：多應用間經過消息隊列對同一消息進行處理，避免調用接口失敗致使整個過程失敗；
  • 異步處理：多應用對消息隊列中同一消息進行處理，應用間併發處理消息，相比串行處理，減小處理時間；
  • 限流削峯：普遍應用於秒殺或搶購活動中，避免流量過大致使應用系統掛掉的狀況；
  • 消息驅動的系統：系統分爲消息隊列、消息生產者、消息消費者，生產者負責產生消息，消費者(可能有多個)負責對消息進行處理；

下面詳細介紹上述四個場景以及消息隊列如何在上述四個場景中使用：sql

2.1 異步處理 具體場景：用戶爲了使用某個應用，進行註冊，系統須要發送註冊郵件並驗證短信。對這兩個操做的處理方式有兩種：串行及並行。數據庫

（1）串行方式：新註冊信息生成後，先發送註冊郵件，再發送驗證短信；

在這種方式下，須要最終發送驗證短信後再返回給客戶端。

（2）並行處理：新註冊信息寫入後，由發短信和發郵件並行處理；

在這種方式下，發短信和發郵件 需處理完成後再返回給客戶端。

假設以上三個子系統處理的時間均爲50ms，且不考慮網絡延遲，則總的處理時間：

串行：50+50+50=150ms

並行：50+50 = 100ms

若使用消息隊列：

並在寫入消息隊列後當即返回成功給客戶端，則總的響應時間依賴於寫入消息隊列的時間，而寫入消息隊列的時間自己是能夠很快的，基本能夠忽略不計，所以總的處理時間相比串行提升了2倍，相比並行提升了一倍；

2.2 應用耦合

具體場景：用戶使用QQ相冊上傳一張圖片，人臉識別系統會對該圖片進行人臉識別，通常的作法是，服務器接收到圖片後，圖片上傳系統當即調用人臉識別系統，調用完成後再返回成功，以下圖所示：

該方法有以下缺點：

  • 人臉識別系統被調失敗，致使圖片上傳失敗；
  • 延遲高，須要人臉識別系統處理完成後，再返回給客戶端，即便用戶並不須要當即知道結果；
  • 圖片上傳系統與人臉識別系統之間互相調用，須要作耦合；

若使用消息隊列：

客戶端上傳圖片後，圖片上傳系統將圖片信息如uin、批次寫入消息隊列，直接返回成功；而人臉識別系統則定時從消息隊列中取數據，完成對新增圖片的識別。

此時圖片上傳系統並不須要關心人臉識別系統是否對這些圖片信息的處理、以及什麼時候對這些圖片信息進行處理。事實上，因爲用戶並不須要當即知道人臉識別結果，人臉識別系統能夠選擇不一樣的調度策略，按照閒時、忙時、正常時間，對隊列中的圖片信息進行處理。

2.3 限流削峯

具體場景：購物網站開展秒殺活動，通常因爲瞬時訪問量過大，服務器接收過大，會致使流量暴增，相關係統沒法處理請求甚至崩潰。而加入消息隊列後，系統能夠從消息隊列中取數據，至關於消息隊列作了一次緩衝。

該方法有以下優勢：

  • 請求先入消息隊列，而不是由業務處理系統直接處理，作了一次緩衝,極大地減小了業務處理系統的壓力；
  • 隊列長度能夠作限制，事實上，秒殺時，後入隊列的用戶沒法秒殺到商品，這些請求能夠直接被拋棄，返回活動已結束或商品已售完信息；

2.4 消息驅動的系統

具體場景：用戶新上傳了一批照片， 人臉識別系統須要對這個用戶的全部照片進行聚類，聚類完成後由對帳系統從新生成用戶的人臉索引(加快查詢)。這三個子系統間由消息隊列鏈接起來，前一個階段的處理結果放入隊列中，後一個階段從隊列中獲取消息繼續處理。

該方法有以下優勢：

  • 避免了直接調用下一個系統致使當前系統失敗；
  • 每一個子系統對於消息的處理方式能夠更爲靈活，能夠選擇收到消息時就處理，能夠選擇定時處理，也能夠劃分時間段按不一樣處理速度處理；

3、消息隊列的兩種模式

消息隊列包括兩種模式，點對點模式（point to point， queue）和發佈/訂閱模式（publish/subscribe，topic）。

3.1 點對點模式

點對點模式下包括三個角色：

  • 消息隊列
  • 發送者 (生產者)
  • 接收者（消費者）

消息發送者生產消息發送到queue中，而後消息接收者從queue中取出而且消費消息。消息被消費之後，queue中再也不有存儲，因此消息接收者不可能消費到已經被消費的消息。

點對點模式特色：

  • 每一個消息只有一個接收者（Consumer）(即一旦被消費，消息就再也不在消息隊列中)；
  • 發送者和接收者間沒有依賴性，發送者發送消息以後，無論有沒有接收者在運行，都不會影響到發送者下次發送消息；
  • 接收者在成功接收消息以後需向隊列應答成功，以便消息隊列刪除當前接收的消息；

3.2 發佈/訂閱模式

發佈/訂閱模式下包括三個角色

  • 角色主題（Topic）
  • 發佈者(Publisher)
  • 訂閱者(Subscriber)

發佈者將消息發送到Topic,系統將這些消息傳遞給多個訂閱者。

發佈/訂閱模式特色：

  • 每一個消息能夠有多個訂閱者；
  • 發佈者和訂閱者之間有時間上的依賴性。針對某個主題（Topic）的訂閱者，它必須建立一個訂閱者以後，才能消費發佈者的消息。
  • 爲了消費消息，訂閱者須要提早訂閱該角色主題，並保持在線運行；

4、經常使用消息隊列介紹

本部分主要介紹四種經常使用的消息隊列（RabbitMQ/ActiveMQ/RocketMQ/Kafka）的主要特性、優勢、缺點。

4.1 RabbitMQ

RabbitMQ 2007年發佈，是一個在AMQP(高級消息隊列協議)基礎上完成的，可複用的企業消息系統，是當前最主流的消息中間件之一。

主要特性：

  • 可靠性: 提供了多種技術可讓你在性能和可靠性之間進行權衡。這些技術包括持久性機制、投遞確認、發佈者證明和高可用性機制；
  • 靈活的路由： 消息在到達隊列前是經過交換機進行路由的。RabbitMQ爲典型的路由邏輯提供了多種內置交換機類型。若是你有更復雜的路由需求，能夠將這些交換機組合起來使用，你甚至能夠實現本身的交換機類型，而且當作RabbitMQ的插件來使用；
  • 消息集羣：在相同局域網中的多個RabbitMQ服務器能夠聚合在一塊兒，做爲一個獨立的邏輯代理來使用；
  • 隊列高可用：隊列能夠在集羣中的機器上進行鏡像，以確保在硬件問題下還保證消息安全；
  • 多種協議的支持：支持多種消息隊列協議；
  • 服務器端用Erlang語言編寫，支持只要是你能想到的全部編程語言；
  • 管理界面: RabbitMQ有一個易用的用戶界面，使得用戶能夠監控和管理消息Broker的許多方面；
  • 跟蹤機制：若是消息異常，RabbitMQ提供消息跟蹤機制，使用者能夠找出發生了什麼；
  • 插件機制：提供了許多插件，來從多方面進行擴展，也能夠編寫本身的插件；

使用RabbitMQ須要：

  • ErLang語言包
  • RabbitMQ安裝包

RabbitMQ能夠運行在Erlang語言所支持的平臺之上：

  • Solaris
  • BSD
  • Linux
  • MacOSX
  • TRU64
  • Windows NT/2000/XP/Vista/Windows 7/Windows 8
  • Windows Server 2003/2008/2012
  • Windows 95, 98
  • VxWorks

優勢：

  • 因爲erlang語言的特性，mq 性能較好，高併發；
  • 健壯、穩定、易用、跨平臺、支持多種語言、文檔齊全；
  • 有消息確認機制和持久化機制，可靠性高；
  • 高度可定製的路由；
  • 管理界面較豐富，在互聯網公司也有較大規模的應用；
  • 社區活躍度高；

缺點：

  • 儘管結合erlang語言自己的併發優點，性能較好，可是不利於作二次開發和維護；
  • 實現了代理架構，意味着消息在發送到客戶端以前能夠在中央節點上排隊。此特性使得RabbitMQ易於使用和部署，可是使得其運行速度較慢，由於中央節點增長了延遲，消息封裝後也比較大；
  • 須要學習比較複雜的接口和協議，學習和維護成本較高；

4.2 ActiveMQ

ActiveMQ是由Apache出品，ActiveMQ 是一個徹底支持JMS1.1和J2EE 1.4規範的 JMS Provider實現。它很是快速，支持多種語言的客戶端和協議，並且能夠很是容易的嵌入到企業的應用環境中，並有許多高級功能。

主要特性：

  • 服從 JMS 規範：JMS 規範提供了良好的標準和保證，包括：同步或異步的消息分發，一次和僅一次的消息分發，消息接收和訂閱等等。聽從 JMS 規範的好處在於，不論使用什麼 JMS 實現提供者，這些基礎特性都是可用的；
  • 鏈接性：ActiveMQ 提供了普遍的鏈接選項，支持的協議有：HTTP/S，IP 多播，SSL，STOMP，TCP，UDP，XMPP等等。對衆多協議的支持讓 ActiveMQ 擁有了很好的靈活性。
  • 支持的協議種類多：OpenWire、STOMP、REST、XMPP、AMQP ；
  • 持久化插件和安全插件：ActiveMQ 提供了多種持久化選擇。並且，ActiveMQ 的安全性也能夠徹底依據用戶需求進行自定義鑑權和受權；
  • 支持的客戶端語言種類多：除了 Java 以外，還有：C/C++，.NET，Perl，PHP，Python，Ruby；
  • 代理集羣：多個 ActiveMQ 代理能夠組成一個集羣來提供服務；
  • 異常簡單的管理：ActiveMQ 是以開發者思惟被設計的。因此，它並不須要專門的管理員，由於它提供了簡單又使用的管理特性。有不少中方法能夠監控 ActiveMQ 不一樣層面的數據，包括使用在 JConsole 或者 ActiveMQ 的Web Console 中使用 JMX，經過處理 JMX 的告警消息，經過使用命令行腳本，甚至能夠經過監控各類類型的日誌。

使用ActiveMQ須要：

  • Java JDK
  • ActiveMQ安裝包

ActiveMQ能夠運行在Java語言所支持的平臺之上。

優勢：

  • 跨平臺(JAVA編寫與平臺無關有，ActiveMQ幾乎能夠運行在任何的JVM上)
  • 能夠用JDBC：能夠將數據持久化到數據庫。雖然使用JDBC會下降ActiveMQ的性能，可是數據庫一直都是開發人員最熟悉的存儲介質。將消息存到數據庫，看得見摸得着。並且公司有專門的DBA去對數據庫進行調優，主從分離；
  • 支持JMS ：支持JMS的統一接口;
  • 支持自動重連；
  • 有安全機制：支持基於shiro，jaas等多種安全配置機制，能夠對Queue/Topic進行認證和受權。
  • 監控完善：擁有完善的監控，包括Web Console，JMX，Shell命令行，Jolokia的REST API；
  • 界面友善：提供的Web Console能夠知足大部分狀況，還有不少第三方的組件可使用，如hawtio；

缺點：

  • 社區活躍度不及RabbitMQ高；
  • 根據其餘用戶反饋，會出莫名其妙的問題，會丟失消息；
  • 目前重心放到activemq6.0產品-apollo，對5.x的維護較少；
  • 不適合用於上千個隊列的應用場景；

4.3 RocketMQ

RocketMQ出自 阿里公司的開源產品，用 Java 語言實現，在設計時參考了 Kafka，並作出了本身的一些改進，消息可靠性上比 Kafka 更好。RocketMQ在阿里集團被普遍應用在訂單，交易，充值，流計算，消息推送，日誌流式處理，binglog分發等場景。

主要特性：

  • 是一個隊列模型的消息中間件，具備高性能、高可靠、高實時、分佈式特色；
  • Producer、Consumer、隊列均可以分佈式；
  • Producer向一些隊列輪流發送消息，隊列集合稱爲Topic，Consumer若是作廣播消費，則一個consumer實例消費這個Topic對應的全部隊列，若是作集羣消費，則多個Consumer實例平均消費這個topic對應的隊列集合；
  • 可以保證嚴格的消息順序；
  • 提供豐富的消息拉取模式；
  • 高效的訂閱者水平擴展能力；
  • 實時的消息訂閱機制；
  • 億級消息堆積能力；
  • 較少的依賴；

使用RocketMQ須要：

  • Java JDK
  • 安裝git、Maven
  • RocketMQ安裝包

RocketMQ能夠運行在Java語言所支持的平臺之上。

優勢：

  • 單機支持 1 萬以上持久化隊列
  • RocketMQ 的全部消息都是持久化的，先寫入系統 PAGECACHE，而後刷盤，能夠保證內存與磁盤都有一份數據，
  • 訪問時，直接從內存讀取。
  • 模型簡單，接口易用（JMS 的接口不少場合並不太實用）；
  • 性能很是好，能夠大量堆積消息在broker中；
  • 支持多種消費，包括集羣消費、廣播消費等。
  • 各個環節分佈式擴展設計，主從HA；
  • 開發度較活躍，版本更新很快。

缺點：

  • 支持的客戶端語言很少，目前是java及c++，其中c++不成熟；
  • RocketMQ社區關注度及成熟度也不及前二者；
  • 沒有web管理界面，提供了一個CLI(命令行界面)管理工具帶來查詢、管理和診斷各類問題；
  • 沒有在 mq 核心中去實現JMS等接口；

4.4 Kafka

Apache Kafka是一個分佈式消息發佈訂閱系統。它最初由LinkedIn公司基於獨特的設計實現爲一個分佈式的提交日誌系統( a distributed commit log)，，以後成爲Apache項目的一部分。Kafka系統快速、可擴展而且可持久化。它的分區特性，可複製和可容錯都是其不錯的特性。

主要特性：

  • 快速持久化，能夠在O(1)的系統開銷下進行消息持久化；

  • 高吞吐，在一臺普通的服務器上既能夠達到10W/s的吞吐速率；

  • .徹底的分佈式系統，Broker、Producer、Consumer都原生自動支持分佈式，自動實現負載均衡；

  • 支持同步和異步複製兩種HA；

  • 支持數據批量發送和拉取；

  • zero-copy：減小IO操做步驟；

  • 數據遷移、擴容對用戶透明；

  • 無需停機便可擴展機器；

  • 其餘特性：嚴格的消息順序、豐富的消息拉取模型、高效訂閱者水平擴展、實時的消息訂閱、億級的消息堆積能力、按期刪除機制；

使用Kafka須要：

  • Java JDK

  • Kafka安裝包

優勢：

  • 客戶端語言豐富，支持java、.net、php、ruby、python、go等多種語言；

  • 性能卓越，單機寫入TPS約在百萬條/秒，消息大小10個字節；

  • 提供徹底分佈式架構, 並有replica機制, 擁有較高的可用性和可靠性, 理論上支持消息無限堆積；

  • 支持批量操做；

  • 消費者採用Pull方式獲取消息, 消息有序, 經過控制可以保證全部消息被消費且僅被消費一次;

  • 有優秀的第三方Kafka Web管理界面Kafka-Manager；

  • 在日誌領域比較成熟，被多家公司和多個開源項目使用；

缺點：

  • Kafka單機超過64個隊列/分區，Load會發生明顯的飆高現象，隊列越多，load越高，發送消息響應時間變長

  • 使用短輪詢方式，實時性取決於輪詢間隔時間；

  • 消費失敗不支持重試；

  • 支持消息順序，可是一臺代理宕機後，就會產生消息亂序；

  • 社區更新較慢；

4.5 RabbitMQ/ActiveMQ/RocketMQ/Kafka對比

這裏列舉了上述四種消息隊列的差別對比

注意：其實RabbitMQ也是支持事物的

結論:

Kafka在於分佈式架構，RabbitMQ基於AMQP協議來實現，RocketMQ/思路來源於kafka，改爲了主從結構，在事務性可靠性方面作了優化。普遍來講，電商、金融等對事務性要求很高的，能夠考慮RabbitMQ和RocketMQ，對性能要求高的可考慮Kafka。

5、參考資料：

5.1 消息隊列：

5.2 RabbitMQ

5.3 ActiveMQ

5.4 RocketMQ

5.5 Kafka

5.6 RabbitMQ/ActiveMQ/RocketMQ/Kafka對比

總結：

消息隊列利用高效可靠的消息傳遞機制進行平臺無關的數據交流，並基於數據通訊來進行分佈式系統的集成。目前業界有不少的MQ產品，例如RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ、MetaMq等，也有直接使用數據庫redis充當消息隊列的案例。而這些消息隊列產品，各有側重，在實際選型時，須要結合自身需求及MQ產品特徵，綜合考慮。

note:只有作好今天，才能夢想明天。

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程