RocketMQ-基础
参考文献
RocketMQ
Broker
(邮递员)Broker
是RocketMQ
的核心,负责消息的接收,存储,投递等功能.
NameServer
(邮局)- 消息队列的协调者,
Broker
向它注册路由信息,同时Producer
和Consumer
向其获取路由信息.
- 消息队列的协调者,
Producer
(寄件人)- 消息的生产者,需要从
NameServer
获取Broker
信息,然后与Broker
建立连接,向Broker建立连接,向Broker
发送消息.
- 消息的生产者,需要从
Consumer
(收件人)- 消费的消费者,需要从
NameServer
获取Broker
信息,然后与Broker
建立连接,从Broker
获取消息.
- 消费的消费者,需要从
Topic
(地区)- 用来区分不同类型的消息,发送和接收消息都需要先创建
Topic
,针对Topic
来发送和接收消息.
- 用来区分不同类型的消息,发送和接收消息都需要先创建
Message Queue
(邮件)- 为了提高性能和吞吐量,引入
Message Queue
,一个Topic
可以设置一个或多个Message Queue
,这样消息就可以并行往各个Message Queue
发送消息,消费者也可以并行的从多个Message Queue
读取消息
- 为了提高性能和吞吐量,引入
Message
- 消息的载体
Producer Group
- 生产者组,简单来说就是多个发送同一类消息的生产者称为一个生产者组.
Consumer Group
- 消费者组,消费同一类消息的多个
Consumer
实例组成一个消费者组.
- 消费者组,消费同一类消息的多个
发送不同类型的消息
普通消息
- RocketMQ提供三种方式来发送普通消息:可靠同步发送,可靠异步发送和单向发送.
可靠同步消息
- 同步发送是指消息发送方发出数据后,会在收到接收方发回响应之后才发下一个数据包的通信方式.
- 这种方式应用场景非常广泛,例如重要通知邮件,报名短信通知,营销短信系统等.
可靠异步发送
- 异步发送是指发送方发出数据后,不等接收方发回响应,接着发送下个数据包的通信方式.发送方通过回调接口接收服务器响应,并对响应结果进行处理.
- 异步发送一般用于链路耗时较长,对RT响应较为敏感的业务场景,例如用户视频上传后通知启动转码服务,转码完成后通知推送转码结果等.
单向发送
- 单向发送是指发送方只负责发送消息,不等待服务器回应且没有回调函数触发,即只发送请求不等待应答.
- 使用与某些耗时非常短,但对可靠性要求并不高的场景,例如日志收集.
顺序消息
- 顺序消息是消息队列提供的一种严格按照顺序来发布和消费的消息类型.
事务消息
- RocketMQ提供了事务消息,通过事务消息就能达到分布式事务的最终一致.
事务消息交互流程
- 半事务消息: 暂不能投递的消息,发送方已经成功地将消息发送到RocketMQ服务端,但是服务端未收到生产者对该消息的二次确认,此时该消息被标记成"暂不能投递状态",处于这种状态下的消息即半事务消息.
- 消息回查: 由于网络闪断,生产者应用重启等原因,导致某条事务的二次确认丢失,
RocketMQ
服务端通过扫描发现某条消息长期处于"半事务消息"时,需要主动向消息生产者询问该消息的最终状态(Commit
或是Rollback
),该询问过程即消息回查.
事务消息发送步骤
- 发送方将半事务消息发送至
RocketMQ
服务端. RocketMQ
服务端将消息持久化之后,向发送方返回ACK
确认消息已经发送成功,此时消息为半事务消息.- 发送方开始执行本地事务逻辑.
- 发送方根据本地事务执行结果向服务端提交二次确认(
Commit
或是Rollback
),服务端收到Commit
状态则将半事务消息标记为可投递,订阅方最终将收到该消息;服务端收到Rollback
状态则删除半事务消息,订阅方将不会接收该消息.
事务消息回查步骤
- 在断网或者是应用重启的特殊情况下,上述步骤4提交的二次确认最终未到达服务端,经过固定时间后服务端将对该消息发起消息回查.
- 发送方收到消息回查,需要检查对应消息的本地事务执行的最终结果.
- 发送方根据检查得到的本地事务的最终状态再次提交二次确认,服务端仍按照步骤4对半事务消息进行操作.
消费模式
- RocketMQ支持两种消费模式:
- 广播消费: 每个消费者实例都会收到消息,也就是一条消息可以被每个消费者实例处理;
- 集群消费: 一条消息只能被一个消费者实例消费.
本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来自 HoleLin's Blog!