RocketMQ消息队列（上）

什么是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作为数据分发，减少数据的修改，提高开发的效率。