Disruptor 系列（一）快速入门

Disruptor 系列（一）快速入门

Disruptor：是一个开源的并发框架，能够在 无锁 的情况下实现网络的 Queue 并发操作，所以处理数据的能力比 Java 本身提供的并发类容器要大的多，在一个线程里每秒处理 6 百万订单。 可以把它当作一个轻量级的 MQ 和无锁的 BlockingQueue。

一、BlockingQueue

jdk 常用的队列有

队列 有界性 锁 数据结构
ArrayBlockingQueue bounded 加锁 arraylist
LinkedBlockingQueue optionally-bounded 加锁 linkedlist
ConcurrentLinkedQueue unbounded 无锁 linkedlist
LinkedTransferQueue unbounded 无锁 linkedlist
PriorityBlockingQueue unbounded 加锁 heap
DelayQueue unbounded 加锁 heap

考虑到内存回收，防止无界队列内存溢出，通常使用 ArrayBlockingQueue。常用于生产者-消费者模式：

二、Disruptor 特点

  • Disruptor 是一个 Java 的并发编程框架，大大的简化了并发程序开发的难度，在性能上也比 Java 本身提供的一些并发包要好。

  • Disruptor 是一个高性能异步处理框架，它实现了观察者模式，或者事件监听模式的实现。

  • Disruptor 是无锁的、CPU 友好，它不会清除缓存中的数据，只会覆盖，降低了垃圾回收机制启动的频率。

三、HelloWorld 代码

可以通过 Maven安装Disruptor。查看 Getting-Started 快速入门，更多API

<dependency>
    <groupId>com.lmax</groupId>
    <artifactId>disruptor</artifactId>
    <version>3.3.7</version>
</dependency>

我们从一个简单的例子开始学习 Disruptor：生产者传递一个 long 类型的值给消费者，而消费者消费这个数据的方式仅仅是把它打印出来。首先声明一个 Event 来包含需要传递的数据：

public class LongEvent { 
    private long value;
    public long getValue() { 
        return value; 
    } 
 
    public void setValue(long value) { 
        this.value = value; 
    } 
}

由于需要让 Disruptor 为我们创建事件，我们同时还声明了一个 EventFactory 来实例化 Event 对象。

public class LongEventFactory implements EventFactory {
    @Override
    public Object newInstance() {
        return new LongEvent();
    }
}

我们还需要一个事件消费者，也就是一个事件处理器。这个事件处理器简单地把事件中存储的数据打印到终端：

public class LongEventHandler implements EventHandler<LongEvent> { 
    @Override 
    public void onEvent(LongEvent longEvent, long l, boolean b) throws Exception { 
        System.out.println(longEvent.getValue()); 
    } 
}

事件都会有一个生成事件的源，可以简单的理解为一个事件生产者。这个例子中假设事件是由于磁盘IO或者network读取数据的时候触发的，事件源使用一个ByteBuffer来模拟它接受到的数据，也就是说，事件源会在IO读取到一部分数据的时候触发事件（触发事件不是自动的，程序员需要在读取到数据的时候自己触发事件并发布）：

public class LongEventProducer {
    private final RingBuffer<LongEvent> ringBuffer;
    public LongEventProducer(RingBuffer<LongEvent> ringBuffer){
        this.ringBuffer = ringBuffer;
    }
    
    /**
     * onData用来发布事件，每调用一次就发布一次事件
     * @param ByteBuffer 它的参数会用过事件传递给消费者
     */
    public void onData(ByteBuffer bb){
        //1.可以把ringBuffer看做一个事件队列，那么next就是得到下面一个事件槽
        long sequence = ringBuffer.next();
        try {
            //2.用上面的索引取出一个空的事件用于填充（获取该序号对应的事件对象）
            LongEvent event = ringBuffer.get(sequence);
            //3.获取要通过事件传递的业务数据
            event.setValue(bb.getLong(0));
        } finally {
            //4.发布事件
            //注意，最后的 ringBuffer.publish 方法必须包含在 finally 中以确保必须得到调用；
            //      如果某个请求的 sequence 未被提交，将会堵塞后续的发布操作或者其它的 producer。
            ringBuffer.publish(sequence);
        }
    }    
}

很明显的是：当用一个简单队列来发布事件的时候会牵涉更多的细节，这是因为事件对象还需要预先创建。发布事件最少需要两步：获取下一个事件槽并发布事件（ 发布事件的时候要使用 try/finally 保证事件一定会被发布 ）。如果我们使用 RingBuffer.next() 获取一个事件槽，那么一定要发布对应的事件。如果不能发布事件，那么就会引起 Disruptor 状态的混乱。尤其是在多个事件生产者的情况下会导致事件消费者失速，从而不得不重启应用才能会恢复。

Disruptor 3.0 提供了 lambda 式的 API。这样可以把一些复杂的操作放在 Ring Buffer，所以在 Disruptor3.0 以后的版本最好使用 Event Publisher 或者 Event Translator 来发布事件。

public class LongEventProducerWithTranslator {
    //一个translator可以看做一个事件初始化器，publicEvent方法会调用它
    private static final EventTranslatorOneArg<LongEvent, ByteBuffer> TRANSLATOR =
            new EventTranslatorOneArg<LongEvent, ByteBuffer>() {
                public void translateTo(LongEvent event, long sequence, ByteBuffer buffer) {
                    event.setValue(buffer.getLong(0));
                }
            };

    private final RingBuffer<LongEvent> ringBuffer;
    public LongEventProducerWithTranslator(RingBuffer<LongEvent> ringBuffer) {
        this.ringBuffer = ringBuffer;
    }
    public void onData(ByteBuffer buffer) {
        ringBuffer.publishEvent(TRANSLATOR, buffer);
    }
}

最后一步就是把所有的代码组合起来完成一个完整的事件处理系统。

public class LongEventMain {
    public static void main(String[] args) throws Exception {
        //1. 创建disruptor
        Disruptor<LongEvent> disruptor = new Disruptor<LongEvent>( // (1)
            new LongEventFactory(),             // 创建工厂
            1024 * 1024,                        // RingBuffer 大小，必须是2的N次方
            Executors.defaultThreadFactory(),   // 线程池
            ProducerType.SINGLE,                // 单个生产者，如果有多个生产者必须使用 ProducerType.MULTI
            new YieldingWaitStrategy()          // 生产者和消费者的平衡策略
        );

        //2. 连接消费事件方法
        disruptor.handleEventsWith(new LongEventHandler());
        //3. 启动
        disruptor.start();

        //4. 发布事件
        RingBuffer<LongEvent> ringBuffer = disruptor.getRingBuffer();

        //LongEventProducer producer = new LongEventProducer(ringBuffer);
        LongEventProducerWithTranslator producer = new LongEventProducerWithTranslator(ringBuffer);
        ByteBuffer byteBuffer = ByteBuffer.allocate(8);
        for(long l = 0; l<100; l++){
            byteBuffer.putLong(0, l);
            producer.onData(byteBuffer);
            //Thread.sleep(1000);
        }

        disruptor.shutdown();//关闭 disruptor，方法会堵塞，直至所有的事件都得到处理；
    }
}

  1. Disruptor 构造方法如下：

    new Disruptor(
    EventFactory<T> eventFactory,   // 事件工厂类
    int ringBufferSize,             // RingBuffer 大小
    ThreadFactory threadFactory,    // ThreadFactory
    ProducerType producerType,      // 生产模式，ProducerType.SINGLE ProducerType.MULTI
    WaitStrategy waitStrategy)      // 等待策略，3种

  2. WaitStrategy 策略类型：

    • BlockingWaitStrategy 是最低效的策略，但其对CPU的消耗最小并且在各种不同部署环境中能提供更加一致的性能表现

    • SleepingWaitStrategy 的性能表现跟BlockingWaitStrategy差不多，对CPU的消耗也类似，但其对生产者线程的影响最小，适合用于异步日志类似的场景

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

四、Disruptor 组件说明

从生产者-消费者的整体：

  • RingBuffer: 被看作 Disruptor 最主要的组件，然而从 3.0 开始 RingBuffer 仅仅负责存储和更新在 Disruptor 中流通的数据。对一些特殊的使用场景能够被用户(使用其他数据结构)完全替代。更多Ringbuffer

    RingBuffer

  • Sequence: Disruptor 使用 Sequence 来表示一个特殊组件处理的序号。和 Disruptor 一样，每个消费者(EventProcessor)都维持着一个 Sequence。大部分的并发代码依赖这些 Sequence 值的运转，因此 Sequence 支持多种当前为 AtomicLong 类的特性。

  • Producer：由用户实现，它调用 RingBuffer 来插入事件(Event)。在 Disruptor 中没有相应的实现代码，由用户实现。

  • Event：从生产者到消费者过程中所处理的数据单元。在 Disruptor 中没有相应的实现代码，由用户定义的。

  • EventHandler：由用户实现并且代表了 Disruptor 中的一个消费者的接口。

从 Disruptor 框架如何处理 Event 的细节：

  • Sequencer: 这是 Disruptor 真正的核心。实现了这个接口的两种生产者（单生产者和多生产者）均实现了所有的并发算法，为了在生产者和消费者之间进行准确快速的数据传递。通过复杂的算法去协调生存者和消费者之间的关系。

  • SequenceBarrier: Sequecer具体的实施者，由 Sequencer 生成。它包含了决定是否有供消费者来消费的 Event 的逻辑。（生产者发布事件快于消费，生产者等待。消费速度大于生产者发布事件速度，消费者监听）

  • EventProcessor：主要事件循环，处理 Disruptor 中的 Event，并且拥有消费者的 Sequence。它有一个实现类是 BatchEventProcessor，包含了event loop有效的实现，并且将回调到一个 EventHandler 接口的实现对象。

  • WorkProcessor：确保每个 sequence 只被一个 processor 消费，在同一个 WorkPool 中的处理多个 WorkProcessor 不会消费同样的 sequence。

  • LifecycleAware：当 BatchEventProcessor 启动和停止时，实现这个接口用于接收通知。

  • WaitStrategy：当消费者等待在SequenceBarrier上时，有许多可选的等待策略。

    • BusySpinWaitStrategy ： 自旋等待，类似 Linux Kernel 使用的自旋锁。低延迟但同时对 CPU 资源的占用也多。
    • BlockingWaitStrategy ： 使用锁和条件变量。CPU 资源的占用少，延迟大。
    • SleepingWaitStrategy ： 在多次循环尝试不成功后，选择让出 CPU，等待下次调度，多次调度后仍不成功，尝试前睡眠一个纳秒级别的时间再尝试。这种策略平衡了延迟和 CPU 资源占用，但延迟不均匀。
    • YieldingWaitStrategy ： 在多次循环尝试不成功后，选择让出 CPU，等待下次调。平衡了延迟和 CPU 资源占用，但延迟也比较均匀。
    • PhasedBackoffWaitStrategy ： 上面多种策略的综合，CPU 资源的占用少，延迟大。

参考：

https://blog.csdn.net/bohu83/article/details/78273246

每天用心记录一点点。内容也许不重要，但习惯很重要！

【推广】 免费学中医，健康全家人
原文地址：https://www.cnblogs.com/binarylei/p/9221547.html