RocketMQ快速失败机制引发集群不稳定的思考和优化

搜狐技术产品小编2023

于 2023-02-09 07:30:15 发布

阅读量576

点赞数

文章标签： java-rocketmq rocketmq java 大数据分布式

本文链接：https://blog.csdn.net/SOHU_TECH/article/details/128962986

版权

本文字数：4844字

预计阅读时间：15 分钟

一、RocketMQ快速失败机制案例

1.RocketMQ快速失败机制是什么?

RocketMQ的快速失败机制是当broker处理请求过慢时，为了防止客户端请求在broker端堆积，造成broker不能响应，而采取的剔除部分超时客户端请求的机制，其本质是RocketMQ为了保护broker而采取的限流策略。

2. RocketMQ快速失败机制引发的问题

某天突然收到多个topic消息生产失败的邮件预警，涉及到整个集群，预警邮件如下：

随即查看了生产端的日志，发现了如下异常栈：

日志中的[TIMEOUT_CLEAN_QUEUE]broker busy说明broker压力过大，触发了快速失败机制。

紧急处理措施：由于默认的快速失败机制的阈值为200ms，即发送消息请求若200ms内还未被处理，则直接剔除该请求，故先把阈值调整为2000ms，暂时保障集群正常处理请求。

3.问题调查

broker流量调查
查看出现问题的broker的消息写入量，发现了问题：
从上图可以看出，消息写入量从之前的平均3万/分钟暴涨到了22.54万/分钟，流量瞬间暴涨了近8倍。这个写入量虽然出现暴涨，但是对于broker来说抗这点量应该不是问题，随即调查了问题机器的负载情况，如下图：
从上图可以看出来，机器5分钟负载已经达到了10.32，而此机器配置较低，仅为4核，而集群中其他broker的流量同样较高，但是load却低于1。
流量暴涨的topic
现在需要调查到底是哪个topic发送消息量暴涨，引起了这个问题。
经过调查broker端的stats.log，发现了如下异常日志：
```
2022-02-08 15:40:00 INFO - [TOPIC_PUT_NUMS] [%RETRY%get-pugc-to-ai-consumer] Stats In One Minute, SUM: 47119 TPS: 785.32 AVGPT: 1.00
```
即get-pugc-to-ai-consumer的重试topic出现了大量消息写入，%RETRY%是RocketMQ为每个消费者创建的重试topic，而RocketMQ会把消费失败的消息重新发送到这个重试topic中，以便消费者能够重新消费。
重试消息暴涨的原因
经过调查业务端get-pugc-to-ai-consumer的消费代码发现，消费端使用的语言是Python，由于业务端对RocketMQ-Python不熟悉，编码不规范，导致消费消息后没有返回ACK标识，致使RocketMQ认为消费失败了，从而导致将所有消费过的消息都重新发送到了重试topic中：
```
def callback(msg):
    print(msg.id, msg.body)
    return ConsumeStatus.CONSUME_SUCCESS // 此ACK语句丢失
```

4.问题结论

该问题实际上是由于编码不规范，导致大量消息重发到broker，而突增的流量导致配置较低的broker负载过高，触发了快速失败机制，而快速失败机制是不区分topic的，从而造成了其他topic消息发送失败。

二、RocketMQ快速失败机制的思考

这里以本次消息发送失败事件为参考，看一下快速失败机制原理，下面是broker通信层的线程模型：

broker通信层采用netty实现，而netty作为异步的、事件驱动的网络框架，在broker中其线程模型如上图所示：

Boss线程：用于处理accept事件，建立连接，注册channel到woker的selector中。
Woker线程：用于处理读写IO事件，并转交给后的handler处理。
handler通用处理线程：broker用于实现tls握手，编解码，channel事件监听分发，处理请求响应等。
broker业务线程：用于各种功能实现，比如消息写入请求处理，消息拉取请求处理等等。

而broker的快速失败机制正是在broker业务线程的SendMessageThread中实现的，该机制会检测线程的ThreadPoolExecutor的阻塞队列，即当阻塞队列的请求在队列中停留时间超过200ms还未被处理，将会被移除掉。

broker的快速失败机制，本意为保护broker，即防止在broker存储过慢或负载过高时，大量请求堆积，导致broker崩溃。

此机制的目的虽然没有错，但是其保护粒度显然有些过于粗糙。

针对本案例，由于某一个消费者大量发送重试消息，导致其他topic的写消息请求别拒绝，显然有些不合理。

三、RocketMQ快速失败机制的优化方案

针对本案例，可以采取如下两种方案进行优化：

采用单独的线程池来处理重试消息发送请求，即跟正常topic写消息请求的线程池隔离开，防止重试消息影响正常消息。
针对ip或topic采取限流策略，防止某个ip或topic大量写消息请求影响其他topic。

第一种方案的优劣：

优点：实现简单，可以保障重试消息不影响正常的消息发送。
缺点：
- 该方案不通用，只适用于重试消息与普通消息。
- 突然暴增的重试消息流量依然会影响其他消费者发送重试消息。

第二种方案的优劣：

优点：以ip或topic为维度，实行细粒度的控制，可以很好的防止某个ip或topic的流量影响整个集群。
缺点：需要单独开发，以及远程实时控制ip或topic级别的限流。

很明显，使用第二种方案更优一些。

那么，限流资源该如何选取呢？

ip，针对ip和端口进行限流
- 优点：可以防止某个ip的写请求量暴增。
- 缺点：若业务存在发送消息到多个topic的情况，可能存在误伤。
topic（重试消息可以针对consumerGroup）
- 优点：多个客户端往一个topic发送消息依然可以触发限流。
- 缺点：限流的阈值不好确定。

显然，针对topic限流更符合业务端的情况，所以采用topic维度的限流更合适。

综上：由于一个业务往往使用的topic不是很多，而RocketMQ集群可以支撑上万个topic，所以一个RocketMQ集群通常是为多个业务提供支撑，所以采用topic维度的限流的策略更适用于这个场景。

四、RocketMQ Topic维度限流的实现

1.在哪里进行限流？

结合上面提到的broker通信层的线程模型, 如果要采取限流，就需要在3.handler通用处理线程层来做，因为不能让消息写入事件传播到broker业务线程的SendMessageThread中，否则依然可能会触发快速失败机制。

针对netty的处理器链模式，在broker的handler通用处理线程增加前置处理器，专门针对写请求进行限流，当写请求触发限流时，直接返回响应，不再让事件往后传播，采取限流的位置如下图所示：

如上图所示，在broker的handler通用处理管道中，处理完通用的事件后，比如tls握手，编解码等，增加限流处理器即可。

2.限流处理器注意事项

第一点：限流处理器运行于netty的ChannelPipeline中，需要采用单独的线程池，不能共用broker的handler通用处理线程来处理，防止限流处理器影响handler通用处理线程的业务。

第二点：如若因为限流逻辑或性能等问题导致限流异常，直接跳过限流策略，执行后续的handler，防止影响正常请求。

第三点：限流器采用本地限流，限流阈值支持实时修改生效。

针对上面三点注意事项，首先是限流处理器在通信层所处的位置设计。

3.限流处理器线程池详细设计

首先，需要看一下broker(netty)的请求响应线程模型：

netty4的链接建立后，channel的事件都是单线程处理的，整体上是并行的。

broker端针对通用handler管道设置了单独的线程池，即DefaultEventExecutorGroup，默认8个线程。

限流处理器不可以使用DefaultEventExecutorGroup，防止对通用的事件处理有影响，所以针对限流处理器采用单独的线程池，如下：

其次，针对限流处理器的线程池，需要单独定制拒绝策略。

由于netty重新实现了jdk的Executor，它的线程池的阻塞队列为每个线程单独所有，即任务来了先往阻塞队列放，如果线程阻塞，可能会影响channel读写，故针对限流处理器的线程池需要单独定制拒绝策略，当任务被拒绝时，直接执行task，如下：

如上图，即如果限流处理器的线程池繁忙而拒绝执行任务，则直接跳过限流处理器，而不影响事件的传播。拒绝策略代码如下：

public void rejected(Runnable task, SingleThreadEventExecutor executor) {
    log.error("RateLimitHandler reject task, {} pendingTasks:{}", getThreadName(executor),
            executor.pendingTasks());
    task.run(); // 直接在拒绝策略中执行任务
}

然后，在task中判断是否是当前线程，如果不是当前线程，则是当前任务队列满了，直接通知下一个handler：

protected void channelRead0(ChannelHandlerContext ctx, RemotingCommand cmd) throws Exception {
    // 非当前线程池直接触发下一个事件
    if (!ctx.executor().inEventLoop()) {
        ctx.fireChannelRead(cmd);
        return;
    }
}

这样，即使限流处理器线程池出现问题而无法执行任务时，也会将事件传播到下一个处理器，不影响broker后续的事件流程。

4.限流处理器之限速器的选择

限流处理器的核心就是限速。而目前流行的限速策略有如下几种：

计数器：java的Semaphore计数来限制并发。
漏桶或令牌桶算法：guava限速器。
滑动窗口限速：sentinel、hystrix等集限速，熔断降级等功能于一体的开源组件。

既然限速器的优秀实现有很多，这里就没有必要再造轮子了，选择合适的就行。

到底什么样的限速器更适用于这种场景呢？

首先，由于broker topic + 重试topic较多，单个broker支持上万个topic，所以以topic为维度进行限速时尽量不用sentinel或hystrix的限速器，因为其针对每个topic采用滑窗机制，消耗内存较大。

其次，采用Semaphore来限制并发的话，其需要在请求执行完毕时release，在netty的事件机制中到处传播Semaphore不太靠谱，并且channel可能关闭等，若不能保障正确释放Semaphore，可能造成限速错误。

最后，采用guava的限速器，理由：设计的轻量，精巧，其内部虽然有锁，经过测试单线程qps可达千万，8线程qps达800万，满足性能要求。

但是，这里还有一个问题，guava的限速器并不完全满足topic维度限速的需求。

这里需要先看一下guava限速器的原理：

如上图所示，guava限速器实现主要分为两个部分：

令牌的计算流程
用户请求令牌时，如果当前时间大于下次可请求时间，说明限速器比较空闲，需要将时间差值转换为令牌放入令牌桶。由于限速器的qps是初始化时设置的，故根据时间差可以很容易计算出空闲令牌
令牌的获取流程
如果能够获取到令牌，那么直接返回。关键是流程④，需要根据获取的令牌量计算出需要等待的时间，加到下次可请求时间上。

这里不能满足topic维度限速的需求是由于如下两个问题：

在流程③获取不到令牌时，进行sleep
而broker流控时，希望获取不到令牌时，马上返回，通知客户端已经超过流控阈值，而不是卡主流程。
获取不到令牌时，下次可请求时间可能增加到很大，影响后续请求
举个例子，比如qps限制为1，当请求量为10时，只能通过一个，下次可请求时间会在当前时间基础上加9秒，后续9秒内的请求都被流控了。

5.限流处理器之限速器的改造

针对guava限速器存在的两个问题，进行如下的改造优化：

流程③获取不到令牌时，进行sleep
针对这点，移除sleep代码，直接执行后续逻辑
获取不到令牌时，下次可请求时间可能增加到很大，影响后续请求
针对这个问题，本质原因是guava的限速器不满足broker限流需求。
broker限流需求是当某个topic被限流后，应该处于熔断状态，在熔断状态期间，请求都会直接返回，不被放行。但是熔断期过后，需要自动放开，不能因为某一次大量请求，影响后续请求
故增加熔断层，即当guava限速器无法获取令牌时，触发熔断，不再增加下次可请求时间，并且当检测到超过熔断时间阈值时，再关闭熔断，改造如下：
如上图所示，当限速器触发限速时，会自动熔断，所有的请求直接返回。当熔断超过阈值（默认1秒），自动关闭熔断，继续执行正常的限速流程。

部分限速器改造代码如下：

/**
 * 令牌桶限速器-改造自guava
 * 增加熔断机制，超阈值自动熔断ns后恢复
 */
public class TokenBucketRateLimiter {
    /**
     * 获取令牌
     */
    public boolean acquire(int permits) {
        synchronized (this) {
            // 获取启动以来的时间
            long nowMicros = readMicros();
            // 熔断器打开
            if (circuitBreakerOpen) {
                // 当前时间超过可以预支的时间阈值后，流量放开
                if (nowMicros - nextFreeTicketMicros >= circuitBreakerOpenTimeInMicros) {
                    circuitBreakerOpen = false;
                }
            }
            // 熔断器未打开
            if (!circuitBreakerOpen) {
                // 获取需要等待的时间
                lastNeedWaitMicrosecs = reserveAndGetWaitLength(permits, nowMicros);
                // 需要等待证明熔断器打开
                if (lastNeedWaitMicrosecs > 0) {
                    circuitBreakerOpen = true;
                    // 记录限流时间戳
                    lastRateLimitTimestamp = System.currentTimeMillis();
                }
            }
            // 熔断器未打开，则可以获取令牌
            return !circuitBreakerOpen;
        }
    }
}

限流处理器部分代码如下：

/**
 * 限流处理器
 */
@ChannelHandler.Sharable
public class RateLimitHandler extends SimpleChannelInboundHandler<RemotingCommand> {

    // 限流器map
    private ConcurrentMap<String, TokenBucketRateLimiter> rateLimiterMap = new ConcurrentHashMap<>();
    
    // 是否禁用
    private volatile boolean disabled;

    // 限流器处理线程池
    private EventExecutorGroup rateLimitEventExecutorGroup;

    @Override
    protected void channelRead0(ChannelHandlerContext ctx, RemotingCommand cmd) throws Exception {
        // 非当前线程池直接触发下一个事件
        if (!ctx.executor().inEventLoop()) {
            ctx.fireChannelRead(cmd);
            return;
        }
        if (disabled || cmd == null || cmd.getType() != RemotingCommandType.REQUEST_COMMAND) {
            ctx.fireChannelRead(cmd);
            return;
        }
        // 获取限流资源
        String resource = getResource(cmd);
        if (resource == null) {
            ctx.fireChannelRead(cmd);
            return;
        }
        // 限流流量
        double limitQps = defaultLimitQps;
        if (cmd.getCode() == RequestCode.CONSUMER_SEND_MSG_BACK) {
            limitQps = sendMsgBackLimitQps;
        }
        final double finalLimitQps = limitQps;
        // 获取或创建限流器
        TokenBucketRateLimiter rateLimiter = rateLimiterMap.computeIfAbsent(resource, k -> new TokenBucketRateLimiter(finalLimitQps));
        boolean acquired = rateLimiter.acquire();
        // 不需要限流
        if (acquired) {
            ctx.fireChannelRead(cmd);
            return;
        }
        // 需要限流
  RemotingCommand response = RemotingCommand.createResponseCommand(RemotingSysResponseCode.SYSTEM_BUSY, "RateLimit");
  response.setOpaque(cmd.getOpaque());
  ctx.writeAndFlush(response);
    }
}

6.限流处理器之远程访问

限流处理器需要具备远程实时修改和访问的功能，以便能够根据某个topic的流量进行调整，避免重启broker。

通过扩展RocketMQ的通信协议，支持限流处理器的属性获取和修改，实现了在web端进行实时查看和修改，如下图所示：

五、总结

Broker的快速失败机制本质是为了保护broker，而进行的整体性限流，然而该限流机制的粒度显然过于粗糙。

因为通常情况下，broker是多个业务共用的，不能因为某个业务流量的突增而影响整体的可用性，所以，应该以更为精细的粒度来进行限流保护。

通过在broker的通信层增加额外的限流处理器，进行topic维度的限流保护，并针对限流处理器的线程池制定合适的拒绝策略，保障该限流处理器即使无法执行时，也会将事件传播到下一个处理器，不影响整体事件流程。

另外，改造guava的限速器，支持熔断及实时响应，以满足broker限流的需求，从而避免了某个topic流量过大对其他topic的影响，提升了整体集群的稳定性。

六、参考文献

RocketMQ开发指南 https://github.com/apache/rocketmq/tree/develop/docs/cn
guava限流原理 https://zhuanlan.zhihu.com/p/60979444

搜狐技术产品小编2023

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
RocketMQ快速失败机制引发集群不稳定的思考和优化

本文字数：4844字预计阅读时间：15 分钟一、RocketMQ快速失败机制案例1.RocketMQ快速失败机制是什么?RocketMQ的快速失败机制是当broker处理请求过慢时，为了防止客户端请求在broker端堆积，造成broker不能响应，而采取的剔除部分超时客户端请求的机制，其本质是RocketMQ为了保护broker而采取的限流策略。2. RocketMQ快速失败机制引发的问题某天突...
复制链接

扫一扫