文章目录
- 一、消息模型(Message Model)
- 二、消息生产者(Producer)
- 三、消息消费者(Consumer)
- 四、主题(Topic)
- 五、代理服务器(Broker Server)
- 六、名字服务(Name Server)
- 七、拉取式消费(Pull Consumer)
- 八、推动式消费(Push Consumer)
- 九、生产者组(Producer Group)
- 十、消费者组(Consumer Group)
- 十一、集群消费(Clustering)
- 十二、广播消费(Broadcasting)
- 十三、普通顺序消息(Normal Ordered Message)
- 十四、严格顺序消息(Strictly Ordered Message)
- 十五、消息(Message)
- 十六、标签(Tag)
- 十七、 队列(Queue)
- 十八、分片(Sharding)
- 十八、消息标识(MessageId/Key)
一、消息模型(Message Model)
- RocketMQ主要由 Producer、Broker、Consumer 三部分组成
- Producer 负责生产消息
- Consumer 负责消费消息
- Broker 负责存储消息
- Broker 在实际部署过程中对应一台服务器,每个 Broker 可以存储多个Topic的消息,每个Topic的消息也可以分片存储于不同的 Broker
- Message Queue 用于存储消息的物理地址,每个Topic中的消息地址存储于多个 Message Queue 中
- ConsumerGroup 由多个Consumer 实例构成
二、消息生产者(Producer)
- 负责生产消息,一般由业务系统负责生产消息
- 一个消息生产者会把业务应用系统里产生的消息发送到broker服务器
- RocketMQ提供多种发送方式:同步发送、异步发送、顺序发送、延迟发送、单向发送
- 同步和异步方式均需要Broker返回确认信息,单向发送不需要
三、消息消费者(Consumer)
- 负责消费消息,一般是后台系统负责异步消费
- 一个消息消费者会从Broker服务器拉取消息、并将其提供给应用程序
- 从用户应用的角度而言提供了两种消费形式:拉取式消费、推送式消费
- RocketMQ中的消息消费者都是以消费者组(Consumer Group)的形式出现
- 消费者组只是对消费者的划分,方便消息的管理
- 例如topic是学校,tag是学生,group就是班级
- 班级把tag分为不同组,但实际上tag都一样
- 消费者组是同一类消费者的集合,这类Consumer消费的是同一个Topic类型的消息
- 消费者组使得在消息消费方面,实现负载均衡(将一个Topic中的不同的Queue平均分配给同一个Consumer Group的不同的Consumer,注意,并不是将消息负载均衡)和容错(一个Consmer挂了,该Consumer Group中的其它Consumer可以接着消费原Consumer消费的Queue)的目标变得非常容易
- 消费者组中Consumer的数量应该小于等于订阅Topic的Queue数量。如果超出Queue数量,则多出的Consumer将不能消费消息
- 一个Topic类型的消息可以被多个消费者组同时消费
- 消费者组只能消费一个Topic的消息,不能同时消费多个Topic消息
- 一个消费者组中的消费者必须订阅完全相同的Topic
四、主题(Topic)
- 表示一类消息的集合,每个主题包含若干条消息,每条消息只能属于一个主题,是RocketMQ进行消息订阅的基本单位
- topic:message:1:n
- message:topic:1:1
- 一个生产者可以同时发送多种Topic的消息;而一个消费者只对某种特定的Topic感兴趣,即只可以订阅和消费一种Topic的消息
- producer:topic:1:n
- consumer:topic:1:1
- 手动创建Topic时,有两种模式
- 集群模式:该模式下创建的Topic在该集群中,所有Broker中的Queue数量是相同的
- Broker模式:该模式下创建的Topic在该集群中,每个Broker中的Queue数量可以不同
- 自动创建Topic时,默认采用的是Broker模式,会为每个Broker默认创建4个Queue
- 读/写队列
- 从物理上来讲,读/写队列是同一个队列,所以,不存在读/写队列数据同步问题
- 读/写队列是逻辑上进行区分的概念,一般情况下,读/写队列数量是相同的
五、代理服务器(Broker Server)
- 消息中转角色,负责存储、转发消息
- 代理服务器在RocketMQ系统中负责接收从生产者发送来的消息并存储、同时为消费者的拉取请求做准备
- 代理服务器也存储消息相关的元数据,包括消费者组、消费进度偏移和主题和队列消息等
六、名字服务(Name Server)
- NameServer是一个Broker与Topic路由的注册中心,支持Broker的动态注册与发现
- 生产者或消费者能够通过名字服务查找各主题相应的Broker IP列表
- 多个Namesrv实例可组成集群,但相互独立,没有信息交换
- NameServer主要包括两个功能
- Broker管理
- 接受Broker集群的注册信息并且保存下来作为路由信息的基本数据
- 提供心跳检测机制,检查Broker是否还存活
- 路由信息管理
- 每个NameServer中都保存着Broker集群的整个路由信息和用于客户端查询的队列信息
- Producer和Conumser通过NameServer可以获取整个Broker集群的路由信息,从而进行消息的投递和消费
- Broker管理
- 路由注册
- NameServer通常以集群的方式部署,不过NameServer无状态,即NameServer集群中的各个节点间无差异,各节点间相互不进行信息通讯
- 那各节点中的数据如何进行数据同步?
- 在Broker节点启动时,轮询NameServer列表,与每个NameServer节点建立长连接,发起注册请求
- 在NameServer内部维护着⼀个Broker列表,用来动态存储Broker的信息
- Broker节点为了证明自己活着,会维护与NameServer间的长连接,会将最新的信息以心跳包的方式上报给NameServer,每30秒发送一次心跳
- 心跳包中包含 BrokerId、Broker地址(IP+Port)、 Broker名称、Broker所属集群名称等等
- NameServer在接收到心跳包后,会更新心跳时间戳,记录这个Broker的最新存活时间
- 路由剔除
- 由于Broker关机、宕机或网络抖动等原因,NameServer没有收到Broker的心跳,NameServer可能会将其从Broker列表中剔除
- NameServer中有⼀个定时任务,每隔10秒就会扫描⼀次Broker表,查看每一个Broker的最新心跳时间戳距离当前时间是否超过120秒,如果超过,则会判定Broker失效,然后将其从Broker列表中剔除
- 路由发现
- RocketMQ的路由发现采用的是Pull模型。当Topic路由信息出现变化时,NameServer不会主动推送给客户端,而是客户端定时拉取主题最新的路由。默认客户端每30秒会拉取一次最新的路由
- Push模型:推送模型实时性较好,是一个“发布-订阅”模型,需要维护一个长连接。而长连接的维护是需要资源成本的,该模型适合于的场景
- 实时性要求较高
- Client数量不多,Server数据变化较频繁
- Pull模型:拉取模型存在的问题:实时性较差,但可控性较高
- Long Polling模型:长轮询模型。其是对Push与Pull模型的整合,充分利用了这两种模型的优势,屏蔽了它们的劣势
- 客户端NameServer选择策略
- 客户端在配置时必须要写上NameServer集群的地址,那么客户端到底连接哪个NameServer节点呢?
- 客户端首先会生产一个随机数,然后再与NameServer节点数量取模,此时得到的就是所要连接的节点索引,然后就会进行连接。如果连接失败,则会采用round-robin策略,逐个尝试着去连接其它节点
- 首先采用的是随机策略进行的选择,失败后采用的是轮询策略
七、拉取式消费(Pull Consumer)
- Consumer消费的一种类型,应用通常主动调用Consumer的拉消息方法从Broker服务器拉消息、主动权由应用控制
- 一旦获取了批量消息,应用就会启动消费过程
八、推动式消费(Push Consumer)
- Consumer消费的一种类型,该模式下Broker收到数据后会主动推送给消费端,该消费模式一般实时性较高
九、生产者组(Producer Group)
- 同一类Producer的集合,这类Producer发送同一类消息且发送逻辑一致
- 如果发送的是事务消息且原始生产者在发送之后崩溃,则Broker服务器会联系同一生产者组的其他生产者实例以提交或回溯消费
十、消费者组(Consumer Group)
- 同一类Consumer的集合,这类Consumer通常消费同一类消息且消费逻辑一致
- 消费者组使得在消息消费方面,实现负载均衡和容错的目标变得非常容易
- 要注意的是,消费者组的消费者实例必须订阅完全相同的Topic
- RocketMQ 支持两种消息模式:集群消费(Clustering)和广播消费(Broadcasting)
十一、集群消费(Clustering)
- 集群消费模式下,相同Consumer Group的每个Consumer实例平均分摊消息
十二、广播消费(Broadcasting)
- 广播消费模式下,相同Consumer Group的每个Consumer实例都接收全量的消息
十三、普通顺序消息(Normal Ordered Message)
- 普通顺序消费模式下,消费者通过同一个消息队列( Topic 分区,称作 Message Queue) 收到的消息是有顺序的,不同消息队列收到的消息则可能是无顺序的
十四、严格顺序消息(Strictly Ordered Message)
- 严格顺序消息模式下,消费者收到的所有消息均是有顺序的
十五、消息(Message)
- 消息系统所传输信息的物理载体,生产和消费数据的最小单位,每条消息必须属于一个主题
- RocketMQ中每个消息拥有唯一的Message ID,且可以携带具有业务标识的Key
- 系统提供了通过Message ID和Key查询消息的功能
十六、标签(Tag)
- 为消息设置的标志,用于同一主题下区分不同类型的消息
- 也就是说,一条消息是通过 topic+tag 区分
- 来自同一业务单元的消息,可以根据不同业务目的在同一主题下设置不同标签
- 标签能够有效地保持代码的清晰度和连贯性,并优化RocketMQ提供的查询系统
- 消费者可以根据Tag实现对不同子主题的不同消费逻辑,实现更好的扩展性
- Topic是消息的一级分类,Tag是消息的二级分类
- Topic:中国省份
- Tag:广东
- Tag:贵州
- Topic:中国省份
十七、 队列(Queue)
- 存储消息的物理实体,一个Topic中可以包含多个Queue,每个Queue中存放的就是该Topic的消息
- 一个Topic的Queue也被称为一个Topic中消息的分区(Partition)
- 一个Topic的Queue中的消息只能被一个消费者组中的一个消费者消费
- 一个Queue中的消息不允许同一个消费者组中的多个消费者同时消费
注:广播模式下消息可以被多个消费者同时消费
十八、分片(Sharding)
- 分片不同于分区,在RocketMQ中,分片指的是存放相应Topic的Broker
- 每个分片中会创建出相应数量的分区,即Queue,每个Queue的大小都是相同的
十八、消息标识(MessageId/Key)
- RocketMQ中每个消息拥有唯一的MessageId,且可以携带具有业务标识的Key,以方便对消息的查询
- 不过需要注意的是,MessageId有两个:在生产者send()消息时会自动生成一个MessageId(msgId),当消息到达Broker后,Broker也会自动生成一个MessageId(offsetMsgId)
- msgId、offsetMsgId与key都称为消息标识
- msgId:由producer端生成,其生成规则为:producerIp + 进程pid + MessageClientIDSetter类的ClassLoader的hashCode +当前时间 + AutomicInteger自增计数器
- offsetMsgId:由broker端生成,其生成规则为:brokerIp + 物理分区的offset(Queue中的偏移量)
- key:由用户指定的业务相关的唯一标识,推荐发送消息时指定,方便根据key查询消费状态