队列 阻塞队列 BlockingQueue
在不同的线程之间交换数据

Disruptor 实现了其他队列没有的特性
同一个 事件 可以有多个消费者，消费者之间既可以并行处理，也可以相互依赖形成处理的先后次序(形成一个依赖图) 
预分配用于存储事件的空间
极度优化和无锁的设计 



核心组件

RingBuffer

Sequence  
每个消费者和Disruptor本身都会维护一个Sequence  
注意 防止不同的 Sequence 之间的CPU缓存伪共享(Flase Sharing)问题

Sequence Barrier
保持Sequencer的引用
Consumer是否还有可处理事件的逻辑



Wait Strategy
消费者如何等待生产者将事件（Event）放入Disruptor中

Event

EventProcessor
消费者Sequence + 主事件循环（main event loop） 
BatchEventProcessor 

EventHandler  用户实现的接口，用于处理事件

Producer


事件广播（Multicast Events）
Disruptor和队列最大的区别
对同一数据进行多个并行操作

日志（将数据持久到日志文件中）
复制（将数据发送到其他的机器上，以确保存在数据远程副本）
业务逻辑处理


消费者依赖关系图（Consumer Dependency Graph）
Disruptor提供了多个消费者之间的协作功能
让日志处理和远程副本写入执行完之后再执行业务处理流程，这个功能被称之为gating
gating 两种场景
1 确保生产者不要超过消费者 通过调用RingBuffer.addGatingConsumers()增加相关的消费者至Disruptor来完成
2 通过构造包含必须先完成的消费者的Sequence的SequenceBarrier来实现


有三个消费者监听来自RingBuffer的事件
依赖关系图
ApplicationConsume r依赖 JournalConsumer 和 ReplicationConsumer


事件预分配（Event Preallocation）
减少GC停顿（在低延迟的C/C++系统中，由于内存分配器的争用，大量的内存分配也会导致问题）
事件预分配内存  EventFactory课自定义 
新的数据发布时，更新事件对象  确保操作线程安全


可选择的无锁
无锁算法 内存可见性和正确性使用内存屏障和CAS
仅BlockingWaitStrategy中使用了lock 
仅仅是为了使用Condition 唤醒 park 的消费线程 

许多低延迟系统使用自旋（busy-wait）来避免使用Condition造成的抖动
但是大量的自旋（busy-wait）会导致性能的下降，特别是CPU资源严重受限的情况下
例如虚拟环境中的Web服务器




影响性能的两个参数

wait strategy 和 producer的类型
单生产者 vs 多生产者
如果只有一个线程写数据，可以设置成单生产者来提升性能
Disruptor< LongEvent> disruptor = new Disruptor(factory, bufferSize, DaemonThreadFactory.INSTANCE, ProducerType.SINGLE, new BlockingWaitStrategy());

ProducerType.SINGLE
BlockingWaitStrategy

等待策略
BlockingWaitStrategy
默认策略是BlockingWaitStrategy
使用锁和condition来控制线程的唤醒
最低效的策略，但其对CPU的消耗最小并且在各种不同部署环境中能提供更加一致的性能表现

SleepingWaitStrategy
性能表现跟 BlockingWaitStrategy 差不多，对 CPU 的消耗也类似，
但其对生产者线程的影响最小，通过使用LockSupport.parkNanos(1)来实现循环等待
一般来说Linux系统会暂停一个线程约60µs
平均延迟会高一些   常见场景是异步日志


YieldingWaitStrategy
调用Thread.yield  
可以使用在低延迟系统的策略之一

BusySpinWaitStrategy
性能最好，适合用于低延迟的系统
在要求极高性能且事件处理线程数小于CPU逻辑核心数的场景中
推荐使用此策略 例如 CPU开启超线程的特性



清除Ring Buffer中的对象
可在处理事件后清除事件