RocketMQ - 2 高级特性
RocketMQ - 高级特性
6.1） 持久化与持久化介质
6.1.1）数据库持久化
ActiveMQ 使用了数据库的消息存储
缺点：数据库瓶颈将成为MQ瓶颈
6.1.2）文件系统持久化
不用数据库,直接用文件存储
(RocketMQ/Kafka/RabbitMQ)
6.2）顺序写与零拷贝
6.2.1）MQ 高效的消息存储与读写方式
-
SSD（Solid State Disk）
-
- 随机写（100KB/s）
- 顺序写（600MB/s）1秒1部电影
6.2.2）零拷贝技术
1) 通过启动时初始化话文件大小来保证 占用固定的磁盘空间,保证磁盘读写速度
2) 零拷贝”技术
数据传输由传统的4次复制简化成3次复制(如下图)，减少1次复制过程
Java语言中使用MappedByteBuffer类实现了该技术
要求：预留存储空间，用于保存数据（1G存储空间起步）
6.3）消息存储结构
消息数据存储区域
topic
queueId
message
消费逻辑队列
minOffset
maxOffset
consumerOffset
索引
key索引
创建时间索引
……
6.4） 刷盘机制
6.4.1） 同步刷盘
1)生产者发送消息到MQ，MQ接到消息数据
2)MQ挂起生产者发送消息的线程
3)MQ将消息数据写入内存
4)内存数据写入硬盘
5)磁盘存储后返回SUCCESS
6)MQ恢复挂起的生产者线程
7)发送ACK到生产者
6.4.2） 异步刷盘
1)生产者发送消息到MQ，MQ接到消息数据
2)MQ将消息数据写入内存
3)发送ACK到生产者
--等消息量多了--
4)内存数据写入硬盘
6.4.3) 同步刷盘/ 异步刷盘 优缺点对比
同步刷盘：安全性高，效率低，速度慢（适用于对数据安全要求较高的业务）
异步刷盘：安全性低，效率高，速度快（适用于对数据处理速度要求较高的业务）
6.4.4) 配置方式
#刷盘方式
#- ASYNC_FLUSH 异步刷盘
#- SYNC_FLUSH 同步刷盘
flushDiskType=SYNC_FLUSH
6.5）高可用与主从复制方案
6.5.1）高可用方案
nameserver
nameserver ,通过无状态+全服务器注册 来保证即使一个宕机了也能提供所有的服务
消息服务器
主从架构（2M-2S） ,即使又一台服务器宕机, 服务依旧可以正常提供
注意: master 一旦宕机,slave 只提供消费服务,不能写入新的消息(slave 不会升级为master)
消息生产(开发人员写代码时保障)
生产者将相同的topic绑定到多个group组，保障master挂掉后，其他master仍可正常进行消息接收
消息消费
RocketMQ自身会根据master的压力确认是否由master承担消息读取的功能，当master繁忙时候，自动切换由slave承担数据读取的工作
6.5.2）主从复制方案
同步复制
master接到消息后，先复制到slave，然后反馈给生产者写操作成功
优点：数据安全，不丢数据，出现故障容易恢复
缺点：影响数据吞吐量，整体性能低
异步复制
master接到消息后，立即返回给生产者写操作成功，当消息达到一定量后再异步复制到slave
优点：数据吞吐量大，操作延迟低，性能高
缺点：数据不安全，会出现数据丢失的现象，一旦master出现故障，从上次数据同步到故障时间的数据将丢失
配置(配置在启动时 -c 指定的配置文件中 broker.conf)
#Broker 的角色
#- ASYNC_MASTER 异步复制Master
#- SYNC_MASTER 同步双写Master
#- SLAVE
brokerRole=SYNC_MASTER
6.6）负载均衡
- Producer负载均衡
内部实现了不同broker集群中对同一topic对应消息队列的负载均衡 - Consumer负载均衡
平均分配
循环平均分配
6.7）消息重试
当消息消费后未正常返回消费成功的信息将启动消息重试机制
6.7.1) 顺序消息重试
当消费者消费消息失败后，RocketMQ会自动进行消息重试（每次间隔时间为 1 秒）
注意：应用会出现消息消费被阻塞的情况，因此，要对顺序消息的消费情况进行监控，避免阻塞现象的发生
6.7.2) 无序消息重试
无序消息包括普通消息、定时消息、延时消息、事务消息
无序消息重试仅适用于负载均衡（集群）模型下的消息消费，不适用于广播模式下的消息消费
为保障无序消息的消费，MQ设定了合理的消息重试间隔时长
6.8）死信队列
6.8.1）概念
当消息消费重试到达了指定次数（默认16次）后，MQ将无法被正常消费的消息称为死信消息（Dead-Letter Message）
死信消息不会被直接抛弃，而是保存到了一个全新的队列中，该队列称为死信队列（Dead-Letter Queue）
6.8.2) 死信队列特征
- 归属某一个组（Gourp Id），而不归属Topic，也不归属消费者
- 一个死信队列中可以包含同一个组下的多个Topic中的死信消息
- 死信队列不会进行默认初始化，当第一个死信出现后，此队列首次初始化
6.8.3)死信队列中消息特征
- 不会被再次重复消费
- 死信队列中的消息有效期为3天，达到时限后将被清除
6.8.4) 死信处理
在监控平台中，通过查找死信，获取死信的messageId，然后通过id对死信进行精准消费
6.9）重复消费与消息幂等
6.9.1）重复消费原因
1 生产者发送了重复的消息
网络闪断
生产者宕机
2 消息服务器投递了重复的消息
网络闪断
3 动态的负载均衡过程
网络闪断/抖动
broker重启
订阅方应用重启（消费者）
客户端扩容
客户端缩容
6.9.2）消息幂等
对同一条消息，无论消费多少次，结果保持一致，称为消息幂等性
6.9.3）解决方案
- 使用业务id作为消息的key
- 在消费消息时，客户端对key做判定，未使用过放行，使用过抛弃
*注意：messageId由RocketMQ产生，messageId并不具有唯一性，不能作用幂等判定条件*
