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读取到一部分数据的时候触发事件(触发事件不是自动的,程序员需要在读取到数据的时候自己触发事件并发布):
![](/qrcode.jpg)
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() // 创建ThreadFactory
);
//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,方法会堵塞,直至所有的事件都得到处理;
}
}
Disruptor 构造方法如下:
new Disruptor( EventFactory<T> eventFactory, // 事件工厂类 int ringBufferSize, // RingBuffer 大小 ThreadFactory threadFactory, // ThreadFactory ProducerType producerType, // 生产模式,ProducerType.SINGLE ProducerType.MULTI WaitStrategy waitStrategy) // 等待策略,3种
WaitStrategy 策略类型:
BlockingWaitStrategy 是最低效的策略,但其对CPU的消耗最小并且在各种不同部署环境中能提供更加一致的性能表现
SleepingWaitStrategy 的性能表现跟BlockingWaitStrategy差不多,对CPU的消耗也类似,但其对生产者线程的影响最小,适合用于异步日志类似的场景
YieldingWaitStrategy 的性能是最好的,适合用于低延迟的系统。在要求极高性能且事件处理线数小于CPU逻辑核心数的场景中,推荐使用此策略;例如,CPU开启超线程的特性
四、Disruptor 组件说明
从生产者-消费者的整体:
RingBuffer
: 被看作 Disruptor 最主要的组件,然而从 3.0 开始 RingBuffer 仅仅负责存储和更新在 Disruptor 中流通的数据。对一些特殊的使用场景能够被用户(使用其他数据结构)完全替代。更多RingbufferSequence
: 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
每天用心记录一点点。内容也许不重要,但习惯很重要!