消息队列使用场景及优缺点

在分布式系统中&＃xff0c;经常使用到的一个中间件就是消息队列&＃xff0c;所以为什么要使用消息队列&＃xff0c;消息队列使用有哪些优缺点&＃xff1f;

1.为什么要使用消息队列&＃xff1f;

事实上&＃xff0c;回答这个问题也就是在考虑消息队列的使用场景&＃xff0c;使用消息队列能解决些什么问题&＃xff1a;

1.1.解耦

有这么一个场景&＃xff0c;在微服务系统中&＃xff0c;当A系统产生新数据后需要将数据发送给BCD系统。如果此时E系统也需要&＃xff0c;那么A系统需要适配&＃xff1b;如果B系统不再需要了&＃xff0c;那么A系统也必须要适配&＃xff1b;如果有些系统挂了&＃xff0c;A系统需不需要重发等。所以A系统与下游系统耦合性很高。如果在它们之间引入MQ(消息队列)&＃xff0c;会带来哪些优化。

引入MQ之后&＃xff0c;A系统产生新数据之后&＃xff0c;直接发送到MQ中&＃xff0c;哪些系统需要数据&＃xff0c;自己去MQ中消费&＃xff0c;如果不需要了&＃xff0c;可以取消对MQ的消费操作&＃xff0c;这样&＃xff0c;A系统不需要再去考虑给谁发送数据问题&＃xff0c;依赖MQ的特性&＃xff0c;也不需要关注下游服务是否消费成功&＃xff0c;重发数据等问题。

**总结&＃xff1a;**通过中间层引入MQ&＃xff0c;发布订阅模式&＃xff0c;将A系统与下游服务进行业务解耦。

1.2.异步

再看另一个场景&＃xff0c;

下图&＃xff08;左&＃xff09;&＃xff0c;当浏览器发送一个请求到A系统时&＃xff0c;这个请求业务的完成需要依赖于BCD系统&＃xff0c;比如A系统为订单模块&＃xff0c;订单生成之后需要完成B系统的积分等流程&＃xff0c;比如A系统业务完成需要3ms&＃xff0c;BCD业务完成个需要300ms&＃xff0c;所以整个流程需要3&＃43;450&＃43;500&＃43;450&＃61;1403ms&＃xff0c;这对于一般互联网来说&＃xff0c;时长有点不太友好&＃xff0c;基本要求在一个请求完成在200ms内

下图&＃xff08;右&＃xff09;&＃xff0c;引入MQ之后&＃xff0c;A系统不在需要等待BCD的同步操作&＃xff0c;而是将预期操作同步下发到三个队列中&＃xff0c;然后直接返回给浏览器成功&＃xff0c;加入这过程耗时5ms&＃xff0c;那么总时长为3&＃43;5&＃61;8ms&＃xff0c;非常快&＃xff0c;网站做的非常nice&＃xff01;

**总结&＃xff1a;**通过引入MQ实现预期的异步操作&＃xff0c;但是会面临最终一致性问题

1.3.削峰

下图&＃xff08;左&＃xff09;&＃xff0c;假如A系统每天到 12:00 ~ 13:00 &＃xff0c;每秒并发请求数量突然会暴增到 5k&＃43; 条。系统基于 MySQL 做数据处理&＃xff0c;每秒并发大概2k&＃xff0c;大量的请求涌入 MySQL&＃xff0c;可能就直接把 MySQL 给打死了&＃xff0c;导致系统崩溃&＃xff0c;但是高峰期一过&＃xff0c;其他时间可能也就 1w 的用户同时在网站上操作&＃xff0c;每秒中的请求数量可能也就 50 个请求&＃xff0c;对整个系统几乎没有任何的压力。

下图&＃xff08;右&＃xff09;&＃xff0c;引入MQ之后&＃xff0c;每秒 5k 个请求写入 MQ&＃xff0c;A 系统每秒钟最多处理 2k 个请求&＃xff0c;不要超过自己每秒能处理的最大请求数量即可&＃xff0c;A 系统从 MQ 中慢慢拉取请求&＃xff0c;这样哪怕是高峰期的时候&＃xff0c;A 系统也绝对不会挂掉。但是MQ 每秒钟 5k 个请求进来&＃xff0c;就 2k 个请求出去&＃xff0c;会导致在高峰期&＃xff08;1 个小时&＃xff09;&＃xff0c;可能有几十万甚至几百万的请求积压在 MQ 中。这个短暂的高峰期积压是 ok 的&＃xff0c;因为高峰期过了之后&＃xff0c;每秒钟就 50 个请求进 MQ&＃xff0c;但是 A 系统依然会按照每秒 2k 个请求的速度在处理。所以说&＃xff0c;只要高峰期一过&＃xff0c;A 系统就会快速将积压的消息给解决掉。

**总结&＃xff1a;**通过引入MQ存储短时间大量的涌入的数据&＃xff0c;给后端系统带来缓冲时间&＃xff0c;但是会导致请求积压。

2.优缺点

2.1.优点

上面基本描述了MQ的优点&＃xff0c;在一定的场景下实现解耦、异步、削峰等问题。

2.2.缺点

• 系统可用性降低

  系统引入的外部依赖越多&＃xff0c;越容易挂掉。本来你就是 A 系统调用 BCD 三个系统的接口就好了&＃xff0c;ABCD 四个系统还好好的&＃xff0c;没啥问题&＃xff0c;你偏加个 MQ 进来&＃xff0c;万一 MQ 挂了咋整&＃xff1f;MQ 一挂&＃xff0c;整套系统崩溃&＃xff0c;你不就完了&＃xff1f;如何保证消息队列的高可用&＃xff1f;

• 系统复杂度提高

  不管是开发还是运维&＃xff0c;加入MQ之后&＃xff0c;系统的复杂度变高了&＃xff0c;维护成本变高&＃xff0c;而且会面临怎么保证消息没有重复消费&＃xff1f;怎么处理消息丢失的情况&＃xff1f;怎么保证消息传递的顺序性&＃xff1f;等

• 一致性问题

  异步中场景&＃xff0c;A系统下发到MQ之后就直接返回浏览器成功&＃xff0c;人都以为你这个请求就成功了&＃xff1b;但是问题是&＃xff0c;要是 BCD 三个系统那里&＃xff0c;BD 两个系统写库成功了&＃xff0c;结果 C 系统写库失败了&＃xff0c;就会造成不一致性问题。

个系统写库成功了&＃xff0c;结果 C 系统写库失败了&＃xff0c;就会造成不一致性问题。