最近，我們開源了LMAX Disruptor， 它是我們的交易系統(tǒng)吞吐量快（LMAX是一個新型的交易平臺，號稱能夠單線程每秒處理數(shù)百萬的訂單）的關(guān)鍵原因。為什么我們要將其開源？我們意識到對高性 能編程領(lǐng)域的一些傳統(tǒng)觀點，有點不對勁。我們找到了一種更好、更快地在線程間共享數(shù)據(jù)的方法，如果不公開于業(yè)界共享的話，那未免太自私了。同時開源也讓我 們覺得看起來更酷。

從這個站點，你可以下載到一篇解釋什么是Disruptor及它為什么如此高性能的文檔。這篇文檔的編寫過程，我并沒有參與太多，只是簡單地插入了一些標(biāo)點符號和重組了一些我不懂的句子，但是非常高興的是，我仍然從中提升了自己的寫作水平。

我發(fā)現(xiàn)要把所有的事情一下子全部解釋清楚還是有點困難的，所有我準(zhǔn)備一部分一部分地解釋它們，以適合我的NADD聽眾。

首先介紹ringbuffer。我對Disruptor的最初印象就是ringbuffer。但是后來我意識到盡管ringbuffer是整個模式（Disruptor）的核心，但是Disruptor對ringbuffer的訪問控制策略才是真正的關(guān)鍵點所在。

ringbuffer到底是什么？

嗯，正如名字所說的一樣，它是一個環(huán)（首尾相接的環(huán)），你可以把它用做在不同上下文（線程）間傳遞數(shù)據(jù)的buffer。

（好吧，這是我通過畫圖板手畫的，我試著畫草圖，希望我的強迫癥不會讓我畫完美的圓和直線）

基本來說，ringbuffer擁有一個序號，這個序號指向數(shù)組中下一個可用的元素。（校對注：如下圖右邊的圖片表示序號，這個序號指向數(shù)組的索引4的位置。）

隨著你不停地填充這個buffer（可能也會有相應(yīng)的讀取），這個序號會一直增長，直到繞過這個環(huán)。

要找到數(shù)組中當(dāng)前序號指向的元素，可以通過mod操作：

sequence mod array length = array index           

以上面的ringbuffer為例（java的mod語法）：12 % 10 = 2。很簡單吧。

事實上，上圖中的ringbuffer只有10個槽完全是個意外。如果槽的個數(shù)是2的N次方更有利于基于二進制的計算機進行計算。

（校對注：2的N次方換成二進制就是1000，100，10，1這樣的數(shù)字， sequence & （array length－1） = array index，比如一共有8槽，3&（8－1）=3，HashMap就是用這個方式來定位數(shù)組元素的，這種方式比取模的速度更快。）

那又怎么樣？

如果你看了維基百科里面的關(guān)于環(huán)形buffer的 詞條，你就會發(fā)現(xiàn)，我們的實現(xiàn)方式，與其最大的區(qū)別在于：沒有尾指針。我們只維護了一個指向下一個可用位置的序號。這種實現(xiàn)是經(jīng)過深思熟慮的—我們選擇用 環(huán)形buffer的最初原因就是想要提供可靠的消息傳遞。我們需要將已經(jīng)被服務(wù)發(fā)送過的消息保存起來，這樣當(dāng)另外一個服務(wù)通過nak (校對注：拒絕應(yīng)答信號)告訴我們沒有成功收到消息時，我們能夠重新發(fā)送給他們。

聽起來，環(huán)形buffer非常適合這個場景。它維護了一個指向尾部的序號，當(dāng)收到nak(校對注：拒絕應(yīng)答信號)請求，可以重發(fā)從那一點到當(dāng)前序號之間的所有消息：

我們實現(xiàn)的ring buffer和大家常用的隊列之間的區(qū)別是，我們不刪除buffer中的數(shù)據(jù)，也就是說這些數(shù)據(jù)一直存放在buffer中，直到新的數(shù)據(jù)覆蓋他們。這就是 和維基百科版本相比，我們不需要尾指針的原因。ringbuffer本身并不控制是否需要重疊（決定是否重疊是生產(chǎn)者-消費者行為模式的一部分–如果你等 不急我寫blog來說明它們，那么可以自行檢出Disruptor項目）。

它為什么如此優(yōu)秀？

之所以ringbuffer采用這種數(shù)據(jù)結(jié)構(gòu)，是因為它在可靠消息傳遞方面有很好的性能。這就夠了，不過它還有一些其他的優(yōu)點。

首先，因為它是數(shù)組，所以要比鏈表快，而且有一個容易預(yù)測的訪問模式。（譯者注：數(shù)組內(nèi)元素的內(nèi)存地址的連續(xù)性存儲的）。這是對CPU緩存友好的—也就是說，在硬件級別，數(shù)組中的元素是會被預(yù)加載的，因此在ringbuffer當(dāng)中，cpu無需時不時去主存加載數(shù)組中的下一個元素。（校對注：因為只要一個元素被加載到緩存行，其他相鄰的幾個元素也會被加載進同一個緩存行）

其次，你可以為數(shù)組預(yù)先分配內(nèi)存，使得數(shù)組對象一直存在（除非程序終止）。這就意味著不需要花大量的時間用于垃圾回收。此外，不像鏈表那樣，需要為每一個添加到其上面的對象創(chuàng)造節(jié)點對象—對應(yīng)的，當(dāng)刪除節(jié)點時，需要執(zhí)行相應(yīng)的內(nèi)存清理操作。

缺少的部分

我并沒有在本文中介紹如何避免ringbuffer產(chǎn)生重疊，以及如何對ringbuffer進行讀寫操作。你可能注意到了我將ringbuffer和鏈表那樣的數(shù)據(jù)結(jié)構(gòu)進行比較，因為我并認(rèn)為鏈表是實際問題的標(biāo)準(zhǔn)答案。

當(dāng)你將Disruptor和基于 隊列之類的實現(xiàn)進行比較時，事情將變得很有趣。隊列通常注重維護隊列的頭尾元素，添加和刪除元素等。所有的這些我都沒有在ringbuffer里提到，這 是因為ringbuffer不負(fù)責(zé)這些事情，我們把這些操作都移到了數(shù)據(jù)結(jié)構(gòu)（ringbuffer）的外部

原文鏈接：http://ifeve.com/ringbuffer/

譯文鏈接：http://ifeve.com/dissecting-disruptor-whats-so-special/

網(wǎng)頁題目：如何使用Disruptor（一）Ringbuffer的特別
網(wǎng)頁鏈接：http://m.5511xx.com/article/cccdgdc.html