以下为官方Disruptor Introduction文档翻译
理解Disruptor 的最好方法就是将其与其他比较好理解且非常相似的东西进行比较。Java 中与Dsiruptor类似的是BlockingQueue。Disruptor 与队列的功能类似，在进程的不同线程之间传递数据（消息、事件等）。但是，Dsiruptor 有一些与队列不同的特点：
- 具有消费者依赖关系图的消费者多播事件
- 为事件预分配内存空间（译者注：内存是提升性能的一大利器，这也是 Disruptor 如此强悍的最大原因之一 ）
- 无锁支持
核心概念
在我们理解Disruptor的工作机制之前，了解一下几个核心术语，这些术语将会出现在文档和代码中。对于熟悉DDD的人而言，这些术语就是Disruptor的域模型。
- RingBuffer：常常被认为是Disruptor的核心概念，但是在3.0以后它只负责数据的存储和数据的更新，在一些高阶场景下完全可以被用户替换掉；
- Sequence：是Disruptor用来识别特定组件所在位置的工具。每个消费者与Disruptor本身一样都维护了一个Sequence。大多数并发操作都依赖Sequence进行，因此Sequence提供了许多与AtomicLong类似的功能。该类较版本2多了一些功能以防止与其他值之间的错误共享。
- Sequencer：Disruptor 真正的核心。它的两个实现类（）包含了所有的并发算法，以实现快速、正确的在生产者和消费者之间传递数据。
- Sequence Barrier：序列屏障由序列发生器产生，并包含对序列发生器中主要发布的序列和所有相关消费者的序列的引用。它的内部逻辑判断是否有可用的event供消费者消费。
- Wait Strategy：用于在没有事件时决定消费者如何等待。更多细节将会在无锁支持章节介绍。
- Event：生产者和消费者之间传递的数据单元。事件没有特定的代码规范，完全有用户决定。
- Event Processer: 处理来自Disruptor的事件，并且拥有消费者Sequence的所有权。有一个名为BatchEventProcessor的类，它包含事件循环的有效实现，并将调用提供的EventHandler接口实现。
- EventHandler: 提供给用户用于消费事件的接口类。
- Producer: 生产者是由用户提供的一段不断往Dsiruptor输送事件的代码，它在Disruptor中也没有特定的代码规范。
为了更好理解上面这些术语，下面提供一个LMAX使用Disruptor用于构建高性能核心服务的例子。
事件多播（Multicast Event）
该特性是队列和Disruptor在行为上最大的不同点。当我们对同一个数据有多次消费时，传统的方式是串行的消费多次，Disruptor 则可以通过多个消费者并行消费，监听同一个Disruptor 的多个消费者回都会收到这条数据，而 BlockingQueue 只会有一个消费者拿到这条数据。LMAX 中的经典例子是日志（持久化日志）、备份（将数据发送到其他机器以保证有一个完整的备份）、业务（真正的业务）同时消费一条数据。执行器风格的事件处理模型也可以通过线程池来同时并行处理不同的事件以达到性能扩展的目的。注意该特性在现有Disruptor之上进行，而且并没有被视为第一等类型，因此它或许不是实现该特定目标最有效的方式（这句话翻译的有点生硬，我并没有理解他是什么意思）。
上图中有三个事件处理器（JournalConsumer, ReplicationConsumer and ApplicationConsumer），每个处理器都会收到Disruptor中所有可用的数据，这样就可以并行处理。
译者注：这种方式另外一个好处是各个子逻辑之间完全解耦，互不影响。
消费依赖图（Consumer Dependency Graph）
为了支持真实应用中的并行处理，有必要进行消费者之间的协调。上面提到的例子中，业务处理器必须在日志处理器和备份处理器之后执行，我们称之为 Gating ，或者更准确的说，这种行为的超集称为 Gating。Gating 发生在两处：1. 确保生产者不会超过消费者，通过调用RingBuffer.addGatingConsumers()方法将消费者添加到Dsruptor；2. 与上述提到的情况类似，通过构建一个SequenceBarrier来引用那些必须在之前完成的组件的Sequence。
上图中有三哥消费者在监听RingBuffer中的事件，其中就有一个消费依赖关系。ApplicationConsumer 依赖于 JournalConsumer 和 ReplicationConsumer。也就是说JournalConsumer 和 ReplicationConsumer可以并行，依赖关系可以通过 ApplicationConsumer的SequenceBarrier得到。值得注意的是Sequencer与下游消费者的关系，它的一个作用是确保事件的发布不会包裹整个RingBuffer（避免还未消费就被下一圈的数据覆盖）。为了做到这一点，任何下游消费者的Sequence 都一定大于Disruptor的Sequence，并且这个差值一定小于RingBuffer的大小。依赖图可以进行更有趣的优化：由于ApplicationConsumer 的Sequence 一定不大于 JournalConsumer 和 ReplicationConsumer，Sequencer 只要检查ApplicationConsumer的Sequence就可以了。一般意义上来说，Sequencer 只需要知道依赖关系图中处于叶子结点的消费者的Sequence即可。
事件内存预分配（Event Preallocate）
Disruptor 的一大目标就是保证低延迟。在低延迟系统中有必要减少或者去除内存的分配。对基于java 的系统而言就是减少由于GC引起的停顿（在C/C++系统中由于存在内存分配器的争用，大量的内存分配也是一个值得注意的问题）。
用户可以在Disruptor中预先分配events需要的内存。Disruptor在构造期间会调用用户提供的EventFactory来为RingBuffer的每个Entry创建对象。当向Disruptor发布新的数据时，API允许用户获取预先分配的对象以便他们可以调用方法或者更新对象的属性。Disruptor 保证只要实现正确这些并发操作就是安全的。
无锁支持（Optional Lock-free）
Disruptor 低延迟的另外一个关键因素是无锁算法的大量使用。所有的内存可见性以及正确性保证是通过使用内存屏障和/或CAS操作。只有一个地方是使用锁的—BlockingWaitStrategy，这完全是为了在等待新事件到达之前使用Condition让消费者线程暂停。许多低延迟系统使用忙等（busy-wait）来避免Condition可能引起的抖动，然而在许多系统中忙等操作会导致明显的性能下降，特别是在CPU资源比较紧张的系统中，例如虚拟化的WEB服务器。
