rabbitmq disruptor?disruptor响应数据?disruptor调研报告

你是否正在寻找关于disruptor的内容？让我把最宝贵的东西奉献给你：

disruptor调研报告

票池暂定使用disruptor来做消息队列，把最近对disruptor的调研结果整理一下。大部分文字都是把disruptor和其它网站上看到的资料翻译一下。

原文：

disruptor是什么？

disruptor是一个线程间通信的框架，即在多线程间共享数据。它是由LMAX公司开发的可信消息传递架构的一部分，以便用非常快速的方法来在多组件之间传递数据。它的一个核心思想是理解并适应硬件工作方式来达到最优的效果。

在很多（并行）架构里，普遍使用队列来共享数据（例如传递消息）。图1就是使用队列来传递消息的一个（里面蓝色的小圈圈表示一个线程）。这种架构允许生产线程（图1里的stage1）在消费线程（图1里的stage2）处理不过来的情况下，还可以继续后面的工作，队列在其中用来做为消息的缓冲区。

在最简单的情况下，disruptor可以用来替代图1架构里的队列，也就是线程间通过disruptor来传递数据。在disruptor里保存消息的数据结构是环状缓冲区（RingBuffer - 后面都用RingBuffer这个术语）。生产线程stage1将消息放到RingBuffer里，然后消费线程stage2从RingBuffer里读取消息，如图2。

从图2里可以看到，RingBuffer里的每一个元素都有一个序列号（sequence number）来索引，RingBuffer维护当前最新放置的元素的序列号，这个序列号一直递增，（通过求余来得到元素在RingBuffer下面的数组下标）。

Disruptor的关键特性是无锁编程，这个是通过单一写线程的方式实现的 - 即一块数据永远只有一个线程写入。通过遵循这个编程原则来避免使用昂贵的同步锁或CAS操作，这就是为什么disruptor这么快的原因。

因为RingBuffer规避了锁，而且每个EventProcessor维护自己的序列号。

向disruptor发布消息

往RingBuffer里写入消息使用两步提交的方式。首先，生产线程Stage1需要确定RingBuffer里下一个空闲槽，如图3。

RingBuffer维护了最后一次写入的序列号（图3里的18号），因此就可以推知下一个空闲的槽号。RingBuffer通过检查所有从RingBuffer读取消息的EventProcessor的序列号，以判别下一个槽号是否空闲。

图4演示了索取下一个空闲槽序列号的过程。

当生产线程拿到了下一个序利号之后，它从RingBuffer里拿到槽里保存的对象并执行任何操作。这个过程中，因为RingBuffer的最新序列号依然是18，因此其它线程无法读取19号槽里面的事件 - 生产线程还在处理它。

图5演示了RingBuffer在提交变更后的情况。当生产线程处理完第19号槽的数据后，它告诉RingBuffer将其公布出来。这个时候，RingBuffer才会更新它维护的序列号，任何等待读取第19号槽里的数据的线程才能读取它。

从RingBuffer里读取信息

disruptor框架里提供了一个叫做BatchEventProcessor来从RingBuffer里读取数据。当生产线程向RingBuffer要求下一个可写入的空闲槽的序列号时，同时一个EventProcessor（类似消费者，但其并消费RingBuffer里的元素 - 即不从RingBuffer里移除任何元素）也会维护其最后所处理的数据的序列号，并要求下一个可处理的数据的序列号。

图6演示了EventProcessor等待处理下一个可读取数据序利号的过程。

EventProcessor不是直接从RingBuffer里获取下一个可读取数据的序列号，而是通过一个SequenceBarrier对象来做的，稍后我们谈这个细节。

图6里，EventProcessor（即消费者线程Stage2）最后看到的是第16号槽的数据，它希望处理下一个（第17号）槽的数据，因此它执行SequenceBarrier的waitFor(17)函数调用。线程Stage2可以一直等待下一个可读序列号，因为如果尚没有数据生产出来的话，它什么也不需要做。但跟图6所示的一样，RingBuffer里最新可用数据已经到18号槽了，因此waitFor返回18，即告诉EventProcessor可以一直读到第18号的所有数据。如图7。

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