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

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

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

延迟消息相对简单，就是我们在Message封装的时候添加delayTime属性即可，使得我们的消息可以进行延迟发送，根据具体的业务场景也可以很好的使用得到。
场景举例：
1. 比如你在电商平台买到商品签收后，不点击确定支付，那么系统自动会在7天（一定时间）去进行支付操作。
2. 还要一些自动超时作废场景，你的优惠券/红包有使用时间限制，也可以用延迟消息机制。

事务消息，相对使用比较少见，但是本身在早期做互联网行业中，面对单笔大额现金流交易时遇到遇到过：比如单笔转账超过一个上限的时候，我们就希望这个消息优先级最高，并且可靠性要求达到100%，当然我们的系统和银行端系统都要兼顾才行，所有也会有一些补偿机制，主动发起银行端查询指令机制等。
为了保障性能的同时，也支持事务。我们并没有选择传统的RabbitMQ事务和Spring集成的机制，因为在性能测试过程中，效果并不理想，非常消耗系统资源且会出现阻塞等情况，在高峰期也是一定程度上影响MQ集群的性能
解决方案：
我们采用类似可靠性投递的机制，也就是补偿机制。
但是我们的数据源必须是同一个，也就是业务操作DB1数据和消息记录BD2数据库必须使用同一个数据源
然后利用重写Spring DatasourceTransactionManage，在本地事务提交的时候进行发送消息，但是也有可能事务提交成功但是消息发送失败，这个时候就需要进行补偿了。
- DatasourceTransactionManager核心代码：

保障消息的幂等性，这也是我们在使用MQ中至关重要的环节
可能导致消息出现非幂等性的原因：
1. 可靠性消息投递机制（消息失败时多次发送）
2. MQ Broker服务与消费端传输消息过程中出现网络抖动
3. 消费端的故障或异常
  以上这些问题都会导致消费端重复消息问题。