异步消息中间件比较：ActiveMQ、RocketMQ、RabbitMQ、KafkaMQ、Redis

1. 消息中间件的作用

       为了应对流量大爆炸的时代带来的服务器压力，我们引入消息队列来对一些允许延迟执行的任务进行异步化，满足这种需求的软件被称为消息中间件。消息中间件在系统中起到了削峰增流的作用，让我们的系统更容易应对高并发的场景。

2. 消息中间件 vs RPC

       消息中间件可以理解为异步通讯框架，理所当然的，RPC也就可以用同步框架来解释了。两者的相同点是都是建立在不同服务之间的接口调用，异同点是消息中间件允许任务异步执行，而RPC要求尽快得到响应。

3. 常见的几种消息中间件：ActiveMQ、RocketMQ、RabbitMQ、KafkaMQ、Redis

（1）ActiveMQ

    Apache维护的老牌MQ，基于JMS标准。最大的优点就是实现了JMS规范，所以很容易与其他同样实现了JMS的消息中间件进行对接。缺点也是实现了JMS规范，其实很多东西是日常开发中几乎不会用到的，所以对于系统应用来说过于臃肿了。

    在追求稳定的企业级应用场景中，ActiveMQ是最佳的选择。

（2）Redis（发布订阅模式）

    Redis并不算是严格意义上的消息中间件，因为它压根没遵循消息队列的规范。但是耐不住Redis在缓存方面的能力啊，Redis在互联网应用中已经成为了刚需，而它对于简单场景中的消息队列的支持也让它脱颖而出，在消息中间件中占据了一席之地。而且，因为基于内存，所以快，这也是它的一大亮点吧。

    对于异步任务没有很严格的要求的情况下（比如任务的顺序到达，事故恢复），Redis会是不错的选择。

（3）Kafka（发布订阅模式）

    互联网公司对于Kafka有着谜一样的热爱，几乎是面试必问的。想想它的几个特点就明白了：完全分布式、高吞吐、零拷贝技术、快速持久化和消息有序到达，几乎每一项都命中了架构师内心深处的需要。

    在大多数场景中，Kafka都是很不错的选择。缺点也很明显，因为基于轮询的方式遍历每一个消息队列，所以当消息队列数量上去以后，响应时间就会越来越长，这也限制了它在超高并发下的能力。所以更适用于用户请求没那么恐怖的中小型企业。

     另外，kafka并没有遵循jms规范。

（4）RocketMQ

     阿里参考kafka设计的一款消息中间件，做了一些改进，性能上是很优秀的。在阿里内部被广泛应用在订单，交易，充值，流计算，消息推送，日志流式处理，binglog分发等场景。

    但是呢，既然基于kafka，就没办法避免它的缺点了。当消息队列数量达到某一值时，还是会有响应时间越来越长的问题。

（5）RabbitMQ

     RabbitMQ基于AMQP，是用Erlang语言编写的，需要在Erlang环境下使用。因为Erlang语言本身的特性，消息队列性能较好，支持高并发。

     RabbitMQ支持的功能是极多的，但也带来了不好维护的问题，学习成本较高。