本文主要是介绍记一次Disruptor排坑，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
Abstract
我们在项目中使用了Disruptor作为事件总线，实现的业务是：用户消费完成成就，完成八个成就之后自动获得第九个成就——获得前面八个成就。
这个项目不是我参与的，当时我自己封装的高性能事件总线（Electrons）已经完全能胜任上述功能，但是由于小伙伴当时对我的这个组件没有特别研究，仍然感觉我的这个就是顺序执行前面几个监听器，就没有用。
这个项目在测试环境中一直没有问题，原因我分析一下有下：
- 并发量太小，
RingBuffer的队列的size太小都完全足够。 - 测试环境中代码不稳定，经常重启服务器，导致有些问题被我们的重启掩盖掉了。
问题出现
这个项目中我们一共遇见几次问题。下面我会给大家一一讲解排查、解决的方案。
第一个问题
第一个问题就很好解决，我们通过日志发现有一个RingBuffer满了，这个解决方法也很简单，我们直接把RingBuffer的size扩大四倍，就不再出现这个问题了。
并且通过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！！
在我们的监控上来看，就比较类似图中点所示的，事件都不再消费了，那么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超时之类的。排查一顿无果。
这个时候没办法，用狼人杀的话来说，这是个生推局，要么我们搞一个压测环境，大量并发模拟当时的场景。要么就能生看。这个时候其实就比较晚了，又重新看了一下消费者的循环，看见一注解，之前在maven的source里没有看到，在源码里看到了：
| 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。这也是需要注意的点，希望大家以后少踩坑！
这篇关于记一次Disruptor排坑的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
