一文讲透Apache RocketMQ技术精华

最新推荐文章于 2024-07-29 09:00:00 发布

架构师技术联盟

最新推荐文章于 2024-07-29 09:00:00 发布

阅读量1.7k

点赞数

640?wx_fmt=jpeg

640?wx_fmt=gif&wxfrom=5&wx_lazy=1

嘉宾介绍：刘振东

阿里巴巴中间件技术专家，2016年中间件性能挑战赛亚军，具有丰富的分布式系统设计和优化经验，目前负责Apache RocketMQ新航道探索和创新。

分享文章内容包括RocketMQ的起源、RocketMQ概念模型、存储模型、部署模型和最佳实践总结。

一、RocketMQ的起源

通常，每个产品的诞生都源于一个具体的需求或问题，RocketMQ也不例外。起初，产品的原型像一个巨石，把所有需要实现的程序和接口都罗列到一起。但随着公司业务的发展，所有的系统和功能都在这个巨石上开发，当覆盖几百上千名开发人员的时候，瓶颈就出来了。这时候，就需要我们把系统进行分解。

图释：巨石 -> 分布式

分解后，就出现了上图中的分布式架构，这类架构最大的特点就是解耦，而RocketMQ的异步解耦意味着底层的重构不会影响到上层应用的功能。RocketMQ另一个优势是削峰填谷，在面临流量的不确定性时，实现对流量的缓冲处理。此外，RocketMQ的顺序设计特性使得RocketMQ成为一个天然的排队引擎，例如，三个应用同时对一个后台引擎发起请求，排队引擎的特性可以确保不会引起“撞车”事故。

二、RocketMQ的概念模型

对于任何一款中间件产品而言，清晰的概念模型是帮助开发者正确理解使用它的关键。从RocketMQ的概念模型来看：Topic是用于存储逻辑的地址的，Producer是信息的发送，Consumer是信息的接收者。

图释：最基本的概念模型

这只是一个基础的概念模型，在实际的生产中，结构会更复杂，例如我们需要对中间的Topic进行分区，出现多个有关联的Topic，再如同一个信息的发送方会有多个订阅者，同一个需求方会有多个发送方，出现一对多、多对一的情况。

图释：扩展后的概念模型

上图就是对Topic、Producer、Consumer扩展后的概念模型。RocketMQ中可以接触到的所有概念都可以在这个概念模型图中找到。左边有两个Producer，中间就是两个分布式的Topic，用于存储逻辑地址的两个Topic中分别有两个用于存储物理存储地址的Message Queue，Broker是实际部署过程的对应的一台设备，右边则是两个Consumer，Consumer Group是代表两个Consumer可共享相互之间的订阅。不同的Consumer Group相互独立。一句话总结就是不同的Group是广播订阅的，同一个Group则是负载订阅的。图中的连线表示各模块之间的关系，例如Consumer Group A中的Consumer1对应着Message Queue0和Message Queue1的两个队列，分布在BrokerA这一台设备上。

三、RocketMQ的存储模型

RocketMQ的消息的存储是由ConsumeQueue和CommitLog 配合来完成的，ConsumeQueue中只存储很少的数据，消息主体都是通过CommitLog来进行读写。

图释：存储模型

CommitLog：是消息主体以及元数据的存储主体，对CommitLog建立一个ConsumeQueue，每个ConsumeQueue对应一个（概念模型中的）MessageQueue，所以只要有Commit Log在，Consume Queue即使数据丢失，仍然可以恢复出来。

Consume Queue：是一个消息的逻辑队列，存储了这个Queue在CommitLog中的起始offset，log大小和MessageTag的hashCode。每个Topic下的每个Queue都有一个对应的ConsumerQueue文件，例如Topic中有三个队列，每个队列中的消息索引都会有一个编号，编号从0开始，往上递增。并由此一个位点offset的概念，有了这个概念，就可以对Consumer端的消费情况进行队列定义。

四、RocketMQ的部署模型

在实际的部署过程中，Broker是实际存储消息的数据节点，Nameserver则是服务发现节点，Producer发送消息到某一个Topic，并给到某个Consumer用于消费的过程中，需要先请求Nameserver拿到这个Topic的路由信息，即Topic在哪些Broker上有，每个Broker上有哪些队列，拿到这些请求后再把消息发送到Broker中；相对的，Consumer在消费的时候，也会经历这个流程。