在上一期中，我们讨论了使用消息队列的好处。然后，我们回顾了消息队列产品的历史。现在看来，当我们需要在项目中使用消息队列时，Kafka 是首选产品。但是，当我们考虑特定要求时，它并不总是最佳选择。
数据库支持的队列
让我们再次使用我们的星巴克示例。最重要的两个要求是：
-
异步处理，因此收银员无需等待即可接受下一个订单。
-
坚持不懈，以便在出现问题时不会错过客户的订单。
消息订购在这里并不重要，因为咖啡机经常制作成批的相同饮料。可扩展性也不那么重要，因为队列仅限于每个星巴克门店。
星巴克队列可以在数据库表中实现。下图显示了它是如何工作的：
当收银员接受订单时，将在数据库支持的队列中创建一个新订单。然后，收银员可以接受另一个订单，而咖啡机则分批接取新订单。订单完成后，咖啡机会在数据库中将其标记为完成。然后，顾客在柜台领取咖啡。
内务管理作业可以在每天结束时运行，以删除已完成的订单（即那些状态为"完成"的订单）。
对于星巴克的用例，一个简单的数据库队列就可以满足要求，而不需要 Kafka。具有 CRUD（创建-读取-更新-删除）操作的订单表工作正常。
Redis支持的队列
数据库支持的消息队列仍然需要开发工作来创建队列表并从中读取/写入。对于预算有限且已经使用 Redis 进行缓存的小型初创公司，Redis 还可以用作消息队列。
有 3 种方法可以将 Redis 用作消息队列：
1.Pub/Sub 发布/订阅
2.List 列表
3.Stream 流
下图显示了它们的工作原理。
Pub/Sub 很方便，但有一些交付限制。当生产者将数据发布到同一密钥时，消费者订阅密钥并接收数据。限制是数据最多传递一次。如果使用者关闭且未收到已发布的数据，则该数据将丢失。此外，数据不会保留在磁盘上。如果 Redis 出现故障，则所有 Pub/Sub 数据都将丢失。Pub/Sub 适用于可以接受某些数据丢失的指标监控。
Redis 中的 List 数据结构可以构造 FIFO（先进先出）队列。使用者使用 BLPOP 在阻塞模式下等待消息，因此应应用超时。等待同一列表的消费者形成一个消费者组，其中每条消息仅由一个消费者使用。作为 Redis 数据结构，List 可以持久化到磁盘上。
Stream 解决了上述两种方法的限制。使用者选择从何处读取消息 - "$"表示新消息，"id"表示特定消息 ID，"0-0"表示从头开始读取。
总之，数据库支持和 Redis 支持的消息队列易于维护。如果它们不能满足我们的需求，专用的消息队列产品会更好。接下来我们将比较两个流行的选项。
对于需要可靠、可扩展和可维护系统的大型公司，请在以下方面评估消息队列产品：
-
功能性
-
性能
-
可扩展性
-
生态系统
下图比较了两种典型的消息队列产品：RabbitMQ 和 Kafka。
它们是如何工作的
RabbitMQ 的工作方式类似于消息传递中间件 - 它将消息推送给消费者，然后在确认时删除它们。这避免了 RabbitMQ 认为有问题的消息堆积。
Kafka 最初是为大规模日志处理而构建的。它会将消息保留到过期，并允许使用者按照自己的节奏拉取消息。
语言和 API
RabbitMQ 是用 Erlang 编写的，这使得修改核心代码具有挑战性。但是，它提供了非常丰富的客户端 API 和库支持。
Kafka 使用 Scala 和 Java，但也具有适用于 Python、Ruby 和 Node.js 等流行语言的客户端库和 API。
性能和可扩展性
RabbitMQ 每秒处理数万条消息。即使在更好的硬件上，吞吐量也不会高得多。
Kafka 每秒可以处理数百万条消息，具有很高的可扩展性。
生态系统
默认情况下，许多现代大数据和流式处理应用程序都集成了 Kafka。这使得它非常适合这些用例。
Message Queue使用案例
现在我们已经介绍了不同消息队列的功能，让我们看一些如何选择正确产品的示例。
日志处理和分析
对于具有购物车、订单和付款等服务的电子商务网站，我们需要分析日志以调查客户订单。
下图显示了使用"ELK"堆栈的典型体系结构：
-
ElasticSearch - 为全文搜索的日志编制索引
-
LogStash - 日志收集代理
-
Kibana - 用于搜索和可视化日志的 UI
-
Kafka - 分布式消息队列
