1 前言

分享互联网大厂的基础组件架构封装思路，

其中涉及到

消息发送的多模式化、

消息的高性能序列化、

消息的异步化、

连接的缓存容器、

消息的可靠性投递、补偿策略、

消息的幂等解决方案

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

支持高性能的序列化转换, 异步化发送消息

支持消息生产实例与消费实例的链接池化缓存化, 提升性能

支持可靠性投递消息, 保障消息100%不丢失

支持消费端的幂等操作, 避免消费端重复消费的问题

支持迅速消息发送模式, 在一些日志收集/统计分析等需求下可以保证高性能, 高吞吐量

支持延迟消息模式, 消息可以延迟发送, 指定延迟时间, 用于某些延迟检查, 服务限流场景

支持事务消息, 器100%保障可靠性投递, 在金融行业单笔大金额操作时会有此类需求

支持顺序消息, 保证消息送达消费端的先后顺序

支持消息补偿, 重试, 以及快速定位异常/失败消息

支持集群消息负载均衡, 保障消息落到具体SET集群的负载均衡

支持消息路由策略, 指定某些消息路由到指定的SET集群

3 基础MQ消息组件设计思路-1（迅速，确认，批量，延迟）

迅速消息发送

迅速消息是指消息不进行落库存储, 不做可靠性的保障

在一些非核心消息, 日志数据, 或者统计分析等场景下比较合适

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

确认消息发送

step1, step2 : 业务信息和消息信息入库

step3 : 消息发送到MQ Broker

step4 : Broker回送一个ACK确认消息

step5 : 更新DB中消息状态

step6 : 定时任务读取中间状态消息

step7 : 执行消息重发

step8 : 重发多次依旧失败的消息, 将其置为失败终态

批量消息发送

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

step1 : 业务数据入库

step2 : 消息组装之后进行统一入库(如果不需要可靠性投递的话, 可以省略)

step3 : 消息发送到Broker

step4-step8基本和确认消息是一致的,如果不需要可靠性投递的话, 是可以省略的

延迟消息发送

延迟消息就是在Message封装的时候, 添加delayTime属性即可, 使得我们的消息可以进行延迟发送1

4 基础MQ消息组件设计思路-2（顺序）

顺序消息有点类似于批量消息的实现机制, 但是有些不同, 顺序消息需要保障一下几点:

发送的顺序消息, 必须保障消息投递到同一个队列, 且这个消费者只能有一个(独占模式)

然后需要统一提交(可能是合并成一个大的消息, 也可能是拆分为多个消息), 并且所有消息的会话ID要一致

添加消息属性 : 顺序标记的序号, 和本次顺序消息的SIZE属性, 进行落库操作

并行进行发送给自身的延迟消息(带上关键属性 : 会话ID, SIZE)进行后续处理消费

当收到延迟消息后, 根据会话ID, SIZE抽取数据库数据进行处理即可

定时轮询补偿机制, 对于异常情况(如生产端消息没有完全投递成功或者消费端落库异常导致消费端落库后缺少消息条目的情况)进行补偿

5 基础MQ消息组件设计思路-3(事务)

事务消息, 使用相对较少

为了保障性能的同时, 也支持事务。并不推荐选择传统的RabbitMQ事务和Spring集成的机制, 因为在性能测试过程中, 这种方式性能并不理想, 非常消耗系统资源, 且会出现阻塞等情况, 高峰期也是一定程度上影响MQ集群的性能

解决方案 : 采用类似可靠性投递的机制, 也就是补偿机制。但是数据源必须是同一个, 也就是业务操作的数据库DB1和消息记录的数据库DB2使用同一个数据库, 保证DB层的数据一致性

然后利用重写Spring DataSourceTransactionManager, 在本地事务提交的时候进行发送消息, 但是也有可能事务提交成功但是消息发送失败, 这个时候就需要进行补偿了。