本文主要对于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.解决方案(根据原因匹配对应的解决方案)
①:限制生产者速率
②:提高消费者效率
③:增加消费者数量
④:资源配置优化
