前言

    通过前面两篇文章的学习，我们学习了RocketMQ的搭建和以及如何使用，在本篇文章，我们将对一些概念进行了解并通过实例加深印象。

1、架构设计

    Apache RocketMQ是一个分布式消息传递和流媒体平台，具有低延迟，高性能和可靠性，万亿级容量和灵活的可伸缩性。 它由四个部分组成：NameServer，BrokerServer，生产者和消费者。 它们中的每一个都可以水平扩展，而没有单个故障点。

    我们先来看一下RocketMQ的架构图（盗来的），在第一节我们对一些基本概念做了简单描述，那么接下来，我们将围绕这张图进行稍微深入一点的讲解。

2、 NameServer

    做过分布式系统的读者一定都知道，为了保证高可用及其方便管理，注册中心一般都是必不可少的。而RocketMQ也针对系统特性而专门开发了一款类似Zookeeper的注册中心。

    NameServer负责保存每个Broker上的信息，每个Broker与NameServer集群中的所有节点建立长连接，定时注册Topic和Queue等信息到所有NameServer。

    但是与Zookeeper极为不同的是，NameServer集群之间没有信息交换，也就是说，每个NameServer都作为一个完整的信息存储中心，即使10个节点挂了9个，剩下的1个依然能提供正常服务。

3、 BrokerServer

    既然NameServer不干活，那么很明显，BrokerServer就是真正负责存储消息、中转消息的劳动力了。

    BrokerServer在RocketMQ系统中负责接收从生产者发送来的消息并存储、同时为消费者的拉取请求作准备。代理服务器也存储消息相关的元数据，包括消费者组、消费进度偏移和主题和队列等

    单个Broker和所有NameServer保持长连接，每隔30秒向所有NameServer发送心跳。而NameServer每隔10秒，扫描所有还存活的Broker连接，若某个连接2分钟内没有发送心跳数据，则断开连接。

    对于BrokerServer，RocketMQ提供了Master/Slave的结构，Salve定时从Master同步数据，如果Master宕机，则Slave提供消费服务，但是不能写入消息，此过程对应用透明，由RocketMQ内部解决。

    因此一旦Master宕机，默认情况下最多需要30秒客户端才能感知到。

    集群模式下的主从架构以及消费者组我们后面说，那么这个消费进度偏移，主题和队列又是什么呢？

3.1 消费进度偏移

    从字面意思上我们就能大概理解，既然RocketMQ是生产者消费者模型中的种阻塞队列角色，那么消费者当前消费进度对于原点总得有一个记录，就相当于游标的概念。

    而消费者在每个队列中的消费进度则是存储在consumerOffset.json文件中

3.2 主题（Topic）

    从图中可以看到，一个BrokerServer可以有多个Topic，无论是生产者还是消费者，每次消息都是在某个Topic上活跃。每个主题包含若干条消息，每条消息只能属于一个主题，是RocketMQ进行消息订阅的基本单位

    通俗点来说就是，你订阅了某个公众号，那么你就可以收到这个公众号给你推送的消息。这里公众号就等价于主题。

3.3 队列

    每个Topic下默认会创建4个消息队列用于存放消息索引。注意，这里队列里存放的是消息索引而不是真实的消息。生产者生产的消息是完整的存放在commit log文件中

    从这里我们可以反推出上一节的问题：为什么RocketMQ默认不允许自动创建Topic

    因为对于BrokerServer而言，每个Topic都会造成一定开销，一旦Topic超过一定数量，BrokerServer可能会不堪重负而导致崩溃。

    因此Topic一般不允许自动创建，而是交给专门的运维人员来管理和分配。

3.4 标签（Tag）

    这里在多说一个概念：标签。

    消息设置的标志，用于同一主题下区分不同类型的消息。来自同一业务单元的消息，可以根据不同业务目的在同一主题下设置不同标签。

    标签能够有效地保持代码的清晰度和连贯性，并优化RocketMQ提供的查询系统。消费者可以根据Tag实现对不同子主题的不同消 费逻辑，实现更好的扩展性。

    比如对于订单这个主题，我们可以分为线上支付和线下支付这两个标签，不同的消费者通过标签消费自己需要的消息

4、 生产者（Producer）

    负责生产消息，一般由业务系统负责生产消息（比如订单、支付服务）。一个消息生产者会把业务应用系统里产生的消息发送到BrokerServer。RocketMQ提供多种发送方式，同步发送、异步发送、顺序发送、单向发送。同步和异步方式均需要Broker返回确认信息，单向发送不需要。

    关于这些发送方式在下一章将结合案例进行逐个讲解

4.1 生产者组（Producer Group）

    同一类Producer的集合（即生产者集群概念），这类Producer发送同一类消息且发送逻辑一致。如果发送的 是事物消息且原始生产者在发送之后崩溃，则Broker服务器会联系同一生产者组的其他生产者实例以提交或回溯消费

    在上一节的实例中我们也可以看到，构造器要求我们提供生产者组参数

5、消费者（Consumer）

    负责消费消息，一般是后台系统负责异步消费（线程池大放异彩）。一个消息消费者会从BrokerServer服务器拉取消息，并将其提供给应用程序。从用户应用的角度而言提供了两种消费形式：拉取式消费 (pull consumer)、推动式消费(push consumer)。

5.1 消费者组（Consumer Group）

    同一类Consumer的集合，这类Consumer通常消费同一类消息且消费逻辑一致。消费者组使得在消息消费方面，实现负载均衡和容错的目标变得非常容易。

    在上一章的实例中，我们只需要启动多个consumer就已经完成了消费者的集群。

    要注意的是，消费者组的消费者实例必须订阅完全相同的Topic。RocketMQ 支持两种消息模式：集群消费 （Clustering）和广播消费（Broadcasting）。

结尾

    本章简单的为大家介绍了一些基本概念，下一章，我将针对生产者和消费者不同的模式结合实际场景通过案例进行分析。