有一个订单系统，最多能处理一万次订单，这个处理能力应付正常时段的下单是没问题的，正常时段我们下单一秒后就能返回结果
但是在高峰期，如果有两万次下单操作，系统是处理不了的。那么以前的解决方法只能限制订单超过一万后，不允许用户下单
如果我们使用消息队列做为缓冲，那么就可以取消这个限制。把一秒内发送过来的订单分散成一段段的时间来处理。这时有些用户可能在下单十几秒后才能收到下单成功的操作，但是比不能下单的体验要好
现在的电商应用中，存在很多的系统，比如：有订单系统、库存系统、物流系统、支付系统。用户创建订单后，则会相应的去调用库存系统、物流系统、支付系统等其他相关的系统。那么如果任何一个子系统出了故障，都会造成下单操作异常，这就是应用的耦合问题
但是如果使用基于消息队列的方式，系统间调用的问题会减少很多。比如物流系统因为发生故障，需要时间来修复。那么在这段修复的时间里，物流系统要处理的数据就会被缓存在消息队列中，用户的下单操作也可以正常完成。当物流系统恢复后，继续处理订单信息即可，其中用户并不会感受不到物流系统发生了故障，提升系统的可用性和用户操作的体验性
有些服务间调用是异步的，例如 A 调用 B，B 需要花费很长时间执行，但是 A 需要知道 B 什么时候可以执行完
以前处理这种情况有两种办法：A 过一段时间去调用 B 的查询 api 查询；或者 A 提供一个 回调(callback) api，B 执行完之后调用 api 通知 A 服务
这两种方式其实都不好，首先是第一种方式，A 服务要循环多次的去调用 B 服务的查询 api ，一次就能得到回复还好，但是要是 B 服务要处理很久，那么 A 服务一边完成自己的工作，还要一边去看看 B 服务是否处理完成。第二种方式的话，A 服务要专门提供一个回调 api，然后 B 服务还要去调用。总体来说的话，两种方式都会极大的浪费资源和时间
使用消息总线，就可以很方便解决这个问题， A 调用 B 服务后，只需要监听 B 处理完成的消息，当 B 处理完成后，会发送一条消息给 MQ，MQ 会将此消息转发给 A 服务。这样 A 服务既不用循环调用 B 的查询 api，也不用提供 回调(callback) api。同样 B 服务也不用做回调操作，A 服务还能及时的得到异步处理成功的消息
是 Apache 软件基金会的一个开源项目，是一个基于消息的通信中间件
优点：
缺点：进入 5.X 版本后，官方社区对其维护变少，其相关的社区也并不活跃，所以在高吞吐量场景下，比较少使用它
由 Apache 开发的一个开源流处理平台，由 Scala 和 Java 编写，是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者在网站中的所有动作流数据
适合产生大量数据的互联网服务的数据收集业务
优点：
缺点：
详解：https://blog.csdn.net/wanzijy/article/details/127717026
阿里巴巴的开源产品，用 Java 语言实现
适合可靠性要求很高的场景，尤其是电商里面的订单扣款，以及业务削峰，在大量交易涌入时，后端可能无法及时处理的情况。该中间件在阿里双 11 已经经历了多次考验
优点：
缺点：支持的客户端语言不多，目前是 Java 和 C++
由 Rabbit 科技有限公司开发，是一个在 AMQP(高级消息队列协议) 基础上完成的，可复用的企业消息系统
适合数据量没有那么大，中小型公司优先选择
优点：
缺点：实现机制比较重。使用 Erlang 语言进行开发，较难定制和读懂源码