disruptor使用场景

并发编程网 1 什么是 Disruptor Martin Fowler 在自己网站上写了一篇 LMAX 架构的文章，在文章中他介绍了 LMAX 是一种新型零售金融交易平台，它能够以很低的延迟产生大量交易。这个系统是建立在 JVM 平台上，其核心是一个业务逻辑处理器， 它能够在一个线程里每秒处理 6 百万订单 。业务逻辑处理器完全是运行在内存中，使 用 事件源驱动方式 。业务逻辑处理器的核心是 Disruptor`。 Disruptor 它是一个开源的并发框架，并获得 2011 Duke’s 程序框架创新奖，能够在无锁的情况下实现网络的 Queue 并发操作。 Disruptor 是一个高性能的异步处理框架，或者可以认为是最快的消息框架（轻量的 JMS ），也可以认为是一个观察者模式的实现，或者事件监听模式的实现。 在使用之前，首先说明 disruptor 主要功能加以说明，你可以理解为他是一种高效的 生产者-消费者 模型。也就性能远远高于传统的 BlockingQueue 容器。 在 JDK 的多线程与并发库一文中，提到了 BlockingQueue 实现了 生产者-消费者模型 。 BlockingQueue 是基于锁实现的, 而锁的效率通常较低。有没有使用 CAS 机制实现的 生产者-消费者 ， Disruptor 就是这样。 Disruptor 使用 观察者模式

目录 一、前言 二、RingBuffer简介 三、依赖链 四、无锁竞争实现 1、生产者和消费者竞争实现 2、生产者和生产者竞争实现 3、消费者和消费者竞争实现 4、消费组内的消费者竞争实现 5、实现总结 五、惯例 一、前言 说到Disruptor都会提到其牛逼的性能，一说其性能大家都应该会想到它的无锁实现。大家都会说因为它是无锁实现的（重要因素，并不是唯一因素），所以它的性能很好。 那么它是怎样通过无锁的方式解决了多线程（消费者和生产者）之间的竞争呢？本文将给大家做一个基本的分析。 二、RingBuffer简介 熟悉或者了解Disruptor同学都知道，Disruptor采用了RingBuffer的数据结构来存储数据，而不是像BlockingQueue那样使用的队列。RingBuffer就是一个基于数据组实现的环形结构(如果还有不了解的同学，可以先行百度了解下)。生产者每生产一个数据就向前移动一格，而消费者每消费一个数据也向前移动一格。 图片来自网络 另外RingBuffer的大小是创建的时候就固定的，且其会预先分配好所有内存。即每个位置都会提前填充好对应的数据对象（一般是一个空对象）。然后每次生产者生成数据的时候仅仅是拿到这个位置的数据对象，然后将数据填充到（如通过setter）该对象中（该步骤由业务代码自己完成）。这样就避免了因频繁的创建和销毁对象而导致的不必要的对象回收

EventBus： 基于观察者模式实现的， 本文基于同步模式来操作 ；这里只介绍下几个常用操作的代码实现： register：注册观察者实现：主要就是以把观察者观察的类key，同类观察者的set集合为value构成一个ConcurrenHashMap 代码如下： private final ConcurrentMap<Class<?>, CopyOnWriteArraySet<Subscriber>> subscribers = Maps.newConcurrentMap(); 这里有两步加锁：map分段锁，copyOnWriteArraySet读写锁； EventBus.post(Object):发送事件实现：根据事件的class找subscribers中的观察者，通过反射执行所有观察者的@Subscribe注解注释的方法； 代码如下： public void post(Object event) { Iterator<Subscriber> eventSubscribers = subscribers.getSubscribers(event); if (eventSubscribers.hasNext()) { dispatcher.dispatch(event, eventSubscribers); } else if (!(event instanceof

前言 最近工作比较忙，在工作项目中，看了很多人都自己实现了一套数据任务处理机制，个人感觉有点乱，且也方便他人的后续维护，所以想到了一种数据处理模式，即生产者、缓冲队列、消费者的模式来统一大家的实现逻辑。 下面时是对Disruptor基本使用的演示。使用中需要引入依赖 <dependency> <groupId>com.lmax</groupId> <artifactId>disruptor</artifactId> <version>3.4.2</version> </dependency> 名称解释 Ring Buffer 环境的缓存区,3.0版本以前被认为是Disruptor的主要成员。3.0版本以后，环形缓冲区只负责通过Disruptor的事件方式来对数据进行存储和更新。在一些高级的应用场景中，Ring Buffer可以由用户的自定义实现完全替代。 Sequence Disruptor使用Sequence作为一种方法来确定特定组件的位置。每个使用者（EventProcessor）与Disruptor本身一样维护一个序列。大多数并发代码依赖于这些序列值的移动，因此序列支持AtomicLong的许多当前特性。事实上，两者之间唯一真正的区别是序列包含额外的功能，以防止序列和其他值之间的错误共享。 Sequencer Sequencer是真正的核心，该接口的两个实现（单生产者，

前言 最近工作比较忙，在工作项目中，看了很多人都自己实现了一套数据任务处理机制，个人感觉有点乱，且也方便他人的后续维护，所以想到了一种数据处理模式，即生产者、缓冲队列、消费者的模式来统一大家的实现逻辑。 下面时是对Disruptor基本使用的演示。使用中需要引入依赖 <dependency> <groupId>com.lmax</groupId> <artifactId>disruptor</artifactId> <version>3.4.2</version> </dependency> 名称解释 Ring Buffer 环境的缓存区,3.0版本以前被认为是Disruptor的主要成员。3.0版本以后，环形缓冲区只负责通过Disruptor的事件方式来对数据进行存储和更新。在一些高级的应用场景中，Ring Buffer可以由用户的自定义实现完全替代。 Sequence Disruptor使用Sequence作为一种方法来确定特定组件的位置。每个使用者（EventProcessor）与Disruptor本身一样维护一个序列。大多数并发代码依赖于这些序列值的移动，因此序列支持AtomicLong的许多当前特性。事实上，两者之间唯一真正的区别是序列包含额外的功能，以防止序列和其他值之间的错误共享。 Sequencer Sequencer是真正的核心，该接口的两个实现（单生产者，

秒杀架构持续优化中，基于自身认知不足之处在所难免，也请大家指正，共同进步。文章标题来自码友的建议，希望可以把阻塞队列ArrayBlockingQueue这个队列替换成Disruptor，由于之前曾接触过这个东西，听说很不错，正好借此机会整合进来。 LMAX Disruptor是一个高性能的线程间消息库。它源于LMAX对并发性，性能和非阻塞算法的研究，如今构成了Exchange基础架构的核心部分。 Disruptor它是一个开源的并发框架，并获得2011 Duke’s 程序框架创新奖，能够在无锁的情况下实现网络的Queue并发操作。 Disruptor是一个高性能的异步处理框架，或者可以认为是最快的消息框架（轻量的JMS），也可以认为是一个观察者模式的实现，或者事件监听模式的实现。 在这里你可以跟BlockingQueue队列作比对，简单的理解为它是一种高效的"生产者-消费者"模型，先了解后深入底层原理。 写代码案例之前，大家最好先了解 Disruptor 的核心概念，至少知道它是如何运作的。 Ring Buffer 如其名，环形的缓冲区。曾经 RingBuffer 是 Disruptor 中的最主要的对象，但从3.0版本开始，其职责被简化为仅仅负责对通过 Disruptor 进行交换的数据（事件）进行存储和更新。在一些更高级的应用场景中，Ring Buffer

一 .什么是 Disruptor 从功能上来看，Disruptor 是实现了“队列”的功能，而且是一个有界队列。那么它的应用场景自然就是“生产者-消费者”模型的应用场合了。 可以拿 JDK 的 BlockingQueue 做一个简单对比，以便更好地认识 Disruptor 是什么。 我们知道 BlockingQueue 是一个 FIFO 队列，生产者(Producer)往队列里发布(publish)一项事件(或称之为“消息”也可以)时，消费者(Consumer)能获得通知；如果没有事件时，消费者被堵塞，直到生产者发布了新的事件。 这些都是 Disruptor 能做到的，与之不同的是，Disruptor 能做更多： 同一个“事件”可以有多个消费者，消费者之间既可以并行处理，也可以相互依赖形成处理的先后次序(形成一个依赖图)； 预分配用于存储事件内容的内存空间； 针对极高的性能目标而实现的极度优化和无锁的设计； 以上的描述虽然简单地指出了 Disruptor 是什么，但对于它“能做什么”还不是那么直截了当。一般性地来说，当你需要在两个独立的处理过程(两个线程)之间交换数据时，就可以使用 Disruptor 。当然使用队列（如上面提到的 BlockingQueue）也可以，只不过 Disruptor 做得更好。 拿队列来作比较的做法弱化了对 Disruptor 有多强大的认识

一、什么是Disruptor Martin Fowler在自己网站上写了一篇LMAX架构的文章，在文章中他介绍了LMAX是一种新型零售金融交易平台，它能够以很低的延迟产生大量交易。这个系统是建立在JVM平台上，其核心是一个业务逻辑处理器，它能够在一个线程里每秒处理6百万订单。业务逻辑处理器完全是运行在内存中，使`用事件源驱动方式。业务逻辑处理器的核心是Disruptor。 Disruptor它是一个开源的并发框架，并获得2011 Duke’s 程序框架创新奖，能够在无锁的情况下实现网络的Queue并发操作。 Disruptor是一个高性能的异步处理框架，或者可以认为是最快的消息框架（轻量的JMS），也可以认为是一个观察者模式的实现，或者事件监听模式的实现。 在使用之前，首先说明disruptor主要功能加以说明，你可以理解为他是一种高效的"生产者-消费者"模型。也就性能远远高于传统的BlockingQueue容器。 在JDK的多线程与并发库一文中, 提到了BlockingQueue实现了生产者-消费者模型 BlockingQueue是基于锁实现的, 而锁的效率通常较低. 有没有使用CAS机制实现的生产者-消费者 Disruptor使用观察者模式, 主动将消息发送给消费者, 而不是等消费者从队列中取; 在无锁的情况下, 实现queue(环形, RingBuffer)的并发操作,

已经不记得最早接触到 Disruptor 是什么时候了，只记得发现它的时候它是以具有闪电般的速度被介绍的。于是在脑子里， Disruptor 和“闪电”一词关联了起来，然而却一直没有时间去探究一下。 最近正在进行一项对性能有很高要求的产品项目的研究，自然想起了闪电般的 Disruptor ，这必有它的用武之地，于是进行了一番探查，将成果和体会记录在案。 一、什么是 Disruptor 从功能上来看，Disruptor 是实现了“队列”的功能，而且是一个有界队列。那么它的应用场景自然就是“生产者-消费者”模型的应用场合了。 可以拿 JDK 的 BlockingQueue 做一个简单对比，以便更好地认识 Disruptor 是什么。 我们知道 BlockingQueue 是一个 FIFO 队列，生产者(Producer)往队列里发布(publish)一项事件(或称之为“消息”也可以)时，消费者(Consumer)能获得通知；如果没有事件时，消费者被堵塞，直到生产者发布了新的事件。 这些都是 Disruptor 能做到的，与之不同的是，Disruptor 能做更多： 同一个“事件”可以有多个消费者，消费者之间既可以并行处理，也可以相互依赖形成处理的先后次序(形成一个依赖图)； 预分配用于存储事件内容的内存空间； 针对极高的性能目标而实现的极度优化和无锁的设计； 以上的描述虽然简单地指出了

1、单生产者和多生产者 One of the best ways to improve performance in concurrect systems is to ahere to the Single Writer Princple, this applies to the Disruptor. If you are in the situation where there will only ever be a single thread producing events into the Disruptor, then you can take advantage of this to gain additional performance. 上述的描述大致的意思是在多并发的系统中，如果选择基于单生产者的Disruptor，能够获得比多生产者更好的性能。 2、可选择的等待策略 1）Disruptor默认的等待策略是BlockingWaitStrategy。内部是使用lock和condition来进行线程间的协作的。相对于其他的策略是最慢的但对cpu的使用是最保守的，也是所有选项中一致性行为最高的。 2）和BlockingWaitStrategy一样，SleepingWaitStrategy尝试保守的使用cpu，通过使用busy wait loop