淘寶海量資料庫之二：一緻性選擇

衆所周知，一緻性是資料最關鍵的屬性之一。2000年，eric brewer教授在acm分布式計算年會上指出了著名的cap理論：

brewer, e. a. 2000. towards robust distributed systems. in proceedings of the 19th annual acm symposium on principles of distributed computing (july 16-19, portland, oregon)

即分布式系統不可能滿足一緻性(c: consistency)，可用性(a: availability)和分區容錯性(p: tolerance of network partition)這三個需求。

大約兩年後，seth gilbert 和 nancy lynch兩人證明了cap理論的正确性：

gilbert , s., lynch, n. 2002. brewer's conjecture and the feasibility of consistent, available, partition-tolerant web services. acm sigact news 33(2)

幾種常見的一緻性類型有：

強一緻性：系統中的某個資料被成功更新(事務成功傳回)後，後續任何對該資料的讀取操作都得到更新後的值。這是傳統關系資料庫提供的一緻性模型，也是關系資料庫深受人們喜愛的原因之一。

弱一緻性：系統中的某個資料被更新後，後續對該資料的讀取操作得到的不一定是更新後的值，這種情況下通常有個“不一緻性時間視窗”(inconsistency window)存在：即資料更新完成後在經過這個“不一緻性時間視窗”，後續讀取操作就能夠得到更新後的值。

最終一緻性：屬于弱一緻性的一種，即某個資料被更新後，如果該資料後續沒有被再次更新，那麼最終所有的讀取操作都會傳回更新後的值。

關于最終一緻性，werner vogels提出了nwr模型(eventually consistent - revisited, by werner vogels on december 23, 2008 12:15 am,   http://www.allthingsdistributed.com/2008/12/eventually_consistent.html)：

n：資料複制的份數(the number of nodes that store replicas of the data)

w：資料更新完成前需要到達的節點數(the number of replicas that need to acknowledge the receipt of the update before the update completes)

r：為了讀取正确資料需要讀取的節點數(the number of replicas that are contacted when a data object is accessed through a read operation)

werner vogels還寫到，如果w+r > n，那麼讀寫節點有重疊，讀總是能夠得到最新的資料，這就是強一緻性。在傳統的一主一備同步複制的關系資料庫中，n=2，w=2，r=1；在非同步複制模型中，w變成1，此時w+r=n，一緻性也就無法保證。

不過，nwr模型隻代表了一類情形，例如，在傳統的一主一備的非同步複制的關系資料庫中，盡管n=2，w=1，r=1，如果隻有主庫提供服務，則一緻性仍然是保證的，不過主機異常時，服務的恢複不是實時的，是以cap理論依然适用。

在調研中，我們發現一些項目正在或傾向于弱一緻性或最終一緻性，咋看這似乎表明這些工程師偏愛弱一緻性或最終一緻性。然而，在經過仔細溝通和深入分析後，我們發現，這些項目采用弱一緻性或最終一緻性，其實是在高資料量(十幾億條記錄、數tb資料)和高通路量(數千tps、數萬qps)需求壓力之下的無奈選擇。如果兩個系統都能滿足上述高資料量和高通路量需求且成本差異不是很大，那麼在強一緻性和若一緻性(或最終一緻性)兩者中他們會毫不猶豫地選擇前者。

顯而易見，作為整個系統中最為基礎的部件，如果資料庫的資料是弱一緻，那麼上層應用就不得不承受這種弱一緻導緻的種種後果，從上層應用的角度看，這并不是十分友善的行為。由于上述原因，我們決心在我們的海量資料庫中實作與傳統關系資料庫相同的強一緻性，因為我們相信這種強一緻性不僅會簡化資料庫的管理，減輕資料庫管理的工作量，尤其重要的是，上層應用不再需要關注資料的不一緻性，應用程式也會是以而簡化，并且易于開發和維護。