在上周,消息我们讨论了使用消息队列的队列好处。然后我们回顾了消息队列产品的去选发展历史。如今,消息在项目中需要使用消息队列时,队列Apache Kafka似乎是去选首选产品。然而,消息考虑到特定需求时,队列它并不总是去选最佳选择。
让我们再次使用星巴克的例子。最重要的队列两个需求是:
在这里,消息的顺序不太重要,因为咖啡师经常批量制作相同的饮料。可扩展性也不是很重要,因为队列受限于每个星巴克门店。
星巴克的队列可以在数据库表中实现。下面的图表显示了它的工作原理:
当收银员接受一个订单时,在数据库支持的队列中创建一个新订单。然后收银员可以继续接受另一个订单,而咖啡师则会批量获取新的订单。一旦订单完成,咖啡师会在数据库中标记为已完成。然后顾客可以在柜台上取走他们的咖啡。
每天结束时可以运行一个维护作业来删除已完成的订单(即“DONE”状态的订单)。
对于星巴克的用例,一个简单的数据库队列可以在不需要使用Kafka的情况下满足需求。具有CRUD(创建-读取-更新-删除)操作的订单表就可以胜任。
基于数据库的消息队列仍然需要开发工作来创建队列表并从中读取/写入数据。对于预算有限且已经使用Redis进行缓存的小型创业公司,Redis也可以用作消息队列。
有三种使用Redis作为消息队列的方法:
下面的图表显示了它们的工作原理。
发布/订阅是方便的,但有一些传递限制。消费者订阅一个键,当生产者向相同的键发布数据时,消费者会接收数据。限制在于数据最多只会传递一次。如果消费者关闭并且未接收到已发布的数据,则该数据会丢失。此外,数据不会持久保存在磁盘上。如果Redis宕机,所有发布/订阅数据都会丢失。发布/订阅适用于度量监视等情况,其中可以接受一些数据丢失。
Redis中的列表数据结构可以构建FIFO(先进先出)队列。消费者使用BLPOP以阻塞模式等待消息,因此应该应用超时。等待相同列表的消费者形成一个消费者组,每个消息只由一个消费者消费。作为Redis数据结构,列表可以持久保存在磁盘上。
流解决了上述两种方法的限制。消费者可以选择从何处读取消息 - 使用“$”表示新消息,“”表示特定消息ID,或使用“0-0”从开始读取消息。
总而言之,基于数据库和基于Redis的消息队列易于维护。如果它们无法满足我们的需求,专用的消息队列产品更好。接下来我们将比较两个流行的选项。
对于需要可靠、可扩展和可维护的系统的大公司,在以下方面评估消息队列产品:
下面的图表比较了两种典型的消息队列产品:RabbitMQ和Kafka。
RabbitMQ的工作方式类似于消息中间件 - 它将消息推送给消费者,然后在确认后将其删除。这避免了消息积压,这是RabbitMQ认为有问题的。
Kafka最初是为大规模日志处理而构建的。它会保留消息直到过期,并允许消费者以自己的速度拉取消息。
RabbitMQ是用Erlang编写的,这使得修改核心代码变得具有挑战性。然而,它提供了非常丰富的客户端API和库支持。
Kafka使用Scala和Java,但也有针对流行语言(如Python、Ruby 和Node.js)的客户端库和API。
RabbitMQ每秒可以处理数万条消息。即使在更好的硬件上,吞吐量也不会大幅提高。
Kafka可以处理数百万条每秒的消息,并具有很高的可扩展性。
许多现代大数据和流式应用程序默认集成了Kafka。这使得它非常适合这些用例。
既然我们已经介绍了不同消息队列的特点,让我们看一些如何选择正确产品的示例。
对于具有购物车、订单和付款等服务的电子商务网站,我们需要分析日志以调查顾客订单。
下面的图表显示了使用“ELK”堆栈的典型架构:
图片
责任编辑:赵宁宁 来源: 小技术君 数据库Redis消息队列(责任编辑:娱乐)
华兰生物(002007.SZ):2020年度净利升25.69% 基本每股收益0.8873元
平安WiFi获得光启集团5.5亿元投资 联合成立新公司平安讯科
亚太旅行体验预订平台Klook客路旅行获3000万美元B轮融资