Disruptor

本次代码测试基于相同的 容量、生产线程数、单个线程生产量， 仅有一个消费线程。 修改各参数得到的结果： 数据规模、并发线程数、 最主要的是容量小时：Disruptor没有优势 2019-08-29T07:42:35.235Z 线程数：64 单线程生产量: 2048 容量：32 数据总量：131072 2019-11-26T07:57:42.087Z dataEvent newInstance: 1 2019-11-26T07:57:42.087Z dataEvent newInstance: 2 ... 2019-11-26T07:57:42.087Z dataEvent newInstance: 64 2019-08-29T07:42:48.742Z EventProcessor wrapper 2019-08-29T07:42:48.743Z disruptor start success！ 2019-08-29T07:42:51.113Z 处理的sequence：131071 count：131072 Disruptor 总耗时：2369 2019-08-29T07:42:36.200Z ArrayBlockingQueue 生产耗时：962 2019-08-29T07:42:36.200Z 处理count：131072 ArrayBlockingQueue 消费耗时：962

Disruptor是什么？ Disruptor是一个高性能的异步处理框架，或者可以认为是线程间通信的高效低延时的内存消息组件，它最大特点是高性能，其LMAX架构可以获得每秒6百万订单，用1微秒的延迟获得吞吐量为100K+。 它是如何实现高性能的呢？它由于JDK内置的队列有什么区别呢？ JDK内置内存队列？ 我们知道，Java内置了几种内存消息队列，如下所示： 队列 加锁方式 是否有界 数据结构 ArrayBlockingQueue 加锁 有界 ArrayList LinkedBlockingQueue 加锁 无界 LinkedList ConcurrentLinkedQueue CAS 无界 LinkedList LinkedTransferQueue CAS 无界 LinkedList 我们知道CAS算法比通过加锁实现同步性能高很多，而上表可以看出基于CAS实现的队列都是无界的，而有界队列是通过同步实现的。在系统稳定性要求比较高的场景下，为了防止生产者速度过快，如果采用无界队列会最终导致内存溢出，只能选择有界队列。而有界队列只有 ArrayBlockingQueue ，该队列是通过加锁实现的，在请求锁和释放锁时对性能开销很大，这时候基于有界队列的高性能的Disruptor就应运而生。 Disruptor如何实现高性能？ Disruptor实现高性能主要体现了去掉了锁

Storm技术增强 注：学习本课程，请先学习Storm基础 课程目标： 通过本模块的学习，能够掌握Storm底层的通信机制、消息容错机制、storm目录树及任务提交流程。 课程大纲： 1、 Storm程序的并发机制 2、 Storm框架通信机制（worker内部通信与外部通信） 3、 Storm组件本地目录树 4、 Storm zookeeper目录树 5、 Storm 任务提交的过程 1、Storm程序的并发机制 1.1、概念  Workers (JVMs): 在一个物理节点上可以运行一个或多个独立的JVM 进程。一个Topology可以包含一个或多个worker(并行的跑在不同的物理机上), 所以worker process就是执行一个topology的子集, 并且worker只能对应于一个topology  Executors (threads): 在一个worker JVM进程中运行着多个Java线程。一个executor线程可以执行一个或多个tasks。但一般默认每个executor只执行一个task。一个worker可以包含一个或多个executor, 每个component (spout或bolt)至少对应于一个executor, 所以可以说executor执行一个compenent的子集, 同时一个executor只能对应于一个component。 

最近翻看技术文章，发现一个叫做 disruptor 的高性能内存队列占据了头版头条，好奇其高性能的秘密，于是对该框架进行了一些简单的研究。 disruptor 并非新出，而是从2013年到现在经历了3个大版本的迭代。本文有如下几个部分： disruptor如何使用？ disruptor高性能的秘密？ 如何使用 核心概念： EventFactory：用于生成一个事件提供消费者消费 EventHandler：消费者处理器 事件和生产者：无内部接口，可以自己封装实体对象和RingBuffer RingBuffer：核心数据结构，可以理解为环形缓冲，disruptor高性能秘密 WaitStrategy：消费者阻塞时候的等待策略： SleepingWaitStrategy , BlockingWaitStrategy , BusySpinWaitStrategy , YieldingWaitStrategy Disruptor：disruptor框架入口，进行相关配置 事件和工厂 public static class LogEvent { String content; public void setContent(String content) { this.content = content; } } public static class LogEventFactory

Martin Fowler在自己网站上写了一篇 LMAX架构 的文章，在文章中他介绍了LMAX是一种新型零售金融交易平台，它能够以很低的延迟产生大量交易。这个系统是建立在JVM平台上，其核心是一个业务逻辑处理器，它能够在一个线程里每秒处理6百万订单。业务逻辑处理器完全是运行在内存中，使用事件源驱动方式。业务逻辑处理器的核心是Disruptor。 Disruptor它是一个开源的并发框架，并获得 2011 Duke’s 程序框架创新奖，能够在无锁的情况下实现网络的Queue并发操作。本文是 Disruptor官网 中发布的文章的译文（ 现在被移到了GitHub ）。 剖析Disruptor:为什么会这么快 剖析Disruptor:为什么会这么快？(一)锁的缺点 剖析Disruptor:为什么会这么快？(二)神奇的缓存行填充 剖析Disruptor:为什么会这么快？(三)伪共享 剖析Disruptor:为什么会这么快？(四)揭秘内存屏障 Disruptor如何工作和使用 如何使用Disruptor（一）Ringbuffer的特别之处 如何使用Disruptor（二）如何从Ringbuffer读取 如何使用Disruptor（三）写入Ringbuffer Disruptor(无锁并发框架)-发布 LMAX Disruptor——一个高性能、低延迟且简单的框架 Disruptor

RingBuffer ：基于数组的缓存实现，也是创建sequencer与定义WaitStrategy的入口 Disruptor :持有RingBuffer、消费者线程池Executor、消费者集合ConsumerRepository等引用 Sequence： 通过顺序递增的序号来编号，管理进行交换的数据（事件） 对数据（事件）的处理过程总是沿着序号逐个递增处理 一个 Sequence用于跟踪标识某个特定的事件处理着（RingBuffer、Producer、Consumer）的处理进度 可以看成是一个AtomicLong用于标识进度 防止不同 Sequence之间cpu缓存伪共享（Flase Sharing）的问题 Sequencer: 真正 Disruptor 核心 有两个实现：SingleProducerSequencer、 MultiProducerSequencer 主要实现生产者和消费者之间快速、正确地传递数据的并发算法 Sequence Barrier 用于保持对RingBuffer的Main Published Sequence（Producer）和Consumer之间的平衡关系； 还定义了决定Consumer是否还有可处理的事件的逻辑 WaitStrategy 决定一个消费者将如何等待生产者将Event置入 Disruptor 主要策略

1、初看Disruptor，给人的印象就是RingBuffer是其核心，生产者向RingBuffer中写入元素，消费者从RingBuffer中消费元素。 2、RingBuffer到底是什么？ 他是一个环（首尾相接的环） 他用作在不同上下文（线程）间传递数据的buffer RingBuffer拥有一个序号，这个序号指向数组中下一个可用元素 先获取下一个可用序号（4） 根据4获取再赋值 来源： https://my.oschina.net/u/3915790/blog/3112323

创建步骤： 简历一个工厂Event类，用于创建Event类实例对象 需要有一个监听事件类，用于处理数据（Event类） 实例化Disruptor实例，配置一系列参数，编写Disruptor核心组件 编写生产者组件，向Disruptor容器中去投递数据 简历一个工厂Event类，OrderEvent.java package com.bfxy.disruptor.quickstart; public class OrderEvent { //订单的价格 private long value; public long getValue() { return value; } public void setValue(long value) { this.value = value; } } OrderEventFactory.java package com.bfxy.disruptor.quickstart; import com.lmax.disruptor.EventFactory; public class OrderEventFactory implements EventFactory<OrderEvent>{ public OrderEvent newInstance() { return new OrderEvent(); //这个方法就是为了返回空的数据对象

为什么会有内存屏障？ 为了提升数据加载速度有了CPU缓存，在多核情况下带来了缓存一致性问题，可以通过MESI缓存一致性协议来解决。但MESI缓存一致性协议下，一个CPU可能需要等待另一个CPU响应后才能继续执行，导致了阻塞，影响性能（可以参考之前voltile那篇文章，因为涉及到总线加锁或者缓存锁）。所以增加了StoreBuffer和InvalidateQueue，也就是需要store时先放到StoreBuffer里，然后继续执行下一条指令，等到其他CPU响应返回后再处理对应store；收到invalidate通知时也不立即处理，而是先放到InvalidateQueue，并立即给予对方响应，然后等到合适时机再一起处理。这种优化提升了CPU执行能力，但也使得MESI协议的操作无法立即得到处理，产生了可见性和有序性问题。 什么是内存屏障？ 它是一个CPU指令。它是这样一条指令： a)确保一些特定操作执行的顺序。 b)影响一些数据的可见性(可能是某些指令执行后的结果)。 有序性：编译器和CPU可以在保证输出结果一样的情况下对指令重排序，使性能得到优化。插入一个内存屏障，相当于告诉CPU和编译器先于这个命令的必须先执行，后于这个命令的必须后执行。 可见性：内存屏障另一个作用是强制更新一次不同CPU的缓存。例如，一个写屏障会把这个屏障前写入的数据刷新到缓存

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