RocketMQ消息队列介绍与应用
RocketMQ简单介绍
RocketMQ是一个消息中间件,MQ的主要特点为解耦、异步、削峰,具有高性能、高可靠、高实时、分布式特点,用于减少数据库压力的业务场景,其中RocketMQ的核心组件概念如下:
- 支持严格的消息顺序
- 支持Topic与Queue两种模式
- 亿级消息堆积能力
- 支持多种消息协议,如 JMS、MQTT 等
- 分布式高可用的部署架构,满足至少一次消息传递语义
- 提供 docker 镜像用于隔离测试和云集群部署
- 提供配置、指标和监控等功能丰富的 Dashboard
RocketMQ结构
Name Server:注册中心(zookeeper)频繁更新offset。
Producer:消息生产者 生产消息 寄件人。
Consumer:消息消费者、复制消息消费、收件人。
Broker:中介(邮政) 提供消息中转服务。
Group :分组好处(业务区分,便于管理)。
Tag:多个标签 where 。
Key:区分业务系统 。
Msgid: broker在这个系统中它是独一无二的。
PS:消息中间件的最重要的作用是异步和解耦。
图中箭头的含义
- 从 Broker 开始,Broker Master1 和 Broker Slave1 是主从结构,它们之间会进行数据同步,即 Date Sync。同时每个 Broker 与
- NameServer 集群中的所有节点建立长连接,定时注册 Topic 信息到所有 NameServer 中。
- Producer 与 NameServer 集群中的其中一个节点(随机选择)建立长连接,定期从 NameServer 获取 Topic 路由信息,并向提供 Topic 服务的 Broker Master 建立长连接,且定时向 Broker 发送心跳。Producer 只能将消息发送到 Broker master,但是 Consumer 则不一样,它同时和提供 Topic 服务的 Master 和 Slave
- 建立长连接,既可以从 Broker Master 订阅消息,也可以从 Broker Slave 订阅消息。
RocketMQ事务消息设计思路
- 应用模块遇到要发送事务消息的场景时,先发送prepare消息给MQ。
- prepare消息发送成功后,应用模块执行数据库事务(本地事务)。
- 根据数据库事务执行的结果,再返回Commit或Rollback给MQ。
- 如果是Commit,MQ把消息下发给Consumer端,如果是Rollback,直接删掉prepare消息。
- 第3步的执行结果如果没响应,或是超时的,启动定时任务回查事务状态(最多重试15次,超过了 默认丢弃此消息),处理结果同第4步。
- MQ消费的成功机制由MQ自己保证。
业务案例
有一个点赞业务,不限制用户的点赞数只需进行记录(产品需求,开发提议无效),当每个用户都进行x连击享受数量猛增的快感时如果数据库都需要进行x个点赞数据的插入,数据库毫无疑问会塞死导致崩溃。
于是想到可以尝试下MQ削峰,比如每秒来了5000消息但数据库只能承受2000,那我消费时每次只拉取消费1600就好了,剩下的放在Broker堆积慢慢消费就好。由于之前的消息中心也在用RocketMQ,于是确认使用RocketMQ来进行削峰。
五、结束语
本篇简单介绍了Rocket基本的设计思路和流程,注意要保证数据可靠,需采用同步刷盘和同步双写的方式,但性能会较其他方式低,文章内有任何不正确或不详尽之处请留言指导,谢谢。