RocketMQ系列之架构设计原理讲解

前言

在市面上的任何一个消息队列中间件，架构的实现总少不了独有的并且共有的概念和专业名词，当然了RocketMQ也不例外，所以这篇文章就要好好的剖析一下

---

整体架构设计

说到RocketMQ的架构，其实它的实现多多少少因为Kafka，为什么呢，Kafka作为一款性能比较高的消息中间件，哪怕是经常出现在大数据场景下，但是他也是有一定缺陷的，比如不支持消费失败重试、定时消息、事务消息等等，淘宝团队在使用Kafka的时候呢，也发现了这些问题，顺势也就是参考了Kafka的设计，设计出了RocketMQ，还是用java写的，吸收了Kafka的优势，弥补了Kafka的缺点，所以两者之间有很多概念和机制是差不多的

常见的消息中间件有Kafka、RocketMQ、RabbitMQ等等，他们都是基于发布/订阅机制实现的，发送者Producer会把消息发送到消息服务器，消费者Consumer会从消息服务器订阅对应的消息，那这个过程的发送者和消费者都是客户端，存放消息和取出消息的消息服务器是服务端，而且客户端与服务端两者之间都需要通过注册中心感知对方的存在 

架构组成部分

• Producer：消息发布的角色，主要负责把消息发送到Broker，支持分布式集群
• Consumer：消息消费者的角色，主要负责从Broker订阅消息消费，支持分布式集群
• Broker：消息存储的角色，主要负责消息的存储、投递和查询，以及服务高可用保证、支持分布式集群
• NameServer：服务管理角色，主要负责管理Broker集群的路由信息，支持分布式集群 

看一下上面的架构图，其实能发现NameServer是一个非常简单的Topic路由注册中心，其角色类似于Dubbo中的zk，支持Broker的动态注册与发现，其主要有两个功能：

• 服务注册：NameServer接收Broker集群的注册信息，保存下来作为路由信息的基本数据，并提供心跳检测机制，检查Broker是否存活
• 路由信息管理：NameServer保存了Broker集群的路由信息，用于提供给客户端查询Broker的队列信息，Producer和Consumer通过NameServer可以知道Broker集群的路由信息，从而进行消息的投递和消费

基本概念

上面我们讲到了RocketMQ的架构组成部分，那现在就需要讲一下在这些组成部门中必不可少的一些概念，或者是设计元素/属性

• Message：消息体，系统传输信息的物理载体，生产和消费数据的最小单位，每条消息必须属于一个Topic，RocketMQ中每条数据拥有为的MessageID并且还具有业务标识的KEY
• Topic：主题，标识一类消息的集合，消费者读取消息的容器，每个主题都包含若干条消息，每条消息都只能属于一个主题，消息和主题是多对一的关系，Topic还是RocketMQ进行消息订阅的基本单位
• Queue：消息队列，组成Topic的最小单元，默认情况下一个Topic会对应多个Queue，Topic是逻辑概念，Queue是屋里存储，在Consumer消费Topic消息时底层实际则拉取Queue消息
• Tag：消息设置的标识，用于同一个主题Topic下区分不同类型的消息，来自同一业务单元的消息，可以根据不同业务目的在同一个主题下设置不同标签，标签能够有效的保持代码的可读性，并优化了RocketMQ提供的查询系统，消费者还可以根据Tag实现对不同子主题的不同消费的处理逻辑，实现更好的拓展性
• UserProperties：用户自定义的属性集合，属于Message的一部分
• ProducerGroup：同一类Producer的集合，这一类发送同一类消息且发送逻辑是一致的，如果发送的是事务消息且原始生产者在发送之后崩溃，则Broker服务器会联系统一生产者组的其他生产者实例以提交或回溯消费
• ConsumerGroup：同一类Consumer的集合，这一类通常消费同一类消息且消费逻辑一致，消费者组在消息消费方面，实现负责均衡和容错都变得非常容易，但是需要注意的是，消费者组的消费者实例必须订阅完全相同的Topic

以上概念都是官方解释，需要认真品味一下彼此之间的关系和在架构中的一个地位