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基本的设计思路和流程，注意要保证数据可靠，需采用同步刷盘和同步双写的方式，但性能会较其他方式低，文章内有任何不正确或不详尽之处请留言指导，谢谢。