下一代NoSQL：最終一致性的末日？

數據與實際時間不一樣步致使開發者在構建數據庫時老是接受一些折衷的辦法，可是若是你能改變這種情況將會怎樣？

相比關係型數據庫，NoSQL解決方案提供了shared-nothing、容錯和可擴展的分佈式架構等特性，同時也放棄了關係型數據庫的強數據一致性和隔離性，美其名曰：「最終一致性」。

最終一致性將讀取不一致和不可靠的寫帶來的麻煩推給了軟件開發人員。以如此弱的數據保證能力構建一個現在互聯網需求的複雜、可擴展的系統是異常困難的，咱們須要中止接受最終一致性，去探索能提供數據強一致性的可擴展的、分佈式數據庫設計。

最終一致性的概念頻繁出如今分佈式數據庫的討論中，主要的NoSQL數據庫像Riak、Couchbase和DynamoDB，爲客戶端程序提供了「最終一致性」，MongoDB和Cassandra在一些配置中保證最終一致性。

最終一致性意味着：該系統最終一致——若是至關長的一段時間內，沒有更新一個給定的數據項，最終，硬件和網絡故障修復之後，全部該項目的讀取都將返回相同一致的值。這也意味着：若是客戶沒有等足夠長的時間，他們根本不能保證一致性。

最終一致性的問題

雖然最終一致性被吹捧爲一種新的模式，但它一樣有必定的負面含義，由於它不是在全部的狀況下都很吸引人，這和分佈式系統是同樣的。

當一個工程師使用最終一致性數據庫構建一個應用程序時，他們每次從數據庫訪問數據都要解決一些棘手的問題：

• 若是數據庫讀取返回一個任意的舊值對應用程序的影響是什麼？
• 若是對數據庫的修改順序發生了錯誤對應用程序的影響是什麼？
• 若是我在其餘用戶修改數據庫時，讀取數據對應用程序的影響是什麼？
• 個人數據庫更新對其它試圖讀取數據的客戶有什麼影響？

這是一個繁重的任務，而且佔用大量的開發人員的時間。從本質上說，工程師須要手動去大量的工做，以確保多個用戶不產生衝突和處理過時數據。

最終一致性帶給軟件開發者巨大的負擔，在一個不能保證準確性的數據庫上，設計一個準確的應用程序是一個巨大的挑戰。谷歌最近發佈的一篇關於其F1數據庫的論文中指出了最終一致性的痛點：

谷歌在最終一致性系統方面有不少的經驗。在全部這些系統中，咱們發現開發人員花費至關一部分時間構建極其複雜且容易出錯的機制來應對最終一致性和處理可能過期的數據。咱們認爲這是一個不可接受的強加給開發者的負擔，而且一致性問題應該在數據庫級別解決。

爲何是最終一致性？

構建一個最終一致性數據庫有兩個優點，一是構建一個弱一致性保證的系統更容易，第二個是從大型數據庫機器中分割出來的數據庫服務器仍然能夠接受應用程序的寫入。然而，第二個理由是由第一代NoSQL系統的創始人給出的，其可信度值得探究。

許多第一代NoSQL系統設計都是基於對Eric Brewer的CAP定理的早期理解：(C)onsistency、(A)vailability和(P)artition-tolerance三者只能知足兩個。

這個定理適用於任何通訊網絡可能出錯的分佈式系統，根據這個原理，假設系統的可用性是必不可少的，早期的NoSQL數據庫放棄了一致性（即採用了最終一致性）。

怎樣解決這個問題？

CAP理論中的可用性，意味着每個節點即便沒法與系統其它部分通訊時，仍然可以讀取和寫入。很容易看到可用性和一致性的矛盾：若是一個節點不能與其它任何節點通訊，怎麼能保持它們的一致性？

然而，一個優秀的備選方案是可能的：一個分區內部分結點可讀寫的系統是不可用的，從CAP理論來看是不可用的，可是從用戶仍然可以與鏈接的節點進行交互的角度來講是可用的。能夠構建這種沒有單點故障的容錯型數據庫，而不是訴諸最終一致性。

處理最終一致性帶來的麻煩不該該交給開發人員去處理。供應商應該中止以CAP定理做爲理由來推崇最終一致性。新的分佈式、一致的系統，例如谷歌的Spanner，在強一致性和高可用性之間演示了虛假的一種權衡。

下一代的商業分佈式強一致性數據庫雖然不容易構建，但它們將比它們的前任更增強大。像第一代，它們擁有真正的shared-nothing分佈式架構、容錯性和可擴展性。然而，相比最終一致性，他們也應該採起更強有力的模型如ACID，使他們在企業生產工具中更強大。

引用自http://www.csdn.net/article/2013-11-07/2817420