RabbitMQ学习笔记-第七章、学大厂,拓展基础组件封装思路

本章导航

  • 一线大厂的MQ组件实现思路和架构设计方案
  • 基础组件封装设计-迅速消息发送
  • 基础组件封装设计-确认消息发送
  • 基础组件封装设计-批量发送消息
  • 基础组件封装设计-延迟消息发送
  • 基础组件封装设计-顺序消息发送
  • 基础组件封装设计-事务消息发送
  • 消息的幂等性保障-消息路由规则架构设计

7.1一线大厂的MQ组件实现思路和架构设计思路

RabbitMQ学习笔记-第七章、学大厂,拓展基础组件封装思路_第1张图片

一、MQ组件实现功能点

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

7.2消息发送模式-迅速消息发送

  • 迅速消息是指消息不进行落库存储,不做可靠性保障
  • 在一些非核心消息、日志数据、或者统计分析等场景下比较合适
  • 迅速消息的有点就是性能最高、吞吐量最大

RabbitMQ学习笔记-第七章、学大厂,拓展基础组件封装思路_第2张图片

7.3消息发送模式-确认消息发送

RabbitMQ学习笔记-第七章、学大厂,拓展基础组件封装思路_第3张图片

  • step1和step2同时进行把业务相关信息和消息同时入库
  • step3生产者发送消息给broker
  • step4集群收到消息发送确认
  • step5若收到确认修改消息数据库中消息状态
  • step6分布式定时任务检查消息状态若一定时间内没有收到确认进行step7
  • step7尝试重发消息
  • step8若多次尝试重发失败,修改消息状态为失败,执行相关补救措施

7.4消息发送模式-批量消息发送

  • 批量消息是指我们把消息放到一个集合里统一进行提交,这种方案设计思路是期望消息在一个会话里,比如投掷到threadlocal里的集合,然后拥有相同会话ID,并且带有这次提交消息的SIZE等相关属性,最重要的一点是要把这一批消息进行合并。对于Channel而言,就是发送一次消息。这种方式也是希望消费端在消费的时候,可以进行批量化的消费,针对于某一个原子业务的操作去处理,但是不报账可靠性,需要补偿机制

RabbitMQ学习笔记-第七章、学大厂,拓展基础组件封装思路_第4张图片

  • step1业务入库
  • step2消息入库一般就是记录SessionId就够了
  • 其他如同确认机制

7.5消息发送模式-延迟消息发送

  • 延迟消息的实现可以在封装message的时候添加delayTime属性即可,使我们的消息可以进行延迟发送,根据具体业务场景也可以很好的使用
  • 比如电商平台买到商品签收后,不点击确认支付,系统自动会在7天去进行支付操作
  • 优惠券超时作废的机制

7.6消息发送模式-顺序消息

  • 顺序消息的实现类似于批量消息的实现机制
  • 发送的顺序消息必须保证消息投递到同一个队列中,且这个消费者只能有一个(独占模式)
  • 然后需要统一提交(可能是合并成一个大消息,也可能是拆分为多个消息),并且所有消息的会话ID一致
  • 添加消息属性:顺序标记的序号和本次顺序消息的size属性,进行落库操作
  • 并行进行发送给自身的延迟消息(注意带上关键属性:会话ID、SIZE)进行后续处理消费
  • 当收到延迟消息后,根据会话ID和SIZE抽取数据库数据进行处理即可
  • 定时轮询补偿机制,对于异常情况(如生产端消息没有完全投递成功,消费端落库异常,导致消费端落库后缺少消息条目的情况)
    RabbitMQ学习笔记-第七章、学大厂,拓展基础组件封装思路_第5张图片
  • 主要看右边步骤,左边主要是保证消息可靠性投递
  • step1消息入库
  • step2发送延迟消息(这段延迟可以保证所有消息入库成功)
  • step3就是延迟消息处理
  • step4业务入库
  • step5进行失败补偿处理

7.7消息发送模式-事务消息的发送

  • 事务消息,相对少见,但是面对大额现金交易就会使用事务
  • 为了保证性能的同时,支持事务,并没有选择传统的RabbitMQ事务和Spring集成的机制,因为在性能测试中结果不理想,耗性能易阻塞
  • 采用类似可靠性投递的机制,即补偿机制
  • 我们的数据源必须是同一个,就是业务操作DB1数据库和消息记录DB2数据库使用同一个数据源
  • 利用重写Spring DataSourceTransactionManager,在本地事务提交的时候进行发送消息,但是也有可能事务提交成功但是消息发送失败,这个时候就要补偿

7.8消息的幂等性必要性

出现非幂等原因

  • 可靠性消息投递中,Broker会发ack时失败,生产者重发消息造成
  • MQ Broker服务与消费端传输消息的过程中网络波动可能多次传送消息
  • 消费端故障异常

RabbitMQ学习笔记-第七章、学大厂,拓展基础组件封装思路_第6张图片

  • 消费会有全局唯一id(统一id生成服务,本地id生成器)
  • 中间增加id路由组件(redis或者数据库)判断是否已经消费这个消息

你可能感兴趣的:(消息队列)