disruptor 为什么快_disruptor_disrupter

Disruptor是一个开源的Java框架，它被设计用于在生产者—消费者（producer-consumer problem，简称）问题上获得尽量高的吞吐量（TPS）和尽量低的延迟。Disruptor是LMAX交易平台的关键组成部分，LMAX平台使用该框架对订单处理速度能达到600万TPS，除金融领域之外，其他一般的应用中都可以用到Disruptor，它可以带来显著的性能提升。其实Disruptor与其说是一个框架，不如说是一种设计思路，这个设计思路对于存在“并发、缓冲区、生产者—消费者模型、事务处理”这些元素的程序来说，Disruptor提出了一种大幅提升性能（TPS）的方案。

现在有很写过关于Disruptor文章，但是我还是想写这篇浅析，毕竟不同人的理解是不同的，希望没接触过它的人能通过本文对Disruptor有个初步的了解，本文后面给出了一些相关链接供参考。

2、什么是Disruptor？为什么速度更快？

简单的说，Disruptor是一个高性能的Buffer，并提供了使用这个Buffer的框架。为什么说是它性能更好呢？这得从和传统解决办法的缺点开始说起。

我们知道，又称Bounded-Buffer问题，其核心就是保证对一个Buffer的存取操作在多线程环境下不会出错。使用Java中的ArrayBlockingQueue和LinkedBlockingQueue类能轻松的完成模型，这对于一般程序已经没问题了，但是对于并发度高、TPS要求较大的系统则不然。

*BlockingQueue使用的是packagejava.util.concurrent.locks中实现的锁，当多个线程（例如生产者）同时写入Queue时，锁的争抢会导致只有一个生产者可以执行，其他线程都中断了，也就是线程的状态从RUNNING切换到BLOCKED，直到某个生产者线程使用完Buffer后释放锁，其他线程状态才从BLOCKED切换到RUNNABLE，然后时间片到其他线程后再进行锁的争抢。上述过程中，一般来说生产者存放一个数据到Buffer中所需时间是非常短的，操作系统切换线程上下文的速度也是非常快的，但是当线程数量增多后，OS切换线程所带来的开销逐渐增多，锁的反复申请和释放成为性能瓶颈。*BlockingQueue除了使用锁带来的性能损失外，还可能因为线程争抢的顺序问题造成性能再次损失：实际使用中发现线程的调度顺序并不理想，可能出现短时间内OS频繁调度出生产者或消费者的情况，这样造成缓冲区可能短时间内被填满或被清空的极端情况。（理想情况应该是缓冲区长度适中，生产和消费速度基本一致）

对于上面的问题Disruptor的解决方案是：不用锁。

Disruptor使用一个Ring Buffer存放生产者的“产品”，环形缓冲区实际上还是一段连续内存，之所以称作环形是因为它对数据存放位置的处理，生产者和消费者各有一个指针（数组下标），消费者的指针指向下一个要读取的Slot，生产者指针指向下一个要放入的Slot，消费或生产后，各自的指针值p = (p +1) % n，n是缓冲区长度，这样指针在缓冲区上反复游走，故可以将缓冲区看成环状。（如右图）（Ring Buffer并非Disruptor原创，Linux内核中就有环形缓冲区的实现。）使用Ring Buffer时：

①当生产者和消费者都只有一个时，由于两个线程分别操作不同的指针，所以不需要锁。

②当有多个消费者时，（按Disruptor的设计）每个消费者各自控制自己的指针，依次读取每个Slot（也就是每个消费者都会读取到所有的产品），这时只需要保证生产者指针不会超过最慢的消费者（超过最后一个消费者“一圈”）即可，也不需要锁。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-26632-1.html