目录
一、前言
二、什么是Disruptor
三、最后
四、惯例
一、前言
最近在看蚂蚁金服团队的Jraft的时候，无意中发现其中多次使用了一个组件—Disruptor。出于好奇便去百度了一下，看看它到底是个什么鬼。真是不看不知道，一看吓一跳。通过慢慢了解我发现它居然是一个非常牛逼的并发框架。我认为它的牛逼并不仅仅在于它具有的牛逼的并发性能，而是在于它为了达到这么牛逼的性能几乎把咱们平时所说的高并发提升高性能的种种手段都应用到了它的代码实现中，比如：False Sharing，无锁实现(无锁实现高并发资源竞争)，Volatile(内存屏障)，CAS的应用。所以出于对这么优秀的代码实现的敬畏，同时也想通过其实现好好学习下高并发提升的各种手段的实际应用。于是楼主决定去撸撸源码。
所以本系列文章后续章节，我将从各种优化提升手段的应用入手来解析Disruptor是如何做到这么牛逼的性能的。
那么在分享其高逼格实现之前，本片入门文章还是打算对Disruptor做一个基本的扫盲介绍。
本系列文章后续将介绍各自提升手段的应用，并不会介绍Disruptor的详细使用，也不会介绍Disruptor的详细代码实现（这些内容网上太多了，大家自己百度吧）。所以阅读本系列的后续文章内容需要有一定的基础，对Disruptor的使用和基本代码实现需要有一定的了解。
二、什么是Disruptor
一条消息要先消费组1消费，消费完成之后再被消费组2消费，消费组2消费完成之后消息再继续被消费组3消费
一条消息需要被消费组1中的所有消费者要消费
一条消息在消费组2和消费组3中只能够被一个消费者消息
要实现这个业务逻辑，貌似就比较复杂了吧。当然我们动动脑子还是可以自己实现出来的。那么如果自己去实现上述业务有什么问题呢？
首先对BlockingQueue比较了解的同学都知道，其Offer和Poll是通过lock的方式来读写冲突的。大家都应该知道Lock是重量级的操作，在高并发高性能的场景下，肯定是不建议使用的或者极少的使用。由此我们知道自己实现的第一个问题就是性能不佳。
另外一个问题我不说大家都应该知道，自己实现编码太复杂，容易出错。那么这种情况下，我们有没有一种实现简单且能够满足性能的框架可以使用呢？当然有，没错它就是我们今天的主角Disruptor了。它能够在这种生产者-消费者模式下提供优秀的性能（前面已经哔哔过了），其性能能够比BlocingQueue好7-8倍，甚至是1个数量级（10倍+）。具体大家可以去搜一搜网上很多小伙伴已经做过压测实验了。
另外就是Disruptor能够让我们用非常简单的代码就能够实现我们上面列举的第二个业务场景，而且能够保证优良的性能（这一句是废话）。至于通过Disruptor如何实现上述业务场景，大家就自行百度吧。
三、最后
四、惯例
