《NoSQL權威指南》——1.7 伺服器端一緻性

本節書摘來自異步社群出版社《nosql權威指南》一書中的第1章，第1.7節，作者：【美】joe celko（喬•塞科） ，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。

在伺服器端，我們可能在幾個節點，但不一定是所有的節點，擁有相同的資料。如果所有n個節點都在一個資料值上達成一緻，那麼我們确定這個資料就是對的。生活是美好的。

但是，在針對“更新”建立共識的過程中，我們需要知道到目前為止郵件清單外有多少節點确認收到更新。我們正在尋找一個仲裁規則來審計節點故障和不完整複制。這些規則與應用程式不同。大型銀行轉賬可能想要在所有節點上完全一緻。一個網站購物車應用程式隻要滿足下面的條件就是令人滿意的：客戶傳回給任何服務節點購物車的某個版本，使用者就可以繼續購物，即使有一些丢失的物品也沒關系。隻要確定當使用者點選“結賬”按鈕時其他節點知道要删除其購物車的本地副本就可以。

我們不希望将節點的突發緊急重新啟動作為預設動作。早期的檔案系統是就是以這種方式工作的。幾十年前，我的妻子為處理社會保障資料的保險公司工作，一個打卡故障會中止整批處理，并發出無用的錯誤消息。

我們希望系統會設計有優雅的降級機制。sabre的航空訂票系統會排出少量的重複訂票。如果某個人有兩次沖突的或備援的訂票，不會有什麼問題，因為一名乘客無法同時做兩個座位，在同一個座位也無法乘坐兩次，問題會通過人為方式或者問題本身的邏輯來解決。

當某一個節點過載時，你可能會容忍降低性能并将部分負載遷移到其他節點，直到第一個系統得以修複。最好的例子是獨立磁盤備援陣列（redundant array of independent disks，raid）系統。當一個磁盤發生故障時，它在實體上從陣列中删除并插入一個新的單元來取代它。在故障磁盤重建的過程中，通路的性能将會有一點點下降。在系統繼續運作其日常任務時，資料必須從被替換陣列磁盤中複制到新磁盤。