在上周，我們討論了使用消息隊列的好處。然后我們回顧了消息隊列產品的發展歷史。如今，在項目中需要使用消息隊列時，Apache Kafka似乎是首選產品。然而，考慮到特定需求時，它并不總是最佳選擇。

基于數據庫的隊列

讓我們再次使用星巴克的例子。最重要的兩個需求是：

• 異步處理，使收銀員可以在不等待的情況下接下一個訂單。
• 持久性，以防出現問題時錯過顧客的訂單。

在這里，消息的順序不太重要，因為咖啡師經常批量制作相同的飲料。可擴展性也不是很重要，因為隊列受限于每個星巴克門店。

星巴克的隊列可以在數據庫表中實現。下面的圖表顯示了它的工作原理：

當收銀員接受一個訂單時，在數據庫支持的隊列中創建一個新訂單。然后收銀員可以繼續接受另一個訂單，而咖啡師則會批量獲取新的訂單。一旦訂單完成，咖啡師會在數據庫中標記為已完成。然后顧客可以在柜臺上取走他們的咖啡。

每天結束時可以運行一個維護作業來刪除已完成的訂單（即“DONE”狀態的訂單）。

對于星巴克的用例，一個簡單的數據庫隊列可以在不需要使用Kafka的情況下滿足需求。具有CRUD（創建-讀取-更新-刪除）操作的訂單表就可以勝任。

基于Redis的隊列

基于數據庫的消息隊列仍然需要開發工作來創建隊列表并從中讀取/寫入數據。對于預算有限且已經使用Redis進行緩存的小型創業公司，Redis也可以用作消息隊列。

有三種使用Redis作為消息隊列的方法：

• 發布/訂閱（Pub/Sub）
• 列表（List）
• 流（Stream）

下面的圖表顯示了它們的工作原理。

發布/訂閱是方便的，但有一些傳遞限制。消費者訂閱一個鍵，當生產者向相同的鍵發布數據時，消費者會接收數據。限制在于數據最多只會傳遞一次。如果消費者關閉并且未接收到已發布的數據，則該數據會丟失。此外，數據不會持久保存在磁盤上。如果Redis宕機，所有發布/訂閱數據都會丟失。發布/訂閱適用于度量監視等情況，其中可以接受一些數據丟失。

Redis中的列表數據結構可以構建FIFO（先進先出）隊列。消費者使用BLPOP以阻塞模式等待消息，因此應該應用超時。等待相同列表的消費者形成一個消費者組，每個消息只由一個消費者消費。作為Redis數據結構，列表可以持久保存在磁盤上。

流解決了上述兩種方法的限制。消費者可以選擇從何處讀取消息 - 使用“$”表示新消息，“”表示特定消息ID，或使用“0-0”從開始讀取消息。

總而言之，基于數據庫和基于Redis的消息隊列易于維護。如果它們無法滿足我們的需求，專用的消息隊列產品更好。接下來我們將比較兩個流行的選項。

RabbitMQ vs. Kafka

對于需要可靠、可擴展和可維護的系統的大公司，在以下方面評估消息隊列產品：

• 功能
• 性能
• 可擴展性
• 生態系統

下面的圖表比較了兩種典型的消息隊列產品：RabbitMQ和Kafka。

工作原理

RabbitMQ的工作方式類似于消息中間件 - 它將消息推送給消費者，然后在確認后將其刪除。這避免了消息積壓，這是RabbitMQ認為有問題的。

Kafka最初是為大規模日志處理而構建的。它會保留消息直到過期，并允許消費者以自己的速度拉取消息。

語言和API

RabbitMQ是用Erlang編寫的，這使得修改核心代碼變得具有挑戰性。然而，它提供了非常豐富的客戶端API和庫支持。

Kafka使用Scala和Java，但也有針對流行語言（如Python、Ruby 和Node.js）的客戶端庫和API。

性能和可擴展性

RabbitMQ每秒可以處理數萬條消息。即使在更好的硬件上，吞吐量也不會大幅提高。

Kafka可以處理數百萬條每秒的消息，并具有很高的可擴展性。

生態系統

許多現代大數據和流式應用程序默認集成了Kafka。這使得它非常適合這些用例。

消息隊列用例

既然我們已經介紹了不同消息隊列的特點，讓我們看一些如何選擇正確產品的示例。

日志處理與分析

對于具有購物車、訂單和付款等服務的電子商務網站，我們需要分析日志以調查顧客訂單。

下面的圖表顯示了使用“ELK”堆棧的典型架構：

• ElasticSearch - 為全文搜索索引日志
• LogStash - 日志收集代理
• Kibana - 用于搜索和可視化日志的用戶界面
• Kafka - 分布式消息隊列

圖片