闲情居|「mq」消息队列 - 作用与优缺点详细讲解( 二 ) 消息队列的作用消息队列在大流量的环境

此时，系统的写业务会大量的请求打到MySql中， MySql每秒处理2K+左右请求时，负载已经相当大。如果突然2W+的请求都打到MySQL中，可能会直接将MySql打死，导致业务系统崩溃。
如果使用MQ进行削峰，将数据发送到MQ系统中，通过慢慢消费MQ中的数据，写入到MySQL中。在这种模式下，保证了系统A的稳定性，保证系统的健壮。而MQ每秒中写入2W数据，而每秒只消费2K数据，会导致有大量的请求数据积压在MQ中。
所以，当请求真的巨大，分库（分实例）是需要的。
但是，这个积压是短暂的。因为高峰期过后，每秒钟的请求量较小， MQ消费端会快速的消费掉积压的数据。
总结削峰处理，可以给系统带来更高的吞吐量和更稳定的支撑。
虽然在高峰期，确实会给用户来带来一定的数据延迟。但是这个延迟正常也是在300ms-1s以内。这在如支付账单等场景中完全是可以接受的。
消息队列的优缺点消息队列的优点，就是上述中的在特殊场景下的对应好处。
解耦：降低系统耦合性，给维护、开发带来更好的便利和更好的可扩展性。
异步：降低系统之间调用的耗时，给用户带来更好的感官体验。
削峰：提升系统的吞吐量，同时提升了系统的健壮性、稳定性。
缺点有以下几个：

降低了系统的可用性

系统引入的外部依赖越多，会带来更高的维护成本与意外。如果MQ突然挂掉，整个系统就都会崩溃。所以，如果引入MQ ，则需要保证MQ系统的高可用。

提升了系统的复杂度

引入MQ系统， MQ消费的重复消费问题、消息丢失问题、消息积压无法消耗问题、消息传递的顺序性问题等等，会带来相对应的处理成本。

一致性问题

在上述的例子中，系统A处理完之后直接将消息发送给MQ之后就响应成功了。
但是，如果系统B因为业务问题，迟迟无法消费成功。则此时，多个系统之间数据是不一致的。
所以，消息队列实际上是一种非常复杂的架构体系，引入它会得到很多好处，但是同时也带来了各种问题，需要额外的针对这些问题使用技术方案或者架构来进行规避。它会导致系统的复杂度提长一个量级。
但是，需要用的时候，还是得用！！消息队列带的好处远远大于带来的问题！！
PS：当然，如果系统流量较低、业务不复杂，不是很急需引入消息队列来进行解耦、异步和削峰的情况下，还是不建议增加系统的复杂度了。
一切的架构都是基于业务的。脱离业务来谈架构的行为，都是耍流氓！！