架构设计（消息队列）

---

架构设计（消息队列）

             

                

                                

消息队列

           

发送者将消息发送到topic，消费者从topic中拉取消息进行消费

                  

         

发送端消息发送方式

同步发送：消息发送后，需要等待消息发送响应结果，发送失败可重试
异步发送：消息发送后，立即返回，不需要等待消息发送结果，broker异步通知发送结果
单向发送：消息发送后，立即返回，不需要等待消息发送结果，也没有回调函数通知结果

           

消费端消息消费

# 消费端消息消费失败可以重试
同组消费者：同一个group的消费者分担消费消息，消费的消息不同
不同组消费者：同一个topic可以被多个消费者组订阅，不同组的消费者订阅的消息相同

            

                   

                                

应用场景

         

服务解耦：如果服务调用不需要等待获取结果，可使用消息队列将同步调用变成异步调用

                  

# 使用消息队列将同步调用变成异步调用，可提升服务吞吐量(tps)
服务a：消息发送端，将消息发送到topic后，不需要等待服务b处理完成，可立即返回
服务b：订阅消息队列中的topic，拉取消息进行消费

            

流量削峰：系统在面对极端流量时，可使用消息队列存储消息

                  

                                

                                

注意事项

      

消息积压

# 消息积压
发送端发送消息的速度大于消费端处理消息的速度，致使消息在队列中堆积

# 解决方法
消息持久化存储：rocketmq等队列都提供了持久化机制，会在一段时间内保存消息
优化消费端逻辑：如果消息在流量正常的情况下还是造成堆积，可优化消费端处理逻辑
添加消费者：消费端优化后，如果消息还是堆积，可增加消费者，提升消息处理能力

               

消息可靠传递

# 消息可靠传递
broker：消息发送到队列，队列正常存储消息
消费端：从broker拉取消息，能够消费消息；如果消息前后有顺序，还需要顺序消费

# 解决方法
发送端：消息使用同步发送，发送失败进行重试
消费端：消息消费成功后，手动提交消费偏移量，消费失败进行重试
       rocketmq提供了顺序消费接口，可顺序消费消息

               

消息去重

# 消息去重
broker重复存储：由于网络抖动，发送者在发送成功后，可能仍会发送消息，造成broker重复存储
消费端重复消费：消息消费成功后，提交偏移量失败，重复拉取消息，造成消息重复消费

# 解决方法
broker重复存储：可以容忍broker消息重复存储
消费端重复消费：消费端需要幂等消费的消息，需要采取方法去重
             如使用redis存储成功消费的消息id，消费消息前先判断消息是否已经成功消费