系统中引入消息队列的优缺点

我们经常说自己项目里用了redis、mq，但是我们并不完全了解这个东西。其实说白了，就是为了用而用，或者是别人设计的架构，然后直接让我们使用，但是我们自己并没想过为什么要用这个东西。

或者假如你设计系统，然后你想引入消息队列，你有没有想过引入消息队列之后会不会有什么坏处？你要是没考虑过这个，那你盲目弄个MQ进系统里，后面出了问题，那就尴尬了。

刚好我最近刚好学习了点这方面知识，所以我这里结合项目中的业务场景来简单谈谈引入消息队列的优缺点，如果有不对的地方请指正。

引入消息队列的优点

先说一下消息队列的常见使用场景吧，其实场景有很多，但是结合我们自己项目来说，或者大多数项目使用消息队列的也就是：解耦、异步、削峰。

解耦

先来说说为什么需要解耦吧，先假设一个场景：A系统发送个数据到BCD三个系统，需要调用BCD的接口发送，目前一片祥和，忽然这个时候，E系统也要这个数据了，那么这个时候A系统需要改代码，调用E系统的接口，还行，能接受；突然，C系统说现在不需要数据了？现在A系统又只有苦逼的改代码，A系统负责人濒临崩溃中。。。再来点更加崩溃的事儿，A系统要时时刻刻考虑BCDE四个系统如果挂了咋办？我要不要重发？我要不要把消息存起来？头发都白了啊。。。以上就是系统严重耦合的情况。

但是如果我们这个时候引入了消息队列，以上的问题就很简单的可以解决了，如下图所示：

经过上面的场景与图解的比较，大家是不是一下就感受到消息队列解耦的好处了。

小结：你需要去考虑一下你负责的系统中是否有类似的场景，就是一个系统或者一个模块，调用了多个系统或者模块，互相之间的调用很复杂，维护起来很麻烦。但是其实这个调用是不需要直接同步调用接口的，如果用MQ给他异步化解耦，也是可以的，你就需要去考虑在你的项目里，是不是可以运用这个MQ去进行系统的解耦。

异步

然后我们来说说异步的场景，假如A系统接收一个请求，需要在自己本地写库，还需要在BCD三个系统写库，自己本地写库要20ms，BCD三个系统分别写库要300ms、450ms、200ms。最终请求总延时是20+300 + 450 + 200 = 970ms，接近1s，用户感觉搞个什么东西，慢死了慢死了，如下图所示：

但是我们用消息队列的异步方式就不一样了，如下图所示:

小结：所以如果系统不是那种实时性很强的项目，并且某些操作会耗费大量的时间，这个时候我们就可以考虑使用MQ来异步解决我们的问题了，先把操作结果返回，剩下的操作发到消息队列里面慢慢去解决。

消峰

最后我们来说说消峰的业务场景，这也是我们目前的一个业务场景，我们在某某公司有个日志管理系统，接收所有主机的日志，大家都知道晚上6点到第二天早上8点几乎都没什么日志，也就几百条，系统很快就可以处理，但是这个早上8点半到下午6点，这个时间段内可能日志量就是几千，几万的来，这个时候如果系统没有什么缓冲，全靠系统处理，估计系统一下就挂掉了，所以我们就引入了消息队列来处理，模拟场景如下图所示：

引入消息队列的缺点

优点上面已经说了，就是在特殊场景下有其对应的好处：解耦、异步、削峰

缺点呢？显而易见的

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

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

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

所以消息队列实际是一种非常复杂的架构，你引入它有很多好处，但是也得针对它带来的坏处做各种额外的技术方案和架构来规避掉，最好之后，你会发现，妈呀，系统复杂度提升了一个数量级，也许是复杂了10倍。但是关键时刻，用，还是得用的，至于如何解决以上的缺点，那就是下一步需要讨论的问题了。