RocketMQ消息模型跟其他的消息队列一样 都是 producer - > topic->consumer
producer 生产消息 也就是发送者
topic 消息主题 按topic发送消息 以后消息的存储 分片等都是基于topic做业务处理的
consumer 消息消费者 也是基于topic来进行消息的消费 支持推和拉模式(其实内部都是pull模式的变种)。
扩展集群消息模型
为了支持高并发、提高可扩展性、提高消息堆积能力。
一个topic可以有多个队列 而且还可以在不同的物理机器，这就为高吞吐、水平扩展支持打了基础。
在消费端consumer支持组(group)概念。一组consumer里面有多个消费者实例，一组consumer来消费某个topic 这样消费能力就得到了水平扩展
consumer组支持 集群消费模式 、 广播消费模式
- 集群消费下同组consumer实例会去拉取对应topic的不同队列上数据进行消费。‘
- 广播模式是每个消费者都会拉取对应topic中所有队列的消息来消费。
架构设计
RocketMQ 总体最组件分为 NameServer Broker Porducer Consumer
NameServer 名称服务
NameServer类似于Zookeeper这种角色 负责管理集群组件，简单来说NameServer可以查询到Broker有哪些、Topic在哪些Broker机器上 队列是如何分布的，它就像一颗大脑 管理者 收集者。相当于是一个topic路由管理中心，NameServer可以多实例分别独立部署、相互之间不产出数据交换，每个Broker在启动的时候会向所有的NameServer上报信息，所以他们之间可以相互独立，完全无状态。就算挂掉1个也不影响集群。
Broker 消息存储代理服务
Broker 才是真正托管消费存储、投递查询的服务，这个是非常核心的服务，大部分的性能优化都是针对这个服务进行。Broker分为 master slave 角色 在配置文件中brokerId=0表示Master 不为0表示slave。
broker启动后和NameServer建立了长连接 定期向NameServer上报Topic信息自身信息。
producer 生产者
生产/发送消息服务，一般是程序自己编写的业务发送消息端，启动后首先会和NameServer建立连接，定时从NameServer获取Topic路由信息，定时查询Broker服务信息 同时会和Broker master 角色建立长连接。producer 也是无状态的。
consumer 消费者
消费者服务 一般是由自己业务程序编写实现。启动后和NameServer建立连接 定时从NameServer获取topic信息和Broker信息，获取到Broker的信息后会和broker中的master salve角色也建立长连接 所有consumer中可以订阅master和slave。
只有非常懂IO的人 才能写得出来这么优秀的框架 里面有太多值的学习和借鉴的设计和思想 后面再慢慢精研。
【文章转自：韩国站群服务器 http://www.558idc.com/krzq.html 欢迎留下您的宝贵建议】