消息队列架构演进
早期mq就是按照队列的数据结构来设计的
若有多个生产者往同一队列发送消息、这个队列可以消费到生产者消息的集合、顺序为生产者发送消息的自然顺序
若多个消费者消费一个队列、这些消费者是竞争关系、只消费到队列的一部分数据
需要每个消费者消费全量消息时、只能创建多个Queue、让生产者发送多份数据、并且生产者必须知道有多少消费者、违背了消息队列解耦的初衷
演进架构
发布 - 订阅模型(Publish-Subscribe Pattern)
在P-S架构中、msg发送方称为发布者Publisher、接收方称为订阅者Subscriber、服务端存放消息的容器称为主题Topic、消费之前必须先订阅主题
其实和队列模式没有本质区别、最大的区别在于: 一份数据能不能被消费多次
RabbitMQ的消息模型
RabbitMQ是少数坚持使用队列模型的产品之一、它如何解决多个消费者的问题呢 ？
Exchange: 位于生产者和队列之间、生产者不关心将消息发送给哪个队列、而是将消息发送给Exchange、由Exchange上配置的策略来决定将消息投递到哪些队列中
同一份消息需要被多个消费者消费时、需要配置exchange将消息发送到多个队列、每个队列中存放一份完整的消息数据、
RocketMQ的消息模型
RocketMQ使用的是标准的发布-订阅模型、
普通的MQ都是使用的请求-确认机制、确保消息不会再传递过程中由于网络故障或服务器故障丢失. 在生产端、生产者将消息发给服务端Broker、Broker在收到消息并将消息写入主题或者队列后、会给生产者发送确认的响应、若生产者未收到服务端的确认或者收到失败的响应、会重新发消息; 在消费端、消费者收到消息并完成消费逻辑后也会给服务端发送消费成功的确认、服务端只有在收到消费确认后、才会认为一条消息被成功消费、否则会重发消息
为了保证消息有序性、在消息被成功消费前、下一条消息不能被消费、否则就出现了消息空洞、违背了有序性的原则、所以 MQ增加了队列的概念、只在队列层面保证消息的有序性、主题层面不保证
消息会被不同消费组消费、消费完的消息不会立即删除、MQ为每个队列维护了一个消费位置Consumer Offset、每成功消费一条消息、位置就+1
Kafka的消息模型
Kafka的消费模型和RocketMQ的模型是完全一样的、唯一的区别是 在Kafka中队列这个概念的名称不同、Kafka对应的概念叫 分区 - Partition
注意:
RocketMQ 和 Kafka 的业务模型一样、不代表实现一致、其实实现是完全不同的、就像MySQL和hbase存放数据的单元都是表、实现完全不同、MySQL使用B+树来存储、HBase 使用KV结构存储
MQ的事务实现
Kafka 和 RocketMQ 都提供了事务的实现
在消息队列上开启一个事务、给服务器发送一个半消息状态、它包含完整的消息内容、但对于消费者不可见、本地事务提交后再提交消息事务
但: 如果提交消息事务失败怎么办 ？
- kafka的方案简单粗暴、直接抛异常、用户自行处理
-
RocketMQ提供了事务反查机制、若Broker未收到提交或者回滚的请求、Broker会定期去Producer上反查本地事务对应状态、来决定事务提交还是回滚
image.png
消息可靠性保证
检测消息丢失
1.若基础设施比较完善、一般会有分布式链路追踪系统、可以追踪消息流
2.利用消息有序性校验: 给每个发出的消息附加一个连续的序号、若序号不连续、就可以判定为消息丢失
注意: 多个producer 和 多个consumer的情况、需要判定每个分区的序列有效性
如何保证
1.生产阶段、根据不同mq的确认机制、进行对应的处理 eg: kafka -> 捕获异常
2.存储阶段、正常broker运行的时候、不会出现消息丢失、但若broker出现了故障或者宕机、是可能丢消息的. 单节点broker可以配置broker在收到消息后立即落盘、broker是集群的时候、可以配置至少2个节点收到消息再确认
3.消费阶段、同生产阶段、消费端业务逻辑成功后再回传确认
有可能消息再网络传输过程中发生错误、发送方收不到确认就会重发消息、所以Broker 和 Consumer 都可能会收到重复消息、需要注意接口的幂等性
业务变相实现
1.利用数据库的唯一约束实现幂等、
2.为更新的数据设置前置条件、满足某种条件才更新
3.记录并检查操作(需要考虑唯一ID的生成和多步操作的原子性)
思考
幂等方案、不止是可以解决消息重复的问题、也同样适用于其它场景.eg: 将HTTP服务设计成幂等的、解决前端或者APP重复提交表单数据问题、也可以将一个微服务设计成幂等的、解决RPC框架自动重试导致的重复调用问题
