1. 幂等性保障
1.1 介绍
幂等性是数学和计算机科学中某些运算的性质, 它们可以被多次应⽤, ⽽不会改变初始应⽤的结果.
在应⽤程序中, 幂等性就是指对⼀个系统进⾏重复调⽤(相同参数), 不论请求多少次, 这些请求对系统的影响都是相同的效果.
⽐如数据库的 select 操作. 不同时间两次查询的结果可能不同, 但是这个操作是符合幂等性的.
幂等性指的是对资源的影响, ⽽不是返回结果 . 查询操作对数据资源本⾝不会产⽣影响, 之所以结果不同, 可能是因为两次查询之间有其他操作对资源进⾏了修改.
⽐如 i++ 这个操作, 就是⾮幂等性的. 如果调⽤⽅没有控制好逻辑, ⼀次流程重复调⽤好⼏次, 结果 就会不同.
MQ的幂等性介绍
对于MQ⽽⾔, 幂等性是指同⼀条消息, 多次消费, 对系统的影响是相同的.
比如,接口幂等性:
多次调用支付接口(同一个订单,同样的参数),对于系统的影响是一样的(只能支付一次)
⼀般消息中间件的消息传输保障分为三个层级:
- At most once:最多⼀次. 消息可能会丢失，但绝不会重复传输.
- At least once:最少⼀次. 消息绝不会丢失，但可能会重复传输.
- Exactly once:恰好⼀次. 每条消息肯定会被传输⼀次且仅传输⼀次.(RabbitMQ不⽀持)
在业务使⽤中, 对于可靠性要求⽐较⾼的场景, 建议使⽤"最少⼀次", 以防⽌消息丢失. "最多⼀次" 会因为消息发送过程中, ⽹络问题, 消费出现异常等种种原因, 导致消息丢失.
以下场景可能会导致消息发送重复:
- 发送时消息重复: 当⼀条消息已被成功发送到服务端并完成持久化, 此时出现了⽹络闪断或者客⼾端宕机, 导致服务端对客⼾端应答失败. 如果此时Producer意识到消息发送失败并尝试再次发送消息, Consumer后续会收到两条内容相同并且Message ID也相同的消息.
- 投递时消息重复: 消息消费的场景下, 消息已投递到Consumer并完成业务处理, 当客⼾端给服务端反馈应答的时候⽹络闪断. 为了保证消息⾄少被消费⼀次, 云消息队列 RabbitMQ 版的服务端将在⽹络恢复后再次尝试投递之前已被处理过的消息, Consumer后续会收到两条内容相同并且 Message ID也相同的消息.
但是"最少⼀次", 就会造成⼀个问题, 消费端会收到重复的消息, 也会造成对同⼀条消息进⾏多次处理. ⼀些不重要的业务还好,对于重要的事务,如果不对重复的消息进⾏处理, 会造成严重事故.
⽐如:
当⽤⼾对⼀个订单付款之后, 因为⽹络问题, 付款成功的结果未返回给订单系统, 当⽤⼾再次点击付款时, 如果系统未做幂等性处理, 那就会造成两次扣款
1.2 解决
MQ消费者的幂等性的解决⽅法, ⼀般有以下⼏种:
全局唯⼀ID
- 为每条消息分配⼀个唯⼀标识符, ⽐如UUID或者MQ消息中的唯⼀ID,但是⼀定要保证唯⼀性.
- 消费者收到消息后, 先⽤该id判断该消息是否已经消费过, 如果已经消费过, 则放弃处理.
- 如果未消费过, 消费者开始消费消息, 业务处理成功后, 把唯⼀ID保存起来(数据库或Redis等)
可以使⽤Redis 的原⼦性操作setnx(set if not exists)来保证幂等性, 将唯⼀ID作为key放到redis中 (SETNX messageID 1) .
返回1, 说明之前没有消费过, 正常消费. 返回0, 说明这条消息之前已消费过, 抛弃.
业务逻辑判断
在业务逻辑层⾯实现消息处理的幂等性
例如:
检查数据库中是否已存在相关数据记录, 或者使⽤乐观锁机制来避免更新已被其他事务更改的数据, 再或者在处理消息之前, 先检查相关业务的状态, 确保消息对应的操作尚未执⾏, 然后才进⾏处理, 具体根据业务场景来处理
2. 顺序性保障
2.1 介绍
消息的顺序性是指消费者消费的消息和⽣产者发送消息的顺序是⼀致的.
⽐如⽣产者发送的消息分别是msg1, msg2, msg3, 那么消费者也是按照msg1, msg2, msg3的顺序进⾏消费的.
很多业务场景下, 消息的消费是不⽤保证顺序的, ⽐如使⽤MQ实现订单超时的处理.
但有些业务场景, 可能存在多个消息顺序处理的情况. ⽐如⽤⼾信息修改, 对同⼀个⽤⼾的同⼀个资料进⾏修改, 需要保证消息的顺序.(修改name为张山,修改name为李四)
⼀些资料显⽰RabbitMQ的消息能够保障顺序性, 这是不严谨的.
在不考虑消息丢失, ⽹络故障等异常的情况下, 如果只有⼀个消费者, 最好也只有⼀个⽣产者的情况下, 是可以保证消息的顺序性.
如果有多个⽣产者同时发送消息, ⽆法确定消息到达RabbitMQ Broker的前后顺序, 也就⽆法验证消息的顺序性.
下面是几种常见的场景:
- 多个消费者: 当队列配置了多个消费者时, 消息可能会被不同的消费者并⾏处理, 从⽽导致消息处理的顺序性⽆法保证.
- ⽹络波动或异常: 在消息传递过程中, 如果出现⽹络波动或异常, 可能会导致消息确认(ACK) 丢失, 从⽽使得消息被重新⼊队和重新消费, 造成顺序性问题.
- 消息重试：如果消费者在处理消息后未能及时发送确认, 或者确认消息在传输过程中丢失, 那么MQ 可能会认为消息未被成功消费⽽进⾏重试, 这也可能导致消息处理的顺序性问题.
- 消息路由问题: 在复杂的路由场景中, 消息可能会根据路由键被发送到不同的队列, 从⽽⽆法保证全局的顺序性.
- 死信队列: 消息因为某些原因(如消费端拒绝消息)被放⼊死信队列, 死信队列被消费时, ⽆法保证消息的顺序和⽣产者发送消息的顺序⼀致
2.2 解决
消息顺序性保障分为: 局部顺序性保证 和全局顺序性保证.
局部顺序性通常指的是在单个队列内部保证消息的顺序.
全局顺序性是指在多个队列或多个消费者之间保证消息的顺序.(难以实现)
mq消息的顺序性保证的常见策略:
单队列单消费者
最简单的⽅法是使⽤单个队列(合成一个队列), 并由单个消费者进⾏处理.
同⼀个队列中的消息是先进先出的, 这是 RabbitMQ来帮助我们保证的.
分区消费(rabbitmq不支持)
单个消费者的吞吐太低了, 当需要多个消费者以提⾼处理速度时, 可以使⽤分区消费.
把⼀个队列分割成多个分区, 每个分区由⼀个消费者处理, 以此来保持每个分区内消息的顺序性.
举个例子:根据订单ID进行分区
把同一个订单的消息发送给同一个队列,由同一个消费者进行消费
消息确认机制
使⽤⼿动消息确认机制, 消费者在处理完⼀条消息后, 显式地发送确认, 这样RabbitMQ才会移除并继续发送下⼀条消息.
业务逻辑控制
在某些情况下, 即使消息乱序到达, 也可以在业务逻辑层⾯实现顺序控制.
⽐如通过在消息中嵌⼊序列号, 并在消费时根据这些信息来处理
RabbitMQ本⾝并不保证全局的严格顺序性, 特别是在分布式系统中. 在实际应⽤开发中, 根据具体的业务需求, 可能需要结合多种策略来实现所需要的顺序保证.
3. 消息积压问题
消息积压是指在消息队列)中, 待处理的消息数量超过了消费者处理能⼒, 导致消息在队列中不断堆积的现象.
3.1 原因
- 1)消息⽣产过快: 在⾼流量或者⾼负载的情况下, ⽣产者以极⾼的速率发送消息, 超过了消费者的处理能⼒.
- 2)消费者处理能⼒不⾜: 消费者处理处理消息的速度跟不上消息⽣产的速度, 也会导致消息在队列中积压.
2)可能原因有:
- 消费端业务逻辑复杂, 耗时⻓
- 消费端代码性能低
- 系统资源限制, 如CPU、内存、磁盘I/O等也会限制消费者处理消息的效率.
- 异常处理处理不当. 消费者在处理消息时出现异常, 导致消息⽆法被正确处理和确认.
- 3)⽹络问题: 因为⽹络延迟或不稳定, 消费者⽆法及时接收或确认消息, 最终导致消息积压
- 4)RabbitMQ 服务器配置偏低
3.2 解决
1. 提⾼消费者效率
- a. 增加消费者实例数量, ⽐如新增机器
- b. 优化业务逻辑, ⽐如使⽤多线程来处理业务
- c. 设置prefetchCount, 当⼀个消费者阻塞时, 消息转发到其他未阻塞的消费者.
- d. 消息发⽣异常时, 设置合适的重试策略, 或者转⼊到死信队列
2. 限制⽣产者速率. ⽐如流量控制, 限流算法等.
- a. 流量控制: 在消息⽣产者中实现流量控制逻辑, 根据消费者处理能⼒动态调整发送速率
- b. 限流: 使⽤限流⼯具, 为消息发送速率设置⼀个上限
- c. 设置过期时间. 如果消息过期未消费, 可以配置死信队列, 以避免消息丢失, 并减少对主队列的压⼒
3. 资源与配置优化.
- ⽐如升级RabbitMQ服务器的硬件, 调整RabbitMQ的配置参数等