disruptor 为什么快_disruptor_disrupter(3)

②避免GC：写Java程序的时候，很习惯随手new各种对象，虽然Java的GC会负责回收，但是系统在高压力情况下频繁的new必定导致更频繁的GC，Disruptor避免这个问题的策略是：提前分配。在创建RingBuffer实例时，参数中要求给出缓冲区元素类型的Factory，创建实例时，Ring Buffer会首先将整个缓冲区填满为Factory所产生的实例，后面生产者生产时，不再用传统做法（顺手new一个实例出来然后add到buffer中），而是获得之前已经new好的实例，然后设置其中的值。举个形象的例子就是，若缓冲区是个放很多纸片的地方，纸片上记录着信息，以前的做法是：每次加入缓冲区时，都从系统那现准备一张纸片，然后再写好纸片放进缓冲区，消费完就随手扔掉。现在的做法是：实现准备好所有的纸片，想放入时只需要擦掉原来的信息写上新的即可。

③成批操作（Batch）：Ring Buffer的核心操作是生产和消费，如果能减少这两个操作的次数，性能必然相应地提高。Disruptor中使用成批操作来减少生产和消费的次数，下体说一下Disruptor的生产和消费过程中如何体现Batch的。向RingBuffer生产东西的时候，需要经过2个阶段：阶段一为申请空间，申请后生产者获得了一个指针范围[low,high]，然后再对缓冲区中[low,high]这段的所有对象进行setValue（见优化点②），阶段2为发布（像这样ringBuffer.publish(low,high);）。阶段1结束后，其他生产者再申请的话，会得到另一段缓冲区。阶段2结束后，之前申请的这一段数据就可以被消费者读到。Disruptor推荐成批生产、成批发布，减少生产时的同步带来的性能损失。从RingBuffer消费东西的时候也需要两个阶段，阶段一为等待生产者的（写）指针值超过指定值（N，即N之前的数据已经消费过了），阶段一执行完后，消费者会得到一个指针值（R），表示Ring Buffer中下标R之前的值是可以读的。阶段2就是具体读取（略）。阶段一返回值R很有可能大于N，此时消费者应该进行成批读取操作，将[R,N]范围内的数据全部处理。

④LMAX架构：（注：指的是LMAX公司在做他们的交易平台时使用的一些设计思想的集合，严格讲是LMAX架构包含了Disruptor，并非其中的一部分，但是Disruptor的设计中或多或少体现了这些思想，所以在这还是要提一下，关于LMAX架构应该可以写很多，但限于个人水平，在这只能简单说说。另外，这个架构是以及极端追求性能的产物，不一定适合大众。）如下图所示LMAX架构分为三个部分，输入/输出Disruptor，和中间核心的业务逻辑处理器。所有的信息输入进入InputDisruptor，被业务逻辑处理器读取后送入OutputDisruptor，最后输出到其他地方。

对于一般由表现层+业务层+持久层组成的Web系统，LMAX架构指的是业务层，它有如下几个特点：

a)业务逻辑处理器（简称BLP）完全的In-Memory：如上图，业务逻辑处理器是处理所有业务逻辑的地方，Input Disruptor把输入（例如订单数据、用户操作）以消息的形式（称作Message或者Event都可以）发到BLP，BLP进行响应。一般系统中我们可能会多线程执行一些业务逻辑代码，然后这些代码最终生成一些*QL语句，然后这些语句再去查，可能在其他主机，查询结果可能直接用了内存中的缓存，最坏情况是从磁盘中读取了想要的数据，最后再返回给业务逻辑代码。这个过程有很多的时间浪费：首先，多线程访问持久层会涉及到同步问题（锁，有是这货）。其次，生成*QL语句、查询的耗时也是非常大的。最后，最坏情况下还要进行一大串磁盘IO和内存IO才能取到数据。LMAX对此的解决方案是：把能用到的所有数据全部装入内存，只有到极少数或周期性需要同步、持久化的时候再访问。（这听起来有点疯狂，但是仔细想想这些业务真的需要那么大空间吗？）这么做的好处也是显而易见，减少了网络、磁盘的IO后In-Memory系统上的大部分业务逻辑全都变成一些加减乘除运算了。

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