Disruptor高性能之道—开篇&介绍
目录
一、前言
最近在看蚂蚁金服团队的Jraft的时候，无意中发现其中多次使用了一个组件—Disruptor。出于好奇便去百度了一下，看看它到底是个什么鬼。真是不看不知道，一看吓一跳。通过慢慢了解我发现它居然是一个非常牛逼的并发框架。我认为它的牛逼并不仅仅在于它具有的牛逼的并发性能，而是在于它为了达到这么牛逼的性能几乎把咱们平时所说的高并发提升高性能的种种手段都应用到了它的代码实现中，比如：False Sharing，无锁实现(无锁实现高并发资源竞争)，Volatile(内存屏障)，CAS的应用。所以出于对这么优秀的代码实现的敬畏，同时也想通过其实现好好学习下高并发提升的各种手段的实际应用。于是楼主决定去撸撸源码。
所以本系列文章后续章节，我将从各种优化提升手段的应用入手来解析Disruptor是如何做到这么牛逼的性能的。
那么在分享其高逼格实现之前，本片入门文章还是打算对Disruptor做一个基本的扫盲介绍。
本系列文章后续将介绍各自提升手段的应用，并不会介绍Disruptor的详细使用，也不会介绍Disruptor的详细代码实现（这些内容网上太多了，大家自己百度吧）。所以阅读本系列的后续文章内容需要有一定的基础，对Disruptor的使用和基本代码实现需要有一定的了解。
二、什么是Disruptor
Disruptor它是一个开源的并发框架，并获得2011 Duke’s 程序框架创新奖，能够在无锁的情况下实现网络的Queue并发操作（来自于网络）。
我敢保证，很多同学看了这段描述之后仍然一头雾水，不知道Disruptor到底有什么作用。那么让我们先看看如下场景：
我们业务开发的时候常常有这样的需求，我们的代码有一个或者多个生产者，其能够生成很多消息。这些消息需要被机器上的其他消费者（一个或者多个）消费处理（比如业务发布场景，在发布某个业务之后往往需要做一系列后续操作，如：同步三方系统，更新相关业务状态等）。
对这样的业务场景，我想大家都能够提供出具体的解决办法。常规的解决办法就是使用一个BlockingQueue。然后生产者向其中添加消息(offer)，消费者从其中拉取消息来处理（poll）。该方法的流程图如下。
我们暂且不考虑性能的问题，从业务上来说，如果我们需要实现如下业务场景，我们又需要怎么实现呢？
如上业务流程：
-
一条消息要先消费组1消费，消费完成之后再被消费组2消费，消费组2消费完成之后消息再继续被消费组3消费
-
一条消息需要被消费组1中的所有消费者要消费
-
一条消息在消费组2和消费组3中只能够被一个消费者消息
要实现这个业务逻辑，貌似就比较复杂了吧。当然我们动动脑子还是可以自己实现出来的。那么如果自己去实现上述业务有什么问题呢？
首先对BlockingQueue比较了解的同学都知道，其Offer和Poll是通过lock的方式来读写冲突的。大家都应该知道Lock是重量级的操作，在高并发高性能的场景下，肯定是不建议使用的或者极少的使用。由此我们知道自己实现的第一个问题就是性能不佳。
另外一个问题我不说大家都应该知道，自己实现编码太复杂，容易出错。那么这种情况下，我们有没有一种实现简单且能够满足性能的框架可以使用呢？当然有，没错它就是我们今天的主角Disruptor了。它能够在这种生产者-消费者模式下提供优秀的性能（前面已经哔哔过了），其性能能够比BlocingQueue好7-8倍，甚至是1个数量级（10倍+）。具体大家可以去搜一搜网上很多小伙伴已经做过压测实验了。
另外就是Disruptor能够让我们用非常简单的代码就能够实现我们上面列举的第二个业务场景，而且能够保证优良的性能（这一句是废话）。至于通过Disruptor如何实现上述业务场景，大家就自行百度吧。
三、最后
看过上面的介绍之后，没有了解过Disruptor的同学有没有想要去学习了解Disruptor的冲动呢？如果有就赶紧去官网学习了解吧。之前就了解过Disruptor甚至用过的同学有没有想要知道为什么Disruptor性能如此之高呢？如果有那么敬请期待本系列文章后续精彩章节。
如果同学们说没有，那么我只能说”打扰了，告辞！“，哈哈哈哈哈哈。。。
下一篇文章预告《Disruptor高性能之道—False Sharing》，敬请期待！
四、惯例
如果你对本文有任何疑问或者高见，欢迎添加公众号共同交流探讨（添加公众号可以获得”Java高级架构“上10G的视频和图文资料哦）。