工作模式
1. 简单模式
生产者 -> 消费者
2. 工作队列模式
生产者 -> 多个消费者
消息 -> 一次消费
3. 发布订阅模式
生产者 -> 多个消费者
消息 -> 多次消费
4. 路由模式
生产者 -> exchange -> 多个消费者
消息 -> 多次消费
5. 主题模式
生产者 -> exchange -> 多个消费者
消息 -> 多次消费
相当于特殊的路由模式,可以通过 * 来进行主题订阅
-
多个队列可以绑定到同一个路由键:这意味着当一个消息被发送到交换机,并且它匹配了特定的路由键时,所有绑定了这个路由键的队列都会接收到这个消息。因此,每个队列后面可以有多个消费者从中读取消息,实现了消息的多播。
-
单个队列可以绑定多个路由键:这使得队列能够从不同的源接收消息,根据不同的业务逻辑进行处理。
MQ集群
普通集群
消费者链接的mq有概率没有消息,所以,这个时候mq可以拉取别人的消息储存到自己这里,供消费者消费
消息发送也如此,有可能发送到不保存数据的节点,这个时候就把消息进行转发
缺点: 如果存储消息的mq 挂了,这个集群就完了
镜像模式
每一个设备上存储的内容是一样的,这个时候找谁去拉取消息都可以
可以保证高可用
幂等性问题
接口幂等性
消息幂等性
1. 一锁
上一个分布式锁,如果说没上锁就可能会造成并发问题,处理业务逻辑的时候,又进来一个线程
2. 二判
判断该消息是否已经被消费了
可以把消息id存入redis/mysql
消息天然幂等性,比如说id作为主键(进行业务操作的时候,可以利用mysql的主键天然唯一性解决幂等性)最好不要用,因为数据库只负责存储消息,单一职责
3. 更新
说是更新实际上是执行业务逻辑
如何保证消息不丢失
消息可能会在三个地方丢失
producer -> mq 手动ACK、事务
mq 开启持久化
mq-> consumer 手动ACK
MQ的事务机制,允许消费者把请求打包为一个事务,可提交,可回滚
持久化机制,允许对队列/交换机上的消息做持久化
以上机制并不能保证消息100%不丢
如果想要消息100% 不丢失,可以引入本地消息表,以轮询的方式进行重投递