怎么理解RabbitMQ在一线大厂中的基础组件架构设计思路

这篇文章将为大家详细讲解有关怎么理解RabbitMQ在一线大厂中的基础组件架构设计思路，文章内容质量较高，因此小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。

1、MQ组件实现功能点

MQ组件实现功能点
1) 支持消息高性能的序列化转换、异步化发送消息
2) 支持消息生产实例与消费实例的连接池化缓存化,提升性能
3) 支持可靠性投递消息,保证消息的100%不丢失
4) 支持消费端的幂等操作,避免消费端重复消费问题

5) 支持迅速消息发送模式,有些场景下不需要保证100%成功投递,在一些日志收集、统计分析等需求下可以保证高性能、超高吞吐量
6) 支持延迟消息模式,消息可以延迟发送,指定延迟时间,用于某些延迟检查、服务限流场景
7) 支持事务消息,且100%保障可靠性投递,在金融行业单笔大金额操作时会有此类需求
8) 支持顺序消息,保证消息送达消费端的前后顺序,例如下订单等复合型操作
9) 支持消息补偿、重试,快速定位异常

2、迅速消息发送

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

3、批量消息发送

   批量消息是指我们把消息放到一个集合里统一进行提交,将消息合并,对于channel而言,就是发送一次消息,这种方式也是希望消费端在
消费的时候,可以进行批量化消费,但是不保证可靠性,需要进行补偿机制RabbitMQ不支持消息批量发送,可以自己实现

4、延迟消息发送

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

5、顺序消息发送

要保障以下几点：
1) 发送的顺序消息,必须保障消息投递到同一个队列,且这个消费者只能有一个(独占模式)
2) 然后需要统一提交(可能是合并成一个大消息,也可以是拆分成多个小消息),并且所有消息的会话ID一致
3) 添加消息的属性:顺序标记的序号、本次顺序消息的SIZE属性,先不消费消息,消费端收到后进行消息落库
4) 并行进行发送给自身的延迟消息,注意带上关键属性(会话ID、SIZE)进行后续处理消费,确保延迟的事件段中这一批消息都已经全部收到
5) 当收到延迟消息后,根据会话ID、SIZE抽取数据库数据进行处理即可
6) 定时轮询补偿机制,对于异常情况,如生产端消息没有完全投递成功、或者消费端落库异常,导致消费端落库后缺少消息条目的情况

6、事务消息发送

我们采用类似可靠性投递的机制,也就是补偿机制.

我们使用的数据源必须是同一个,也就是业务操作DB1数据库和消息记录DB2数据库使用同一个数据源

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

7、消息的幂等性

可能导致消息出现非幂等的原因:
1) 可靠性消息投递机制
2) MQ Broker服务与消费端传输消息的过程中的网络抖动
3) 消费端故障或异常

关于怎么理解RabbitMQ在一线大厂中的基础组件架构设计思路就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。