目前常用的消息中间件有RabbitMQ、RocketMQ、Kafka等，本篇博客不涉及任何任何消息中间件，只是简单的介绍消息中间件一些概念和解决方案。消息中间件的本质是两个进程之间的通讯，像HTTP、RPC、Webservice都可以进行进程间通讯，那么我们为什么还需要消息中间件这个组件呢？
我们考虑一个场景，假如有一个交易系统，交易成功之后需要发送短信通知，如果交易耗时100毫秒，发送短信需要200毫秒，如果使用HTTP则整个交易流程需要300毫秒，而对于短信的实时性并不是那么强，这个时候我们可以将短信放到消息队列，然后在发送。这就是消息中间件的一个典型的场景。相对于HTTP和RPC的实时性通讯，消息通讯降低了系统之间的耦合度，可以提高系统之间的处理能力。
下面我们会介绍消息中间件的几种常用的场景，包括订阅发布、削峰填谷、异步解耦、顺序收发，日志收集等。
削峰填谷：诸如秒杀、红包等大型活动皆会带来比较高的流量高峰，很可能会导致系统超负荷甚至崩溃、或者因限制请求数而导致请求大量失败影响用户体验，消息中间件可以实现削峰填谷的服务来解决这些问题。
异步解耦：一般交易系统作为核心系统，每笔交易订单数据会引起几十上百个下游业务的关注，比如积分、计算分析等、消息中间件可以实现异步解耦，确保核心业务的连续
顺序收发：顺序消息的使用非常多，比如订单创建、支付、退款等都必须按照顺序处理，很多消息中渐渐都能够保证消息的顺序性，即符合FIFO原理。
分布式一致性：分布式、微服务都要保证事务的一致性。消息中间件的使用可以使得应用之间既能解耦又能保证事务的一致性。
消息中间件的使用还有很多，不同的消息中间件都有不同的特性，但总的来说最基本得到组件包括生产者、消息和消费者。生产者用于生产消息，会将消息发送到消息中间件服务器，消费者会主动拉取需要消息或者消息中间件推送消费者订阅的消息给消费者。如下为消息中间件的消息传递流程：
这里我们不具体的介绍生产者。消费者和消息，因为不同的消息中间件会有不同的实现。后续我们会详细介绍RocketMQ、RabbitMQ和Kafka的使用。如下为常用的中间件的对比：
