Disruptor

从构建分布式秒杀系统聊聊Disruptor高性能队列 https://blog.52itstyle.vip/archives/2911/ Disruptor与BlockingQueue压力测试性能对比 https://blog.csdn.net/danielzhou888/article/details/86683771 disruptor框架为什么这么强大 https://blog.csdn.net/liweisnake/article/details/9113119 并发框架disruptor（高性能内存Queue） https://blog.csdn.net/fenglongmiao/article/details/79203788 来源： https://www.cnblogs.com/tonggc1668/p/11777837.html

Ring Buffer : The Ring Buffer is often considered the main aspect of the Disruptor, however from 3.0 onwards the Ring Buffer is only responsible for the storing and updating of the data (Events) that move through the Disruptor. And for some advanced use cases can be completely replaced by the user. Sequence : The Disruptor uses Sequences as a means to identify where a particular component is up to. Each consumer (EventProcessor) maintains a Sequence as does the Disruptor itself. The majority of the concurrent code relies on the the movement of these Sequence values, hence the Sequence supports

demo1 单生产者多消费者创建。 maven 依赖 <dependency> <groupId>com.lmax</groupId> <artifactId>disruptor</artifactId> <version>3.4.2</version> </dependency> 1 对象 - Message @Data @AllArgsConstructor @NoArgsConstructor @Builder public class Message2 { private String id; private String name; private double price; } 2 在主函数中创建 disruptor Disruptor disruptor = new Disruptor<>( new EventFactory() { @Override public Message2 newInstance() { return new Message2(); } }, 1 << 10, Executors.defaultThreadFactory(), ProducerType.SINGLE, new BusySpinWaitStrategy() ); 3 disruptor 绑定消费者 // disruptor 绑定消费者 disruptor

秒杀架构持续优化中，基于自身认知不足之处在所难免，也请大家指正，共同进步。文章标题来自码友的建议，希望可以把阻塞队列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 java实现的线程间通信的高性能低延迟消息组件，也就是消息队列，相比于BlockingQueue 最大的特点在于无锁的机制，性能提高一倍以上，常用于金融行业。 核心机制 1）无锁 CAS 使用了CPU级别的CAS指令，比os级的 lock快很多 ，避免了上下文切换。 2）数组减小GC开销 使用环形数组，而不是链表的数组结构存储数据，数组预分配，避免JavaGC的开销r 3）避免伪共享 数组顺序执行，利用了cpu的缓存特性，不至于 经常缓存失效，重新到内存读，提高缓存命中率。disruptor会尽量将两个不相关的内存隔离到两个缓存行上，不过要牺牲空间。一个缓存行可能128字节或者64字节。可重用大于替换。 环形数组结构 为了避免垃圾回收，采用数组而非链表。同时，数组对处理器的缓存机制更加友好。 元素位置定位 数组长度2^n，通过位运算，加快定位的速度。下标采取递增的形式。不用担心index溢出的问题。index是long类型，即使100万QPS的处理速度，也需要30万年才能用完。 9 223 372 036 854 775 807 无锁设计 每个生产者或者消费者线程，会先申请可以操作的元素在数组中的位置，申请到之后，直接在该位置写入或者读取数据。 核心组件 RingBuffer

前言 到了年底果然都不太平，最近又收到了运维报警：表示有些服务器负载非常高，让我们定位问题。 还真是想什么来什么，前些天还故意把某些服务器的负载提高（ 没错，老板让我写个 BUG！ ），不过还好是不同的环境互相没有影响。 定位问题 拿到问题后首先去服务器上看了看，发现运行的只有我们的 Java 应用。于是先用 ps 命令拿到了应用的 PID 。 接着使用 top -Hp pid 将这个进程的线程显示出来。输入大写的 P 可以将线程按照 CPU 使用比例排序，于是得到以下结果。 果然某些线程的 CPU 使用率非常高。 为了方便定位问题我立马使用 jstack pid > pid.log 将线程栈 dump 到日志文件中。 我在上面 100% 的线程中随机选了一个 pid=194283 转换为 16 进制（2f6eb）后在线程快照中查询： 因为线程快照中线程 ID 都是16进制存放。 发现这是 Disruptor 的一个堆栈，前段时间正好解决过一个由于 Disruptor 队列引起的一次 OOM ： 强如 Disruptor 也发生内存溢出？ 没想到又来一出。 为了更加直观的查看线程的状态信息，我将快照信息上传到专门分析的平台上。 http://fastthread.io/ 其中有一项菜单展示了所有消耗 CPU 的线程，我仔细看了下发现几乎都是和上面的堆栈一样。 也就是说都是

disruptor发布了Java的2.0版本(.Net版本见 这里 )，disruptor是一个高性能的 异步 处理框架，或者可以认为是最快的消息框架(轻量的JMS)，也可以认为是一个观察者模式实现，或者 事件-监听模式 的实现，直接称disruptor模式。 disruptor最大特点是高性能， 其LMAX架构 可以获得每秒6百万订单，用1微秒的延迟获得吞吐量为100K+。 disruptor与传统高性能模型是不同的，LMAX团队通过测试发现热门的Actor模型在高并发设计有瓶颈，disruptor的RingBuffer根据多核CPU的高速 缓存 设计特点进行了优化，让每个CPU运行一个线程，多个CPU就是多线程并发模式了，正如团队所言：我们想出一个更好，更快的线程之间共享数据的方式，不与世界分享将是自私的，不共享知识让我们看上去是死聪明。 传统消息框架使用Queue队列，如JDK LinkedList等数据结构实现，RingBuffer比Linked之类数据结构要快，因为没有锁，是CPU友好型的。另外一个不同的地方是不会在清除RingBuffer中数据，只会覆盖，这样降低了垃圾回收机制启动频率。 使用案例代码： DisruptorWizard<MyEvent> dw = new DisruptorWizard<MyEvent>(MyEvent.FACTORY, 32,

1、背景 Martin Fowler在自己网站上写了一篇LMAX架构的文章，在文章中他介绍了LMAX是一种新型零售金融交易平台，它能够以很低的延迟产生大量交易。这个系统是建立在JVM平台上，其核心是一个业务逻辑处理器，它能够在一个线程里每秒处理6百万订单。业务逻辑处理器完全是运行在内存中，使用事件源驱动方式。业务逻辑处理器的核心是Disruptor。 2、什么是distruptor Disruptor它是一个开源的并发框架，并获得2011 Duke’s 程序框架创新奖，能够在无锁的情况下实现网络的Queue并发操作。 可以简单理解为一种高效的"生产者-消费者"模型，性能远远高于传统的BlockingQueue容器。在JDK的多线程与并发库一文中, 提到了BlockingQueue实现了生产者-消费者模型。BlockingQueue是基于锁实现的, 而锁的效率通常较低。没有使用CAS机制实现的生产者-消费者。Disruptor使用观察者模式, 主动将消息发送给消费者, 而不是等消费者从队列中取；在无锁的情况下, 实现queue(环形, RingBuffer)的并发操作, 性能远高于BlockingQueue。 下面介绍两者的差异性 将从下面几种线程情况下测试BlockingQueue和disruptor的吞吐量和性能测试。 对比测试结果 吞吐量结果 性能延迟测试结果