MQ组件实现的功能性点：
- 支持消息高性能的序列化转换、异步化发送消息。
- 支持消息生产实例与消费实例的链接池化缓存化，提升性能。
- 支持可靠性投递消息，保障消息100%不丢失。
- 支持消费端的幂等操作，避免消费端重复消费的问题。
- 支持迅速消息发送模式，在一些日志收集/统计分析等需求下可以保证高性能，超高吞吐量。
- 支持延迟消息模式，消息可以延迟发送，指定延迟时间，用于某些延迟检查、服务限流场景。
- 支持事务消息，且100%保障可靠性投递，在金融行业单笔大金额操作时会有此类需求。
- 支持顺序消息，保证消息送达消费端的前后顺序，例如下订单等复合性操作。
- 支持消息补偿，重试，以及快速定位异常/失败消息。
- 支持集群消息负载均衡，保障消息落到具体SET集群的负载均衡。
- 支持消息路由策略，指定某些消息路由到指定的SET集群。
迅速消息发送
- 迅速消息是指消息不进行落库存储，不做可靠性的保障。
- 在一些非核心消息、日志数据、或者统计分析等场景下比较合适。
- 迅速消息的优点就是性能最高，吞吐量最大。
确认消息发送
- 将业务消息和消息记录同时入库。
- 发送消息到broker
- 接收broker应答并同步DB，更新消息状态。
- 定时任务扫描并根据消息状态进行补偿处理。
批量消息发送
批量消息是指我们把消息放到一个集合里统一进行提交，这种方案设计思路是期望消息在一个会话里，比如投掷到threadlocal里的集合，然后拥有相同会话ID，并且带有这次提交消息的SIZE等相关属性，最重要的一点是要把这一批消息进行合并。对于Channel而言，就是发送一次消息。这种方式也是希望消费端在消费的时候，可以进行批量化的消费，针对于某一个原子业务的操作去处理，但是不保障可靠性，需要进行补偿机制。
延迟消息
延迟消息相对简单，就是我们在Message封装的时候添加delayTime属性即可，使得我们的消息可以进行延迟发送，根据具体业务场景也可以很好的使用得到。
顺序消息
顺序消息，比较类似于批量消息的实现机制，但是也有些不同。
我们要保障以下几点：
- 发送的顺序消息，必须保障消息投递到同一个队列，且这个消费者只能有一个（独占模式）
- 然后需要统一提交（可能合并成一个大消息，但是还是推荐拆分成多个小消息），并且所有消息的会话ID一致。
- 添加消息属性：顺序标记的序号、和本次顺序消息的SIZE属性，进行落库。
- 并行进行发送给自身的延迟消息（注意带上关键属性：会话ID、SIZE）进行后续处理消费。为了保障在延迟消费的这段时间内，所有顺序消息都能接收并落库。
- 当收到延迟消息后，根据会话ID、SIZE抽取数据库数据进行处理即可。
- 定时轮训补偿机制，对于异常情况
事务消息发送
- 我们采用类似可靠性投递的机制，也就是补偿机制。
- 但是我们的数据源必须是同一个，也就是业务操作DB1数据库和消息记录DB2数据库使用同一个数据源。
- 然后利用重写Spring DataSourceTransactionManager，在本地事务提交的时候进行发送消息，但是也有可能事务提交成功但是消息发送失败，这个时候就需要进行补偿了。