一、看前提问：
- RocketMQ支持的消息类型有哪些？
- RocketMQ各消息类型的特点有哪些？
- RocketMQ各消息类型的优缺点？
- RocketMQ各消息类型的实现原理？
- RocketMQ各消息类型的应用场景？
二、消息类型：
1、普通消息：
概念： 普通消息是 RocketMQ 版中⽆特性的消息。 普通消息主要包含了：同步消息、异步消息两种。
1.1、同步消息的发送：
概念： 同步消息就是生产者（消息发送方）发送一条消息后必须要收到服务端返回响应后才发下一条消息。
应用场景： 重要消息例如邮件发送等；
1.2、异步消息：
概念：
需要⽤户实现异步发送回调接⼝（SendCallback）
应用场景： 异步发送⼀般⽤于链路耗时较⻓，对响应时间较为敏感的业务场景
1.3、单向发送消息：
概念： 发送⽅只负责发送消息，不等待服务端返回响应且没有回调函数触发，即只发送请求不等待应答。响应毫米级
应用场景： 需要极快的响应速度，但不能保证可靠性
2、顺序消息：
概念： 顺序消息（FIFO 消息）是消息队列，顺序发布和顺序消费是指对于指定的⼀个 Topic⽣产者按照⼀定的先后顺序发布消息；消费者按照既定的先后顺序订阅消息，即先发布的消息⼀定会先被客户端接收到。
如何保证顺序：
- 消息被发送时保持顺序
- 消息被存储时保持和发送的顺序⼀致
- 消息被消费时保持和存储的顺序⼀致
理解： 只保证消息从头到尾的数据是按顺序来的 至于多个消息之间的顺序不保证
顺序实现的方式：
- 全局顺序：对于指定的⼀个 Topic，所有消息按照严格的先⼊先出
- 分区顺序：对于指定的⼀个 Topic，所有消息根据 Sharding Key 进⾏区块分区。 同⼀个分区内的消息按照严格的 FIFO 顺序进⾏发布和消费
MessageListenerOrderly与MessageListenerConcurrently区别：
- MessageListenerOrderly:有序消费，同⼀队列的消息同⼀时刻只能⼀个线程消费，可保证消息在同⼀队列严格有序消费
- MessageListenerConcurrently:并发消费
3、广播消息：
3.1:类型： 集群模式、广播模式
3.2：集群模式：
RocketMQ默认为集群模式，集群模式下每条消息只会被处理(消费)一次且消费进度在服务端维护可靠性更高。
注意：
- 集群消费模式下，每条消息只会被分发到一台服务器上处理。
- 集群消费模式下，不会保证失败的同一条消息在重新投放的时候会被路由到同一台服务器上。
3.2：广播模式：
每条消息都需要被集群下的每一个消费者处理。
注意：
- 广播模式下不支持顺序消息
- 不支持重置消费点位
- 每条消息都需要被相同订阅逻辑的多台机器处理
- 消费进度在客户端维护
- 消息队列 保证每条消息⾄少被每台客户端消费⼀次，但是并不会重投消费失败的消息，因此业务⽅需要关注消费失败的情况
- 客户端每⼀次重启都会从最新消息消费。客户端在被停⽌期间发送⾄服务端的消息将会被⾃动跳过。
- 每条消息都会被⼤量的客户端重复处理所以推荐集群模式
4:延时消息：
概念： 延迟一段时间后才会进行投放消费
适用场景： 订单失效
延迟的实现方式：
- 轮询
- 延时服务，将延迟消息通过⼀个临时存储进⾏暂存，到期后才投递到⽬标Topic中
注意：
- 对临时存储需要满足高性能(写入快)，高可靠(写入后能备份不能丢失)，支持排序，长时间保存
- RocketMQ不支持任意时间的延迟只支持以下任意时间的延迟但可以自行增加延迟级别
原理：
RocketMQ延迟消息只能存在指定的topic(SCHEDULE_TOPIC_XXXX),注意根据延迟level的个数，创建对应数量的队列并不一定是在内部创建固定数量队列而是在各个节点下都会有相同数量的队列。
5.批量消息：
批量消息发送可以提高发送性能
- topic相同
- waitStoreMsgOK相同（⾸先我们建设消息的iswaitstoremsgok=true(默认为true), 如果没有异常,我们将始终收到"OK"， org.apache.rocketmq.common.message.Message#isWaitStoreMsgOK））
- 不支持延迟发送，一批消息不能大于1M
6.过滤消息：
过滤消息类型包括：tag模式过滤、sql表达式过滤、类过滤模式
tag消息过滤：
发送消息时我们会为每⼀条消息设置TAG标签，同⼀⼤类中的消息放在⼀个主题TOPIC下
7.事务消息：
- 事务消息：提供类型X/Open XA分布式消息达到最终一致
- 半事务消息：消息发送给服务端未收到二次确认消息会被标记为“暂不能投递”
- 消息回查：由于⽹络闪断、⽣产者应⽤重启等原因，导致某条事务消息的⼆次确认丢失，消息队列服务端通过扫描发现某条消息⻓期处于“半事务消息”时，需要主动向消息⽣产者询问该消息的最终状态（Commit 或是 Rollback）
交互流程：
