MQ的应用场景

异步处理：当注册成功后，进行短信和邮箱通知。可以并行执行邮件发送和端性发送业务。
应用解耦：下单后就通知库存系统应该进行扣库存操作。相对于传统的串行处理如果当前库存系统异常也不会影响订单系统。
流量削锋：先将秒杀系统的请求先写入消息队列。client请求另为的查询接口判断是否下单成功（1.下单成功2.正在下单中）。秒杀业务消费消息队列的秒杀请求。
消息通讯：发布订阅，下游系统一直监听MQ，下游系统一直监听MQ的数据。如果MQ有数据，下游系统则会按照先进先出这样的规则，逐条进行消费.(Redis的发布-订阅一样可以实现)

主流MQ的工作模式简介

ActiveMQ

Apache ActiveMQ是[Apache软件基金会]所研发的开放源代码消息中间件；由于ActiveMQ是一个纯Java程序，因此只需要操作系统支持Java虚拟机，ActiveMQ便可执行。

kafka

kafka是Linkdin开源的分布式发布-订阅系统,目前属于Apache的顶级项目.Kafka主要的特点是基于Pull模式来处理消息消费,追求高吞吐量,一开始的目的就是用于日志收集和传输.0.8版本开始支持复制,不支持事务,对消息的重复,丢失,错误没有严格要求,适合产生大量数据的互联网服务的数据收集业务.Kafka关注于性能，对于消息的有效性不是特别高

kafka工作原理图

Kafka集群模式

RocketMQ

RocketMQ是阿里开源的消息中间件,目前也已经孵化为Apache顶级项目,它是纯Java开发,具有高吞吐量,高可用,审核大规模分布式系统应用.RocketMQ思路起源于Kafka,它对消息的可靠传输及事务性做了优化,RocketMQ保证了消息的顺序性.

RocketMQ集群拓扑

其实Name server的前身就是Zookeeper

RabbitMQ

RabbitMQ是使用ErIang语言开发的开源消息队列系统，基于AMQP协议来实现·AMQP的主要特征是面向消息、队列、路由（包括点对点和发布/订阅）、可靠性、安全。AMQP协议更多用在企业系统内，对数据一致性、稳定性和可靠性要求很高的场景，对性能和吞吐量的要求还在具次。

RabbitMQ工作原理

RabbitMQ集群

总结

特性	ActiveMQ	RabbitMQ	RocketMQ	Kafka
单机吞吐量	万级，吞吐量比RocketMQ和Kafka要低了一个数量级	万级，吞吐量比RocketMQ和Kafka要低了一个数量级	10万级，RocketMQ也是可以支撑高吞吐的一种MQ	10万级别，这是kafka最大的优点，就是吞吐量高。一般配合大数据类的系统来进行实时数据计算、日志采集等场景
topic数量对吞吐量的影响			topic可以达到几百，几千个的级别，吞吐量会有较小幅度的下降,这是RocketMQ的一大优势，在同等机器下，可以支撑大量的topic	topic从几十个到几百个的时候，吞吐量会大幅度下降所以在同等机器下，kafka尽量保证topic数量不要过多。如果要支撑大规模topic，需要增加更多的机器资源
时效性	ms级	微秒级，这是rabbitmq的一大特点，延迟是最低的	ms级	延迟在ms级以内
可用性	高，基于主从架构实现高可用性	高，基于主从架构实现高可用性	非常高，分布式架构	非常高，kafka是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用
消息可靠性	有较低的概率丢失数据		经过参数优化配置，可以做到0丢失	经过参数优化配置，消息可以做到0丢失
功能支持	MQ领域的功能极其完备	基于erlang开发，所以并发能力很强，性能极其好，延时很低	MQ功能较为完善，还是分布式的，扩展性好	功能较为简单，主要支持简单的MQ功能，在大数据领域的实时计算以及日志采集被大规模使用，是事实上的标准
优劣势总结	非常成熟，功能强大，在业内大量的公司以及项目中都有应用,偶尔会有较低概率丢失消息而且现在维护和说那个也比较少，主要是基于解耦和异步来用的，较少在大规模吞吐的场景中使用	erlang语言开发，性能极其好，延时很低；吞吐量到万级，MQ功能比较完备,而且开源提供的管理界面,社区也很活跃,RabbitMQ确实吞吐量会低一些,而且rabbitmq集群动态扩展会很麻烦，其实主要是erlang语言本身带来的问题。很难读源码，很难定制和掌控。	接口简单易用，日处理消息上百亿之多，可以做到大规模吞吐，性能也非常好，分布式扩展也很方便，社区维护还可以，可靠性和可用性都是ok的，还可以支撑大规模的topic数量，支持复杂MQ业务场景,接口这块不是按照标准JMS规范走的有些系统要迁移需要修改大量代码	kafka的特点其实很明显，就是仅仅提供较少的核心功能，但是提供超高的吞吐量，ms级的延迟，极高的可用性以及可靠性，而且分布式可以任意扩展,同时kafka最好是支撑较少的topic数量即可，保证其超高吞吐量而且kafka唯一的一点劣势是有可能消息重复消费，那么对数据准确性会造成极其轻微的影响，在大数据领域中以及日志采集中，这点轻微影响可以忽略,这个特性天然适合大数据实时计算以及日志收集