（五）基于RocketMQ--Demo项目的测试和原理说明

简介：

文章一、二、三为RocketMQ的初步了解、搭建环境工作，文章四基于myeclipse搭建Demo测试项目

本文的内容基于之前的Demo项目和环境进行测试工作，探究说明RocketMQ的工作原理

术语解释

Name Server：

• 无状态节点，可集群部署，节点之间无任何信息同步（Broker与每个namesrv连接，可以保证信息同步性）
• NameServer用来保存活跃的 broker 列表，包括 Master 和 Slave。
• NameServer用来保存所有 topic 和该 topic 所有队列的列表。
• Namesrv只是Broker的服务注册与发现，具体的消息收发，都依靠Broker。

Broker

• 消息中转角色，负责存储消息，转发消息。
• 拥有Master、slave（主备）的概念，主备有同步双写、异步复制功能来保持数据同步。标识：Master的BrokerId 为 0 ，Slave的BrokerId 非0。
• Broker 与 Name Server 集群中的所有节点建立长连接，定时（心跳）注册 Topic 信息到所有 Name Server。

Producer

• 消息发送者，消息通过topic来标示

Producer Group

• 一类 Producer 的集合名称，这类 Producer 通常发送一类消息，且发送逻辑一致。

Consumer

• 有两种实现方式，一种push Consumer，第二种是 pull Consumer。

Consumer Group

• 一类 Consumer 的集合名称，这类 Consumer 通常消费一类消息，且消费逻辑一致。
• 两种模式：广播消费和集群消费

广播消费（Broadcasting）

• 一条消息被多个 Consumer 消费，即使这些 Consumer 属于同一个 Consumer Group，消息也会被 Consumer Group 中的每个 Consumer 都消费一次，广播消费中的 Consumer Group 概念可以认为在消息划分方面无意 义。broadcasting

集群消费（Clustering）

• 一个 Consumer Group 中的 Consumer 实例平均分摊消费消息。例如某个 Topic 有 9 条消息，其中一个 Consumer Group 有 3 个实例（可能是 3 个进程，或者 3 台机器），那么每个实例只消费其中的 3 条消息。

Topic

• 消息的逻辑管理单位。

Queue(Message Queue/Topic Queue)

• 消息的物理管理单位。一个Topic下可以有多个Queue，Queue的引入使得消息存储可以分布式集群化，具有了水平扩展的能力

• Queue可以理解为Topic的实际存储单元，服务器创建Topic时会指定ReadQueueNum和WriteQueueNum。即某Producer发送了40条关于TopicA的消息，如果TopicA下有4个queue，则每个queue均分存储10条消息

• 在 RocketMQ 中，Queue都是持久化，长度近乎无限的数据结构，访问其中的存储单元使用 Offset 来访问，offset 为 java long 类型64 位，另外队列中只保存最近几天（默认三天）的数据，之前的数据会按照过期时间来 删除。 也可以认为 Message Queue 是一个长度无限的数组，offset 就是下标

• 详细可以参看RocketMQ数据存储结构，如Commit log、offset等概念

  ​

工作原理的问题及测试

Q1：producer发送消息时，如果有