消息中间件-有什么优缺点？

首先，我们先来确认下业界使用MQ的三大场景。

1 消息中间件的优点：

1.1 场景一：

A 系统发送数据到 BCD 三个系统，通过接口调用发送。如果 E 系统也要这个数据呢？那如果 C 系统现在不需要了呢？A 系统负责人几乎崩溃…

在这个场景中，A系统和各个系统之间有复杂的耦合关系；
如果使用MQ,A系统生产一条数据，发送到MQ中，那个系统需要数据，自己就去MQ中消费。
如果有新的系统需要数据，直接从MQ中消费即可；
如果某个系统不需要这条数据，我们就取消对MQ的消费；
A系统就不需要关心数据要发给谁，不需要维护这个代码，也不要考虑人家是否调用成功、失败超时等情况。

总结：在这个场景中，我们通过发布订阅消息，A系统就和其他系统之间，完成了解耦。

1.2 场景二：

A系统 ,每天22个小时，每秒并发量在30个数据左右。只有在晚上8点-10点昨天，并发量在5k+左右。但是系统是基于MySQL数据库的，大量的数据请求涌入mysql，会导致mysql数据库崩溃。（一般mysql数据库也就是每秒2000个请求）

如果使用MQ，每秒5k请求写入MQ,A系统每秒中处理2k个请求。因为MYSQL的数据请求瓶颈的问题，所以A系统每秒从MQ中拉去2k个请求来处理。哪怕是业务高峰的时候来临，A系统也不会挂掉。因为它每秒就处理2k+请求。

这个短暂的高峰期积压是 ok 的，因为高峰期过了之后，每秒钟就 50 个请求进 MQ，但是 A 系统依然会按照每秒 2k 个请求的速度在处理。所以说，只要高峰期一过，A 系统就会快速将积压的消息给解决
总结：这样的场景适用于解决系统的消峰的问题。比如大量的用户注册发送短信验证等；

1.3 场景三：

如果场景三描述的是A系统受到一个请求，需要写本地库，花费3ms，而其中还需要调用B系统，花费300ms，c系统 450ms，d系统 200ms。这样这个一个业务就要花费3+300+450+200=953ms。正常的用户请求正常控制在200ms内完成。等待1s 用户体验很差。

如果使用MQ，那么A系统从接受这个请求到返回响应给用户。总时长8ms。对于用户来说，这样的用户体验很好。

总结：在这个场景中。我们看到了mq的异步处理的作用。

2 消息中间件也有缺点：

2.1. 系统可用性降低

系统引入的外部依赖越多，越容易挂掉。本来你就是 A 系统调用 BCD 三个系统的接口就好了，人 ABCD 四个系统好好的，没啥问题，你偏加个 MQ 进来，万一 MQ 挂了咋整，MQ 一挂，整套系统崩溃的，你不就完了？

2.2.系统复杂度提高

硬生生加个 MQ 进来，你怎么保证消息没有重复消费？怎么处理消息丢失的情况？怎么保证消息传递的顺序性？头大头大，问题一大堆，痛苦不已。

2.3.一致性问题

A 系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是 BCD 三个系统那里，BD 两个系统写库成功了，结果 C 系统写库失败了，咋整？你这数据就不一致了。

所以消息队列实际是一种非常复杂的架构，你引入它有很多好处，但是也得针对它带来的坏处做各种额外的技术方案和架构来规避掉，做好之后，你会发现，妈呀，系统复杂度提升了一个数量级，也许是复杂了 10 倍。但是关键时刻，用，还是得用的。

3 消息中间件的对比

4 建议

中小型公司，技术实力较为一般，技术挑战不是特别高，用 RabbitMQ 是不错的选择；大型公司，基础架构研发实力较强，用 RocketMQ 是很好的选择。

大数据领域的实时计算、日志采集等场景，用 Kafka 是业内标准的，绝对没问题，社区活跃度很高，绝对不会黄，何况几乎是全世界这个领域的事实性规范