Cosmos DB的5種事物一致性

TP和AP最重要的區別就是事物。事務是指對系統進行的一組操做，爲了保證系統的完整性，事務須要具備ACID特性，具體指原子性（Atomic）一致性（Consistency）隔離性（Isolation）持久性（Durability）。

微軟Build 2017發佈的Cosmos數據庫比較有意思，同時支持5個級別一致性。

一致性指的是事務的執行必須使資料庫從一個一致性狀態遷移至另外一個一致性狀態，事務的一致性決定了一個系統設計和實現的複雜度。

最多見的兩種模式是強制一致性（Strong consistency）與最終一致性（EventuallyConsistency），但Azure Cosmos DB額外提供了介於上述二者之間的 有邊界一致性（ Bounded Staleness）、事物一致性（Session）與單調一致性（ConsistentPrefix）等模式，容許開發人員依據程式的需求選擇適用的模式。

事務能夠不一樣程度的一致性：

強一致性：讀操做能夠當即讀到提交的更新操做

Bounded Staleness：提交的更新操做，不必定當即會被讀操做讀到，此種狀況會存在一個不一致窗口，指的是讀操做能夠讀到最新值的一段時間。

會話一致性：保證客戶端和服務器交互的會話過程當中，讀操做能夠讀到更新操做後的最新值。

單調一致性：若是一個進程已經讀到一個值，那麼後續不會讀到更早的值。

最終一致性：是弱一致性的特例。事務更新一份數據，最終一致性保證在沒有其餘事務更新一樣的值的話，最終全部的事務都會讀到以前事務更新的最新值。若是沒有錯誤發生，不一致窗口的大小依賴於：通訊延遲，系統負載等。

Cosmos DB在許多方面借鑑了DocumentDB，這不足爲奇。其中一個方面就是擁有可調整的一致性模型（consistency model）。若是你平時不常考慮全局分佈式數據庫，那麼一致性模型對你來講根本不是那麼重要，可是大多數與之競爭的數據庫系統（包括谷歌最近發佈的Cloud Spanner，https://cloud.google.com/spanner/）只有兩種一致性模型：強一致性（strong consistency）和最終一致性（eventualconsistency）。好比說，就強一致性而言，只要數據被寫入到數據庫，全部的不一樣節點（這些節點可能分佈於全球各地的數據中心）都要先就一個新的值達成一致，以後新的值纔出如今應用程序中。任什麼時候刻，任何用戶或節點均可以讀到最近一次成功更新的副本數據。因爲這種方法增添了延遲，這在性能方面顯然存在着一些不足。最終一致性其實是一種比較寬容的系統；全部節點並不一樣時更新，而是隻有在一段時間沒有任何最近的更新後，才就某個值達成一致。

CosmosDB不一樣尋常的地方在於，它提供了不一樣的一致性模型，那樣用戶能夠在得到多強的一致性與承受多大的性能開銷之間做一個取捨。好比說，對於Cosmos DB（以及以前的DocumentDB）而言，那意味着，你能夠選擇這種一致性模型：容許讀取操做比寫入操做只延後某一段時間（毫秒級），也能夠選擇這種一致性模型：專一於爲某種特定的客戶會話提供一致性（好比在相似Twitter的應用中），可是每一個用戶在同一時間（或者以徹底同樣的順序）看到每次寫入的數據又不是那麼重要。

ACID另外三個概念分佈是：

1.原子性（Atomic）
一個事務包含多個操做，這些操做要麼所有執行，要麼全都不執行。實現事務的原子性，要支持回滾操做，在某個操做失敗後，回滾到事務執行以前的狀態。
回滾其實是一個比較高層抽象的概念，大多數DB在實現事務時，是在事務操做的數據快照上進行的（好比，MVCC），並不修改實際的數據，若是有錯並不會提交，因此很天然的支持回滾。
而在其餘支持簡單事務的系統中，不會在快照上更新，而直接操做實際數據。能夠先預演一邊全部要執行的操做，若是失敗則這些操做不會被執行，經過這種方式很簡單的實現了原子性。

2. 隔離性（Isolation）
   併發事務之間互相影響的程度，好比一個事務會不會讀取到另外一個未提交的事務修改的數據。在事務併發操做時，可能出現的問題有：
   髒讀：事務A修改了一個數據，但未提交，事務B讀到了事務A未提交的更新結果，若是事務A提交失敗，事務B讀到的就是髒數據。
   不可重複讀：在同一個事務中，對於同一份數據讀取到的結果不一致。好比，事務B在事務A提交前讀到的結果，和提交後讀到的結果可能不一樣。不可重複讀出現的緣由就是事務併發修改記錄，要避免這種狀況，最簡單的方法就是對要修改的記錄加鎖，這回致使鎖競爭加重，影響性能。另外一種方法是經過MVCC能夠在無鎖的狀況下，避免不可重複讀。
   幻讀：在同一個事務中，同一個查詢屢次返回的結果不一致。事務A新增了一條記錄，事務B在事務A提交先後各執行了一次查詢操做，發現後一次比前一次多了一條記錄。幻讀是因爲併發事務增長記錄致使的，這個不能像不可重複讀經過記錄加鎖解決，由於對於新增的記錄根本沒法加鎖。須要將事務串行化，才能避免幻讀。
   事務的隔離級別從低到高有：
   Read Uncommitted：最低的隔離級別，什麼都不須要作，一個事務能夠讀到另外一個事務未提交的結果。全部的併發事務問題都會發生。
   Read Committed：只有在事務提交後，其更新結果纔會被其餘事務看見。能夠解決髒讀問題。
   Repeated Read：在一個事務中，對於同一份數據的讀取結果老是相同的，不管是否有其餘事務對這份數據進行操做，以及這個事務是否提交。能夠解決髒讀、不可重複讀。
   Serialization：事務串行化執行，隔離級別最高，犧牲了系統的併發性。能夠解決併發事務的全部問題。
   一般，在工程實踐中，爲了性能的考慮會對隔離性進行折中。

3. 持久性（Durability）事務提交後，對系統的影響是永久的。