MQ消息队列的作用及可能使用之后可能产生的问题

**

MQ的使用场景优点及其弊端

**

业务场景说明

MQ 是message queue ,消息队列，也叫消息中间件，遵守JMS（java message service）规范的一种软件。现如今已经MQ在大量的互联网网站（淘宝，京东，微博等等）已经广泛应用。

若不使用消息队列的情况在中大型互联网企业里，用户的请求直接写入数据当中，在高并发的情况下会对数据库产生巨大的压力，甚至可能会导致服务器宕机o(╥﹏╥)o。

在使用了MQ之后，用户的请求发给MQ后立即返回可以返回提示信息,（例如: 当我们在淘宝上买个东西下完订单之后，淘宝就会提示你订单已经提交完成），再由消费者去MQ中消费数据，异步写入数据库。

1. 消息队列的说明

消息队列中间件是分布式系统中重要的组件，主要解决应用耦合，异步消息，流量削锋等问题。

实现高性能，高可用，可伸缩和最终一致性架构。是大型分布式系统不可缺少的中间件。

目前在生产环境，主流的的消息队列有ActiveMQ，RabbitMQ，Kafka，RocketMQ等。

2.消息队列的主要作用

消息队列实际应用中的主要应用场景：应用解耦，异步，削峰。

2.1解耦

传统模式下带来的麻烦：

假设现在有A、B、C、D三个系统，A系统负责了一个重要数据的输出的A需要调用B、C系统的接口给它们发送数据这个时候公司有新业务需要重新开了一个D系统也需要A系统的数据，过了一段时间产品该需求了，B系统不需要A系统的数据了，在这个过程当中A系统的程序员需要不断的修改更新他的代码，给他带来了无限的麻烦，并且在系统开发的时候开发A系统的哥们还需要考虑，如果C系统挂了怎么办？如果A系统访问超时了又该怎么办？A系统是不是需要加一个重试的机制，这一列的问题，导致了A程序走上了自闭的道路。如下图：

如何解决上述问题？引入消息队列之后的方案

1.生产者：将所产生的数据，发送到MQ里面去，生产者的开发者无需考虑数据要发送给谁，不需要多次维护代码。
2.消费者：自己去MQ里面消费自己所需的数据，如果某个消费者不需要消费了则取消对MQ的消费即可
总结：通过一个MQ，发布和订阅消息的这么一个模型（pub/sub模型）系统A就和其他系统解耦了

2.2异步

场景说明：
假设一个用户向用户中心发送一个注册请求，需要调用三个接口分别做邮箱验证，短信验证，信息写入这三个接口。三个系统接口处理时长分别要 400ms、400ms、200ms。最终请求总延时是接近 1s，这对用户来说是非常慢的，不能给用户带来良好的用户体验，这就会让用户对你的产品产生质疑

那么使用了MQ以后又该如何呢？
如果使用 MQ，那么 A 系统连续发送 3 条消息到 MQ 队列中，假如耗时 5ms，接口从接受一个请求到返回响应给用户的时间是极其短暂的，这对于用户而言，将会大大的减少了等待时间,极大的提高了用户体验

2.3 削峰

场景说明：
我们知道在不同的时间段对于一个网站来说明会有不同的请求量，例如某网站在深夜每秒并发的请求量只有100到200之间，而在每天中午13点到14点之间每秒并发请求量将会达到10000万到20000之间
这个时候要是系统是直接基于mysql（一般的 MySQL，扛到每秒 2k 个请求就差不多了）可想而知mysql服务器将会被这高并发的请求打宕机了，导致系统崩溃，用户无法再使用。

这个时候MQ削峰的这个主要作用就体现出来了
1.可以控制活动的人数
2.可以缓解短时间内高流量压垮应用
订单系统从 MQ 中慢慢拉取请求，每秒钟就限制拉取2k 个请求，不能超过超过所能承载的请求量，这样的话，即使是高峰期的时候，订单系统也绝对不会挂因数据库而挂掉。

在此期间积压的数据在高峰期过了之后再以虽然外界仍然有请求进入但是数据时少量的，但是订单系统还是回忆每秒2000的速度拉取MQ中的消息，因此很快就会将积压的数据给处理完毕。

消息队列的缺点

任何事务都具有双面性，当然消息队列也不例外
优点上面已经说了，就是在特殊场景下有其对应的好处，解耦、异步、削峰。
那么下面我们来谈谈消息队列的缺点

系统可用性低

系统引入越多的外部依赖就越容易挂。原先的A、B、C、D几个系统间，A系统调用四个系统并没有什么问题，即使B、C、D其中一个系统挂了那么A系统还是能提供部分服务。现在引入了MQ，它作为中间件，为B、C、D提供服务，那么如果它挂了怎么办，不就导致了整套系统都崩溃了，所以这里就出现了一个新的问题，那就是如何保证消息队列的高可用（这里就先不做解释了(#^.#)）

系统设计的复杂度增加
加了个MQ，我们在系统中需要考虑的东西就变得越来越多了。例如：我们该如何保证不会有重复消费的情况，碰到数据丢失的问题该如何处理，如何保证数据处理的顺序性这都是我们所该考虑的问题。这些都是需要我们考虑的，否则在使用软件或者网站的过程中，可想而知会出现许多令人不愉快的事情发生，大大降低了用户的体验感。

数据的一致性问题
我们知道MQ有一个极大的优点就是实现了异步，那么假如这个时候我们购买一件物品，为了提高用户的体验感，可以在订单系统处理完之后就直接给用户返回购买成功的信息，而这个时候可能其他几个系统也需要进行写库操作，这时其中有个系统写库失败了，这就造成了数据不一致性。那怎么办这时候该呢？

总结

所以说任何事务都是具有两面性，MQ既然给我们带来这么大的好处，那么相对而来带来的坏处也是不可避免的，但是针对如今这种大数据，大流量的环境下，MQ的存在是必不可少的，这时就需要我们制定一定的方案来解决这些MQ所存在的题。。。。。。（好了，电脑快没电了，就不哔哔了，欲知后事如何请听下回分解）

这篇文章是笔者学习的总结，学习之处https://github.com/doocs/advanced-java