原文：Disruptor 2.0 – All Change Please 譯者：楊帆
馬丁最近發佈了Disruptor的2.0版本，從我們開始將其開源以來發生了很多變化，現在是個時候推出一個正式的里程碑了。馬丁的博客上涵蓋了這次更新的所有內容，這篇文章的目的是嘗試把我以前的博文以新框架的架構轉述給大家，因爲將它們都重寫一遍要耗費很多時間。現在我看到手工繪圖的缺點了。
在舊的版本中：
這是一個Disruptor的配置示例，具體上來說就是一個菱形的結構。如果你對此毫無感覺，可以回過頭複習下disruptor的細節。
對於2.0版的主要變化有3點：
- 更貼切的命名；
- 把producer barrier（生產者屏障）整合進了ring buffer；
- 將Disruptor Wizard加入了主代碼庫。
新版本：
你可以看到基本原理還是類似的。新版本更加簡單，因爲ProducerBarrier本身不再作爲一個單獨的實體存在，它的替代者是PublishPort 接口，且RingBuffer自身就實現了這個接口。 類似地，DependencyBarrier替代ConsumerBarrier ，釐清了此對象的職責。另外，Publisher (Producer的替代者)和EventProcessor(替代了Consumer)也更能精確地體現出它們的行爲。Consumer這個名字總是會帶來一些混淆，因爲因爲其實消費者從來不從ring buffer消費任何東西。Consumer之前僅僅是用於隊列實現的一個術語。
圖上沒有表現出來的變動是以前存在ring buffer裏的東西叫entry(輸入條目），而現在改名叫Event（事件）了，相應的就是EventProcessor。
整個命名上的大規模更改是爲了讓大家更清晰的明白Disruptor是如何工作的，以及該如何使用它。儘管我們把它用在事件處理上，但是當我們開源它的時候，還是希望它看起來可以更像一個通用的解決方案，所以命名慣例也傾向於表述這個事實。但是事件模型看起來確實更直觀一些，於是我們就改成這個命名了。
另外由於Wizard的引入，事件發佈者和事件處理者之間的接駁更加簡單了。
現在如果你想建立一個菱形的Disruptor模式（例如FizzBuzz性能測試），一切變得優雅很多：
|
01 |
DisruptorWizard dw = new DisruptorWizard( |
|
02 |
ENTRY_FACTORY, |
|
03 |
RING_BUFFER_SIZE, |
|
04 |
EXECUTOR, |
|
05 |
ClaimStrategy.Option.SINGLE_THREADED, |
|
06 |
WaitStrategy.Option.YIELDING); |
|
07 |
FizzBuzzEventHandler fizzHandler = |
|
08 |
new FizzBuzzEventHandler(FIZZ); |
|
09 |
FizzBuzzEventHandler buzzHandler = |
|
10 |
new FizzBuzzEventHandler(BUZZ); |
|
11 |
FizzBuzzEventHandler fizzBuzzHandler = |
|
12 |
new FizzBuzzEventHandler(FIZZ_BUZZ); |
|
13 |
|
14 |
dw.handleEventsWith(fizzHandler, buzzHandler) |
|
15 |
.then(fizzBuzzHandler); |
|
16 |
|
17 |
RingBuffer ringBuffer = dw.start(); |
其它變化：性能提升
馬丁在他博客提到過，他已經成功的提高了2.0版的性能。 在2.0版中還有一個閃耀的新成員Sequence（序列），它被用來搞緩存行填充，並消除了對內存屏障的需要。現在緩存行填充的做法和以前略有不同，因爲JAVA7新的優化特性，它成功的“優化”掉了我們原來的技術方案。
那麼就到這裏吧，這篇博文我就是想給大家一個簡明的更新摘要，並且解釋我以前畫的圖爲什麼可能不再正確了。
轉載自併發編程網 – ifeve.com本文鏈接地址: Disruptor 2.0更新摘要
如何使用Disruptor（一）Ringbuffer的特別之處
如何使用Disruptor（二）如何從Ringbuffer讀取
LMAX Disruptor——一個高性能、低延遲且簡單的框架
Disruptor Wizard已死，Disruptor Wizard永存！