Disruptor是一个开源框架，研发的初衷是为了解决高并发下队列锁的问题，最先由LMAX提出并使用，可以在无锁的状况下实现队列的并发操做，并号称可以在一个线程里每秒处理6百万笔订单
html
官网：http://lmax-exchange.github.io/disruptor/java
目前，包括Apache Storm、Camel、Log4j2在内的不少知名项目都应用了Disruptor以获取高性能git
为何会产生Disruptor框架
「目前Java内置队列保证线程安全的方式：」github
ArrayBlockingQueue：基于数组形式的队列，经过加锁的方式，来保证多线程状况下数据的安全；web
LinkedBlockingQueue：基于链表形式的队列，也经过加锁的方式，来保证多线程状况下数据的安全；算法
ConcurrentLinkedQueue：基于链表形式的队列，经过CAS的方式编程
咱们知道，在编程过程当中，加锁一般会严重地影响性能，因此尽可能用无锁方式，就产生了Disruptor这种无锁高并发框架数组
基本概念
参考地址：https://github.com/LMAX-Exchange/disruptor/wiki/Introduction#core-concepts缓存
RingBuffer——Disruptor底层数据结构实现，核心类，是线程间交换数据的中转地；安全
Sequencer——序号管理器，生产同步的实现者，负责消费者/生产者各自序号、序号栅栏的管理和协调,Sequencer有单生产者,多生产者两种不一样的模式,里面实现了各类同步的算法；
Sequence——序号，声明一个序号，用于跟踪ringbuffer中任务的变化和消费者的消费状况，disruptor里面大部分的并发代码都是经过对Sequence的值同步修改实现的,而非锁,这是disruptor高性能的一个主要缘由；
SequenceBarrier——序号栅栏，管理和协调生产者的游标序号和各个消费者的序号，确保生产者不会覆盖消费者将来得及处理的消息，确保存在依赖的消费者之间可以按照正确的顺序处理
EventProcessor——事件处理器，监听RingBuffer的事件，并消费可用事件，从RingBuffer读取的事件会交由实际的生产者实现类来消费；它会一直侦听下一个可用的序号，直到该序号对应的事件已经准备好。
EventHandler——业务处理器，是实际消费者的接口，完成具体的业务逻辑实现，第三方实现该接口；表明着消费者。
Producer——生产者接口，第三方线程充当该角色，producer向RingBuffer写入事件。
Wait Strategy：Wait Strategy决定了一个消费者怎么等待生产者将事件（Event）放入Disruptor中。
等待策略
源码地址：https://github.com/LMAX-Exchange/disruptor/blob/master/src/main/java/com/lmax/disruptor/WaitStrategy.java
「BlockingWaitStrategy」
Disruptor的默认策略是BlockingWaitStrategy。在BlockingWaitStrategy内部是使用锁和condition来控制线程的唤醒。BlockingWaitStrategy是最低效的策略，但其对CPU的消耗最小而且在各类不一样部署环境中能提供更加一致的性能表现。
「SleepingWaitStrategy」
SleepingWaitStrategy 的性能表现跟 BlockingWaitStrategy 差很少，对 CPU 的消耗也相似，但其对生产者线程的影响最小，经过使用LockSupport.parkNanos(1)来实现循环等待。
「YieldingWaitStrategy」
YieldingWaitStrategy是可使用在低延迟系统的策略之一。YieldingWaitStrategy将自旋以等待序列增长到适当的值。在循环体内，将调用Thread.yield()以容许其余排队的线程运行。在要求极高性能且事件处理线数小于 CPU 逻辑核心数的场景中，推荐使用此策略；例如，CPU开启超线程的特性。
「BusySpinWaitStrategy」
性能最好，适合用于低延迟的系统。在要求极高性能且事件处理线程数小于CPU逻辑核心数的场景中，推荐使用此策略；例如，CPU开启超线程的特性。
「PhasedBackoffWaitStrategy」
自旋 + yield + 自定义策略，CPU资源紧缺，吞吐量和延迟并不重要的场景。
使用举例
参考地址：https://github.com/LMAX-Exchange/disruptor/wiki/Getting-Started
<dependency>
<groupId>com.lmax</groupId>
<artifactId>disruptor</artifactId>
<version>3.3.4</version>
</dependency>
//定义事件event 经过Disruptor 进行交换的数据类型。
public class LongEvent {
private Long value;
public Long getValue() {
return value;
}
public void setValue(Long value) {
this.value = value;
}
}
public class LongEventFactory implements EventFactory<LongEvent> {
public LongEvent newInstance() {
return new LongEvent();
}
}
//定义事件消费者
public class LongEventHandler implements EventHandler<LongEvent> {
public void onEvent(LongEvent event, long sequence, boolean endOfBatch) throws Exception {
System.out.println("消费者:"+event.getValue());
}
}
//定义生产者
public class LongEventProducer {
public final RingBuffer<LongEvent> ringBuffer;
public LongEventProducer(RingBuffer<LongEvent> ringBuffer) {
this.ringBuffer = ringBuffer;
}
public void onData(ByteBuffer byteBuffer) {
// 1.ringBuffer 事件队列 下一个槽
long sequence = ringBuffer.next();
Long data = null;
try {
//2.取出空的事件队列
LongEvent longEvent = ringBuffer.get(sequence);
data = byteBuffer.getLong(0);
//3.获取事件队列传递的数据
longEvent.setValue(data);
try {
Thread.sleep(10);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
} finally {
System.out.println("生产这准备发送数据");
//4.发布事件
ringBuffer.publish(sequence);
}
}
}
public class DisruptorMain {
public static void main(String[] args) {
// 1.建立一个可缓存的线程 提供线程来出发Consumer 的事件处理
ExecutorService executor = Executors.newCachedThreadPool();
// 2.建立工厂
EventFactory<LongEvent> eventFactory = new LongEventFactory();
// 3.建立ringBuffer 大小
int ringBufferSize = 1024 * 1024; // ringBufferSize大小必定要是2的N次方
// 4.建立Disruptor
Disruptor<LongEvent> disruptor = new Disruptor<LongEvent>(eventFactory, ringBufferSize, executor,
ProducerType.SINGLE, new YieldingWaitStrategy());
// 5.链接消费端方法
disruptor.handleEventsWith(new LongEventHandler());
// 6.启动
disruptor.start();
// 7.建立RingBuffer容器
RingBuffer<LongEvent> ringBuffer = disruptor.getRingBuffer();
// 8.建立生产者
LongEventProducer producer = new LongEventProducer(ringBuffer);
// 9.指定缓冲区大小
ByteBuffer byteBuffer = ByteBuffer.allocate(8);
for (int i = 1; i <= 100; i++) {
byteBuffer.putLong(0, i);
producer.onData(byteBuffer);
}
//10.关闭disruptor和executor
disruptor.shutdown();
executor.shutdown();
}
}
核心设计原理
Disruptor经过如下设计来解决队列速度慢的问题：
「环形数组结构：」
为了不垃圾回收，采用数组而非链表。同时，数组对处理器的缓存机制更加友好
❝缘由：CPU缓存是由不少个缓存行组成的。每一个缓存行一般是64字节，而且它有效地引用主内存中的一起地址。一个Java的long类型变量是8字节，所以在一个缓存行中能够存8个long类型的变量。CPU每次从主存中拉取数据时，会把相邻的数据也存入同一个缓存行。在访问一个long数组的时候，若是数组中的一个值被加载到缓存中，它会自动加载另外7个。所以你能很是快的遍历这个数组。
❞
「元素位置定位：」
数组长度2^n，经过位运算，加快定位的速度。下标采起递增的形式。不用担忧index溢出的问题。index是long类型，即便100万QPS的处理速度，也须要30万年才能用完。
「无锁设计：」
每一个生产者或者消费者线程，会先申请能够操做的元素在数组中的位置，申请到以后，直接在该位置写入或者读取数据，整个过程经过原子变量CAS，保证操做的线程安全
数据结构
框架使用RingBuffer来做为队列的数据结构，RingBuffer就是一个可自定义大小的环形数组。
除数组外还有一个序列号(sequence)，用以指向下一个可用的元素，供生产者与消费者使用。
原理图以下所示：
Sequence
mark：Disruptor经过顺序递增的序号来编号管理经过其进行交换的数据（事件），对数据(事件)的处理过程老是沿着序号逐个递增处理。
「数组+序列号设计的优点是什么呢？」
回顾一下HashMap，在知道索引(index)下标的状况下，存与取数组上的元素时间复杂度只有O(1)，而这个index咱们能够经过序列号与数组的长度取模来计算得出，index=sequence % table.length。固然也能够用位运算来计算效率更高，此时table.length必须是2的幂次方。
写数据流程
单线程写数据的流程：
-
申请写入m个元素； -
如果有m个元素能够入，则返回最大的序列号。这儿主要判断是否会覆盖未读的元素； -
如果返回的正确，则生产者开始写入元素。
使用场景
通过测试，Disruptor的的延时和吞吐量都比ArrayBlockingQueue优秀不少，因此，当你在使用ArrayBlockingQueue出现性能瓶颈的时候，你就能够考虑采用Disruptor的代替。
参考：https://github.com/LMAX-Exchange/disruptor/wiki/Performance-Results
固然，Disruptor性能高并非必然的，因此，是否使用还得通过测试。
Disruptor的最经常使用的场景就是“生产者-消费者”场景，对场景的就是“一个生产者、多个消费者”的场景，而且要求顺序处理。
举个例子，咱们从MySQL的BigLog文件中顺序读取数据，而后写入到ElasticSearch（搜索引擎）中。在这种场景下，BigLog要求一个文件一个生产者，那个是一个生产者。而写入到ElasticSearch，则严格要求顺序，不然会出现问题，因此一般意义上的多消费者线程没法解决该问题，若是经过加锁，则性能大打折扣
参考：
https://tech.meituan.com/2016/11/18/disruptor.html
https://github.com/LMAX-Exchange/disruptor/wiki
扫描二维码
获取更多精彩
月伴飞鱼
本文分享自微信公众号 - 月伴飞鱼（gh_c4183eee9eb9）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。