持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第1天，点击查看活动详情
什么是MQ？为什么要用MQ？
MQ：MessageQueue，消息队列。 队列，是一种FIFO 先进先出的数据结构。消息由生产者发送到MQ进行排队，然后按原来的顺序交由消息的消费者进行处理。QQ和微信就是典型的MQ。
MQ的作用
主要有以下三个方面：
- 异步
例子：快递员发快递，直接到客户家效率会很低。引入菜鸟驿站后，快递员只需要把快递放到菜鸟驿站，就可以继续发其他快递去了。客户再按自己的时间安排去菜鸟驿站取快递。 作用：异步能提高系统的响应速度、吞吐量。
- 解耦
例子：《Thinking in JAVA》很经典，但是都是英文，我们看不懂，所以需要编辑社，将文章翻译成其他语言，这样就可以完成英语与其他语言的交流。 作用：
- 服务之间进行解耦，才可以减少服务之间的影响。提高系统整体的稳定性以及可扩展性。
- 另外，解耦后可以实现数据分发。生产者发送一个消息后，可以由一个或者多个消费者进行消费，并且消费者的增加或者减少对生产者没有影响。
- 削峰
例子：长江每年都会涨水，但是下游出水口的速度是基本稳定的，所以会涨水。引入三峡大坝后，可以把水储存起来，下游慢慢排水。
作用：以稳定的系统资源应对突发的流量冲击。
MQ的优缺点
上面MQ的所用也就是使用MQ的优点。 但是引入MQ也是有他的缺点的
- 系统可用性降低
系统引入的外部依赖增多，系统的稳定性就会变差。一旦MQ宕机，对业务会产生影响。这就需要考虑如何保证MQ的高可用。
- 系统复杂度提高
引入MQ后系统的复杂度会大大提高。以前服务之间可以进行同步的服务调用，引入MQ后，会变为异步调用，数据的链路就会变得更复杂。并且还会带来其他一些问题。比如：如何保证消费不会丢失？不会被重复调用？怎么保证消息的顺序性等问题。
- 消息一致性问题
A系统处理完业务，通过MQ发送消息给B、C系统进行后续的业务处理。如果B系统处理成功，C系统处理失败怎么办？这就需要考虑如何保证消息数据处理的一致性。
几大MQ产品对比
| 产品 | RabbitMq | RocketMq | Kafka | Pulsar |
|---|---|---|---|---|
| 成熟度 | 成熟 | 比较成熟 | 成熟的日志领域 | 一般 |
| 社区活跃度 | 高 | 中 | 高 | 中 |
| 关注度 | 高 | 中（国内使用较多） | 高 | 高 |
| 消息可靠性 | 较好 | 很高 | 很高 | 很高 |
| 文档 | 多 | 中 | 多 | 低 |
| 单机吞吐量 | 万 | 10万+ | 20w+ | 100万+ |
topic数量对吞吐量的影响 | topic可以达到几百，几千个的级别，吞吐量会有较小幅度的下降这是RocketMQ的一大优势，在同等机器下，可以支撑大量的topic | topic从几十个到几百个的时候，吞吐量会大幅度下降所以在同等机器下，kafka尽量保证topic数量不要过多。如果要支撑大规模topic，需要增加更多的机器资源 | 可无缝扩展到超过一百万个 topic,不会出现因topic增加出现的性能问题 | |
| 可用性 | 高（主从架构） | 高（主从架构） | 非常高（分布式） | 非常高（分布式） |
| 持久化 | 内存、文件 | 磁盘 | 磁盘 | 磁盘 |
| 事务 | 支持 | 支持 | 支持 | 支持 |
| 集群 | 支持 | 支持 | 支持 | 支持 |
| 优缺点 | erlang语言发开，性能一般，出现比较早，有一定的用户基数性能有瓶颈，消息堆积处理不好，二次开发较难 | 各个环节分布式扩展设计，主从HA,多种消费模式，性能很好支持语言不多，国内主流，国际不是很流行，没有在 mq 核心中去实现 JMS 等接口 | 高吞吐量、持久化数据存储、分布式系统易于扩展，性能极好延迟比较高，topic过多，性能影响较大 | 灵活、多租户、云原生架构、跨地域复制，性能超极好处于成长期，流行度和成熟度较低 |
