消息(Message)
生产者和消费者数据流转的基础数据模型,主要属性有
字段名 | 默认值 | 必要性 | 说明 |
---|---|---|---|
Topic | null | 必填 | 消息所属topic的名称 |
Body | null | 必填 | 消息体 |
Tags | null | 选填 | 消息标签,方便服务器过滤使用。目前只支持每个消息设置一个 |
Keys | null | 选填 | 代表这条消息的业务关键词 |
Flag | 0 | 选填 | 完全由应用来设置,RocketMQ不做干预 |
DelayTimeLevel | 0 | 选填 | 消息延时级别,0表示不延时,大于0会延时特定的时间才会被消费 |
WaitStoreMsgOK | true | 选填 | 表示消息是否在服务器落盘后才返回应答 |
属性解读
Topic
定义消息会发送到哪个Topic上
Body
消息携带的真正的业务数据
Tags
消息在同一个Topic进行的二级分类
不同的 Topic 之间的消息没有必然的联系,而 Tag 则用来区分同一个 Topic 下相互关联的消息,例如全集和子集的关系、流程先后的关系。
Keys
Apache RocketMQ 每个消息可以在业务层面的设置唯一标识码 keys 字段,方便将来定位消息丢失问题。 Broker 端会为每个消息创建索引(哈希索引),应用可以通过 topic、key 来查询这条消息内容,以及消息被谁消费。由于是哈希索引,请务必保证 key 尽可能唯一,这样可以避免潜在的哈希冲突。
Flag
选填,消息的标记,完全由应用设置,RocketMQ不做任何处理,类似于memcached中flag的作用。目前还没应用过
DelayTimeLevel
设置延迟消息,当大于0时,代表此消息是延迟消息,会被延迟消费
WaitStoreMsgOK
消息在被发送端发送到broker,broker在将消息存储到磁盘上之后,才会进行返回,保证消息的可靠性。
队列(MessageQueue)
队列是消息存储的物理概念,
一个topic会有多个队列
一个消息最终会发送到topic的某个队列上
一个消费者也会从一个或多个队列上进行消费
生成者(Producer)
消息的起始,将业务消息组装成message,发送给broker
发送消息的方式
- 普通消息发送
- 同步发送
- 异步发送
- 单向发送
- 顺序消息发送
- 批量消息发送
- 延迟消息发送
- 事务消息发送
消费者(Consumer)
消息的终点,负责将消息从broker中取出,并进行处理
消息者与队列形成对应关系:
- 消费者 >= 队列:消费者与队列形成一对一的关系,其余的消费者空闲
- 消费者 < 队列:一个消费者对应多个队列
消费模式
消息获取方式的消费模式
-
push
Push是服务端主动推送消息给客户端,优点是及时性较好,但如果客户端没有做好流控,一旦服务端推送大量消息到客户端时,就会导致客户端消息堆积甚至崩溃。
-
pull
Pull是客户端需要主动到服务端取数据,优点是客户端可以依据自己的消费能力进行消费,但拉取的频率也需要用户自己控制,拉取频繁容易造成服务端和客户端的压力,拉取间隔长又容易造成消费不及时。
消费者组内消息分配方式的消费模式
-
集群模式
消费者组内的消费者互斥的消费消息,一个消费者组消费全量的消息
-
广播模式
消费者组内的每一个消费者都消费全量的消息
订阅关系一致
同一个消费者组下所有消费者实例所订阅的Topic、Tag必须完全一致。如果订阅关系(消费者组名-Topic-Tag)不一致,会导致消费消息紊乱,甚至消息丢失。