MQ主要使用场景及优缺点

早上来突然看到一篇博文，感觉写得不错，在这里记录一下。

MQ主要使用场景：

系统解耦、异步调用、流量削锋。

1.系统解耦

举个例子：存在5个系统，其中2，3，4号系统需要调用1号系统的接口数据。突然4号系统不需要1号系统的数据了，1号系统则需要修改、删除关于4号系统的代码；同一时间，5号系统发起请求需要1号系统的数据，这时1号系统就容易崩了。如下图：

可以看到，上面例子中1号系统和其他系统之间存在很强的耦合性。这时可以考虑使用MQ，将1号系统的数据放入MQ中。其他系统想请求数据时，直接去MQ中消费。如果不想请求了，就取消对MQ的消费即可。这样1号系统就不用考虑其他系统的响应，也减少代码维护的次数和其他系统是否调用成功。如下图：

2.异步调用

举个例子：存在1，2，3，4号系统。1号系统收到请求，需要自己本地写库和向2，3，4号系统写库。假设1号系统本地写库需要5ms，向其他系统写库都需要400ms。所以从请求到响应一共需要1205ms，对于一般企业请求响应时间得控制在100ms-200ms之间，显然1205ms这是不能接受的。如下图：

使用MQ之后，用户发送请求到1号系统需要5ms，1号系统发送3条消息到MQ需要耗时5ms，用户从发送到响应耗时10ms。

3.流量削峰

举个例子：假设存在一TB电商系统，平时在线人数几万。双11零点抢购，每秒并发千万，TB系统数据库每秒能处理2W条请求。但在双11时，很容易造成系统崩溃。引入MQ后，每秒千万请求写入MQ，tb系统每秒能处理2w请求。此时，每当tb系统处理完2w请求之后，再去MQ里拉取2w请求处理，每次不超过自己的最大请求量。这样处理之后，系统处理速度虽然跟不上用户请求速度，但所有请求都存储在MQ里，不会导致系统崩溃。随着高峰期过后，系统依然会很快处理掉MQ里的请求。如下图：

缺点：

1.系统可用性降低：系统引入外部依赖越多，系统面临风险就越高。比如，对于第一个例子如果MQ挂掉，系统也会崩溃；
2.系统复杂度提高：需要考虑有没有重复消费，消息丢失，消息传递顺序等等；
3.一致性问题：对于场景2，1号系统处理完后成功，但对于2，3，4号系统，如果其中一个写库失败，就会导致数据不一致。

常用MQ的优缺点：

所以中小型公司，技术实力较为一般，技术挑战不是特别高，用RabbitMQ是不错的选择；大型公司，基础架构研发实力较强，用RocketMQ是很好的选择。如果是大数据领域的实时计算、日志采集等场景，用Kafka是业内标准的，绝对没问题，社区活跃度很高，绝对不会黄
以上内容很多都是借鉴“程序员老鬼”文章：“面试官必问的 3 道 MQ 面试题，还有谁不会？？”，给出他的微信，大家有需求可以去看原文