當數據庫遇到分佈式

時間 2019-11-06

原文原文鏈接

概述

NewSQL日漸火熱，不管仍是開源的TiDB，CockroachDB仍是互聯網大廠的Spanner，Oceanbase都號稱NewSQL，也就是分佈式數據庫。NewSQL的典型特徵就是，支持SQL，支持事務，高性能，低成本，高可靠，強一致，易擴展，運維友好等。從NewSQL的演進來看，所謂NewSQL，能夠簡單理解爲NoSQL+傳統的關係型數據庫的結合，NoSQL強調分佈式(高可用，可擴展)，關係型數據庫則強調事務，SQL。正由於兩者的疊加，因此須要把兩個領域的概念整合在一塊兒，本文主要想把分佈式數據庫中幾個基本概念講清楚。html

一致性

數據庫和分佈式系統中都有一致性概念，因爲不少英文單詞對應的中文都是「一致性」，致使容易產生誤區。數據庫中的ACID，C是Consistency，這個C主要強調應用邏輯的一致性，好比應用定義的約束，包括外鍵等。分佈式系統的CAP以及一致性協議，也稱爲一致性。前者主要強調，讀是否能讀到最新，以及併發場景下操做執行的時序關係，主要包括線性一致性(linearizability)，順序一致性(sequential consistency)，因果一致性(causal consistency)等；後者主要強調「共識」，分佈式中的多個節點對某個事情(選主，事務提交)達成一致，常見的共識算法包括paxos協議，raft協議等。算法

線性一致性(linearizability)

簡單來講，線性一致性要求，第一，「寫後讀」，這裏寫和讀是兩個操做，若是寫操做在完成以後，讀纔開始，讀要能讀到最新的數據，並且保證之後也能讀操做也都能讀到這個最新的數據。第二，全部操做的時序與真實物理時間一致。相對於「寫後讀」，第二點要求即便不相關的兩個操做，若是執行有前後順序，線性一致性要求最終執行的結果也須要知足這個前後順序。好比，操做序列(寫A，讀A，寫B，讀B)，那麼不只，讀A，讀B能讀到最新A值和B值；並且要保證，若是讀B讀到最新值時，讀A必定也能讀到最新值，也就是須要保證執行時序與真實時序相同。第三點，若是兩個操做是併發的(好比讀A沒有結束時，寫B開始了)，那麼這個併發時序不肯定，但從最終執行的結果來看，要確保全部線程(進程，節點)看到的執行序列是一致的。數據庫

下圖對線性一致性有詳細的論述，來源於[6]併發

順序一致性(sequential consistency)運維

相比線性一致性，主要區別在於，對於物理上有前後順序的操做，是否要保證這個時序。具體而言，對於單個線程，操做的順序仍然要保留，對於多個線程(進程，節點)，執行的事件的前後順序與物理時鐘順序不保證。可是要求，從執行結果來看，全部線程(進程，節點)看到的執行序列是同樣的。詳細定義來源於[6]分佈式

下圖的例子很好的區分了線性一致性和順序一致性。性能

對於(a),執行序列write(y,2),read(x,0),write(x,4),read(y,2)，結果符合要求，可是從客戶端的角度來看，write(x,4)先於read(x,0)執行，可是read卻沒有讀到最新值。google

對於(b),write(y,2)和read(y,2)有前後順序，也是符合「寫後讀」，因此是線性一致性。spa

對於(c), 有幾種可能：.net

1).write(x,4),read(y,0),write(y,2),read(x,0)，x的寫後讀，不符合要求；

2).write(y,2),read(x,0),write(x,4),read(y,0)，y的寫後讀，不符合要求。

因此既不符合線性一致性，也不符合順序一致性。

因果一致性(causal consistency)

相對於順序一致性，弱化了不相關操做是否須要保序。

對於b),p1和p2 w(x)是沒有前後關係的，所以誰先發生都是能夠的。

從p3的視角來看，操做執行的序列是w(x,7),r(x,7),w(x,2),r(x,2),w(x,4);保證了「寫後讀」

從p4的視角來看，操做執行序列是w(x,2),w(x,4),r(x,4),w(x,7),r(x,7);保證了「寫後讀」

可是不一樣進程看到的執行序列不同，因此不符合順序一致性。

可串行化

上一篇文章講了數據庫中異常和隔離級別，實際上隔離級別是純粹數據庫領域的概念與分佈式系統並無交集，好比讀未提交，讀提交，可重複讀以及可串行化。對於數據庫而言，咱們說Serializable，是說併發場景下，多個併發事務最終執行的序列與某個串行執行的序列相同(無事務併發，事務的執行沒有重疊)。那麼如何實現併發控制來達到可串行化調度。數據庫中對於同一對象的操做可能存在幾類衝突，包括讀寫衝突，寫寫衝突，寫讀衝突等，若是解決了這些衝突，也就實現了可串行化調度。實際上衝突可串行化調度是可串行調度的充分條件，並不是必要條件，詳細展開能夠看這篇blog，而咱們實際的數據庫系統中實現可串行化調度也是解決衝突串行化問題。主要有兩種，一種是基於S2PL(Strict 2 Phrase Locking)，事務操做過程當中，對讀加讀鎖，對寫加寫鎖，事務提交時，纔將鎖釋放，爲了不幻讀，還須要實現間歇鎖等；另一種，是基於Snapshot的SSI隔離級別，這種實現與S2PL的主要區別在於，讀仍然採用快照讀，不加鎖，讀寫不互斥，爲了實現可串行化調度，須要收集事務的讀寫操做信息，並判斷是否事務有相互依賴的狀況(衝突成環)，若有，則將衝突的事務回滾，其實是first-commit-win原則，最後致使成環的事務會被回滾。具體能夠參考論文:Serializable Isolation for Snapshot Databases，目前商業數據庫PG和CockroachDB都是實現了SSI隔離級別。而MySQL的InnoDB存儲引擎則是採用了S2PL實現了可串行化隔離級別。

線性一致性VS可串行化

前面分別介紹了分佈式系統中的一致性以及數據庫中的可串行化隔離級別，分佈式數據庫顯然是分佈式系統，也是數據庫系統，那麼是否能作到線性一致性+可串行化，就是所謂的「Strong Consistency」。這個定義來源於Jepsen的一篇blog，具體能夠看下圖。

咱們要注意到，討論線性一致性時，咱們討論的粒度是一個操做，操做是否知足前後關係；而討論隔離級別時，粒度是一個事務，事務是否與某個串行執行的結果相同。因此，這裏就比較特殊了，事務中包含了若干讀寫操做，咱們要保證讀到最新，是說後開啓的事務的讀能讀到以前的提交；仍是事務中的每一個讀都能讀到讀開始以前的提交(讀提交)。至少從DDIA(Designing Data-Intensive Application)[2]這本書介紹來看，應該是後者，因此它認爲基於S2PL協議實現的可串行化，能夠作到線性一致性兼得；而SSI因爲是快照讀，致使讀不能讀到最新，因此不知足線性一致性的。

數據庫要實現「線性一致性」，須要保證事務操做按全局時鐘的前後順序。對於寫而言，經過一個統一的地方分配時間戳，顯然前後執行的事務分配的時間戳也知足前後關係。這裏實際上須要一個統一「全局時間源」，也就是業內經常使用的TSO(TimeStampOracle)方案，TSO能保證全部事務全局有序。對於讀而言，讀採用加鎖當前讀，也能保證讀到最新，因此結合S2PL能夠兼得可串行化+線性一致性，也就是實現Strict Serializable。

External Consistency(外部一致性)

google Spanner論文還提到一個外部一致性的概念，

Spanner經過GPS+原子鐘保證了全部事務的寫有序，實現了相似TSO的功能，可是避免了TSO的單點可用性和性能問題。它提到External Consistency相比linearizability，主要是約束了非相關併發事務的提交順序與物理時鐘要保持一致，由於linearizability並不約束併發執行的操做。論文中沒有提到Spanner如何實現Serializable隔離級別，我猜想是相似SSI的實現，那麼仍然作不到Strict Serializable。

總結

分佈式數據庫中的一致性概念有不少，但含義都不太同樣，ACID中的一致性主要強調應用邏輯的一致性，須要應用參與保證一致性，CAP中的一致性則主要強調多個副本的一致性，寫後讀是否能讀到最新，這裏面就衍生了幾種一致性，包括線性一致性，順序一致性，因果一致性等。數據庫有隔離級別的概念，對於可串行化隔離級別也要求順序，實際上與分佈式系統的一致性沒有什麼關係，它更強調隔離，不強調事務執行的順序是否與真實執行前後順序保持一致。所以，數據庫可能實現了可串行化隔離級別，可是並不必定實現了線性一致性，好比基於SSI實現的可串行化就是這類系統。