rocketmq的应用场景
1)异步通信
只需要把信息放入mq 中,不需要等待回调的确认信息
2)应用解耦
生产者不需要关心谁来消费,消费者也不关心是谁发送的消息
3)冗余存储
MQ本身具备了存储数据的功能,支持在消费者不能完全消费时进行数据堆积
4)削峰填谷
通过冗余存储,将流量洪峰转换为降低的流量输出,保护consumer;典型应用:秒杀
一、安装
1.导入依赖
2.开启
启动的顺序 nameserver --->broker
二、使用
发送
接收
三、发送的三种模式
1.发送-同步确认发送结果
普通的发送-->接收就是同步队列
2.发送-异步确认发送结果
在发送的一端
3.发送-结束 oneway
消费者模式
1.集群模式,集群模式是rocketmq的默认的模式
在集群模式下,消息只发给接收者中的其中有一个
2.群发模式
群发模式下,是发给同一组分组下的所有的接收者或者消费者
消息类型、
普通消息、顺序消息、延时消息、事务消息
此处主要说明延时和事务信息
延时信息
主要在发送端设置延时等级
事务信息
问题背景:数据库和recketmq之间的数据一致
事务信息模型
事务消息发送步骤如下:
- 发送方将半事务消息发送至消息队列RocketMQ版服务端。
- 消息队列RocketMQ版服务端将消息持久化成功之后,向发送方返回Ack确认消息已经发送成功,此时消息为半事务消息。
- 发送方开始执行本地事务逻辑。
- 发送方根据本地事务执行结果向服务端提交二次确认(Commit或是Rollback),服务端收到Commit状态则将半事务消息标记为可投递,订阅方最终将收到该消息;服务端收到Rollback状态则删除半事务消息,订阅方将不会接受该消息。
事务消息回查步骤如下:
- 在断网或者是应用重启的特殊情况下,上述步骤4提交的二次确认最终未到达服务端,经过固定时间后服务端将对消息发送方即生产者集群中任意一生产者实例发起消息回查。
- 发送方收到消息回查后,需要检查对应消息的本地事务执行的最终结果。
- 发送方根据检查得到的本地事务的最终状态再次提交二次确认,服务端仍按照步骤4对半事务消息进行操作
事务消息的监听器
事务信息的发送者