消息队列选型

MQ 知识点

1、什么是 MQ ？

MQ 即为消息队列，是服务间一种异步通信的方式，适用于无服务器和微服务架构。消息在删除和处理之前一直存储在队列上，每条消息可被一个或者多个消费者进行消费。消息队列可用于服务间的解耦，分离重量级处理、缓冲或批处理工作以及缓解高峰期工作负载。

image-20210903152500688

为什么我们需要消息队列？

​ 当公司的业务非常单一，并且数据量没有那么大的时候，我们采用单机架构完全可以很好的满足业务的需求，虽然这样系统的扩展性很差，但是要牢记一点，技术是为业务服务的，没有必要为了使用新技术而使用新技术。

​ 当公司的业务复杂度逐渐增加，相对应的数据量也会有爆炸式的增长。这个时候再采用单机同步服务的方式确实不太适合。因为业务复杂度上来以后，会有非常多的业务节点。如果其中一个业务节点非常耗时，那会导致整个业务流都非常耗时，从而带来非常差的用户体验。

​ 例如数据中心，当我们添加一条主域名后，后续会进行域名爆破、域名解析、域名数据汇总等任务，单个任务都会有几十秒甚至是几分钟的耗时，如果一直等待着，那用户肯定会认为是系统出了问题。这个时候我们只能采用异步的方式将这些任务分发下去同时执行。然后再统一汇总结果，更改数据库的数据。但是从用户角度来看，我添加了一个域名，那立刻就能在数据中心看到我的数据了。当后续的任务数据汇总过来以后，还能看到更多的数据，对用户体验很好。

​ 提到了异步任务，就会有消息队列。我们各个服务之间的相互调用，消息队列是最为稳妥的方式。使用接口会有网络的抖动等问题，直接调用对方的数据库更加不可取。消息队列采用生产者-消费者模型，能将我们的消息很好的进行分发传输，每个服务只需要接收属于自己服务的消息，然后进行自己的业务逻辑就行，服务直接可以解耦。

2、MQ 的优点

  • 异步处理 – 相比于传统的串行、并行方式，提高了系统的吞吐量
  • 应用解耦 – 各个系统之间通过消息通信，不用关心其他系统的处理，甚至不关心他们处理的结果为失败还是成功
  • 流量削峰 – 可以通过消息队列长度控制请求量；可以缓解短时间内的大量请求
  • 日志处理 – 解决大量日志传输问题 （也可以使用 ELK 解决日志问题）
  • 消息通讯 – 消息队列一般都内置了高效的通信机制，因此可以当做一个简单的消息通讯工具

3、MQ 的缺点

  • 降低系统的可用性 – 每个服务之间虽然解耦，但是还是都通过消息队列进行通信，一旦消息队列挂掉，那整个系统就会崩溃
  • 提高系统的复杂度 – 每个服务现在不仅要关注自己的逻辑处理程序，还需要关系消息队列的一系列问题，比如消息丢失，消息被重复消费，消息一致性等问题
  • 整个系统的一致性问题 – 各个服务通过消息队列进行消息传递，但是一旦某个服务依赖于下一个服务的数据，本服务数据已经更改，但是下个服务崩溃或者数据修改未成功，那就会造成系统数据不一致的问题

4、技术选型问题

image-20210903155605079

ActiveMQ 作为比较早的消息中间件，在国内应用比较广泛，基础功能也很强大。但是没有办法支撑互联网的高并发、高负载以及高吞吐量的复杂场景，并且在国内的互联网公司落地的比较少，应用的基本都是一些传统企业。

RabbitMQ 使用更加广泛，并且就可以支撑高并发、高负载、高吞吐量的复杂应用场景，更为关键的是有着友好的、方便快捷的后台管理界面，极大的减少了运维的工作。另外还支持集群化、高可用部署架构，消息高可靠支持，功能很完善。另外，在国内的互联网公司使用的也比较多，各种可复制操作的例子很多。还有就是 RabbitMQ 的社区很活跃，虽然他的语言是 erlang，并不适合研究源码，但是架不住社区很活跃，绝大部分的问题都能在社区进行解决。

RocketMQ 阿里系出品，适合基础架构研发实力比较强的公司，社区不是很活跃，但是使用了Java 语言进行开发，里边用到的很多设计模式和思路值得学习。

综上所述，中小型公司更加适合使用RabbitMQ，社区活跃，可用度高。大型公司RabbitMQ 和 RocketMQ 都可以使用。