disruptor原理分析

最新推荐文章于 2021-05-20 10:16:44 发布

置顶休息的风

最新推荐文章于 2021-05-20 10:16:44 发布

阅读量832

点赞数 1

分类专栏： disruptor 文章标签：伪共享架构原理消息传递高性能

本文链接：https://blog.csdn.net/u011464536/article/details/88383272

版权

disruptor 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

简介

理解Disruptor是什么的最好方法是将它与目前很好理解和非常相似的东西进行比较。与Java的 BlockingQueue队列一样，Disruptor的目的是在同一进程内的线程之间移动数据（例如消息或事件）。但是，Disruptor提供了一些将其与队列区分开来的关键功能。他们是：

具有消费者依赖关系图的消费者多播事件。
为事件预先分配内存。
可选择无锁。

使用场景

Disruptor的行为旨在用于需要对同一数据进行独立多个并行操作的情况。
来自LMAX的规范示例是我们有三个操作，即日志记录（将输入数据写入持久性日志文件），复制（将输入数据发送到另一台机器以确保存在数据的远程副本）和业务逻辑（真正的处理工作）

整体构成（3.0版本）

组成

Sequencer
核心组件，该接口的两个实现，实现了框架内的所有并发算法，用于生产者消费者正确的，快速的传递数据
RingBuffer
环型缓冲区，3.0后的版本主要负责存储和更新通过disruptor的数据
Sequence
用于获取当前可用（可读或可写）的位置（序号）的组件，每个消费者（EventProcessor）都维护有一个sequence；使用cas操作提高效率，使用padding的方法来避免伪共享
Sequence Barrier
由sequencer产生，包含对sequencer发布的sequence和任何依赖消费者sequence的引用；在消费者之间或消费者与RingBuffer之间，用于确认是否有任何可供消费者处理的事件的逻辑。
Wait Strategy
等待策略，确定消费者如何等待生产者将事件放入RingBuffer中；当消费者等待在SequenceBarrier上时，Disruptor 提供了多个WaitStrategy的实现，每种策略都具有不同性能和优缺点
1. BusySpinWaitStrategy
  自旋等待，类似Linux Kernel使用的自旋锁。低延迟但同时对CPU资源的占用也多。
2. BlockingWaitStrategy
  使用锁和条件变量。CPU资源的占用少，延迟大。
3. SleepingWaitStrategy
  在多次循环尝试不成功后，选择让出CPU，等待下次调度，多次调度后仍不成功，尝试前睡眠一个纳秒级别的时间再尝试。这种策略平衡了延迟和CPU资源占用，但延迟不均匀。
4. YieldingWaitStrategy
  在多次循环尝试不成功后，选择让出CPU，等待下次调度。平衡了延迟和CPU资源占用，但延迟比较均匀。
EventProcessor
用来处理来自disruptor事件的主事件循环，并具有消费者序列的所有权。有一个名为 BatchEventProcessor的组件，它包含事件循环的有效实现，并将回调到用户的提供的EventHandler接口实现。
Event
从生产者传递给消费者的数据单位
Event Handler
由用户实现并代表disruptor使用者的接口
Producer
调用disruptor将事件排入ringbuffer中的用户代码，Disruptor 没有定义特定接口或类型

ringBuffer

读取数据

消费者(EventHandler)想要消费序号1的数据，并不是直接与ringbuffer通讯，而是通过Sequence Barrier向ringbuffer请求。此时序号1刚好没有数据。消费者(EventHandler)只好等待挂起。这里的等待,disruptor实现了Wait Strategy四种等待策略，用于消费者等待有新数据产生后消费。
消费者(EventHandler)等待序号1时，这里有生产者向序号2生产数据了。这时Sequence Barrier知道后，会通知消费者(EventHandler)可以消费直到序号2的消息了
消费者(EventHandler)就先获取序号1的数据，这里没有数据，所有序号1就不做处理了。接着获取序号2的数据进行处理。

写入ringbuffer

生产者生产数据，使用的是两阶段提交。第一步，请求Sequencer获取下一个可以操作的序号。
假设当前序号2不能使用，Sequencer返回可用序号就是3
生产者接收到可用序号是3后，便去获取序号3进行数据的填写。
待填写完毕后，就进行两阶段的第二个阶段——提交。这样完成一次单生产者的写入数据过程，如果是多线程生产者，disruptor实现了MultiProducerSequencer，用于多生产者获取可用序号的组件。

伪共享

何为伪共享，缓存中是以缓存行（cache line）为单位存储的。缓存行是2的整数幂个连续字节，一般为32-256个字节。最常见的缓存行大小是64个字节。当多线程修改互相独立的变量时，如果这些变量共享同一个缓存行，就会无意中影响彼此的性能，这就是伪共享。

伪共享有影响，被称做无声的性能杀手，因为从代码中很难看清楚是否会出现伪共享。同样，disruptor在操作Sequence时，也会遇到伪共享的问题。

接下来简单介绍下伪共享，CPU到主内存间，还有存在多级的缓存。越靠近CPU的缓存越小，但是速度也越快。

如图，L1、L2级缓存会分别被CPU内核拥有。L3为所有CPU内核共用,这里CPU 内核只会更新缓存行；L1级缓存是最小最快的。往上依次变大变慢。如果想让速度最快，就希望数据放到越靠近CPU的缓存。

此时X、Y同处于一个缓存行中。如果内核1只关心X值，内核2只关心Y值。这时，内核心1对处于L1级的X的值进行修改，会导致同一缓存行的Y的值也失效(只有把缓存行 flush到主存后, 其他内核中的相应的缓存行才会被置为过期数据,而缓存行什么时候flush到memory, 这个是有一定延时的 ,在这个延时当中, 其他CPU core是无法得知你的更新的) 。那么内核2再去读取Y的值时，由于L1的缓存里的数据已失效，那么就需要从L3获取，然后放入L2，再放入L1。这样核心2读取Y值就需要从L3级的缓存读了。但是明明是内核1修改的X的值，却影响到内核2去读取Y值了。同理，如果是内核2去修改Y的值，也会影响内核1去读取X的值。

相比之下，如果内核2读取修改Y值与内核1读取修改X值之间的操作不会互相影响各自关心的值，那么内核1,2分别只需读取L1级缓存里的值，这样肯定比去L3读取值来得快。disruptor也关注到了此问题，并且采用了缓存行填充的方式来避免产生伪共享。

Disruptor为什么快

无锁操作(Lock-Free), 没有竞争所以非常快 (系统态的锁会导致线程cache丢失. 锁竞争的时候需要进行仲裁. 这个仲裁会涉及到操作系统的内核切换, 并且在此过程中操作系统需要做一系列操作, 导致原有线程的指令缓存和数据缓很可能被丢掉。用户态的锁往往是通过自旋锁来实现(自旋即忙等), 而自旋在竞争激烈的时候开销是很大的(一直在消耗CPU资源)。disruptor不使用锁, 使用CAS,严格意义上说仍然是使用锁, 因为CAS本质上也是一种乐观锁, 只不过是CPU级别指令, 不涉及到操作系统, 所以效率很高)
高效的RingBuffer数据结构，预分配内存，复用数组中的Entry，GC友好 (用数组实现, 解决了链表节点分散, 不利于cache预读问题，可以预分配用于存储事件内容的内存空间；并且解决了节点每次需要分配和释放, 需要大量的垃圾回收GC问题 (数组内元素的内存地址的连续性存储的,在硬件级别，数组中的元素是会被预加载的,因为只要一个元素被加载到缓存行，其他相邻的几个元素也会被加载进同一个缓存行)
所有访问者都记录自己的序号的实现方式，允许多个生产者与多个消费者共享相同的数据结构
在每个对象中都能跟踪序列号，没有为伪共享和非预期的竞争
增加缓存行补齐，提升cache缓存命中率

源码分析

使用例子

//定义一个事件：
public class LongEvent
{
    private long value;

    public void set(long value)
    {
        this.value = value;
    }
}

//定义一个事件工厂类，用于生产事件
import com.lmax.disruptor.EventFactory;

public class LongEventFactory implements EventFactory<LongEvent>
{
    public LongEvent newInstance()
    {
        return new LongEvent();
    }
}

//定义一个事件处理类，用户具体处理事件的实现
import com.lmax.disruptor.EventHandler;

public class LongEventHandler implements EventHandler<LongEvent>
{
    public void onEvent(LongEvent event, long sequence, boolean endOfBatch)
    {
        System.out.println("Event: " + event);
    }
}

 //用户实现生产数据（事件）的类
import com.lmax.disruptor.RingBuffer;

public class LongEventProducer
{
    private final RingBuffer<LongEvent> ringBuffer;

    public LongEventProducer(RingBuffer<LongEvent> ringBuffer)
    {
        this.ringBuffer = ringBuffer;
    }

    public void onData(ByteBuffer bb)
    {
        long sequence = ringBuffer.next();  // Grab the next sequence
        try
        {
            LongEvent event = ringBuffer.get(sequence); // Get the entry in the Disruptor
                                                        // for the sequence
            event.set(bb.getLong(0));  // Fill with data
        }
        finally
        {
            ringBuffer.publish(sequence);
        }
    }
}

//整体使用disruptor处理的代码
import com.lmax.disruptor.dsl.Disruptor;
import com.lmax.disruptor.RingBuffer;
import com.lmax.disruptor.util.DaemonThreadFactory;
import java.nio.ByteBuffer;

public class LongEventMain
{
    public static void main(String[] args) throws Exception
    {
        // The factory for the event
        LongEventFactory factory = new LongEventFactory();

        // Specify the size of the ring buffer, must be power of 2.
        int bufferSize = 1024;

        // Construct the Disruptor
        Disruptor<LongEvent> disruptor = new Disruptor<>(factory, bufferSize, DaemonThreadFactory.INSTANCE);

        // Connect the handler
        disruptor.handleEventsWith(new LongEventHandler());

        // Start the Disruptor, starts all threads running
        disruptor.start();

        // Get the ring buffer from the Disruptor to be used for publishing.
        RingBuffer<LongEvent> ringBuffer = disruptor.getRingBuffer();

        LongEventProducer producer = new LongEventProducer(ringBuffer);

        ByteBuffer bb = ByteBuffer.allocate(8);
        for (long l = 0; true; l++)
        {
            bb.putLong(0, l);
            producer.onData(bb);
            Thread.sleep(1000);
        }
    }
}

源码类图

此类图与文章开头的构成图对应，用相同的颜色标注。
Sequence 类用继承的RhsPadding、Value、LhsPadding四个类做缓存行填充，解决伪共享问题。

class LhsPadding
{
    protected long p1, p2, p3, p4, p5, p6, p7;
}

class Value extends LhsPadding
{
    protected volatile long value;
}

class RhsPadding extends Value
{
    protected long p9, p10, p11, p12, p13, p14, p15;
}

public class Sequence extends RhsPadding
{
    static final long INITIAL_VALUE = -1L;
    private static final Unsafe UNSAFE;
    private static final long VALUE_OFFSET;
}

ProcessingSequenceBarrier的核心方法：

public long waitFor(final long sequence)
    throws AlertException, InterruptedException, TimeoutException
{
    checkAlert();
//根据策略，等待可用序号
    long availableSequence = waitStrategy.waitFor(sequence, cursorSequence, dependentSequence, this);

    if (availableSequence < sequence)
    {
        return availableSequence;
    }
//根据单生产者或多生产者，从RingBuffer中找到已经被生产数据的可消费的最大序号
    return sequencer.getHighestPublishedSequence(sequence, availableSequence);
}

MultiProducerSequencer的核心方法：

public long next(int n)
{
    if (n < 1)
    {
        throw new IllegalArgumentException("n must be > 0");
    }

    long current;
    long next;

    do
    {
		//获取最新的序号seq
        current = cursor.get();
		//计算想要的序号
        next = current + n;

		//想要的seq在slot里元素的位置
        long wrapPoint = next - bufferSize;
		//获取消费者未消费元素的seq最小值，不是最新的，所以后面还会检验
        long cachedGatingSequence = gatingSequenceCache.get();

		//检查消费者未消费元素的seq最小值的这个seq是否被消费者占用了
        if (wrapPoint > cachedGatingSequence || cachedGatingSequence > current)
        {
            long gatingSequence = Util.getMinimumSequence(gatingSequences, current);

			//slot被消费者占用，生产者自旋等待
            if (wrapPoint > gatingSequence)
            {
                LockSupport.parkNanos(1); // TODO, should we spin based on the wait strategy?
                continue;
            }

            gatingSequenceCache.set(gatingSequence);
        }
		//CAS控制多个生产者哪个可以进入操作
        else if (cursor.compareAndSet(current, next))
        {
            break;
        }
    }
    while (true);

    return next;
}

RingBufferFields的组成，其中private final Object[] entries; 印证前文提到的，RingBuffer数据结构使用的是数组的好处。

abstract class RingBufferFields<E> extends RingBufferPad
{
    private static final int BUFFER_PAD;
    private static final long REF_ARRAY_BASE;
    private static final int REF_ELEMENT_SHIFT;
    private static final Unsafe UNSAFE = Util.getUnsafe();
    private final long indexMask;
    private final Object[] entries;
    protected final int bufferSize;
    protected final Sequencer sequencer;
}

BatchEventProcessor :

public void run()
    {
		//避免重复运行
        if (!running.compareAndSet(false, true))
        {
            throw new IllegalStateException("Thread is already running");
        }
        sequenceBarrier.clearAlert();

        notifyStart();

        T event = null;
        long nextSequence = sequence.get() + 1L;
        try
        {
			//在死循环中处理事件
            while (true)
            {
                try
                {
					//从RingBuffer中获取一批可用的序号，返回的序号可能会比期望的大
                    final long availableSequence = sequenceBarrier.waitFor(nextSequence);

					//在循环中消费，直到最近可用的序号
                    while (nextSequence <= availableSequence)
                    {
						//获取event
                        event = dataProvider.get(nextSequence);
						//调用自定义的eventHandler来处理
                        eventHandler.onEvent(event, nextSequence, nextSequence == availableSequence);
                        nextSequence++;
                    }

					//让生产者知道这批序号又消费
                    sequence.set(availableSequence);
                }
                catch (final TimeoutException e)
                {
                    notifyTimeout(sequence.get());
                }
                catch (final AlertException ex)
                {
                    if (!running.get())
                    {
                        break;
                    }
                }
                catch (final Throwable ex)
                {
                    exceptionHandler.handleEventException(ex, nextSequence, event);
                    sequence.set(nextSequence);
                    nextSequence++;
                }
            }
        }
        finally
        {
            notifyShutdown();
            running.set(false);
        }
    }

使用Disruptor的几点经验

单消费者时，及时回收ringbuffer里的内容可以缩短对象的生命周期。
牢记Ringbuffer里每个slot里的event对象都是被复用的
在声明完Handler后声明handleExceptionsWith（或者在handler里catch住),否则Disruptor默认的实现是会把handler未catch的异常抛到最外面导致handler退出
当盲等风险存在时，正确的用法是使用tryNext(int)而不是next(int)