原文地址：作者：rethinkdb  譯者：sooerr 校對：方騰飛

有兩種非阻塞執行緒同步演算法，即無鎖和無等待，這兩種演算法經常會產生混淆。

在無鎖系統中，當任何特定的運算被阻塞的時候，所有CPU可以繼續處理其他的運算。換種方式說，在無鎖系統中，當給定執行緒被其他執行緒阻塞的時候，所有CPU可以不停的繼續處理其他工作。無鎖演算法大大增加系統整體的吞吐量，因為它只偶爾會增加一定的交易延遲。大部分高階資料庫系統是基於無鎖演算法而構造的，以滿足不同級別。

相反，無等待演算法保證了所有CPU在連續處理有效工作的時候，沒有運算會被其他運算所阻塞。相比於無鎖演算法，無等待演算法有更強的保證，並且不會以交易延遲為代價，來保證高吞吐量。當然，相比之下這種演算法也更難實現，測試和debug。Linux kernel的無鎖頁面快取就是無等待系統的一個典型案例。

在某些情況下，例如系統在處理一些併發交易並且有一些輕微的延遲請求，無鎖系統是在開發難度和高併發請求的一個好的折中選擇。網站的資料庫伺服器就是一個很好的無鎖設計的例子。當任何請求交易被阻塞，同時總是有更多的交易在被處理，因此CPU永遠不會空閒。難點就是要建立一個交易排程器，來維護一個比較好的平均延遲和一定的誤差。

在某些場景下，系統擁有和cpu核心數量相似的併發交易，或者很準確的實時請求，開發者就需要花費更多的時間去構建無等待系統了。在這種案例中，例如：阻斷單一交易是不行的，因為cpu沒有其他交易可以操作，最小的吞吐量，或指定的交易需要在一個非概率化的時間段內完成。核反應控制軟體就是一個無等待系統的絕好案例。

RethinkDB是一個無鎖系統。在一臺具備N個CPU核心的機器上，在大量正常負載的情況下，我們可以保證沒有任何核心會處於空閒狀態，只要有大約N×4的併發交易，則可以保證沒有io管道容量被浪費。例如，一個8核心的系統，如果RethinkDB正在處理大概32個或更多的併發交易時，沒有任何硬體會處於空閒。如果通常只有少於32筆的併發交易，那麼有些核心也許是浪費了。（當然如果你僅僅有32筆併發數量的話，也不需要一個8核的機器）