978
技術社區[雲棲]
無鎖並發和無等待並發的對比分析
有兩種非阻塞線程同步算法，即無鎖和無等待，這兩種算法經常會產生混淆。
在無鎖係統中，當任何特定的運算被阻塞的時候，所有CPU可以繼續處理其他的運算。換種方式說，在無鎖係統中， 當給定線程被其他線程阻塞的時候，所有CPU可以不停的繼續處理其他工作。無鎖算法大大增加係統整體的吞吐量，因為它隻偶爾會增加一定的交易延遲。大部分 高端數據庫係統是基於無鎖算法而構造的，以滿足不同級別。
相反，無等待算法保證了所有CPU在連續處理有效工作的時候，沒有運算會被其他運算所阻塞。相比於無鎖算法，無等待算法有更強的保證，並且不會以交 易延遲為代價，來保證高吞吐量。當然，相比之下這種算法也更難實現，測試和debug。Linux kernel的無鎖頁麵緩存就是無等待係統的一個典型案例。
在某些情況下，例如係統在處理一些並發交易並且有一些輕微的延遲請求，無鎖係統是在開發難度和高並發請求的一個好的折中選擇。網站的數據庫服務器就 是一個很好的無鎖設計的例子。當任何請求交易被阻塞，同時總是有更多的交易在被處理，因此CPU永遠不會空閑。難點就是要建立一個交易調度器，來維護一個 比較好的平均延遲和一定的誤差。
在某些場景下，係統擁有和cpu核心數量相似的並發交易，或者很準確的實時請求，開發者就需要花費更多的時間去構建無等待係統了。在這種案例中，例 如：阻斷單一交易是不行的，因為cpu沒有其他交易可以操作，最小的吞吐量，或指定的交易需要在一個非概率化的時間段內完成。核反應控製軟件就是一個無等 待係統的絕好案例。
RethinkDB是一個無鎖係統。在一台具備N個CPU核心的機器上，在大量正常負載的情況下，我們可以保證沒有任何核心會處於空閑狀態，隻要有大約N×4的並發交易，則可以保證沒有io管道容量被浪費。例如，一個8核心的係統，如果RethinkDB正在處理大概32個或更多的並發交易時，沒有任何硬件會處於空閑。如果通常隻有少於32筆的並發交易，那麼有些核心也許是浪費了。（當然如果你僅僅有32筆並發數量的話，也不需要一個8核的機器）
文章轉自 並發編程網-ifeve.com
最後更新：2017-05-22 17:01:21