海量儲存之十四

這一次，我們來講講資料安全和讀寫高可用

oh no,親，於是我們又掉入了cap所描述的陷阱。好吧，那麼我們也就進入這個領域，來看看這資料安全所代表的一切。

在20年以前，資料安全對於大部分使用者來說，只意味著資料庫acid中的」d」，資料寫入到資料庫，並返回成功後，這個資料也就是安全的了，在老師教給我們的計算機原理課上，似乎最多也就講到，資料庫有冷備份，也有熱備份，因此寫入資料庫內的資料是安全的。

然而，真的如此麼？

可見，從目前來看，解決資料安全的唯一辦法是將資料同步的寫到多個不同的地方（可以是用raid5的方式寫，也可以用raid10的方式，不過核心都是乙個— 冗餘。

而且不能簡單的就用單機的冗餘，必須要多機冗餘才靠得住。

如果要最安全，那麼資料就要同步的複製多機。

下面，我們就專注於這同步複製多機的case，來看看目前我所知的幾種常見的，以解決高可用為基礎的資料冗餘方案吧。

需要強調的是，這些方案本身，沒有絕對的一家獨大之說，每一種方案，都有其自己的特性和適用場景，所以不存在某一種方案一定比其他方案好的這種說法，每一種模式都有其自己的優勢和劣勢。

所謂可用性，就是盡可能的保證，無論發生什麼變故，資料庫都能夠正常的提供讀寫訪問的這種方式。

而所謂安全性，就是盡可能的保證，無論發生什麼變故，資料庫內，持久化的資料都不會丟失。

這裡的資料丟失，其實是個很寬泛的詞彙，為了表達的更為清楚，我們需要仔細的描述乙個最關鍵的問題：什麼時候能夠叫做「資料寫入成功」，換句話說，也就是，資料儲存系統，與前端的無狀態呼叫者之間的承諾關係是什麼呢？

認清這個問題，對於我們定義資料安全，至關重要。

從乙個請求走到網路，提交給儲存系統的過程，細化下來可以認為是以下幾個動作的分解：

可以認為，在時間線上來說，所有的這些操作都可能出現！異常！，導致寫失敗。這裡又涉及到以前我們提到的網路三種反饋狀態問題了，讓我分階段來進行討論：

a. 客戶端發起請求出現失敗 -> 客戶端明確的知道自己失敗，所以所有操作都未進行，對整個系統的一致性沒有影響。

b. 發起請求後，因為網路因素，導致請求未被server接受 -> 客戶端等待，直到超時，但server未接受請求。客戶端應認為失敗。

c. server端接受到寫入請求，但內部操作失敗-> server端應該保證操作的原子性，並反饋client操作失敗。

d. server端一系列操作成功，反饋client，但因為網路異常導致client無法接收請求 ->server端成功，但client端等待超時，則client端對操作有疑問。

e. client端收到server端反饋的成功 -> 認為成功。

可以認為，只有最後一步成功的時候，才算做成功，而其他操作，因為網路因素導致的異常，都認為是失敗的。

從上面的分析中可以看出，儲存對於完整性的保證，只存在於e步驟成功時。

而client端能明確的知道操作失敗的，是a,，c場景。

client端不能明確知道操作成功或失敗的，是b，d，場景，需要人工驗證，或缺省丟超時異常，並被認為是失敗。

而我們所定義的資料安全性，就是指，當e完成時，也就是server對client端反饋成功時，則資料在各種變故出現時，所能保證的完整性的一種體現（ t_t ..真繞。。。）

而我們要在後面，花費大量篇幅來討論的，就是「進行一系列操作處理」這個過程，如何能保證資料的完整性的問題。

因為篇幅的關係，今次就介紹第一種，也是最簡單的一種，使用非同步複製佇列的方式來提公升可用性和安全性吧。

這是所有資料儲存中基本都提供的一種模式，而大部分的其他方案的核心和基礎都是這個非同步的複製的模型的權衡版本。所以，我們就從這裡開始。

要講清這個問題，我們先來看一張圖

所謂非同步傳輸，簡單來說就是資料寫入主機後，不等待其他機器反饋結果請求，直接反饋使用者寫入成功的一種策略。

好處：資料寫入速度快（因為只需要保證一台機器寫成功，那麼就算成功了）。

***：

如果主機寫了位置102，但備機還沒來得及收102的資料到備機，這時候主機down機。資料實際上還未寫入備機呢。於是就出現了資料丟失。

好，就到這裡。。下次我們來討論，在這種情況下，如何能夠保證可用性。

本文**於"阿里中介軟體團隊播客",原文發表時間"

2012-03-27"