课程导航

1. 一线大厂的MQ组件实现思路和架构设计方案
2. 基础组件封装设计 - 迅速消息发送
3. 基础组件封装设计 - 确认消息发送
4. 基础组件封装设计 - 批量消息发送
5. 基础组件封装设计 - 延迟消息发送
6. 基础组件封装设计 - 顺序消息发送
7. 基础组件封装设计 - 事务消息发送

image.png

mq组件实现功能点

• 支持消息高性能的序列化转换，异步发送消息
• 支持消息生产实例与消费实例的链接池化，缓存化，提升性能
• 支持可靠性投递消息，保障消息的100%不丢失
• 支持消费端的幂等操作，避免消费端重复消费的问题
• 支持迅速消息发送模式，在一些日志收集/统计分析等需求下可以保证高性能，超高吞吐量
• 支持延迟消息模式，消息可以延时发送，指定延时时间，用于某些延迟检查，服务限流场景
• 支持事务消息，且100%保障可靠性投递，在金融行业单笔大金额操作时会有此类需求
• 支持顺序消息，保证消息送达消费端的前后顺序，例如下单等复合性操作
• 支持消息补偿，重试，以及快速定位异常/失败消息
• 支持集群消息负载均衡，保障消息落到具体SET集群的负载均衡
• 支持消息路由策略，指定某些消息路由到指定的SET集群

一、消息发送模式- 迅速消息发送

• 迅速消息是指消息不进行落库存储，不做可靠性的保障
• 在一些非核心信息，日志数据，或者统计分析等场景下比较合适

• 迅速消息的优点就是性能最高，吞吐量大

  
  image.png

二、消息发送模式- 确认消息发送

image.png

三、消息发送模式- 批量消息发送

image.png image.png

三、消息发送模式- 延迟消息发送

• 延迟消息相对简单，就是我们在 Message封装的时候添加delayTime属性即可，使得我们的消息可以进行延迟发送，根据具体的业务场景也可以很好的使用得到。

image.png

四、消息发送模式- 顺序消息

• 顺序消息 ， 比较类似于批量消息的实现机制，但是也有些不同。
• 我们要保障以下几点
  1. 发送的顺序消息，必须保障消息投递到同一个队列，且这个消费者只能有一个（独占模式）
  2. 然后需要统一提交（可能是合并成一个大消息，也可能是拆分成多个消息），并且所有消息的会话ID一致
  3. 添加消息属性： 顺序标记的序号，和本次顺序消息的SIZE属性，进行落库操作
  4. 并行进行发送给自身的延迟信息（注意带上关键属性：会话ID .SIZE ） 进行后续处理消费
  5. 当收到延迟消息后，根据会话ID，SIZE抽取数据库数据进行处理即可
  6. 定时轮训补偿机制，对于异常情况
     • 备注 ： 比如生产daunt消息没有完全投递成功，或者消费端落库异常导致消费端落库后缺少消息条目的情况

image.png

五、消息发送模式- 事务消息发送

image.png image.png

解决方案

• 我们采用类似可靠性投递的机制，也就是补偿机制。
• 但是我们的数据源必须是同一个，也就是业务操作DB1数据库和消息记录DB2数据库使用同一个数据源
• 然后利用重写 Spring DataSourceTransactionManage 在本地事务提交的时候进行发送消息，但是也有可能事务提交成功但是消息发送失败。这个时候就要进行补偿了。

image.png image.png

---

---

消息幂等性的必要性

• 保障消息的幂等性，这是使用MQ中至关重要的环节
• 可能导致消息出现非幂等的原因：
  1. 可靠性消息投递机制
  2. MQ Broker服务与消费端传输消息的过程中的网络抖动
  3. 消费端故障或异常

image.png

总结

image.png