子夜枯灯

高性能无锁并发框架Disruptor

2022/03/10

以下文章来源于月伴飞鱼

正文

Disruptor 是一个开源框架，研发的初衷是为了解决高并发下队列锁的问题，最早由 LMAX 提出并使用，能够在无锁的情况下实现队列的并发操作， 并号称能够在一个线程里每秒处理 6 百万笔订单。

官网地址：  http://lmax-exchange.github.io/disruptor/

目前，包括 Apache Storm、Camel、Log4j2 在内的很多知名项目都应用了 Disruptor 以获取高性能。

为什么会产生 Disruptor 框架

目前 Java 内置队列保证线程安全的方式：

  • ArrayBlockingQueue： 基于数组形式的队列，通过加锁的方式，来保证多线程情况下数据的安全。

  • 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，则严格要求顺序，否则会出现问题， 所以通常意义上的多消费者线程无法解决该问题，如果通过加锁，则性能大打折扣。

Post Directory