什么是RocketMQ
RocketMQ作为一款纯java、分布式、队列模型的开源消息中间件，支持事务消息、顺序消息、批量消息、定时消息、消息回溯等。主要功能是异步解耦和流量削峰。
常见的MQ主要有：ActiveMQ、RabbitMQ、Kafka、RocketMQ
四种MQ的对比
| 特性 | ActiveMQ | RabbitMQ | RocketMQ | Kafka |
|---|---|---|---|---|
| 单机吞吐量 | 万级，比RocketMQ和Kafka第一个级别 | 同ActiveMQ | 10万级，支撑高吞吐 | 10万级，高吞吐，一般配合大数据类的系统进行实时数据计算、日志采集等场景 |
| topic数量对吞吐量的影响 | topic可以达到几百/几千级别，吞吐量会有较小幅度的下降，这是RocketMQ的一大优势，在同等机器下，可以支撑大量的topic | topic从几十到几百时，吞吐量会大幅度下降，在同等机器下，kafka尽量保证topic数量不要过多，如果要支撑大规模的topic，需要增加更多的机器资源 | ||
| 时效性 | ms级 | 微秒级别，RabbitMQ的特性，延迟最低 | ms级别 | 延迟在ms级别以内 |
| 可用性 | 高，基于主从架构实现高可用 | 同ActiveMQ | 非常高，分布式架构 | 非常高，分布式一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用 |
| 消息可靠性 | 有较低的概率丢失数据 | 基本不丢 | 经过参数优化配置，可以做到0丢失 | 经过参数优化配置，可以做到0丢失 |
| 功能支持 | MQ领域的功能机器完备 | 基于erlang开发，并发能力很强，性能极好，延时很低 | MQ功能较为完善，基本分布式，扩展性好 | 功能较简单，主要支持简单的MQ功能，在大数据领域的实时计算以及日志采集被大规模使用 |
| 其他 | Apache开发，起步早，没有经过高吞吐场景验证，社区不活跃 | 开源、稳定、社区活跃度高 | 阿里开源，交给Apache，社区活跃度低 | Apache开发，开源、高吞吐量、社区活跃度高 |
消息中间件的使用场景
异步与解耦：
当我们下了一个订单之后，订单系统会进行RPC同步调用 支付系统、库存系统、物流系统等，那么系统之间就会有耦合性，耦合性越高的话，容错性就越低，比如我们的支付系统如果宕机了，就会导致我们整个交易的异常，从而影响用户的体验。
如果我们中间加入了消息中间件，不管是支付还是库存等系统，都是通过异步的方式进行调用的，如果其中一个系统宕机了，不会影响我们用户下单的使用。
本质上MQ第一步完成了 异步 ，第二步完成了 解耦 。那么系统的容错性就越高。
流量削峰：
流量削峰也可以叫削峰填谷，比如一些互联网公司大促场景，双十一、店庆或者秒杀活动，都会使用到消息中间件。
如果在不使用消息中间件或者没有流量削峰，每秒是很高的并发，这个时候如果我们的A系统，如果要将数据写入到我们的MYSQL中，受限于MYSQL本身服务的上限，最大我们只能每秒处理200请求，这个时候会有大量的消息进行堆积，从而导致A系统的奔溃。
这个时候我们可以将用户的请求消息通过MQ进行写入，因为消息中间件本身是对数据量处理比较高的一个系统，所以对于每秒2000请求，消息中间件可以处理，然后A系统作为消息中间件的一个消费者，以固定的速度从MQ中拉取200个消息，完成我们的业务操作，用时间换空间 从而确保我们A系统的稳定性。
数据分发：
如果S系统，在对系统进行开发的时候，需要对接多个(A、B、C、D)系统，使用传统的接口调用，中间有改动就需要修改我们的代码，当新增了A系统，我们需要去修改代码去调用A系统来完成对应的业务逻辑，如果我们当中的D系统需要移除， 同样也需要修改代码删除对应的接口调用。
如果S系统使用了消息中间件，我们S系统只要将消息交给MQ，剩下的不论是新增还是移除，还是原有的，他们都只是消息中间件的一个消费者，这个时候我们就便于数据的分发。
比如我们新增一个系统，我们只需要新增一个MQ的消费者，直接从MQ里面拿消息就可以，当我们需要移除一个系统的时候，只需要取消对MQ消息的监听即可。对于我们原有的S系统不需要进行额外的修改。如果使用MQ作为数据分发，减少数据的修改，提高开发的效率。