在上周，我們討論了使用消息隊列的好處。然后我們回顧了消息隊列產品的發展歷史。如今，在項目中需要使用消息隊列時，Apache Kafka似乎是首選產品。然而，考慮到特定需求時，它并不總是最佳選擇。
基于數據庫的隊列
讓我們再次使用星巴克的例子。最重要的兩個需求是：
•異步處理，使收銀員可以在不等待的情況下接下一個訂單。•持久性，以防出現問題時錯過顧客的訂單。
在這里，消息的順序不太重要，因為咖啡師經常批量制作相同的飲料。可擴展性也不是很重要，因為隊列受限于每個星巴克門店。
星巴克的隊列可以在數據庫表中實現。下面的圖表顯示了它的工作原理：
當收銀員接受一個訂單時，在數據庫支持的隊列中創建一個新訂單。然后收銀員可以繼續接受另一個訂單，而咖啡師則會批量獲取新的訂單。一旦訂單完成，咖啡師會在數據庫中標記為已完成。然后顧客可以在柜臺上取走他們的咖啡。
每天結束時可以運行一個維護作業來刪除已完成的訂單（即“DONE”狀態的訂單）。
對于星巴克的用例，一個簡單的數據庫隊列可以在不需要使用Kafka的情況下滿足需求。具有CRUD（創建-讀取-更新-刪除）操作的訂單表就可以勝任。
基于redis的隊列
基于數據庫的消息隊列仍然需要開發工作來創建隊列表并從中讀取/寫入數據。對于預算有限且已經使用Redis進行緩存的小型創業公司，Redis也可以用作消息隊列。
有三種使用Redis作為消息隊列的方法：
1.發布/訂閱（Pub/Sub）2.列表（List）3.流（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/ target=_blank class=infotextkey>Python、Ruby 和Node.js）的客戶端庫和API。
性能和可擴展性
RabbitMQ每秒可以處理數萬條消息。即使在更好的硬件上，吞吐量也不會大幅提高。
Kafka可以處理數百萬條每秒的消息，并具有很高的可擴展性。
生態系統
許多現代大數據和流式應用程序默認集成了Kafka。這使得它非常適合這些用例。
消息隊列用例
既然我們已經介紹了不同消息隊列的特點，讓我們看一些如何選擇正確產品的示例。
日志處理與分析
對于具有購物車、訂單和付款等服務的電子商務網站，我們需要分析日志以調查顧客訂單。
下面的圖表顯示了使用“ELK”堆棧的典型架構：
•ElasticSearch - 為全文搜索索引日志•LogStash - 日志收集代理•Kibana - 用于搜索和可視化日志的用戶界面•Kafka - 分布式消息隊列
