转载

视频访谈：封仲淹：如何优雅地使用Disruptor

封仲淹： Disruptor是谷歌后来开源的分布式高性能的队列，这个队列是非常赞的队列，它的性能非常高。我们做过性能测试，它比BlockingQueue、ConcurrentQueue要快一个数量级，它的核心原理是对cache有高速的亲和性，在内存有很好的防止GC。还有一个更重要的特性，它在锁这块控制的非常细。像BlockingQueue、ConcurrentQueue它们在头尾上有一个锁，这个锁的粒度远远高于Disruptor，Disruptor彻底利用了CPU里面的指令级的锁，所以它在锁这块非常的高效，这就是为什么Disruptor的性能比BlockingQueue、ConcurrentQueue高一个数量级的核心的原理。在社区上我知道很多人已经开始使用Disruptor queue，它已经发展到三了，是非常不错的。但是Disruptor我们在二的时候出现过一个问题，它会有一个CPU空转的问题。当时我们自己写了一段代码绕过去，但是这段代码其实可以contribute到社区让他们去改进。至于为什么当初选Disruptor，最重要的原因是storm用了Disruptor，我们也就跟进了。但是我们做了一些自己的分析跟性能测试，Disruptor确实是非常赞的高并发队列。

封仲淹： 我个人的观点，就看你对性能的要求有多高。如果你要达到极致的性能，对延迟要求非常低，而且对高并发要求性能非常高的时候，你肯定要选择Disruptor。但是从易用性上来讲，Disruptor使用起来并没有传统的queue使用上更方便。你在百万级别并发的时候，我推荐大家使用Java的ConcurrentQueue跟BlockingQueue。但是如果你需要更低的延迟的话，我推荐用Disruptor。

3. 目前Disruptor社区发展怎么样？

封仲淹： 社区发展的很好，坦白来讲Disruptor社区我也不是非常熟悉，因为这块我主要站在使用者的角度，并不是开发者的角度。

封仲淹： 像我们JStorm的流水线这是一个典型的场景。如果站在更高的角度和业务场景，比如说像风控或者是交易系统这种要求延迟非常低的环境里面，肯定是需要Disruptor的。回到核心的本质，就是说你要高性能以及低延迟的情况下，你还是选择Disruptor。

5. 它的优势就在于性能特别高。

封仲淹： 对，它就是为了高性能所做的一款。

封仲淹： 对，二的时候，最新版的是OK了，但是老版还有这个问题。

9. 除了这个之外，还有别的吗？

封仲淹： 除了这个之外没有别的，最新版和多队列消费都还不错的。

10. 你有哪些使用的建议给其他人吗？

封仲淹： 我对Disruptor的建议，其实它就是一个队列，用起来我们觉得也挺简单的，不是很复杂，可能我们用的比较熟。

11. 您刚才提到易用性方面不是很好，您能说一说吗？

封仲淹： 易用性方面确实不如普通的ConcurrentQueue，消费的方式跟原来的ConcurrentQueue、BlockingQueue还是有区别的。ConcurrentQueue就是一个put一个get，这种思想就是队列头插或者是队列尾插，get的话要么从队列头get，要么从队列尾get。但是它不是这样的，push是一样的，但是你在消费的时候，它的消费的API稍微复杂一点，不如BlockingQueue、ConcurrentQueue这么简单直接。

12. 就是在整个架构的健壮性方面storm还是比较好的。

封仲淹： 因为它比较老，而且已经比较成熟了。

InfoQ： 谢谢您，我的采访就这些。

13. 那关于JStorm您还有什么要跟大家介绍的吗？

封仲淹： 如果大家使用Storm的话，我觉得大家可以用JStorm试一下，JStorm它在整个监控稳定性，以及性能上都是远远超过Storm的。而且我们国内社区做的还不错，基本上现在来说，京东每个月会给我们contribute一个patch，携程每个月也会给我们contribute至少一个issue或者一个patch。整个社区每天的提问至少会超过一百多条，还是非常活跃的。Storm还是整个业界在流式计算这块非常稳定的，因为它比较老，现在新的架构像spark streaming，samza，flink，这些新的架构是非常出色的，但是暂时来讲storm可能还是适合很多场景的。

原文 http://www.infoq.com/cn/interviews/interview-with-fengzhongyan-talk-disruptor

正文到此结束