记一次Disruptor排坑

记一次Disruptor排坑


Abstract

我们在项目中使用了Disruptor作为事件总线,实现的业务是:用户消费完成成就,完成八个成就之后自动获得第九个成就——获得前面八个成就。

这个项目不是我参与的,当时我自己封装的高性能事件总线(Electrons)已经完全能胜任上述功能,但是由于小伙伴当时对我的这个组件没有特别研究,仍然感觉我的这个就是顺序执行前面几个监听器,就没有用。

这个项目在测试环境中一直没有问题,原因我分析一下有下:

  1. 并发量太小,RingBuffer的队列的size太小都完全足够。
  2. 测试环境中代码不稳定,经常重启服务器,导致有些问题被我们的重启掩盖掉了。

问题出现

这个项目中我们一共遇见几次问题。下面我会给大家一一讲解排查、解决的方案。

第一个问题

第一个问题就很好解决,我们通过日志发现有一个RingBuffer满了,这个解决方法也很简单,我们直接把RingBuffersize扩大四倍,就不再出现这个问题了。

并且通过RingBuffer的剩余空间和总空间大小做对比,如果剩余空间低于一个阈值,我们就日志记录一下。

第二个问题

第二个问题是Disruptor的等待策略的使用上,我们也犯了一个错误(其实是我出的问题,我作为组内对Disrupto最熟悉的开发人员,这些问题都是我排查的)。之前说我们的CPU Load特别高,而我们使用的Block的的等待策略,按常识来说,这种等待策略会在并发量非常大的时候表现Load非常高,但是量小的时候就会非常低(这个其实也是第三个问题导致的,其实根本不是等待策略使用的有问题)。我当时建议使用了Thread Yield的等待策略,这是一个在性能和CPU Load上比较折中的方案。

紧急上线之后,GG!我们是餐饮行业,那么流量暴增的事件段就比较集中,都在吃饭时间,4.30-8.00这个时间段流量暴增,其他时间就比较低。这就导致我们空闲时间的时候,由于队列中根本没有事件,那么大家都在等待,不停地让出线程,虽然Disruptor内部会park一下,但是只有1纳秒,跑到最后跟执行while true一样,四核机器上Load暴增到10。

我之前也说了,导致这个问题的原因其实是第三个问题,但是我们当时还是回滚到Lock策略,Load暴跌到0.75,回到一个非常正常的值。

第三个问题

第三个问题就非常牛逼了,我们在有一天日志看到了一条SQL异常,然后在这个时间点之后,我们的有一个消费者就不再消费事件了!!MMP!!

Alt text

在我们的监控上来看,就比较类似图中点所示的,事件都不再消费了,那么RingBuffer作为环形队列,很明显就会满掉,出现问题是在高峰期,没法发布、重启,我们处于瞪眼的状态。

小伙伴第一反应是:Disruptor有问题!Disruptor处理异常之后竟然没有继续移动Cursor,我的第一反应是:不可能,作为一个目前JAVA世界里,能抗住秒级百万订单事件的总线,我们这点并发根本不足道。

不足道归不足道,解决还得解决啊!

我心里说不可能,行动上还是还诚实的第一时间翻了一下Disruptor的源码,我之前看过最少两遍,但是这个东西过于强悍,导致我看了很多遍,也只是明白了Disruptor高性能的关键,细节还不到位。

在这之前,我们dump了一下线程,发现一直在执行一段代码:

1
2
3
4
while ((availableSequence = dependentSequence.get()) < sequence)
{
barrier.checkAlert();
}

这段代码有知道的都知道,这是在等待某个消费者依赖的消费者的Cursor,那么我们直接可以知道,这是消费出了问题,依赖的消费者没有继续移动Cursor

直接跑到消费者部分,消费者是个while true,循环到天荒地老,取出一个事件,就用onEvent处理掉,而且最重要的是,onEvent是被catch住的,即使抛出异常,也不会导致消费者的游标停止!而且,我们能在日志中看到记录的异常,说明这个异常已经被捕获到了,并且处理了,那么消费者是怎么停止的呢。

这个时候我走了歪路,怀疑到MYSQL上,怀疑是insert超时之类的。排查一顿无果。

这个时候没办法,用狼人杀的话来说,这是个生推局,要么我们搞一个压测环境,大量并发模拟当时的场景。要么就能生看。这个时候其实就比较晚了,又重新看了一下消费者的循环,看见一注解,之前在mavensource里没有看到,在源码里看到了:

1
2
3
4
5
6
catch (final Throwable ex)
{
// handle, mark as processed, unless the exception handler threw an exception
exceptionHandler.handleEventException(ex, nextSequence, event);
processedSequence = true;
}

注意那句注释!问题就出在这!注释下面的代码我们很容易看懂,就是用exceptionHandler处理了一下处理事件时抛出的异常,然后重新设置一下标志位,让Cursor继续移动,上面那句注释大意就是如果异常处理器中抛出异常,那么标志位将不会被设置

这是我之前没有注意到的地方!如果异常处理器处理异常也出现异常了,那么整个while true当然就崩溃了,Cursor也不会继续移动,导致整个环崩溃掉!

赶紧看了一下我们的异常处理器,果然是会在处理异常时出问题的!

后记

其实Disruptor的细节很多,比如初始化线程池的大小就很有讲究(最新版的Disruptor已经推荐使用自己的线程池,而是推荐使用ThreadFactory作为参数构建)。之前的Disruptor在关闭时,不会关闭Executor,这也是一个细节。包括等待策略的使用场景,队列大小的把控。

以前我主管跟我说,出问题先想想自己的问题!这句话在今后我写代码甚至人生中都给我帮助良多。

其实我们可以只要在处理异常的外面在catch一下就可以了。还有,Disruptor作为目前性能最强大的事件总线,真的能够让你的系统飞起来,但是也存在一些问题,其中之一就是不适合处理需要等待的业务,会导致整个环阻塞,如果设置了前后执行的消费者,会导致后面的也阻塞,然后一直这么阻塞下去,某个时间点,可能所有的资源都在跑while true。这也是需要注意的点,希望大家以后少踩坑!