RocketMQ高级特性
1.消息的存储
- 消息生成者发送消息到MQ
- MQ返回ACK给生产者
- MQ push 消息给对应的消费者
- 消息消费者返回ACK给MQ
说明:ACK(Acknowledge character)
- 消息生成者发送消息到MQ
- MQ收到消息,将消息进行持久化,存储该消息
- MQ返回ACK给生产者
- MQ push 消息给对应的消费者
- 消息消费者返回ACK给MQ
6. MQ删除消息
注意:
- 第⑤步MQ在指定时间内接到消息消费者返回ACK,MQ认定消息消费成功,执行⑥
- 第⑤步MQ在指定时间内未接到消息消费者返回ACK,MQ认定消息消费失败,重新执行④⑤⑥
2.消息的存储介质
数据库
1.ActiveMQ
2.缺点:数据库瓶颈将成为MQ瓶颈
文件系统
1.RocketMQ/Kafka/RabbitMQ
2.解决方案:采用消息刷盘机制进行数据存储
3.缺点:硬盘损坏的问题无法避免
3.高效的消息存储与读写方式
- SSD(Solid State Disk)
- 随机写(100KB/s)
- 顺序写 (600MB/s)1秒1部电影
-
Linux系统发送数据的方式
-
“零拷贝”技术
1.数据传输由传统的4次复制简化成3次复制,减少1次复制过程
2.Java语言中使用MappedByteBuffer类实现了该技术
3.要求:预留存储空间,用于保存数据(1G存储空间起步)
4.消息存储结构
-
MQ数据存储区域包含如下内容
- 消息数据存储区域
- topic
2. queueId
3. message
- topic
- 消息数据存储区域
-
消费逻辑队列
- minOffset
- maxOffset
- consumerOffset
-
索引
- key索引
- 创建时间索引
5.刷盘机制
- 同步刷盘
- 生产者发送消息到MQ,MQ接到消息数据
- MQ挂起生产者发送消息的线程
- MQ将消息数据写入内存
- 内存数据写入硬盘
- 磁盘存储后返回SUCCESS
- MQ恢复挂起的生产者线程
- 发送ACK到生产者
-
异步刷盘
- 生产者发送消息到MQ,MQ接到消息数据
- MQ将消息数据写入内存
- 发送ACK到生产者
-
同步刷盘:安全性高,效率低,速度慢(适用于对数据安全要求较高的业务)
-
异步刷盘:安全性低,效率高,速度快(适用于对数据处理速度要求较高的业务)
配置方式
在rocketmq配置文件中进行配置
#刷盘方式
#- ASYNC_FLUSH 异步刷盘
#- SYNC_FLUSH 同步刷盘
flushDiskType=SYNC_FLUSH
6.高可用性
- nameserver
- 无状态+全服务器注册
- 消息服务器
- 主从架构(2M-2S)
- 消息生产
- 生产者将相同的topic绑定到多个group组,保障master挂掉后,其他master仍可正常进行消息接收
- 消息消费
- RocketMQ自身会根据master的压力确认是否由master承担消息读取的功能,当master繁忙时候,自动切换由slave承担数据读取的工作
7.主从数据复制
-
同步复制
- master接到消息后,先复制到slave,然后反馈给生产者写操作成功
- 优点:数据安全,不丢数据,出现故障容易恢复
- 缺点:影响数据吞吐量,整体性能低
-
异步复制
-
master接到消息后,立即返回给生产者写操作成功,当消息达到一定量后再异步复制到slave
-
优点:数据吞吐量大,操作延迟低,性能高
-
缺点:数据不安全,会出现数据丢失的现象,一旦master出现故障,从上次数据同步到故障
时间的数据将丢失
-
-
配置方式
#Broker 的角色
#- ASYNC_MASTER 异步复制Master
#- SYNC_MASTER 同步双写Master
#- SLAVE
brokerRole=SYNC_MASTER
8.负载均衡
-
Producer负载均衡
- 内部实现了不同broker集群中对同一topic对应消息队列的负载均衡
- Consumer负载均衡
- 平均分配
- 循环平均分配
- 广播模式(不参与负载均衡)
9.消息重试
- 当消息消费后未正常返回消费成功的信息将启动消息重试机制
- 消息重试机制
- 顺序消息
- 无序消息
1.顺序消息重试
- 当消费者消费消息失败后,RocketMQ会自动进行消息重试(每次间隔时间为 1 秒)
- 注意:应用会出现消息消费被阻塞的情况,因此,要对顺序消息的消费情况进行监控,避免阻塞现
象的发生
2.无序消息重试
- 无序消息包括普通消息、定时消息、延时消息、事务消息
- 无序消息重试仅适用于负载均衡(集群)模型下的消息消费,不适用于广播模式下的消息消费
- 为保障无序消息的消费,MQ设定了合理的消息重试间隔时长
10.死信队列
- 当消息消费重试到达了指定次数(默认16次)后,MQ将无法被正常消费的消息称为死信消息
(Dead-Letter Message) - 死信消息不会被直接抛弃,而是保存到了一个全新的队列中,该队列称为死信队列(Dead-Letter
Queue) - 死信队列特征
- 归属某一个组(Gourp Id),而不归属Topic,也不归属消费者
- 一个死信队列中可以包含同一个组下的多个Topic中的死信消息
- 死信队列不会进行默认初始化,当第一个死信出现后,此队列首次初始化
- 死信队列中消息特征
- 不会被再次重复消费
- 死信队列中的消息有效期为3天,达到时限后将被清除
死信处理
- 在监控平台中,通过查找死信,获取死信的messageId,然后通过id对死信进行精准消费
11.消息重复消费
-
消息重复消费原因
- 网络闪断
- 生产者宕机
-
消息服务器投递了重复的消息
- 网络闪断
-
动态的负载均衡过程
- 网络闪断/抖动
- broker重启
- 订阅方应用重启(消费者)
- 客户端扩容
- 客户端缩容
1.如何处理重复消费
消息队列出现重复消费的情况,在日常开发不可避免会遇到,而出现这个问题应该怎么去解决呢?这就涉及到消息幂等性的概念了
消息幂等性:对同一条消息,无论消费多少次,结果保持一致,称为消息幂等性
注意:messageId由RocketMQ产生,messageId并不具有唯一性,不能作用幂等判定条件
解决方案
1.设置唯一的幂等令牌(业务流水号),对处理成功的流水号进行缓存,在下一次消费时看看缓存是否命中,如果没有则进入下一步,如果命中则时重复消费
2.缓存失效的情况,先在数据库中查询幂等令牌作为索引的数据是否存在,如果存在则说明是重复性操作,如果不存在则进入下一步
3.在同一事务(分布式事务,rocketmq支持事务消息)中完成三项操作:唯一性处理后,将幂等令牌写入到缓存,并将令牌作为唯一索引写入到DB中
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
文章由极客之音整理,本文链接:https://www.bmabk.com/index.php/post/81205.html