消息队列queue

消息队列

RabbitMQ

RabbitMQ中的角色：

• publisher：生产者 发布者

• consumer：消费者 订阅者

• exchange：交换机，负责消息路由，转发消息给队列，注：如果找不到队列，则消息会丢失

• queue：队列，存储消息，一旦被消费，消息就会被删除

• virtualHost：虚拟主机，隔离不同用户|环境的exchange、queue、消息的隔离

WorkQueue

Work queues，也被称为（Task queues），任务模型。简单来说就是让多个消费者绑定到一个队列，共同消费队列中的消息。

当消息处理比较耗时的时候，可能生产消息的速度会远远大于消息的消费速度。长此以往，消息就会堆积越来越多，无法及时处理。

此时就可以使用work 模型，多个消费者共同处理消息处理，速度就能大大提高了。

发布/订阅

发布订阅的模型如图：

可以看到，在订阅模型中，多了一个exchange角色，而且过程略有变化：

• Publisher：生产者，也就是要发送消息的程序，但是不再发送到队列中，而是发给X（交换机）

• Exchange：交换机，。一方面，接收生产者发送的消息。另一方面，知道如何处理消息，例如递交给某个特别队列、递交给所有队列、或是将消息丢弃。到底如何操作，取决于Exchange的类型。Exchange有以下3种类型：

  • Fanout：广播，将消息交给所有绑定到交换机的队列

  • Direct：定向，把消息交给符合指定routing key 的队列

  • Topic：通配符，把消息交给符合routing pattern（路由模式） 的队列

• Consumer：消费者，与以前一样，订阅队列，没有变化

• Queue：消息队列也与以前一样，接收消息、缓存消息。

消息如何保证可靠性

1. 生产者ack确认

2. mq持久化

   • 交换机持久化

   • 队列持久化

   • 消息持久化

3. 消费者确认机制

4. 失败重试机制

延迟队列

利用TTL结合死信交换机，我们实现了消息发出后，消费者延迟收到消息的效果。这种消息模式就称为延迟队列（Delay Queue）模式。

延迟队列的使用场景包括：

• 延迟发送短信

• 用户下单，如果用户在15 分钟内未支付，则自动取消

• 预约工作会议，20分钟后自动通知所有参会人员

死信交换机

当一个队列中的消息满足下列情况之一时，可以成为死信（dead letter）：

• 消费者使用channel.basicReject()或 channel.basicReject()声明消费失败（使用原生的API中进行确认即手动模式），并且消息的requeue参数设置为false

• 消息是一个过期消息，超时无人消费（队列超时和消息超时两种）

• 要投递的队列消息满了，无法投递

TTL

一个队列中的消息如果超时未消费，则会变为死信，超时分为两种情况：

• 消息所在的队列设置了超时时间

• 消息本身设置了超时时间

消息堆积问题

当生产者发送消息的速度超过了消费者处理消息的速度，就会导致队列中的消息堆积，直到队列存储消息达到上限。之后发送的消息就会成为死信，可能会被丢弃，这就是消息堆积问题。

解决方案：惰性队列

惰性队列

从RabbitMQ的3.6.0版本开始，就增加了Lazy Queues的概念，也就是惰性队列。惰性队列的特征如下：

• 接收到消息后直接存入磁盘而非内存

• 消费者要消费消息时才会从磁盘中读取并加载到内存

• 支持数百万条的消息存储

Kafka

Mqtt

消息的重复问题

造成消息重复的根本原因是：网络不可达。

所以解决这个问题的办法就是绕过这个问题。那么问题就变成了：如果消费端收到两条一样的消息，应该怎样处理？

消费端处理消息的业务逻辑需要保持幂等性。只要保持幂等性，不管来多少条重复消息，最后处理的结果都一样。保证每条消息都有唯一编号和添加一张日志表来记录已经处理成功的消息的 ID，如果新到的消息 ID 已经在日志表中，那么就不再处理这条消息。

消息的顺序问题

保证生产者 - MQServer - 消费者是一对一对一的关系