MQ消息隊列中間件介紹及IoT領域應用

• 什麼是消息隊列？

• 發佈/訂閱消息收發

• 爲什麼使用消息隊列？

• 消息隊列有什麼優點和缺點？

• 消息隊列中間件

• Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什麼區別，以及適合哪些場景？

• IoT領域中的消息隊列應用

什麼是消息隊列

什麼是消息隊列？

消息隊列是一種異步的服務間通信方式，使用於無服務和微服務架構。消息在被處理和刪除之前一直存儲在隊列上。每條消息僅可被一直爲用戶處理一次。消息隊列可被用於分離重量級處理、緩存或批處理工作以及緩解高峯期工作負載。

在現代雲架構中，應用程序被分解爲多個規模較小且更易於開發、部署和維護的獨立構建模塊。消息隊列可爲這些分佈式應用程序提供通信和協調。消息隊列可以顯著簡化分離應用程序的編碼，同時提高性能、可靠性和可擴展性。

藉助消息隊列，系統的不同部分可相互通信並異步執行處理操作。消息隊列提供一個臨時存儲消息的輕量級緩存區，以及允許軟件組件連接到隊列以發送接受消息的終端節點。這些消息通常較小，可以是請求、恢復、錯誤消息或明文消息等。要發送消息時，一個名爲“創建器”的組件將消息添加到隊列。消息將存儲在隊列中，直至名爲“處理器”的另一組件檢索該消息並執行相關操作。

許多創建器和處理器都可以使用隊列，但一條信息只能有一盒處理器處理一次。因此，這種消息收發模式通常稱爲一對一或點對點通信。如果消息需要由多個處理器進行處理，可採用扇出設計模式將消息隊列與發佈/訂閱消息收發結合起來。

發佈/訂閱消息收發

發佈/訂閱消息收發是一種異步的服務間通信方式，適用於無服務和微服務架構。在發佈/訂閱模式下，發佈到主題的任何的任何消息都會立即被主題的所有訂閱者接受。發佈/訂閱消息收發可用於啓用事件驅動架構，或分離應用程序，以提高性能、可靠性和可擴展性。

發佈/訂閱消息收發基礎知識

在現代雲架構中，應用程序被分解爲多個規模較小且易於開發、部署和維護的獨立構建塊。發佈/訂閱消息收發可以爲這些分佈式應用程序提供及時事件通知。

發佈/訂閱模式讓消息能夠異步廣播到系統中的不同部分。消息主題與消息隊列類似，可以提供一個輕量型機制來廣播異步事件通知，還可以提供能讓軟件組件連接主題以便發送和接受消息的終端節點。在廣播消息時，一個叫做“發佈者”的組件會將消息推送到主題。與在消息被檢索前批量處理消息的消息隊列不同的是，消息主題無需或使用極少消息隊列即可傳輸消息，並將消息立即推送給所有訂閱者。訂閱該主題的所有組件都會收到廣播的每一條消息，除非訂閱着設置了消息篩選策略。

消息主題的訂閱着通常執行不同的功能，並可以同時對消息執行不同的操作。發佈者無需知道誰在使用廣播的消息而訂閱着也無需知道消息來自哪裏。這種消息收發模式與消息隊列稍有不同，在消息隊列中，發送消息的組件通常知道發送目的地。

爲什麼使用消息隊列

其實就是問問你消息隊列都有哪些使用場景，然後你項目裏具體是什麼場景，說說你在這個場景裏用消息隊列是什麼？

面試官問你這個問題，期望的一個回答是說，你們公司有個什麼業務場景，這個業務場景有個什麼技術挑戰，如果不用 MQ 可能會很麻煩，但是你現在用了 MQ 之後帶給了你很多的好處。

先說一下消息隊列常見的使用場景吧，其實場景有很多，但是比較核心的有 3 個：解耦、異步、削峯。

解耦

看這麼個場景。A 系統發送數據到 BCD 三個系統，通過接口調用發送。如果 E 系統也要這個數據呢？那如果 C 系統現在不需要了呢？A 系統負責人幾乎崩潰......

在這個場景中，A 系統跟其它各種亂七八糟的系統嚴重耦合，A 系統產生一條比較關鍵的數據，很多系統都需要 A 系統將這個數據發送過來。A 系統要時時刻刻考慮 BCDE 四個系統如果掛了該咋辦？要不要重發，要不要把消息存起來？頭髮都白了啊！

如果使用 MQ，A 系統產生一條數據，發送到 MQ 裏面去，哪個系統需要數據自己去 MQ 裏面消費。如果新系統需要數據，直接從 MQ 裏消費即可；如果某個系統不需要這條數據了，就取消對 MQ 消息的消費即可。這樣下來，A 系統壓根兒不需要去考慮要給誰發送數據，不需要維護這個代碼，也不需要考慮人家是否調用成功、失敗超時等情況。

總結：通過一個 MQ，Pub/Sub 發佈訂閱消息這麼一個模型，A 系統就跟其它系統徹底解耦了。

面試技巧：你需要去考慮一下你負責的系統中是否有類似的場景，就是一個系統或者一個模塊，調用了多個系統或者模塊，互相之間的調用很複雜，維護起來很麻煩。但是其實這個調用是不需要直接同步調用接口的，如果用 MQ 給它異步化解耦，也是可以的，你就需要去考慮在你的項目裏，是不是可以運用這個 MQ 去進行系統的解耦。在簡歷中體現出來這塊東西，用 MQ 作解耦。

異步

再來看一個場景，A 系統接收一個請求，需要在自己本地寫庫，還需要在 BCD 三個系統寫庫，自己本地寫庫要 3ms，BCD 三個系統分別寫庫要 300ms、450ms、200ms。最終請求總延時是 3 + 300 + 450 + 200 = 953ms，接近 1s，用戶感覺搞個什麼東西，慢死了慢死了。用戶通過瀏覽器發起請求，等待個 1s，這幾乎是不可接受的。

一般互聯網類的企業，對於用戶直接的操作，一般要求是每個請求都必須在 200 ms 以內完成，對用戶幾乎是無感知的。

如果使用 MQ，那麼 A 系統連續發送 3 條消息到 MQ 隊列中，假如耗時 5ms，A 系統從接受一個請求到返回響應給用戶，總時長是 3 + 5 = 8ms，對於用戶而言，其實感覺上就是點個按鈕，8ms 以後就直接返回了，爽！網站做得真好，真快！

削峯

每天 0:00 到 12:00，A 系統風平浪靜，每秒併發請求數量就 50 個。結果每次一到 12:00 ~ 13:00 ，每秒併發請求數量突然會暴增到 5k+ 條。但是系統是直接基於 MySQL 的，大量的請求湧入 MySQL，每秒鐘對 MySQL 執行約 5k 條 SQL。

一般的 MySQL，扛到每秒 2k 個請求就差不多了，如果每秒請求到 5k 的話，可能就直接把 MySQL 給打死了，導致系統崩潰，用戶也就沒法再使用系統了。

但是高峯期一過，到了下午的時候，就成了低峯期，可能也就 1w 的用戶同時在網站上操作，每秒中的請求數量可能也就 50 個請求，對整個系統幾乎沒有任何的壓力。

如果使用 MQ，每秒 5k 個請求寫入 MQ，A 系統每秒鐘最多處理 2k 個請求，因爲 MySQL 每秒鐘最多處理 2k 個。A 系統從 MQ 中慢慢拉取請求，每秒鐘就拉取 2k 個請求，不要超過自己每秒能處理的最大請求數量就 ok，這樣下來，哪怕是高峯期的時候，A 系統也絕對不會掛掉。而 MQ 每秒鐘 5k 個請求進來，就 2k 個請求出去，結果就導致在中午高峯期（1 個小時），可能有幾十萬甚至幾百萬的請求積壓在 MQ 中。

這個短暫的高峯期積壓是 ok 的，因爲高峯期過了之後，每秒鐘就 50 個請求進 MQ，但是 A 系統依然會按照每秒 2k 個請求的速度在處理。所以說，只要高峯期一過，A 系統就會快速將積壓的消息給解決掉。

消息隊列有什麼優缺點

優點上面已經說了，就是在特殊場景下有其對應的好處，解耦、異步、削峯。

缺點有以下幾個：

• 系統可用性降低
  系統引入的外部依賴越多，越容易掛掉。本來你就是 A 系統調用 BCD 三個系統的接口就好了，人 ABCD 四個系統好好的，沒啥問題，你偏加個 MQ 進來，萬一 MQ 掛了咋整，MQ 一掛，整套系統崩潰的，你不就完了？如何保證消息隊列的高可用？

• 系統複雜度提高
  硬生生加個 MQ 進來，你怎麼保證消息沒有重複消費？怎麼處理消息丟失的情況？怎麼保證消息傳遞的順序性？頭大頭大，問題一大堆，痛苦不已。

• 一致性問題
  A 系統處理完了直接返回成功了，人都以爲你這個請求就成功了；但是問題是，要是 BCD 三個系統那裏，BD 兩個系統寫庫成功了，結果 C 系統寫庫失敗了，咋整？你這數據就不一致了。

所以消息隊列實際是一種非常複雜的架構，你引入它有很多好處，但是也得針對它帶來的壞處做各種額外的技術方案和架構來規避掉，做好之後，你會發現，媽呀，系統複雜度提升了一個數量級，也許是複雜了 10 倍。但是關鍵時刻，用，還是得用的。

消息隊列中間件

• RabbitMQ
• Kafka
• RocketMQ
• Qpid
• Artemis
• NSQ
• ZeroMQ

ActiveMQ

ActiveMQ是由Apache出品，ActiveMQ是一個完全支持JMS1.1和JMS1.4規範的JMS Provider實現。它非常快速，只是多種語言的客戶端和協議，而且可以非常容易的嵌入到企業的應用環境中，並有許多高級功能。

主要特性

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

部署環境

ActiveMQ 可以運行在 Java 語言所支持的平臺之上。使用 ActiveMQ 需要：

• Java JDK
• ActiveMQ 安裝包

優點

• 跨平臺 (JAVA 編寫與平臺無關，ActiveMQ 幾乎可以運行在任何的 JVM 上)；
• 可以用 JDBC：可以將 數據持久化 到數據庫。雖然使用 JDBC 會降低 ActiveMQ 的性能，但是數據庫一直都是開發人員最熟悉的存儲介質；
• 支持 JMS 規範：支持 JMS 規範提供的 統一接口;
• 支持 自動重連 和 錯誤重試機制；
• 有安全機制：支持基於 shiro，jaas 等多種 安全配置機制，可以對 Queue/Topic 進行 認證和授權；
• 監控完善：擁有完善的 監控，包括 Web Console，JMX，Shell 命令行，Jolokia 的 RESTful API；
• 界面友善：提供的 Web Console 可以滿足大部分情況，還有很多 第三方的組件 可以使用，比如 hawtio；

缺點

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

RabbitMQ

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

主要特性

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

部署環境

RabbitMQ 可以運行在 Erlang 語言所支持的平臺之上，包括 Solaris，BSD，Linux，MacOSX，TRU64，Windows 等。使用 RabbitMQ 需要：

• ErLang 語言包
• RabbitMQ 安裝包

優點

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

缺點

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

RocketMQ

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

主要特性

• 基於隊列模型：具有高性能、高可靠、高實時、分佈式等特點；
• Producer、Consumer、隊列都支持分佈式；
• Producer向一些隊列輪流發送消息，隊列集合稱爲Topic。Consumer如果做廣播消費，則一個Consumer實例消費這個Topic對應的所有隊列；如果做集羣消費，則多個Consumer實例平均消費這個Topic對應的隊列集合；
• 能夠保證嚴格的消息順序；
• 提供豐富的消息拉取模式；
• 高效的訂閱着水平擴展能力；
• 實時的消息訂閱機制；
• 億級消息堆積能力；
• 較少的外部依賴；

部署環境

RocketMQ可以運行在Java語言所支持的平臺之上。使用RocketMQ需要：

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

優點

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

缺點

• 支持的客戶端語言不多，目前是Java及C++，其中C++還不成熟；
• RocketMQ社區關注度及成熟度也不及前兩者；
• 沒有Web管理界面，提供了一個CLI管理工具代理查詢、管理和診斷各種問題；
• 沒有在MQ核心裏實現JMS等接口

Kafka

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

主要特性

• 快速持久化：可以在 O(1) 的系統開銷下進行 消息持久化；
• 高吞吐：在一臺普通的服務器上既可以達到 10W/s 的 吞吐速率；
• 完全的分佈式系統：Broker、Producer 和 Consumer 都原生自動支持 分佈式，自動實現 負載均衡；
• 支持 同步 和 異步 複製兩種 高可用機制；
• 支持 數據批量發送 和 拉取；
• 零拷貝技術(zero-copy)：減少 IO 操作步驟，提高 系統吞吐量；
• 數據遷移、擴容 對用戶透明；
• 無需停機 即可擴展機器；
• 其他特性：豐富的 消息拉取模型、高效 訂閱者水平擴展、實時的 消息訂閱、億級的 消息堆積能力、定期刪除機制；

部署環境

使用 Kafka 需要：

• Java JDK
• Kafka 安裝包

優點

• 客戶端語言豐富：支持 Java、.Net、PHP、Ruby、Python、Go 等多種語言；
• 高性能：單機寫入 TPS 約在 100 萬條/秒，消息大小 10 個字節；
• 提供 完全分佈式架構，並有 replica 機制，擁有較高的 可用性 和 可靠性，理論上支持 消息無限堆積；
• 支持批量操作；
• 消費者 採用 Pull 方式獲取消息。消息有序，通過控制 能夠保證所有消息被消費且僅被消費 一次；
• 有優秀的第三方 Kafka Web 管理界面 Kafka-Manager；
• 在 日誌領域 比較成熟，被多家公司和多個開源項目使用。

缺點

• Kafka 單機超過 64 個 隊列/分區 時，Load 時會發生明顯的飆高現象。隊列 越多，負載 越高，發送消息 響應時間變長；
• 使用 短輪詢方式，實時性 取決於 輪詢間隔時間；
• 消費失敗 不支持重試；
• 支持 消息順序，但是 一臺代理宕機 後，就會產生 消息亂序；
• 社區更新較慢。

Kafka、ActiveMQ、RabbitMQ、RocketMQ 有什麼優缺點？

特性	ActiveMQ	RabbitMQ	RocketMQ	Kafka
單機吞吐量	萬級，比 RocketMQ、Kafka 低一個數量級	同 ActiveMQ	10 萬級，支撐高吞吐	10 萬級，高吞吐，一般配合大數據類的系統來進行實時數據計算、日誌採集等場景
topic 數量對吞吐量的影響			topic 可以達到幾百/幾千的級別，吞吐量會有較小幅度的下降，這是 RocketMQ 的一大優勢，在同等機器下，可以支撐大量的 topic	topic 從幾十到幾百個時候，吞吐量會大幅度下降，在同等機器下，Kafka 儘量保證 topic 數量不要過多，如果要支撐大規模的 topic，需要增加更多的機器資源
時效性	ms 級	微秒級，這是 RabbitMQ 的一大特點，延遲最低	ms 級	延遲在 ms 級以內
可用性	高，基於主從架構實現高可用	同 ActiveMQ	非常高，分佈式架構	非常高，分佈式，一個數據多個副本，少數機器宕機，不會丟失數據，不會導致不可用
消息可靠性	有較低的概率丟失數據	基本不丟	經過參數優化配置，可以做到 0 丟失	同 RocketMQ
功能支持	MQ 領域的功能極其完備	基於 erlang 開發，併發能力很強，性能極好，延時很低	MQ 功能較爲完善，還是分佈式的，擴展性好	功能較爲簡單，主要支持簡單的 MQ 功能，在大數據領域的實時計算以及日誌採集被大規模使用

綜上，各種對比之後，有如下建議：

一般的業務系統要引入 MQ，最早大家都用 ActiveMQ，但是現在確實大家用的不多了，沒經過大規模吞吐量場景的驗證，社區也不是很活躍，所以大家還是算了吧，我個人不推薦用這個了；

後來大家開始用 RabbitMQ，但是確實 erlang 語言阻止了大量的 Java 工程師去深入研究和掌控它，對公司而言，幾乎處於不可控的狀態，但是確實人家是開源的，比較穩定的支持，活躍度也高；

不過現在確實越來越多的公司會去用 RocketMQ，確實很不錯，畢竟是阿里出品，但社區可能有突然黃掉的風險（目前 RocketMQ 已捐給 Apache，但 GitHub 上的活躍度其實不算高）對自己公司技術實力有絕對自信的，推薦用 RocketMQ，否則回去老老實實用 RabbitMQ 吧，人家有活躍的開源社區，絕對不會黃。

所以中小型公司，技術實力較爲一般，技術挑戰不是特別高，用 RabbitMQ 是不錯的選擇；大型公司，基礎架構研發實力較強，用 RocketMQ 是很好的選擇。

如果是大數據領域的實時計算、日誌採集等場景，用 Kafka 是業內標準的，絕對沒問題，社區活躍度很高，絕對不會黃，何況幾乎是全世界這個領域的事實性規範。

IoT領域中的消息隊列應用

爲什麼以及何時在您的物聯網項目中使用消息隊列？

考慮溫室中的溫度傳感器，它測量溫度。您的應用程序可以在15分鐘的時間間隔內（每天月96次）將溫度發送到消息隊列。而不是處理溫室中的數據並始終連接。

物聯網的消息隊列旨在提供輕量級的發佈/訂閱消息傳輸。您只需發送數據並在另一項服務中處理數據，而不是保留處理溫室數據的應用程序。這需要較少的網絡帶寬，這可能會限制您的傳感器，或者您的傳感器通過衛星鏈路進行通信。

消息隊列使您的應用程序具有低功耗，發送最小化的數據包，並有效地將信息分發給一個或多個接收器。

物聯網項目中的消息隊列

消息隊列是一種服務到服務通信的方式。它允許應用程序通過相互發送消息進行通信。消息隊列的基本體系結構很簡單，有些客戶端應用程序可以創建消息並將它們傳遞到消息隊列。其他應用程序/服務從隊列中檢索消息並處理消息中包含的請求和信息

消息可以包含任何類型的信息。例如，它可以獲得有關應該從另一個應用程序（可能位於其他位置）開始的進程/任務的消息，或者它可能只是需要處理的數據。

物聯網和異步消息

因特網 應用程序被動反應和異步是一個“必須”。大多數IoT應用程序應該能夠處理來自設備的許多連接以及從中過去的所有消息

異步消息傳遞在機器到機器通信中被廣泛使用。這以爲這發送方不會期望立即相應，並且發送方在等待相應是時不會“阻止”任何內容。

異步通信可以實現靈活性，應用程序可以發送消息，然後繼續處理其他事情-在同步通信中，它必須等待實時響應。您可以將消息寫入隊列，然後讓相同的業務員邏輯發生，而不是調用Web服務並等待它完成。

在您的應用程序需要完成某些操作但不需要立即完成，或者甚至不關心結果的情況下，隊列可能很棒。

解耦

消息隊列可用於實現解耦，並有助於保持結構的靈活性。它使得用不同語言編寫的兩個不同的應用程序連接在一起非常容易。

消息隊列允許每個組件獨立地執行其任務-它允許組件保持完全自治並且彼此不知道，一項服務的更改不應要求更改其他服務。它是分離服務的過程因此它們的功能更加獨立。

冗餘和彈性

應用程序有時會崩潰 - 它會發生。這可能是由於超時或您的代碼中只有錯誤影響整個應用程序。消息隊列強制可以使接收應用程序確認它已完成任務，並且可以安全地從隊列中刪除該任務。如果接收應用程序中的任何內容失敗，該消息將保留在隊列中。

當目標程序繁忙或未連接時，消息隊列提供臨時消息存儲。

通過打破您的應用程序並按隊列分隔不同的組件，您固有地創建了更多的彈性。即使部分後端處理延遲，您的應用程序仍然可以運行。

交通高峯

許多應用程序的流量激增。門鈴應用程序，讓您可以從任何地方回答您的門，萬聖節期間可能會有交通高峯，而購物應用程序可能會在黑色星期五有交通高峯。通過對數據進行排隊，您可以確保最終保留和處理您的數據; 即使這意味着由於高流量峯值，它需要比平常更長的時間。

------------------------------------------------------------------------------------------------------------------------------

如果您覺得這篇博客對您有幫助，希望您能略微打賞打賞。如果您有業務合作意向，請私信聯繫。