MQ - RocketMQ底层原理和源码解析

RocketMQ底层原理和源码解析

本文的内容主要包括：MQ的对比和选型、RocketMQ原理、RocketMQ源码解析、事务消息。

Rocketmq性能压测客户端：https://github.com/Force-King/rocketmq-test

一、MQ的对比和选型

目前业界主要的消息中间件有：ActiveMQ、RabbitMQ、ZeroMQ、Kafka、MetaMQ、RocketMQ。其中开源的，社区比较活跃的是ActiveMQ、RabbitMQ、Kafka、RocketMQ。所以，我们做技术选型时，需要考虑从以上4种开源的MQ中选取。以下是这4种mq的特性:

RabbitMQ、Kafka、RocketMQ性能测试对比：

在同步发送场景中，三个消息中间件的表现区分明显：

Kafka的吞吐量高达17.3w/s，不愧是高吞吐量消息中间件的行业老大。这主要取决于它的队列模式保证了写磁盘的过程是线性IO。此时broker磁盘IO已达瓶颈。

RocketMQ也表现不俗，吞吐量在11.6w/s，磁盘IO %util已接近100%。RocketMQ的消息写入内存后即返回ack，由单独的线程专门做刷盘的操作，所有的消息均是顺序写文件。

RabbitMQ的吞吐量5.95w/s，CPU资源消耗较高。它支持AMQP协议，实现非常重量级，为了保证消息的可靠性在吞吐量上做了取舍。RabbitMQ在消息持久化场景下，吞吐量在2.6w/s左右。

Redis（补充）

是一个Key-Value的NoSQL数据库，开发维护很活跃，同时它也支持MQ功能，所以完全可以当做一个轻量级的队列服务来使用。对于RabbitMQ和Redis的入队和出队操作，各执行100万次，每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。实验表明：入队时，当数据比较小时Redis的性能要高于RabbitMQ，而如果数据大小超过了10K，Redis则慢的无法忍受；出队时，无论数据大小，Redis都表现出非常好的性能，而RabbitMQ的出队性能则远低于Redis。

综合以上对比，可以得出，RocketMQ 和 Kafka 的吞吐量最高，在高吞吐量的业务要求下，首选这两个mq。

Kafka 在topic 达到一定量以上时，吞吐量急剧下降；而RocketMQ影响较小。如下图：

从以上几个图可以看出，随着业务增多，topic 增多，Kafka的稳定性比RocketMQ要差不少。

所以综合来看，作为互联网行业，肯定会涉及资金转账等要求事务一致的场景， Kafka 不支持分布式事务，RocketMQ 支持分布式事务，而且理论上不会丢消息，整体对比来看，还是RocketMQ更加优越。而且RocketMQ是经历了多次双十一考验的，可用性是毋庸置疑的！

二、RocketMQ原理

1. RocketMQ的发展历史

    在2007年的时候，淘宝实施了“五彩石”项目，“五彩石”用于将交易系统从单机变成分布式，也是在这个过程中产生了阿里巴巴第一代消息引擎——Notify。在2010年的时候，阿里巴巴B2B部门基于ActiveMQ的5.1版本也开发了自己的一款消息引擎，称为Napoli，这款消息引擎在B2B里面广泛地被使用，不仅仅是在交易领域，在很多的后台异步解耦等方面也得到了广泛的应用。在2011年的时候，业界出现了现在被很多大数据领域所推崇的Kafka消息引擎，阿里在研究了Kafka的整体机制和架构设计之后，基于Kafka的设计使用Java进行了完全重写并推出了MetaQ 1.0版本，主要是用于解决顺序消息和海量堆积的问题。而在2012年，阿里对于MetaQ进行了架构重组升级，开发出了MetaQ 2.0，这时就发现MetaQ原本基于Kafka的架构在阿里巴巴如此庞大的体系下很难进行水平扩展，所以在2012年的时候就开发了RocketMQ 3.0版本。很多人会问到RocketMQ 3.0和MetaQ 3.0的区别，其实这两者是等价的版本，只不过阿里内部使用的称为MetaQ 3.0，外部开源称之为RocketMQ 3.0。在2015年，又基于RocketMQ开发了阿里云上的Aliware MQ和Notify 3.0。在2016年的时候，阿里巴巴将RocketMQ的内核引擎捐赠给了Apache基金会。

    以上就是RocketMQ的整体发展历史，其实在阿里巴巴内部围绕着RocketMQ内核打造了三款产品，分别是MetaQ、Not