RocketMQ集群管理-一一网

在分布式服务SOA架构中，任何中间件或者应用都不允许单点存在，服务发现机制是必备的。服务实例有多个，且数量是动态变化的。注册中心会提供服务管理能力，服务调用方在注册中心获取服务提供者的信息，从而进行远程调用。

下面介绍RocketMQ的架构设计、集群管理，涉及RocketMQ中一些重要的概念。

整体架构设计

说到RocketMQ的架构设计，不得不说一下它与kafka的渊源。Kafka是一款高性能的消息中间件，在大数据场景中经常使用，但由于kafka不支持失败重试、定时消息、事务消息，顺序消息也有明显缺陷，难以支撑淘宝交易、订单、充值等复杂业务场景。淘宝中间件团队参考Kafka重新设计并用java编写了RocketMQ，因此在RocketMQ中会有一些概念和Kafka相似。

常见的消息中间件Kafka、RabbitMQ、RocketMQ等都基于发布/订阅机制，消息发送者(Producer)把消息发送到消息服务器，消息消费者(Consummer)从消息服务器订阅感兴趣的消息。这个过程中消息发送者和消息消费者是客户端，消息服务器是服务器，客户端与服务器双方都需要通过注册中心感知对方的存在。

RocketMQ部署架构主要分为四个部分，如图所示：

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

NameServer是一个非常简单的Topic路由注册中心，其角色类似于Dubbo中依赖的Zookeeper，支持Broker的动态注册与发现。主要包括如下两个功能。

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

基本概念

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