qidao123.com技术社区-IT企服评测·应用市场

标题: RocketMQ高级使用 [打印本页]

作者: 傲渊山岳 时间: 6 天前
标题: RocketMQ高级使用
消息存储

分布式队列因为有高可靠性的要求，以是数据要进行持久化存储。

消息天生者发送消息
MQ收到消息，将消息进行持久化，在存储中新增一条记录
返回ACK给生产者
MQ push 消息给对应的消费者，然后等候消费者返回ACK
如果消息消费者在指定时间内成功返回ack，那么MQ认为消息消费成功，在存储中删除消息，即执行第6步；如果MQ在指定时间内没有收到ACK，则认为消息消费失败，会尝试重新push消息,重复执行4、5、6步骤
MQ删除消息

存储介质

关系型数据库DB

Apache下开源的别的一款MQ—ActiveMQ（默认采取的KahaDB做消息存储）可选用JDBC的方式来做消息持久化，通过简朴的xml配置信息即可实现JDBC消息存储。由于，普通关系型数据库（如Mysql）在单表数据量达到千万级别的环境下，其IO读写性能往往会出现瓶颈。在可靠性方面，该种方案非常依赖DB，如果一旦DB出现故障，则MQ的消息就无法落盘存储会导致线上故障

文件体系
现在业界较为常用的几款产品（RocketMQ/Kafka/RabbitMQ）均采取的是消息刷盘至所部署虚拟机/物理机的文件体系来做持久化（刷盘一般可以分为异步刷盘和同步刷盘两种模式）。消息刷盘为消息存储提供了一种高效率、高可靠性和高性能的数据持久化方式。除非部署MQ机器本身或是本地磁盘挂了，否则一般是不会出现无法持久化的故障标题。

性能对比

文件体系>关系型数据库DB
消息的存储和发送

1）消息存储
磁盘如果使用恰当，磁盘的速率完全可以匹配上网络的数据传输速率。现在的高性能磁盘，顺序写速率可以达到600MB/s，超过了一般网卡的传输速率。但是磁盘随机写的速率只有大概100KB/s，温和序写的性能相差6000倍！因为有如此巨大的速率差别，好的消息队列体系会比普通的消息队列体系速率快多个数目级。RocketMQ的消息用顺序写,保证了消息存储的速率。
2）消息发送
Linux操作体系分为【用户态】和【内核态】，文件操作、网络操作需要涉及这两种形态的切换，免不了进行数据复制。
一台服务器把本机磁盘文件的内容发送到客户端，一般分为两个步骤：

read；读取本地文件内容；
write；将读取的内容通过网络发送出去。

这两个看似简朴的操作，现实进行了4 次数据复制，分别是：

从磁盘复制数据到内核态内存；
从内核态内存复制到用户态内存；
然后从用户态内存复制到网络驱动的内核态内存；
末了是从网络驱动的内核态内存复制到网卡中进行传输。

通过使用mmap的方式，可以省去向用户态的内存复制，进步速率。这种机制在Java中是通过MappedByteBuffer实现的
RocketMQ充分使用了上述特性，也就是所谓的“零拷贝”技术，进步消息存盘和网络发送的速率。

这里需要留意的是，采取MappedByteBuffer这种内存映射的方式有几个限定，其中之一是一次只能映射1.5~2G 的文件至用户态的虚拟内存，这也是为何RocketMQ默认设置单个CommitLog日记数据文件为1G的原因了

消息存储结构

RocketMQ消息的存储是由ConsumeQueue和CommitLog配合完成的，消息真正的物理存储文件是CommitLog，ConsumeQueue是消息的逻辑队列，类似数据库的索引文件，存储的是指向物理存储的地址。每个Topic下的每个Message Queue都有一个对应的ConsumeQueue文件。

CommitLog：存储消息的元数据
ConsumerQueue：存储消息在CommitLog的索引
IndexFile：为了消息查询提供了一种通过key或时间区间来查询消息的方法，这种通过IndexFile来查找消息的方法不影响发送与消费消息的主流程

刷盘机制

RocketMQ的消息是存储到磁盘上的，如许既能保证断电后恢复，又可以让存储的消息量超出内存的限定。RocketMQ为了进步性能，会尽大概地保证磁盘的顺序写。消息在通过Producer写入RocketMQ的时候，有两种写磁盘方式，分布式同步刷盘和异步刷盘。

1）同步刷盘
在返回写成功状态时，消息已经被写入磁盘。详细流程是，消息写入内存的PAGECACHE后，立刻通知刷盘线程刷盘，然后等候刷盘完成，刷盘线程执行完成后唤醒等候的线程，返回消息写成功的状态。
2）异步刷盘
在返回写成功状态时，消息大概只是被写入了内存的PAGECACHE，写操作的返回快，吞吐量大；当内存里的消息量积累到一定程度时，统一触发写磁盘动作，快速写入。
3）配置
同步刷盘还是异步刷盘，都是通过Broker配置文件里的flushDiskType 参数设置的，这个参数被配置成SYNC_FLUSH、ASYNC_FLUSH中的一个。
高可用性机制

RocketMQ分布式集群是通过Master和Slave的配合达到高可用性的。
Master和Slave的区别：在Broker的配置文件中，参数 brokerId的值为0表明这个Broker是Master，大于0表明这个Broker是 Slave，同时brokerRole参数也会说明这个Broker是Master还是Slave。
Master角色的Broker支持读和写，Slave角色的Broker仅支持读，也就是 Producer只能和Master角色的Broker连接写入消息；Consumer可以连接 Master角色的Broker，也可以连接Slave角色的Broker来读取消息。
消息消费高可用

在Consumer的配置文件中，并不需要设置是从Master读还是从Slave 读，当Master不可用或者繁忙的时候，Consumer会被自动切换到从Slave 读。有了自动切换Consumer这种机制，当一个Master角色的机器出现故障后，Consumer仍然可以从Slave读取消息，不影响Consumer程序。这就达到了消费端的高可用性。
消息发送高可用

在创建Topic的时候，把Topic的多个Message Queue创建在多个Broker组上（雷同Broker名称，不同 brokerId的机器组成一个Broker组），如许当一个Broker组的Master不可用后，其他组的Master仍然可用，Producer仍然可以发送消息。 RocketMQ现在还不支持把Slave自动转成Master，如果机器资源不敷，需要把Slave转成Master，则要手动克制Slave角色的Broker，更改配置文件，用新的配置文件启动Broker。

消息主从复制

如果一个Broker组有Master和Slave，消息需要从Master复制到Slave 上，有同步和异步两种复制方式。
1）同步复制
同步复制方式是等Master和Slave均写成功后才反馈给客户端写成功状态；
在同步复制方式下，如果Master出故障， Slave上有全部的备份数据，容易恢复，但是同步复制会增大数据写入延迟，降低体系吞吐量。
2）异步复制
异步复制方式是只要Master写成功即可反馈给客户端写成功状态。
在异步复制方式下，体系拥有较低的延迟和较高的吞吐量，但是如果Master出了故障，有些数据因为没有被写入Slave，有大概会丢失；
3）配置
同步复制和异步复制是通过Broker配置文件里的brokerRole参数进行设置的，这个参数可以被设置成ASYNC_MASTER、 SYNC_MASTER、SLAVE三个值中的一个。
4）总结

现实应用中要联合业务场景，公道设置刷盘方式和主从复制方式，尤其是SYNC_FLUSH方式，由于频繁地触发磁盘写动作，会显着降低性能。通常环境下，应该把Master和Save配置成ASYNC_FLUSH的刷盘方式，主从之间配置成SYNC_MASTER的复制方式，如许纵然有一台机器出故障，仍然能保证数据不丢，是个不错的选择。
集群Master选举机制

基于raft协议的过半写入机制

在这里考虑有三个Broker节点的环境，即Broker01作为主节点，以及Broker02和Broker03作为从节点。
当Producer将消息写入Broker01主节点时，Broker01只需将消息顺利写入pageCache（页高速缓存）即视为写入成功，该节点会记入写入操作并在后台进行异步持久化。
紧接着，基于RAFT协议，Broker01节点会将消息同步至从节点Broker02和Broker03，并将消息写入他们的pageCache。只要在Broker02和Broker03中有一个节点成功写入，整个写入操作即视为成功。这是因为在这三节点体系中，只需要有过半节点（即2个节点）写入成功，整个体系即认定消息已成功写入。
假设此时Broker01节点发生故障，体系会通过Leader选举机制，让Broker02或Broker03中的一个节点升级为主节点，保证消息能继续被写入。此时只有两个节点，只有当写入消息的操作在这两个节点中全部成功完成，才气被视为成功。这同样体现了"过半写入"的原则。
基于raft协议的Leader选举机制

这里要讨论RocketMQ中的领导选举机制，类似于计划模式中的状态机模式，为了便于理解，我们将其分为三种角色：Follower（跟随者）、Candidate（候选人）、以及Leader（领导）。
首先关注Follower角色，它是节点初始状态，即Broker节点在一开始就处于Follower状态。在此状态中，节点设有一个随机倒计时，如果Follower收到了Leader的生命信号（心跳），这个倒计时将被重置，这意味着只要故意跳信息，Follower状态将一直保持。然而，如果这个随机倒计时结束了，Follower角色会升级为Candidate角色。
作为Candidate，其主动举动是发起投票寻求成为Leader，对于吸取的投票，如果投票数大于或即是整个集群节点数的一半，它将升级为Leader状态，如果小于这个数目，它会降级为Follower状态。
Leader角色则是体系的核心，它的主动举动是发送心跳信号保持其他Follower节点的跟随状态，避免他们试图劫掠领导职位。
举例来说，这里有三个Broker节点，即Broker01，Broker02，和Broker03。他们刚启动，目的是要选举出一个作为Leader。假设Broker01节点首先完成了随机倒计时，它将首先变成Candidate，并开始发起投票。如果其余两个节点，即Broker02和Broker03都把票投给了Broker01，那么Broker01将会升级为Leader，并发送心跳给Broker02和Broker03。一旦Broker02和Broker03吸取到心跳，他们会重置自己的倒计时和状态，一直保持在Follower状态。这就是一种状态转换的环境。

接下来，来讨论另一种领导选举的情形。假设在三个Broker节点刚启动时，Broker01和Broker02都完成了随机倒计时并升级为Candidate状态，并同时发起投票。
在这次投票中，Broker01投自己一票，Broker02也投自己一票，而Broker03则选择投给Broker01。那么由于Broker01的票数达到了过半（二分之一以上），它将成功升级为Leader。在升级后，Broker01将开始发出心跳信号。
另一方面，Broker02由于未能得到过半的选票（只有自己的一票），将不得不降级为Follower，然后重新开始新一轮的随机倒计时，等候下一次的领导选举时机。
在这种环境下，固然Broker01和Broker02同时成为Candidate并发起投票，但由于得票数目的原因，Broker01最终升级为Leader，而Broker02则只能继续留在Follower状态。这也是RocketMQ中领导选举机制的一种典型应用。
负载平衡

Producer负载平衡

Producer端，每个实例在发消息的时候，默认会轮询所有的message queue发送，以达到让消息平均落在不同的queue上。而由于queue可以散落在不同的broker，以是消息就发送到不同的broker下，如下图：

图中箭头线条上的标号代表顺序，发布方会把第一条消息发送至 Queue 0，然后第二条消息发送至 Queue 1，以此类推。
Consumer负载平衡

1）集群模式
在集群消费模式下，每条消息只需要投递到订阅这个topic的Consumer Group下的一个实例即可。RocketMQ采取主动拉取的方式拉取并消费消息，在拉取的时候需要明确指定拉取哪一条message queue。
而每当实例的数目有变动，都会触发一次所有实例的负载平衡，这时候会按照queue的数目和实例的数目平均分配queue给每个实例。
默认的分配算法是AllocateMessageQueueAveragely，如下图：

另有别的一种平均的算法是AllocateMessageQueueAveragelyByCircle，也是平均分摊每一条queue，只是以环状轮流分queue的情势，如下图：

需要留意的是，集群模式下，queue都是只允许分配只一个实例，这是由于如果多个实例同时消费一个queue的消息，由于拉取哪些消息是consumer主动控制的，那样会导致同一个消息在不同的实例下被消费多次，以是算法上都是一个queue只分给一个consumer实例，一个consumer实例可以允许同时分到不同的queue。
通过增加consumer实例去分摊queue的消费，可以起到水平扩展的消费能力的作用。而有实例下线的时候，会重新触发负载平衡，这时候原来分配到的queue将分配到其他实例上继续消费。
但是如果consumer实例的数目比message queue的总数目还多的话，多出来的consumer实例将无法分到queue，也就无法消费到消息，也就无法起到分摊负载的作用了。以是需要控制让queue的总数目大于即是consumer的数目。
2）广播模式
由于广播模式下要求一条消息需要投递到一个消费组下面所有的消费者实例，以是也就没有消息被分摊消费的说法。
在实现上，其中一个不同就是在consumer分配queue的时候，所有consumer都分到所有的queue。

消息重试

顺序消息的重试

对于顺序消息，当消费者消费消息失败后，消息队列 RocketMQ 会自动不断进行消息重试（每次隔断时间为 1 秒），这时，应用会出现消息消费被阻塞的环境。因此，在使用顺序消息时，务必保证应用可以大概及时监控并处理消费失败的环境，避免阻塞现象的发生。
无序消息的重试

对于无序消息（普通、定时、延时、事件消息），当消费者消费消息失败时，您可以通过设置返回状态达到消息重试的效果。
无序消息的重试只针对集群消费方式生效；广播方式不提供失败重试特性，即消费失败后，失败消息不再重试，继续消费新的消息。
1）重试次数
消息队列 RocketMQ 默认允许每条消息最多重试 16 次，每次重试的隔断时间如下：
第几次重试与上次重试的隔断时间第几次重试与上次重试的隔断时间110 秒97 分钟230 秒108 分钟31 分钟119 分钟42 分钟1210 分钟53 分钟1320 分钟64 分钟1430 分钟75 分钟151 小时86 分钟162 小时如果消息重试 16 次后仍然失败，消息将不再投递。如果严格按照上述重试时间隔断盘算，某条消息在一直消费失败的前提下，将会在接下来的 4 小时 46 分钟之内进行 16 次重试，超过这个时间范围消息将不再重试投递。
留意： 一条消息无论重试多少次，这些重试消息的 Message ID 不会改变。
2）配置方式
消费失败后，重试配置方式
集群消费方式下，消息消费失败后期望消息重试，需要在消息监听器接口的实现中明确进行配置（三种方式任选一种）：

返回 Action.ReconsumeLater （推荐）
返回 Null
抛出异常

public class MessageListenerImpl implements MessageListener {
@Override
public Action consume(Message message, ConsumeContext context) {
//处理消息
doConsumeMessage(message);
//方式1：返回 Action.ReconsumeLater，消息将重试
return Action.ReconsumeLater;
//方式2：返回 null，消息将重试
return null;
//方式3：直接抛出异常，消息将重试
throw new RuntimeException("Consumer Message exceotion");
}
}

复制代码

消费失败后，不重试配置方式
集群消费方式下，消息失败后期望消息不重试，需要捕获消费逻辑中大概抛出的异常，最终返回 Action.CommitMessage，此后这条消息将不会再重试。

public class MessageListenerImpl implements MessageListener {
@Override
public Action consume(Message message, ConsumeContext context) {
try {
doConsumeMessage(message);
} catch (Throwable e) {
//捕获消费逻辑中的所有异常，并返回 Action.CommitMessage;
return Action.CommitMessage;
}
//消息处理正常，直接返回 Action.CommitMessage;
return Action.CommitMessage;
}
}

复制代码

自定义消息最大重试次数
消息队列 RocketMQ 允许 Consumer 启动的时候设置最大重试次数，重试时间隔断将按照如下策略：

最大重试次数小于即是 16 次，则重试时间隔断同上表描述。
最大重试次数大于 16 次，超过 16 次的重试时间隔断均为每次 2 小时。

Properties properties = new Properties();
//配置对应 Group ID 的最大消息重试次数为 20 次
properties.put(PropertyKeyConst.MaxReconsumeTimes,"20");
Consumer consumer =ONSFactory.createConsumer(properties);

复制代码

留意：

消息最大重试次数的设置对雷同 Group ID 下的所有 Consumer 实例有效。
如果只对雷同 Group ID 下两个 Consumer 实例中的其中一个设置了 MaxReconsumeTimes，那么该配置对两个 Consumer 实例均生效。
配置采取覆盖的方式生效，即末了启动的 Consumer 实例会覆盖之前的启动实例的配置

获取消息重试次数
消费者收到消息后，可按照如下方式获取消息的重试次数：

public class MessageListenerImpl implements MessageListener {
@Override
public Action consume(Message message, ConsumeContext context) {
//获取消息的重试次数
System.out.println(message.getReconsumeTimes());
return Action.CommitMessage;
}
}

复制代码

死信队列

当一条消息初次消费失败，消息队列 RocketMQ 会自动进行消息重试；达到最大重试次数后，若消费依然失败，则表明消费者在正常环境下无法正确地消费该消息，此时，消息队列 RocketMQ 不会立刻将消息丢弃，而是将其发送到该消费者对应的特殊队列中。
在消息队列 RocketMQ 中，这种正常环境下无法被消费的消息称为死信消息（Dead-Letter Message），存储死信消息的特殊队列称为死信队列（Dead-Letter Queue）。
死信特性

死信消息具有以下特性

不会再被消费者正常消费。
有效期与正常消息雷同，均为 3 天，3 天后会被自动删除。因此，请在死信消息产生后的 3 天内及时处理。

死信队列具有以下特性：

一个死信队列对应一个 Group ID，而不是对应单个消费者实例。
如果一个 Group ID 未产生死信消息，消息队列 RocketMQ 不会为其创建相应的死信队列。
一个死信队列包罗了对应 Group ID 产生的所有死信消息，不论该消息属于哪个 Topic。

查看死信信息

在控制台查询出现死信队列的主题信息

在消息界面根据主题查询死信消息

选择重新发送消息

一条消息进入死信队列，意味着某些因素导致消费者无法正常消费该消息，因此，通常需要您对其进行特殊处理。排查可疑因素并解决标题后，可以在消息队列 RocketMQ 控制台重新发送该消息，让消费者重新消费一次。
消费幂等

消息队列 RocketMQ 消费者在吸取到消息以后，有必要根据业务上的唯一 Key 对消息做幂等处理的必要性。
消费幂等的必要性

在互联网应用中，尤其在网络不稳固的环境下，消息队列 RocketMQ 的消息有大概会出现重复，这个重复简朴可以概括为以下环境：

发送时消息重复
当一条消息已被成功发送到服务端并完成持久化，此时出现了网络闪断或者客户端宕机，导致服务端对客户端应答失败。如果此时生产者意识到消息发送失败并尝试再次发送消息，消费者后续会收到两条内容雷同并且 Message ID 也雷同的消息。
投递时消息重复
消息消费的场景下，消息已投递到消费者并完成业务处理，当客户端给服务端反馈应答的时候网络闪断。为了保证消息至少被消费一次，消息队列 RocketMQ 的服务端将在网络恢复后再次尝试投递之前已被处理过的消息，消费者后续会收到两条内容雷同并且 Message ID 也雷同的消息。
负载平衡时消息重复（包括但不限于网络抖动、Broker 重启以及订阅方应用重启）
当消息队列 RocketMQ 的 Broker 或客户端重启、扩容或缩容时，会触发 Rebalance，此时消费者大概会收到重复消息。

处理方式

因为 Message ID 有大概出现辩说（重复）的环境，以是真正安全的幂等处理，不建议以 Message ID 作为处理依据。最好的方式是以业务唯一标识作为幂等处理的关键依据，而业务的唯一标识可以通过消息 Key 进行设置：

Message message = new Message();
message.setKey("ORDERID_100");
SendResult sendResult = producer.send(message);

复制代码

订阅方收到消息时可以根据消息的 Key 进行幂等处理：

consumer.subscribe("ons_test", "*", new MessageListener() {
public Action consume(Message message, ConsumeContext context) {
String key = message.getKey()
// 根据业务唯一标识的 key 做幂等处理
}
});

复制代码

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

欢迎光临 qidao123.com技术社区-IT企服评测·应用市场 (https://dis.qidao123.com/)