RocketMQ 入门术语

• RocketMQ 网络部署结构

 　　　　　　　　　　　　

• • Name Server

　　　　　　Name Server 是一个注册中心，整个分布式消息调度的总控制，给消息队列的生产者和消费者提供路由信息，提供轻量级的服务发现，路由，元数据信息，能够多个部署，相互独立（比zookeeper轻量）;

　　　　　　Name Server 被设计成几乎无状态的，能够横向扩展，节点之间无任何信息同步；

　　　　　　每一个 Broker 与 Name Server 集群中的全部节点创建长链接，定时注册 Topic 在启动的时候会到NameServer注册；

　　　　　　Producer 与 Name Server 集群中的其中一个节点（随机选择）创建长链接，按期从 Name Server 取 Topic 路由信息，并向提供 Topic 服务的 Master 创建长链接，且定时向 Master 发送心跳；

　　　　　   Consumer 与 Name Server 集群中的其中一个节点（随机选择）创建长链接，按期从 Name Server 取 Topic 路由信息，并向提供 Topic 服务的 Master、 Slave 创建长链接，且定时向 Master、 Slave 发送心跳；

 

• RocketMQ 逻辑部署结构

　　　　　　　　　　

• Producer 与 Producer Group　　

　　　　　　Producer 表示消息队列的生产者；

　　　　　　Producer Group 表示发送同类消息的多个 Producer 实例（一般为发送一类消息，且发送逻辑一致），一个 Producer Group 下包含多个 Producer 实例，能够是多台机器，也能够是一台机器的多个进程，或者一个进程的多个 Producer 对象； 一个 Producer Group 能够发送多个 Topic 消息；

　　　　　　Producer  Group  做用以下：

　　　　　　1. 标识一类 Producer

　　　　　　2. 能够经过运维工具查询这个发送消息应用下有多个 Producer 实例

　　　　　　3. 发送分布式事务消息时，若是 Producer 中途意外宕机，Broker 会主动回调 Producer Group 内的任意一台机器来确认事务状态

 

• • Consumer 与 Consumer Group

 　　　　　　Consumer 表示消息队列的消费者，Consumer 被分为两类：Push Consumer 和 Pull Consumer

• • • Push Consumer，Consumer 的一种，应用向 Consumer 对象注册一个 Listener 接口，一旦收到消息，Consumer对象马上回调 Listener 接口方法；
    • Pull Consumer，Consumer 的一种，应用一般主动调用 Consumer 的拉消息方法从 Broker 拉消息，主动权由应用控制；

　　　　　　Consumer Group 表示消费同类消息的多个实例（一般消费一类消息，且消费逻辑一致），一个 Consumer Group 下包含多个 Consumer 实例，能够是多台机器，也能够是多个进程，或者是一个进程的多个 Consumer 对象，涉及的消费方式：广播消费（BROADCASTING）和 集群消费（默认 CLUSTERING）

• • • 广播消费：一条消息被多个 Consumer 消费，即便这些 Consumer 属于同一个 Consumer Group，消息也会被 Consumer Group 中的每一个 Consumer 都消费一次
    • 集群消费：一个 Consumer Group 中的 Consumer 实例平均分摊消费消息，也就是说排除网络等其余缘由，一条消息只会被消费一次；大多数场景应该使用的是此种消费方式

 

• • Broker

　　　　　　Broker即为消息队列核心；它负责存储消息、接收生产者产生的消息，为消费者转发消息。同时它还会存储与消息相关的元数据，包括消费者组，消费进度偏移和主题/队列信息；

 

• • Topic

　　　　　　主题，表示消息的第一级类型，标识一类消息的逻辑名字，好比一个电商系统能够分为：交易消息、物流消息等；Queue 是消息的物理管理单位，而 Topic 是消息的逻辑管理单位；一条消息必须有一个Topic；RocketMQ最佳实践给出的建议是，一个应用尽量用一个Topic；一个 Topic 下能够有多个 Queue，默认自动建立4个，手动建立8个；不管消息是生产仍是消费，都须要指定 Topic；

• • • Producer Group 和 Topic 消息之间的关系是多对多的关系　　　　　　　

 　　　　　　　　　一个 Producer Group 下的实例（Producer）能够发送多个 Topic 的消息

  　　　　　　　　  一个 Topic 的消息也能够由多个 Producer Group 下的实例（Producer）生产

• • •  Broker Group 和 Topic 消息之间的关系是多对多的关系

　　　　　　　　　一个 Broker Group 能够为多个 Topic 提供服务

    　　　　　　　　一个 Topic 能够由一个或多个 Broker Group 提供服务

    　　　　　　　　一个 Topic 由多个 Broker Group 提供服务即《RocketMQ用户指南》中提到的多 Master，或多 Master 多 Slave 模式

    　　　　　　　　一个 Topic 由一个 Broker Group 提供服务即《RocketMQ用户指南》中提到的单 Master 模式（包含 Slave 或不包含 Slave）

• • •  Consumer Group 和 Topic 消息之间的关系是多对多的关系

 　　　　　　　　  一个  Consumer Group 下的实例 （Consumer）能够消费多个 Topic 的消息

  　　　　　　　　 一个 Topic 的消息也能够由多个 Consumer Group 下的实例（Consumer）消费

 

　　　　　　　Producer Group，Broker Group，Consumer Group，Topic 之间的关系

　　　　　　　　　　

 

　　　　　　　　

• • Tag　

　　　　　　标签，表示消息的第二级（子主题）类型，对 Topic 的进一步细化，用于区分同一主题下不一样的业务消息，好比交易消息又能够分为：交易建立消息、交易完成消息等，一条消息能够没有Tag；

 

• • Message Queue

　　　　　　消息队列，简称 Queue 或 Q；消息物理管理单位；一个Topic下能够设置多个 Queue；当发送消息时，须要执行该消息的 Topic，RocketMQ会轮询该 Topic下的全部队列，将消息发出去；一个 Topic 将有若干个 Q ；若 Topic 同时建立在不一样的 Broker，则不一样的 Broker上都有若干 Q，消息将物理地址存储落在不一样 Broker 结点上，具备水平扩展的能力；

　　　　　　不管生产者仍是消费者，实际的生产和消费都是针对 Q 级别；例如 Producer 发送消息的时候，会预先选择（默认轮询）好该 Topic 下面的某一条 Q 发送；Consumer 消费的时候也会负载均衡地分配若干个 Q，只拉取对应 Q 的消息；

　　　　　　每一条 Message Queue 均对应一个文件，这个文件存储了实际消息的索引信息；即便文件被删除，也能经过实际纯粹的消息文件（commit log）恢复回来；

 

　　　　　　Broker，Topic，Queue 关系以下图：

　　　　　　　　　　　　

• • 广播消费

　　　　　　消费者的一种消费模式。消息将对一个 Consumer Group 下的各个Consumer实例都投递一遍。即即便这些 Consumer 属于同一个 Consumer Group，消息也会被 Consumer Group 中的每一个Consumer 都消费一次；

　　　　　　实际上，是一个消费组下的每一个消费者实例都获取到了 Topic 下面的每一个 Message Queue 去拉取消费，消息会投递到每一个消费者实例；

　　　　　　这种模式下，消费进度会存储持久化到实例本地；

　　

• • 顺序消费

　　　　　　消费消息的顺序要同发送消息的顺序一致；因为 Consumer 消费消息的时候是针对 Message Queue 顺序拉取并开始消费，且一条 Message Queue 只会给一个消费者（集群模式下），因此可以保证同一个消费者实例对于 Q 上消息的消费是顺序地开始消费（不必定顺序消费完成，由于消费可能并行）；

　　　　　　在RocketMQ中，顺序消费主要指的是都是Queue级别的局部顺序。这一类消息为知足顺序性，必须Producer单线程顺序发送，且发送到同一个队列，这样Consumer就能够按照Producer发送的顺序去消费消息；

　　　　　　生产者发送的时候能够用 MessageQueueSelector 为某一批消息（一般是有相同的惟一标示id）选择同一个 Queue，则这一批消息的消费将是顺序消息（并由同一个 Consumer 完成消息）。或者Message Queue 的数量只有1，但这样消费的实例只能有一个，多出来的实例都会空跑。

 

• • 普通顺序消费

　　　　　　顺序消息的一种，正常状况下能够保证彻底的顺序消息，可是一旦发生异常，Broker宕机或重启，因为队列总数发生发化，消费者会触发负载均衡，而默认地负载均衡算法采起哈希取模平均，这样负载均衡分配到定位的队列会发化，使得队列可能分配到别的实例上，则会短暂地出现消息顺序不一致；

　　　　　　若是业务能容忍在集群异常状况（如某个 Broker 宕机或者重启）下，消息短暂的乱序，使用普通顺序方式比较合适；

 

• • 严格顺序消费

　　　　　　顺序消息的一种，不管正常异常状况都能保证顺序，可是牺牲了分布式 Failover 特性，即 Broker集群中只要有一台机器不可用，则整个集群都不可用，服务可用性大大下降；

　　　　　　若是服务器部署为同步双写模式，此缺陷可经过备机自动切换为主避免，不过仍然会存在几分钟的服务不可用；（依赖同步双写，主备自动切换，自动切换功能目前并未实现）

　　　　　　 　　　　　　

 

 参考以下：

http://jm.taobao.org/2017/01/12/rocketmq-quick-start-in-10-minutes/

https://zhuanlan.zhihu.com/rocketmq

https://www.jianshu.com/p/453c6e7ff81c

《RocketMQ用户指南》