消息代理與事件代理：何時使用它們
選擇正確的工具來滿足異步處理需求的技術指南
作為后端開發人員，有一天你需要回答這個問題：
我需要構建一個使用分布式隊列的異步應用程序，我應該使用哪個代理？ 作為工程師，我們的本能是列出我們了解或希望熟悉的工具（如果它是一種新的和已知的技術），然后開始使用它。不幸的是，在那個時刻，我們錯過了第一個最重要的問題，這個問題需要在所有其他問題之前得到答案：我們的現有和有時未來的用例/需求是什么，什么工具能最好地解決它們？ 這是我們在設計一個重要功能時的起點，當時工程師的本能占了上風。我們的第一個問題不是最重要的問題，從那時開始，我們選擇正確工具的過程變得不太有效。我們的團隊開了幾次會，討論了我們對分布式隊列的需求，不同技術的不同限制和特性（來自不同的范例）讓關注點遠離了我們最重要的需求，也遠離了決策和共識的實現。 在那個時候，我們決定回到基本問題，問：我們試圖解決的用例是什么，沒有讓步的余地在哪些領域？一如既往，讓我們從需求開始。
步驟1：明確您要解決的問題以及技術/工具體系結構如何與您的目標和考慮保持一致
在選擇消息代理或事件代理時，有很多事情要考慮：高可用性、容錯性、多租戶、多云區域支持、能夠支持高吞吐量和低延遲等等，列舉不勝枚舉。
大多數情況下，當閱讀有關事件代理或消息代理的主要特性時，我們都是以大多數公司或產品從未完全使用或需要的最復雜用例為例的。
作為工程師，生活中有一句常用的話語：
上帝在細節中，但魔鬼隱藏在細節之間。
在選擇事件代理與消息代理兩個范式之間，"魔鬼"隱藏在更多的低層技術考慮因素中，比如：消息的消耗或生成確認方法、去重、消息的優先級、消費者線程模型、消息的消耗方法、消息的分發/擴散支持、毒藥藥處理等等。
概念之間的不同：橙子與蘋果
步驟2：了解兩種范式之間的差異
(1) 事件代理
存儲一系列事件。通常，事件會按到達事件代理的順序附加到日志（隊列或主題）上。主題或隊列中的事件是不可變的，其順序不能更改。
當事件發布到隊列或主題時，代理識別主題或隊列的訂閱者，并使事件可供多種類型的訂閱者使用。
生產者和消費者不需要彼此熟悉。
事件潛在地可以存儲數天或數周，因為它們一旦被成功消耗，就不會從隊列/主題中刪除。
(2) 消息代理
用于服務或組件之間的通信。它通過異步方式在應用程序之間傳輸由生產者接收的消息。
它通常支持隊列的概念，其中消息通常存儲一段時間。隊列中消息的目的是在消費者可用于處理消息并在成功消耗后刪除消息。
不能保證隊列中消息處理的順序，并且可以更改。
消息代理與事件代理
通常，在處理短命令或面向任務的處理時，我們會傾向于使用消息代理。
例如，假設你在一家電子商務公司工作，想要將新產品添加到公司的網站。這可能意味著多個服務需要知道并以異步方式處理此請求。
上圖顯示了RabbitMQ扇出消息分發的使用，其中每個服務都有自己的隊列連接到扇出交換機。
產品服務發送包含新產品信息的消息到交換機，交換機將消息發送到所有連接的隊列。
在從隊列成功消耗消息后，它將被刪除，因為涉及的服務不需要保留或重新處理消息。
在處理當前或歷史事件時，通常涉及大量數據，需要以單個或批量方式處理這些數據，我們會傾向于使用事件代理。
例如，假設你在一個娛樂評級網站工作，你想為用戶添加一個新功能，用來顯示電影的編劇和導演。這些信息雖然歷史存儲，但不對負責提供這些數據的服務可用。
上圖顯示了使用Kafka作為事件代理，它能夠從數據倉庫中提取數億部電影，以為每個服務存儲的電影信息附加所需的信息。
Kafka可以在相對短的時間內接受大量的數據，而消費者可以有一個獨立的消費者組來單獨處理電影主題流。
需要注意的重要方面
正如我之前提到的，選擇合適的范式時有很多事情要考慮。
我想討論一些關鍵的差異，這些差異通常可能成就或破壞您對技術的決策。
在這一部分，我將比較迄今為止最流行的兩種技術：Kafka（事件代理）和RabbitMQ（消息代理），它們分別代表了這兩個范式，我對它們都有實際經驗。
我強烈鼓勵您在技術選擇過程中考慮以下幾點。
1.輪詢與推送
Kafka消費者的工作方式是通過輪詢一個主題中按順序分區劃分的消息的塊，每個消費者負責從一個或多個分區中消費消息，其中分區用作消費者的并行機制（隱式線程模型）。
這意味著通常負責管理主題的生產者會隱式知道可以訂閱主題的消費者實例的最大數量。
消費者負責處理消息處理的成功和失敗情況。由于消息是從分區中批量輪詢的，所以消息處理順序在分區級別是有保證的。
RabbitMQ消費者從隊列中接收消息的方式是通過代理將消息推送給它們。
每條消息都以一種獨立的方式進行處理，消費者可以采用顯式線程模型，而不需要生產者知道消費者實例的數量。
成功的消息處理是消費者的責任，而處理失敗主要由消息代理完成。
消息分發由代理進行管理。
如延遲消息和消息優先級等功能是開箱即用的，因為消息處理順序在隊列中通常是不保證的。
2.錯誤處理
Kafka處理消息處理錯誤的方式是將處理錯誤的責任委托給消費者。
如果某條消息被處理了幾次但失敗（毒藥藥），消費者應用程序需要跟蹤處理嘗試的數量，然后生成一條消息到一個單獨的DLQ（死信隊列）主題，以便以后檢查/重新運行。
就錯誤處理而言，消費者是承擔所有責任的一方。
這意味著如果您希望具有重試/DLQ功能，您需要提供重試機制，并在發送消息到DLQ主題時充當生產者，這在某些極端情況下可能導致消息丟失。
RabbitMQ處理消息處理錯誤的方式是跟蹤處理消息失敗。一旦一條消息被視為毒藥藥，它將被路由到一個DLQ交換機。
這允許重新排隊消息或將其路由到專用DLQ以進行檢查。
通過這種方式，RabbitMQ提供了保證未成功處理的消息不會丟失。
3.消費者確認和傳遞保證
Kafka處理消費者確認的方式是由消費者提交從主題分區中輪詢的消息的偏移量。
開箱即用，Kafka客戶端會自動提交偏移量，無論消息是否成功處理，這可能導致消息丟失，如下圖所示。
通過消費者代碼負責手動提交獲取的消息的偏移量，包括處理消息消費失敗的情況，可以更改此行為。
RabbitMQ處理消費者確認的方式是消費者以每條消息的方式進行“確認”或“否認”，允許由消息代理處理重試策略/DLQ，如果需要，可以由消息代理進行管理。
開箱即用，RabbitMQ客戶端自動進行確認，無論消息是否成功處理，可以通過消費者端的配置手動控制確認，允許消息在失敗/超時時重新推送給消費者。
RabbitMQ和Kafka在大多數情況下都提供至少一次消息/事件處理的保證，這意味著消費者應該是冪等的，以處理同一消息/事件的多次處理。
我們的流程
步驟 3：根據您的用例選擇技術，而不是反過來
對我們來說，最重要的部分是編制我們解決方案的技術標準清單，并為我們作為團隊和產品不能缺少的要求分配“不可接受”。
回到基礎精神，我使用了一個普通的表格來編制和比較不同的標準，并提到了一些需要注意的地方。記住，“細節藏在細節之中”。
這真的幫助我們組織并集中精力關注對我們至關重要的內容以及我們無法缺少的內容。
例如，我們的“不可接受”要求之一是，如果在處理過程中發生錯誤，我們不能承受丟失消息。
正如您可能從上面的部分中記得的，當使用需要DLQ的Kafka時，消費者也是DLQ的生產者。這意味著在消費者發生故障的某些情況下，消息將不會被發送到DLQ主題，可能導致消息丟失。
在這一點上，正如您可能已經猜到的那樣，我們決定選擇消息代理。
我們的功能包括面向命令/任務的處理用例，消息代理滿足了我們的產品/數據容量要求，也滿足了我們團隊的需求。
最后的思考
消息和事件流生態系統包括許多解決方案，每個解決方案都有許多不同的方面需要考慮和熟悉。
重要的是我們要睜大眼睛進入每個生態系統，并對這些不同的范式有清晰的理解。它們將對我們工程師的日常生活（有時是夜間生活）產生重大影響。
