【高性能队列】Disruptor(高性能内存队列)

https://tech.meituan.com/2016/11/18/disruptor.html // 精巧的无锁设计实现了在高并发情形下的高性能，性能优于ArrayBlockingQueue。包括Apache Storm、Camel、Log4j 2在内的很多知名项目都应用了Disruptor以获取高性能

https://www.cnblogs.com/vivotech/p/18360657 vivo 高性能无锁队列 Disruptor 核心原理分析及其在i主题业务中的应用

https://www.cnblogs.com/crazymakercircle/p/13909102.html

核心原理：

Disruptor 是英国外汇交易公司 LMAX 开发的一个高性能的内存队列（用于系统内部线程间传递消息，不同于 RocketMQ、Kafka 这种分布式消息队列），基于 Disruptor 开发的系统单线程能支撑每秒 600 万订单。

目前，包括 Apache Storm、Camel、Log4j 2(异步日志AsyncAppender实现支持基于Disruptor的DisruptorBlockingQueue) 在内的很多知名项目都应用了 Disruptor 以获取高性能

队列的底层实现一般分为三种：数组、链表和堆，其中堆一般是为了实现带有优先级特性的队列，暂不考虑。另外，像 ConcurrentLinkedQueue 、LinkedTransferQueue 属于无界队列，在稳定性要求特别高的系统中，为了防止生产者速度过快，导致内存溢出，只能选择有界队列。这样 JDK 中剩下可选的线程安全的队列还有 ArrayBlockingQueue和 LinkedBlockingQueue。

LinkedBlockingQueue 是基于链表实现的，由于链表存储的数据在内存里不连续，对于高速缓存并不友好，而且 LinkedBlockingQueue 是加锁的，性能较差。
ArrayBlockingQueue 有同样的问题，它也需要加锁，另外，ArrayBlockingQueue 存在伪共享问题，也会导致性能变差。

而 Disruptor 是基于数组的有界无锁队列，符合空间局部性原理，可以很好的利用 CPU 的高速缓存，同时它避免了伪共享，大大提升了性能。

Disruptor 支持单（多）生产者、单（多）消费者模式。消费时支持广播消费（HandlerA 会消费处理所有消息，HandlerB 也会消费处理所有消息）、集群消费（HandlerA 和 HandlerB 各消费部分消息），HandlerA 和 HandlerB 消费完成后会把消息交给 HandlerC 继续处理。

RingBuffer：前文说 Disruptor 是一个高性能内存内存队列，而 RingBuffer 就是该内存队列的数据结构，它是一个环形数组，是承载数据的载体。
Producer：Disruptor 是典型的生产者消费者模型。因此生产者是 Disruptor 编程模型中的核心组成，可以是单生产者，也可以多生产者。
Event：具体的数据实体，生产者生产 Event ，存入 RingBuffer，消费者从 RingBuffer 中消费它进行逻辑处理。
Event Handler：开发者需要实现 EventHandler 接口定义消费者处理逻辑。
Wait Strategy：等待策略，定义了当消费者无法从 RingBuffer 获取数据时，如何等待。
Event Processor：事件循环处理器，EventProcessor 继承了 Runnable 接口，它的子类实现了 run 方法，内部有一个 while 循环，不断尝试从 RingBuffer 中获取数据，交给 EventHandler 去处理。
Sequence：RingBuffer 是一个数组，Sequence （序号）就是用来标记生产者数据生产到哪了，消费者数据消费到哪了。
Sequencer：分为单生产者和多生产者两种实现，生产者发布数据时需要先申请下可用序号，Sequencer 就是用来协调申请序号的。
Sequence Barrier：见下文分析。

Disruptor和BlockingQueue比较:

BlockingQueue: FIFO队列.生产者Producer向队列中发布publish一个事件时,消费者Consumer能够获取到通知.如果队列中没有消费的事件,消费者就会被阻塞,直到生产者发布新的事件
Disruptor可以比BlockingQueue做到更多:
- Disruptor队列中同一个事件可以有多个消费者,消费者之间既可以并行处理,也可以形成依赖图相互依赖,按照先后次序进行处理
- Disruptor可以预分配用于存储事件内容的内存空间
- Disruptor使用极度优化和无锁的设计实现极高性能的目标

如果你的项目有对性能要求高，对延迟要求低的需求，并且需要一个无锁的有界队列，来实现生产者/消费者模式，那么Disruptor是你的不二选择。

Disruptor 高性能原理分析

1 空间预分配：RingBuffer 是一个环(首尾相连的环)，用做在不同上下文(线程)间传递数据的buffer；RingBuffer 内部维护了一个 Object 数组（也就是真正存储数据的容器），在 RingBuffer 初始化时该 Object 数组就已经使用 EventFactory 初始化了一些空 Event，后续就不需要在运行时来创建了，避免频繁 GC。 -- 为了避免垃圾回收，采用数组而非链表。

　　另外，RingBuffe 的数组中的元素是在初始化时一次性全部创建的，所以这些元素的内存地址大概率是连续的。消费者在消费时，是遵循空间局部性原理的。消费完第一个 Event 时，很快就会消费第二个 Event，而在消费第一个 Event 时，CPU 会把内存中的第一个 Event 的后面的 Event 也加载进 Cache 中，这样当消费第二个 Event 时，它已经在 CPU Cache 中了，所以就不需要从内存中加载了，这样也可以大大提升性能。

2、避免伪共享：通过添加额外的无用信息，避免伪共享问题

3、无锁设计：采用CAS无锁方式，保证线程的安全性；每个生产者或者消费者线程，会先申请可以操作的元素在数组中的位置，申请到之后，直接在该位置写入或者读取数据。整个过程通过原子变量CAS，保证操作的线程安全。

4、支持批量消费定义 Event

5、元素位置定位：数组长度2^n，通过位运算，加快定位的速度。下标采取递增的形式。不用担心index溢出的问题。index是long类型，即使100万QPS的处理速度，也需要30万年才能用完。

伪共享问题（False Sharing）

L1、L2、L3分别表示一级缓存、二级缓存、三级缓存，越靠近CPU的缓存，速度越快，容量也越小。所以L1缓存很小但很快，并且紧靠着在使用它的CPU内核；L2大一些，也慢一些，并且仍然只能被一个单独的CPU核使用；L3更大、更慢，并且被单个插槽上的所有CPU核共享；最后是主存，由全部插槽上的所有CPU核共享。当CPU执行运算的时候，它先去L1查找所需的数据、再去L2、然后是L3，如果最后这些缓存中都没有，所需的数据就要去主内存拿。走得越远，运算耗费的时间就越长。所以如果你在做一些很频繁的事，你要尽量确保数据在L1缓存中。

线程之间共享一份数据的时候，需要一个线程把数据写回主存，而另一个线程访问主存中相应的数据。

Cache是由很多个cache line组成的。每个cache line通常是64字节，并且它有效地引用主内存中的一块儿地址。一个Java的long类型变量是8字节，因此在一个缓存行中可以存8个long类型的变量。CPU每次从主存中拉取数据时，会把相邻的数据也存入同一个cache line。

在访问一个long数组的时候，如果数组中的一个值被加载到缓存中，它会自动加载另外7个。因此你能非常快的遍历这个数组。事实上，你可以非常快速的遍历在连续内存块中分配的任意数据结构。

ArrayBlockingQueue有三个成员变量： - takeIndex：需要被取走的元素下标 - putIndex：可被元素插入的位置的下标 - count：队列中元素的数量

这三个变量很容易放到一个缓存行中，但是之间修改没有太多的关联。所以每次修改，都会使之前缓存的数据失效，从而不能完全达到共享的效果。

当生产者线程put一个元素到ArrayBlockingQueue时，putIndex会修改，从而导致消费者线程的缓存中的缓存行无效，需要从主存中重新读取。这种无法充分使用缓存行特性的现象，称为伪共享。

解决方案：就是通过填充(Padding)数据的形式（下图的Px），来保证本应有可能位于同一个缓存行的两个变量，在被多线程访问时必定位于不同的缓存行。

参考顶部美团文档效率验证对比

public final static class ValuePadding {
            protected long p1, p2, p3, p4, p5, p6, p7;  
            protected volatile long value = 0L;
            protected long p9, p10, p11, p12, p13, p14;
            protected long p15;
        }

简单的说，就是以空间换时间：使用占位字节，将变量的所在的缓冲行塞满。disruptor 无锁框架就是这么干的。

使用样例：

更全：https://blog.csdn.net/crazymakercircle/article/details/127173982

定义生产者

生成者主要是持有 RingBuffer 对象进行数据的发布。这里有几个点需要注意：

RingBuffer 内部维护了一个 Object 数组（也就是真正存储数据的容器），在 RingBuffer 初始化时该 Object 数组就已经使用 EventFactory 初始化了一些空 Event，后续就不需要在运行时来创建了，提高性能。因此这里通过 RingBuffer 获取指定序号得到的是一个空对象，需要对它进行赋值后，才能进行发布。
这里通过 RingBuffer 的 next 方法获取可用序号，如果 RingBuffer 空间不足会阻塞。
通过 next 方法获取序号后，需要确保接下来使用 publish 方法发布数据。

public class OrderEventProducer {
     private RingBuffer<OrderEvent> ringBuffer;
     public OrderEventProducer(RingBuffer<OrderEvent> ringBuffer) {
        this.ringBuffer = ringBuffer;
    }
     public void sendData(ByteBuffer data) {
        // 1、在生产者发送消息的时候, 首先需要从我们的ringBuffer里面获取一个可用的序号
        long sequence = ringBuffer.next();
        try {
            //2、注意此时获取的OrderEvent对象是一个没有被赋值的空对象
            OrderEvent event = ringBuffer.get(sequence);
            //3、进行实际的赋值处理
            event.setValue(data.getLong(0));           
        } finally {
            //4、 提交发布操作
            ringBuffer.publish(sequence);          
        }
    }
}

构造Disruptor对象的几个要点

在构造Disruptor对象，有几个核心的要点：
1：事件工厂(Event Factory)定义了如何实例化事件(Event)，Disruptor 通过 EventFactory 在 RingBuffer 中预创建 Event 的实例。
2：ringBuffer这个数组的大小，一般根据业务指定成2的指数倍。
3：消费者线程池，事件的处理是在构造的线程池里来进行处理的。
4：指定等待策略，Disruptor 定义了 com.lmax.disruptor.WaitStrategy 接口用于抽象 Consumer 如何等待Event事件。

Disruptor 提供了多个 WaitStrategy 的实现，每种策略都具有不同性能和优缺点，根据实际运行环境的 CPU 的硬件特点选择恰当的策略，并配合特定的 JVM 的配置参数，能够实现不同的性能提升。

BlockingWaitStrategy 是最低效的策略，但其对CPU的消耗最小并且在各种不同部署环境中能提供更加一致的性能表现；
SleepingWaitStrategy 的性能表现跟 BlockingWaitStrategy 差不多，对 CPU 的消耗也类似，但其对生产者线程的影响最小，适合用于异步日志类似的场景；
YieldingWaitStrategy 的性能是最好的，适合用于低延迟的系统。在要求极高性能且事件处理线数小于 CPU 逻辑核心数的场景中，推荐使用此策略；。