Disruptor是LMAX公司開源的一個高效的記憶體無鎖佇列。這兩天看了一下相關的設計文件和部落格，下面嘗試進行一下總結。

第一部分。引子
談到併發程式設計，有幾個概念是避免不了的。

1.鎖：鎖是用來做併發最簡單的方式，當然其代價也是最高的。核心態的鎖的時候需要作業系統進行一次上下文切換，等待鎖的執行緒會被掛起直至鎖釋放。在上下文切換的時候，cpu之前快取的指令和資料都將失效，對效能有很大的損失。使用者態的鎖雖然避免了這些問題，但是其實它們只是在沒有真實的競爭時才有效。下面是一個計數實驗中不加鎖、使用鎖、使用CAS及定義volatile變數之間的效能對比。

2. CAS： CAS的涵義不多介紹了。使用CAS時不像上鎖那樣需要一次上下文切換，但是也需要處理器鎖住它的指令流水線來保證原子性，並且還要加上Memory Barrier來保證其結果可見。

3. Memory Barrier: 大家都知道現代CPU是亂序執行的，也就是程式順序與實際的執行順序很可能是不一致的。在單執行緒執行時這不是個問題，但是在多執行緒環境下這種亂序就可能會對執行結果產生很大的影響了。memory barrier提供了一種控制程式執行順序的手段, 關於其更多介紹，可以參考 http://en.wikipedia.org/wiki/Memory_barrier

4. Cache Line：cache line解釋起來其實很簡單，就是CPU在做快取的時候有個最小快取單元，在同一個單元內的資料被同時被載入到快取中，充分利用 cache line可以大大降低資料讀寫的延遲，錯誤利用cache line也會導致快取不同替換，反覆失效。

好，接下來談一談設計併發記憶體佇列時需要考慮的問題。一就是資料結構的問題，是選用定長的陣列還是可變的連結串列，二是併發控問題，是使用鎖還是CAS操作，是使用粗粒度的一把鎖還是將佇列的頭、尾、和容量三個變數分開控制，即使分開，能不能避免它們落入同一個Cache line中呢。
我們再回過頭來思考一下佇列的使用場景。通常我們的處理會形成一條流水線或者圖結構，佇列被用來作為這些流程中間的銜接表示它們之間的依賴關係，同時起到一個緩衝的作用。但是使用佇列並不是沒有代價的，實際上資料的入隊和出隊都是很耗時的，尤其在效能要求極高的場景中，這種消耗更顯得奢侈。如果這種依賴能夠不通過在各個流程之間放一個佇列來表示那就好啦！
第二部分 正文

1.列隊中的元素如何儲存？
Disruptor的中心資料結構是一個基於定長陣列的環形佇列，如圖1。
在陣列建立時可以預先分配好空間，插入新元素時只要將新元素資料拷貝到已經分配好的記憶體中即可。對陣列的元素訪問對CPU cache 是非常友好的。關於陣列的大小選擇有一個講究，大家都知道環形佇列中會用到取餘操作， 在大部分處理器上，取餘操作並不高效。因此可以將陣列大小設定為2的指數倍，這樣計算餘數只需要通過位操作 index & ( size -1 )就能夠得到實際的index。
Disruptor對外只有一個變數，那就是隊尾元素的下標：cursor，這也避免了對head/tail這兩個變數的操作和協同。生產者和消費者對disruptor的訪問分別需要通過producer barrier和consumer barrier來協調。關於這兩個barrier是啥，後面會介紹。

圖1. RingBuffer,當前的隊尾元素位置為18

2.生產者如何向佇列中插入元素？
生產者插入元素分為兩個步驟，第一步申請一個空的slot, 每個slot只會被一個生產者佔用，申請到空的slot的生產者將新元素的資料拷貝到該slot；第二步是釋出，釋出之後，新元素才能為消費者所見。如果只有一個生產者，第一步申請操作無需同步即可完成。如果有多個生產者，那麼會有一個變數：claimSequence來記錄申請位置，申請操作需要通過CAS來同步，例如圖二中，如果兩個生產者都想申請第19號slot, 則它們會同時執行CAS(&claimSequence, 18, 19)，執行成功的人得到該slot，另一個則需要繼續申請下一個可用的slot。在disruptor中，釋出成功的順序與申請的順序是嚴格保持一致的，在實現上，釋出事件實際上就是修改cursor的值，操作等價於CAS(&cursor, myslot-1, myslot)，從此操作也可以看出，釋出執行成功的順序必定是slot, slot 1, slot 2 ….嚴格有序的。另外，為了防止生產者生產過快，在環形佇列中覆蓋消費者的資料，生產者要對消費者的消費情況進行跟蹤，實現上就是去讀取一下每個消費者當前的消費位置。例如一個環形佇列的大小是8，有兩個消費者的分別消費到第13和14號元素，那麼生產者生產的新元素是不能超過20的。插入元素的過程圖示如下：

圖2. RingBuffer當前的隊尾位置序號為18.生產者提出申請。

圖3. 生產者申請得到第19號位置，並且19號位置是獨佔的，可以寫入生產元素。此時19號元素對消費者是不可見的。

圖4，生產者成功寫入19號位置後，將cursor修改為19，從而完成釋出，之後消費者可以消費19號元素。

3.消費者如何獲知有新的元素進來了？
消費者需要等待有新元素進入方能繼續消費，也就是說cursor大於自己當前的消費位置。等待策略有多種。可以選擇sleep wait, busy spin等等，在使用disruptor時，可以根據場景選擇不同的等待策略。

4.批量
如果消費者發現cursor相比其最後的一次消費位置前進了不止一個位置，它就可以選擇批量消費這區段的元素，而不是一次一個的向前推進。這種做法在提高吞吐量的同時還可以使系統的延遲更加平滑。

5.依賴圖
前面也提過，在傳統的系統中，通常使用佇列來表示多個處理流程之間的依賴，並且一步依賴就需要多新增一個佇列。在Disruptor中，由於生產者和消費者是分開考慮和控制的，因此有可能能夠通過一個核心的環形佇列來表示全部的依賴關係，可以大大提高吞吐，降低延遲。當然，要達到這個目的，還需要使用者細心地去設計。下面舉一個簡單的例子來說明如何使用disruptor來表示依賴關係。

第三部分 結束語
disruptor本身是用java寫的，但是筆者認為在c 中更能體現其優點，自己也山寨了一個c 版本。在一個生產者和一個消費者的場景中測試表明，無鎖佇列相比有鎖佇列，qps有大約10倍的提升，latency更是有幾百倍的提升。不管怎麼樣，現在大家都漸漸都這麼一個意識了：鎖是效能殺手。所以這些無鎖的資料結構和演算法，可以嘗試借鑑來使用在合適的場景中。

轉載自：http://www.searchtb.com/2012/10/introduction_to_disruptor.html