普通消息
分为以下5步：
- 初始化：生产者构建消息，并投递到Broker
- 待消费：等待消费者消费
- 消费中：消息已进行消费，等待消费结果的响应
- 消费者提交：消费已完成，进行结果响应，但消息不会马上删除，在删除前消费者仍然可以回溯消息重新消费
- 消息删除：消费者提交消费结果后，消息并不会马上删除，而是按照消息的存储顺序滚动删除
定时/延时消息
应用场景
- 分布式定时调度
比如：每天5点执行文件清理、每隔2分钟触发一次消息推送 - 任务超时处理
订单下单后暂时未支付，需要等待一段时间之后才关闭订单
注：定时队列的时间需要是毫秒级的时间戳，并需要保持在24小时之内
顺序消息
应用场景
应用于有序场景
实现
要保证消息生产的顺序性，要满足以下三个条件：
- 设置消费组，并将消息投递到类型为FIFO的TOPIC
- 单一生产者，且生产者串行发送
- 单一消费者，且消费者串行消费
注：创建FIFO的TOPIC
./bin/mqadmin updateTopic -c DefaultCluster -t FIFOTopic -o true -n 127.0.0.1:9876 -a +message.type=FIFO
事务消息
过程
- 消息持久化成功之后，消息被标记为“暂不能投递”，消息被定义为半事务消息
- 生产者开始执行本地事务逻辑
- 生产者根据本地事务的结构进行二次确认，成功过则commit、失败则Rollback
- 断网则一段时间后Broker主动请求生产者，询问本地事务情况
消息投递重试和流控机制
消息投递默认投递一次，重试二次，总共三次
流控机制则通过快速失败的方式，进行流控
消费者分类
PushConsumer: 并发度、负载均衡和消费结果返回由sdk实现，消费者只能在监听器中处理业务逻辑
SimpleConsumer：并发度、负载均衡、消费结果和业务逻辑均由消费者处理
PullConsumer：并发度、负载均衡、消费结果和业务逻辑均由消费者处理，吞吐量更好，但负载容易不均衡，仅推荐在流处理场景下使用
消息过滤
主要通过tag过滤
消费者负载均衡
模式
消息粒度负载均衡：PushConsumer和SimpleConsumer
队列粒度负载均衡：PullConsumer
注：负载均衡的过程可能会导致出现重复消息，需要做好消息的幂等处理
消费进度原理
消息位点
目前消息存储的坐标
消费位点
目前消息被消费的坐标
消费情况
- 当消费速度和生产速度一致时，表示全部消息处理完成，此时消息位点=消费位点
- 当消费速度小于生产速度时，表示队列中有部分消息未消费，此时消息位点>消费位点
注意点
严格控制消费位点重置的权限
消息重试
尝试消费16次之后，会将当前数据放到死信队列中
消息存储和清理机制
消息存储
消息存储主要分两块消息索引存储（存储在index和consumeQueue中）和消息存储（存储在commitLog中）
消息清理
消息默认保存3天，本次磁盘空间不足时，也会触发消息清理。
注：消息存储时长建议改长
