手写消息队列 消息列队mq

概述

MQ全称 Message Queue，直译中文就是：消息队列，是在消息的传输过程中的保存消息的容器。多用于分布式系统之间的通信。

• MQ是存储消息的中间件
• 发送方称为生产者，接收方称为消费者

MQ相比于直接调用的优劣势

优势

• 应用解耦：系统的耦合性越高，容错性就越低，可维护性就越低

传统直接调用模式存在一下问题：

1. 当一个业务系统A某个业务操作需要调用多个外部系统的时候，把所有调用链路垂直调用；当调用链路中有一个调用失败的时候就会导致整个链路的失败，整个业务的容错性低
2. 当调用链路中需要增加一个调用环节的时候，就要修改A系统的代码，长此以往，A系统的代码的可读性和维护性将大大降低

MQ：

1. 业务系统A将业务操作信息传递给MQ
2. 在业务链路中的各个系统B、C、D等系统从MQ中获取A系统的业务信息（消费消息），之后各个系统完成自己的工作；当某个链路中的系统消费了消息后业务执行失败，其可以反复的消费MQ中的消息，直到最终执行成功，不会影响其他系统的业务执行，保证了业务的最终一致性就可以了
3. 当业务链路中增加一个环节的时候，只需要新增加的业务系统去消费MQ中的业务信息就可以了，并不需要A系统去做代码的修改

---

• 异步提速：提升用户体验，增加系统的吞吐量

传统垂直业务执行：

1. 当业务复杂的时候，所有业务同步执行，整个业务的执行时间是业务链路中各个环节执行时间的总和
2. 当整个调用成功之后才返回业务结果

MQ：

1. 主业务系统A在执行过程中只需要生产消息即可（把业务信息传递给MQ）
2. 主业务系统A在将业务信息传递给MQ之后，即可返回执行结果
3. 其他在业务链路中的系统各自从MQ中获取业务信息执行，不影响主业务的执行时间

---

• 削峰填谷：极大的提高了系统的稳定性

在某些高并发的业务场景下，传统垂直业务系统是无法承受的，例如：春运抢票、双十一抢购、秒杀活动等，由于MQ可以承载大量的请求，所以MQ在这种业务场景下就可以作为一个“缓冲”，帮助业务系统缓解瞬时的压力。

1. 当请求并发增高的时候，所有业务请求首先放入MQ
2. 业务系统则在保证系统正常平稳的情况下，尽力从MQ获取业务信息，按照自己的“节奏”处理业务
3. 过多的业务积压在MQ中，拉长了整体业务的执行时长，这就是填谷

劣势

• 系统的可用性降低：系统引入的外部依赖越多，系统的可用性就越差

由于引入了MQ的缘故，MQ成为了系统业务执行的关键中间件，一旦MQ挂掉，就会对业务造成影响。

---

• 系统的复杂度提高

需要多考虑如下等问题：

1. 消费者系统是否重复消费了MQ的业务信息
2. 是否能稳定的从MQ获取到业务信息
3. 从MQ获取的消息的顺序是怎么保证的呢？

---

• 一致性问题

从MQ消费业务消息的各个系统如B、C、D、E等系统，这其中的每一个系统都可能会发生业务执行失败的情况，所以就要有措施来保证业务链路中各个环节的最终一致性

使用MQ需要满足的条件

1.生产者不需要从消费者获取业务执行的反馈

2.允许短暂的不一致性

3.MQ这一中间件的引入，确实能解决问题

即解耦、提速、削峰等方面的收益超过了加入MQ、管理MQ等需要承受的成本

常见的MQ产品

RabbitMQ、RocketMQ、ActiveMQ、Kafka等，也有用redis发布订阅的功能做为MQ的替代

需要根据各个MQ的特点和能力，结合自身的实际业务场景选择不同的MQ来使用