* 在互联网架构中，MQ是一种非常常见的上下游“逻辑解耦+物理解耦”的消息通信服务。

* QMQ是去哪儿网内部广泛使用的消息中间件，自2012年诞生以来在去哪儿网所有业务场景中广泛的应用，包括跟交易息息相关的订单场景； 也包括报价搜索等高吞吐量场景。目前在公司内部日常消息qps在60W左右，生产上承载将近4W+消息topic，消息的端到端延迟可以控制在10ms以内。

* Apache RocketMQ is a distributed messaging and streaming platform with low latency, high performance and reliability, trillion-level capacity and flexible scalability.

* ActivyMQ，RabbitMQ搭建集群需要自己配置HAV

* 解耦（解决不同重要程度、不同能力级别系统之间依赖导致一死全死）

复杂的应用里会存在多个子系统， 比如在电商应用中有订单系统、库存系统、物流系统 支付系统等，这个时候如果各个子系统之间的耦合性太高，整体系统的可用性就会大幅降低，多个低错误率的子系统糅合在一起，得到的是一个高错误率的整体系统。以电商应用为例，用户创建订单后，如果耦合调用库存系统、物流系统、支付系统，任何一个子系统出了故障或者因为升级等原因暂时不可用，都会造成下单操作异常，影响用户使用体验。当转变成基于消息队列的方式后，系统可用性就高多了，比如物流系统因为发生故障，需要几分钟的时间来修 ，在这几分钟的时间里，物流系统要处理的内容被缓存在消息队列里，用户的下单操作可以正常完成。当物流系统恢复后，补充处理存储在消息队列里的订单信息即可，终端用户感知不到物流系统发生过几分钟的故障。

* 削峰（主要解决瞬时写压力大于应用服务能力导致消息丢失、系统奔溃等问题）

每年的双十一，淘宝的很多活动都在0点的时候开启，大部分应用系统流量会在瞬间猛增，这个时候如果没有缓冲机制，不可能承受住短时大流量的冲击。通过利用消息队列，把大量的请求暂存起来，分散到相对长的一段时间内处理，能大大提高系统的稳定性和用户体验。举个例子，如果订单系统每秒最多能处理1万次下单，这个处理能力应对正常时段的下单是绰绰有余的，正常时段我们下单后一秒内就能返回结果。双十一零点的时候，如果没有消息队列这种缓冲机制，为了保证系统稳定，只能在订单超过一万次后就不允许用户下单了；如果有消息队列做缓冲，我们可以取消这个限制，把一秒内下的订单分散成一段时间来处理，这时有些用户可能在下单后十几秒才能收到下单成功的状态，但是也比不能下单的体验要好。使用消息队列进行流量消峰，很多时候不是因为能力不够，而是出于经济性的考量。比如有的业务系统，流量最高峰也不会超过一万QPS ，而平时只有一千左右的 QPS 这种情况下我们就可以用个普通性能的服务器（只支持一千左右的 QPS 就可以），然后加个消息队列作为高峰期的缓冲，无须花大笔资金部署能处理上万 QPS 的服务器。

* 异步（当存在一对多调用时，可以发一条消息给消息系统，让消息系统通知相关系统，应用间并发处理消息，相比串行处理，减少处理时间）

比如用户注册的消息，需要被数据部门处理，也要被业务部门处理，如果串行调用，会导致用户注册的流程耗时，这时候采用消息异步处理，用户完成基本的注册后只需要写入消息，各个子系统订阅消费此消息。

* 蓄流压测（线上有些链路不好压测，可以通过堆积一定量消息再放开来压测）