本文主要对于RabbitMQ的一些应用问题来进行小结
⭐一.幂等性保障
1.幂等性概念:对于MQ而言,幂等性是指同一条消息多次消费后,对系统的影响是相同的
**2.常见幂等性:**①:接口幂等(如同一个支付接口多次请求对系统影响应该是相同的)
②:编程幂等
③:MQ消息幂等
3.幂等性应用场景:
重复执行不会改动数据、不产生资源损耗就不用幂等；
新增、扣减、付费、外部调用等重复会出错亏损的场景，一律做幂等。
⭐4.一般消息中间件的消息传输保障分三级:
①:最多一次:消息可能 会丢失 ,但绝不会重复传输
②:最少一次:消息绝不会丢失 ,但可能 会重复传输
③:恰好一次: 每条消息肯定会被传一次且仅传一次
RabbitMQ支持①:最多一次和②:最少一次. 注:市面上主流中间件都不支持③
tips:
<1>对于可靠性要求较高的场景,建议用②:最少一次,以防止消息丢失.
<2>而①:最多一次会因为消息发送过程中,可能出现的网络问题,消费者逻辑异常等问题导致消息丢失.
<3>所以为了保证消息不丢失,最好选择②:最少一次.
但是②:最少一次可能会造成一个问题,由于网络,消费者逻辑异常问题,消费端可能接收到生产者发送的消息收到了两条重复的,对于支付业务会造成严重事故
⭐为什么消费端会收到生产者发送的两条相同的消息呢?
**因为:**可能消费者在返回ACK给生产者的过程中出现了网络问题等问题,生产者一段时间后仍迟迟收不到消费者返回的应答,因为选择了②:最少一次.为了保证消息最少被消费一次,所以生产者会重新发送一条与之前相同的消息给消费者,这时可能网络等问题恢复了,消费者就会收到两条相同的消息,这对于金融类业务会造成巨大事故,毕竟没有老板希望用户充一份钱,得两倍的Q币,就是这个道理.
5.解决MQ消费者业务为非幂等的问题:
①:设置全局唯一ID(80%)
<1>给每条消息分配一个唯一ID(UUID,自增ID)
<2>判断该ID对应的消息是否被消费
<3>该消息被消费后,保存好这条被消费的消息对应的唯一ID(redis-setnx:存在redis或数据库)
②:业务逻辑判断
<1>乐观锁机制
⭐二.顺序性保障
1.什么是顺序性保障:消息的顺序性是指消费者消费的消息 和生产者发送的消息,顺序是一致的
2.应用场景:用户修改信息:对同一个用户的同一个资料进行修改,需要保证消息的顺序性,如:小明在短时间内修改了两次昵称,若无顺序性保障,可能最后修改的昵称是第一次修改的,而不是第二次.
3.哪些情况可能打破RabbitMQ的顺序性呢?
①:多个消费者
②:网络波动异常
③:消息重试
④:消息路由问题
⑤:死信队列
4.顺序性保障方案:
1.消息顺序性保障分为:{①:局部顺序性保障
②:全局顺序性保障}
2.常见策略:
①:单队列消费者(先进先出)
②:分区消费(RabbitMQ不支持)
③:消息确认机制(手动确认)
④:业务逻辑控制
⭐三.消息积压:
1.什么是消息积压:在消息队列中,待处理的消息数量超过了消费者处理能力 而导致的消息在队列中不断堆积的现象.
2.原因:
①:消息生成过快
②:消费者处理消息能力不足
③:网络问题
④:RabbitMQ服务器配置偏低
3.解决方案(根据原因匹配对应的解决方案)
①:限制生产者速率
②:提高消费者效率
③:增加消费者数量
④:资源配置优化