DTCC 2019 | 深度解碼阿里數據庫實現 數據庫內核——基於HLC的分佈式事務實現深度剖析

分佈式事務是分佈式數據庫最難攻克的技術之一，分佈式事務爲分佈式數據庫提供一致性數據訪問的支持，保證全局讀寫原子性和隔離性，提供一體化分佈式數據庫的用戶體驗。本文主要分享分佈式數據庫中的時鐘解決方案及分佈式事務管理技術方案。混合邏輯時鐘（HLC）能夠實現本地獲取，避免了中心時鐘的性能瓶頸和單點故障，同時維護了跨實例的事務或事件的因果（happen before）關係。

演講嘉賓簡介：
何登成（花名：圭多），阿里雲智能數據庫產品事業部資深技術專家，DTCC的老朋友。從2005年開始一直堅守在數據庫內核研發領域，前後在神州通用、網易和阿里從事數據庫內核產品研發工做，目前帶領團隊打造阿里新一代分佈式數據庫POLARDB-X。

直播回放

連接：https://yq.aliyun.com/live/1045

議題PPT下載，戳這裏！

https://yq.aliyun.com/download/3566

本次的分享主要圍繞如下兩個方面：

1、時鐘方案
2、分佈式事務管理

1、時鐘方案

1.數據庫爲何須要時鐘

數據庫歸根結底是爲了將每個事務進行排序。在單機上狀況下，事務排序能夠很是簡單的實現，可是在分佈式下如何進行事務排序？數據庫經過事務對外提供數據相關操做的ACID。數據庫對事務順序的標識決定了事務的原子性和隔離性。原子性指一個事務是完整的，既發生或不發生，表明每一個事務都是獨立的。隔離性指事務之間是相互隔離的。時鐘有各類方式來標識一個事務的順序，如Oracle每個日誌都有日誌序列號LSN，事務ID，以及時間戳。目前許多商業和開源數據庫產品都支持MVCC，MVCC經過支持數據的多版本，容許讀寫相同數據，實現併發，在讀多寫少的場景下極大的提高了性能。多版本出現以後，其自己就隱含了事務的順序。當一個事務開始以後，須要肯定哪一個版本的數據是可見的和不可見的，因此這就涉及到了多體系，多版本和版本回收等問題。一個很經典的場景，淘寶或天貓的購物場景，有一條商品記錄，用戶每買一個商品，就是對商品數量記錄作一次扣減。商品記錄版本會變的一個很是長，把全部的版本都保存起來是不合理的，不然整個存儲容量就不斷增長。那如何進行版本回收？在回收的時候也須要有順序，肯定應該回收哪些版本？

2.分佈式數據庫下的時鐘

分佈式數據庫下的時鐘和單機數據庫下的時鐘有什麼區別？首先，單機數據庫的排序很是簡單，經過日誌序列號或事務ID就能夠表示事務的順序。在分佈式數據庫下，由於數據庫運行在多臺服務器上，每一個數據庫實例有獨立的時鐘或日誌（LSN），每個本地的時鐘不能反映全局的順序。服務器之間會有時鐘偏移，最理想狀況是一個分佈式數據庫部署100個節點，100個節點的時鐘是徹底同步的。但實際狀況下，在機房作越軌須要作時鐘校對，由於服務器和服務器之間時鐘點有快慢之差，因此分佈式數據庫下的時鐘沒法作全局設置的反映。

3.時鐘解決方案

時鐘解決方案有不少，如使用統一的中心節點，或者使用獨立的服務器產生分佈式時鐘。還有一種解決方案是邏輯時間，Lamport時鐘是邏輯時鐘。邏輯時鐘指的是沒有任何一箇中心節點來產生時間，每個節點都有本身本地的邏輯時間。好比有十個Oracle數據庫，每一個節點有本身的LSN，若是節點的事務比較多，事務ID跑的就比較快。若是節點事務比較少，事務ID就跑得比較慢。下圖展現了目前主流的幾種時鐘解決方案，其中TIDB是國人的驕傲，TIDB使用的是中心時鐘。除此以外，Postgres-XL使用了GTM，也屬於中心時鐘。Oracle使用的是邏輯時鐘SCN。Cockraoch DB 是模仿Spanner作的分佈式數據庫，使用的是混合邏輯時鐘。還有最知名的Google Cloud Spanner，Spanner對硬件依賴比較高，使用的是Truetime。Truetime本質上是一個原子鐘，經過原子鐘授時確保兩個服務器之間時鐘偏移在很小的範圍以內。

4.邏輯時鐘

邏輯時鐘在分佈式環境下如何實現？以下圖，有A、B和C，3個節點，每一個節點會有本身的邏輯時間，邏輯時間能夠簡單的理解爲單調遞增的天然數，0、一、二、3...。事務開始後加1，新事務開再加1。整個分佈式環境下，三個節點徹底獨立，相互之間沒有關係。若是事務跨多個節點，涉及到多個節點交互，產生一個事務的時候，本地時鐘要加1。發message出去的時候，要把message的主體發出去，還要將本地的時間發給另外一個節點。收到一個message節點後要處理這條消息，從收到的消息裏面將對時間和本地的邏輯時間作一個取值，取最大的值設爲本地時間。若是A節點發布較快，第一個事務完成之後，要作第二個事務，這時與B節點有交流，A加1，而後將時鐘帶到B節點，B節點直接從0跳到2。如此就在兩個時鐘之間創建了聯繫，經過創建聯繫，將兩個節點之間的邏輯時鐘拉平，這時候就構建它們之間的happen before的關係，表明A節點的事務是在B節點的新事務開始以前完成的。分佈式數據庫中，若是兩個事務沒有操做一樣的節點，則兩個事務是無關的事務。無關的事務能夠認爲是沒有前後順序的。可是當一個事務橫跨多個節點的時候，將多個節點之間的關係創建起來，就變成有關係的事務，構建的是事務間的因果序。所謂因果序，若是一樣來了兩個事務，一個事務操做AB節點，另一個事務操做BC節點，由於它們在B節點上創建了一個聯繫。經過B節點的關係，將事務的順序維護起來。

純邏輯時鐘能夠起到因果一致性和因果序的能力。那邏輯時鐘最大的問題是什麼呢？最極端的狀況下，節點和節點之間永遠不產生聯繫，兩個節點之間的邏輯時鐘的差距會愈來愈大。這時若是兩個節點之間作查詢或者備份，須要強制將它們創建關係，那麼兩節點之間的gap會變得很是大。

1. 混合時鐘

雖然機器和機器之間物理時鐘有偏移，但若是有NTP校準或者Google的Truetime這種時鐘服務器話，其物理時鐘的差距是很是小的。混合時鐘把分佈式下的時鐘切成兩部分，上半部分用物理時鐘來填充，下半部分用邏輯時鐘來填充。填充在一塊兒變成了一個HLC時鐘，既混合邏輯時鐘。它既有物理時鐘的部分，又有邏輯時鐘的部分。因爲物理時鐘服務器之間的差距不會特別大，因此能夠比較物理時鐘大小。而物理時鐘又有必定的誤差，在必定的誤差範圍內，可使用邏輯時鐘作校準。下圖是混合邏輯時鐘的一個示例。當發送一個消息的時候，首先應該把邏輯時鐘的物理時鐘部分與當前的時鐘作一個比較。若是當前的物理時鐘是4點，新事務產生後，由於物理時鐘沒變，新事務加在邏輯時鐘的部分（加1）。若是物理時鐘從4點變成4：01，則將物理時鐘推動。物理時鐘若是不推動，就加邏輯時鐘。若是物理時鐘發生了變化就把物理時鐘往上推動，將邏輯時鐘部分置零。

1. HLC和中心時鐘的差異

基於中心時鐘的方案的時間是經過事務ID來判斷的，從而爲因此事物排序。分佈式數據庫中，須要消除中心節點。一種方法是純邏輯時鐘，但邏輯時鐘之間沒法比較大小。另外一種方法是混合邏輯時鐘（HLC），它爲數據庫定義了一類因果關係的事務。混合邏輯時鐘沒有中心節點，用本地的物理時間加上邏輯時間。本地產生的事務不保序，可是若是事務跨了節點，其因果聯繫是有順序的。以下圖T1，T2和T3表明提交時間，T1是一個分佈式事務，T2是一個單機事務，T3是一個分佈式事務。由於T1 是一個分佈式事務，在數據庫節點上進1是比進2先執行，因此在整個時鐘裏面，進1小於進2，進1也小於進3。經過這種方式，將有關係的事務的順序排好。

7.中心式 VS. 分佈式 VS. Truetime

以下圖，中心式時鐘的優勢一目瞭然，它能夠保證全局一致的時間。分佈式數據庫下的時鐘的優勢是無中心化的性能和無HA瓶頸，由於不須要中心的授時服務。分佈式數據庫下的時鐘主要有兩個能力，第一個能力是能夠作到計算和存儲的水平擴展。另外，由於分佈式數據庫把一個業務的workload拆分到了不一樣的機器上，從而單點故障帶來的影響減少了。把核心數據庫拆成了幾百份，任何一個單點數據庫故障帶來的整個系統可用性的下跌是很是小的。這說明了爲何如今的分佈式和互聯網+結合在一塊兒比較火，一個很重要的緣由是分佈式下降了單點故障對業務帶來的的可用性的影響。不只僅是互聯網公司，包括金融類的銀行也想往分佈式走，一個方面是爲了解決容量和擴展性的問題，另一方面也是爲了解決高可用問題。中心式的缺點是會有單點的single point of failure。分佈式時鐘雖然消除了單點的影響，可是時鐘是不能夠排序的，沒法實現真正的外圍一致性。外圍一致性指的是每兩個事務均可以排序。而分佈式時鐘只能對有關聯的事務進行排序，實現因果順序。Google的Truetime的優勢是保證全局一致時間，簡化應用開發。缺點首先是須要專有的硬件，若是Truetime的原子鐘授時的話，也會有必定的時鐘誤差，這個時鐘誤差物理上沒法克服。Google Spanner的paper中能夠發現每個事務的提交都要等待一段時間，就是要等這段時鐘誤差。

2、分佈式事務管理

1.兩階段提交

分佈式事務管理是爲了保證全局讀寫原子性和隔離性。一個事務要跨兩個節點，這時候存在失敗的可能性。假如一個節點成功一個節點失敗，那麼看到的結果就是不一致的，這喪失了事務的原子性。還有一種是兩個節點上都提交成功，可是由於兩個節點自己的時間不同，致使提交的時間也不同。若是用MVCC去讀這個事務，能看到一半，另外一半可能看不到，這樣就沒法保證事務的原子性。對於事務的原子性問題，目前相關技術已經很是成熟，既兩階段提交。若是要保證一個分佈式事務成功或者失敗，能夠利用兩個階段提交技術，先作一個prepare事務，若是全部的prepare均可以，再作commit。

2.其它分佈式事務管理技術

常見的分佈式事務管理技術分爲三類。第一類是兩個階段提交技術，包含prepare階段和commit階段。第二類基於MVOCC，其中FOUNDATION DB是蘋果開源的分佈式數據庫，使用的是MVOCC，能夠理解爲OCC（optimistic concurrency control）。OCC指在事務提交時檢查是否有衝突，基於衝突有設置衝突檢測算法和權重算法，最後選擇毀掉或者提交哪一個事務。對於鎖，在事前和在更新的時候加鎖，提交的時候檢查衝突。在衝突不劇烈的狀況下，由於沒有加鎖開銷，整個吞吐很是高。在衝突劇烈的狀況下，大量的abort事務會反覆回滾。第三類技術主要針對肯定性事務，如FAUNA技術。

美國的一位教授提出了肯定性事務，並基於肯定性事務模型創辦了一家公司，建立了一個分佈式數據庫（FAUNA）。肯定性事務指事務是完整的，而不是交互型的。好比，在淘寶這種互聯網企業處理的都是非肯定性事務。非肯定性事務只begin事務，select事務等，每一個操做都是交互的，既APP須要跟DateBase作交互。若是站在數據庫的視角，數據庫永遠沒法預測下一條語句，這類事物是非肯定性的。肯定性事務是把一個事務全部的邏輯一次性寫好，而後發送給DateBase。DateBase收到事務的時候，清楚這個事務須要操做哪些表，讀取哪些記錄並進行哪些操做。從數據庫的視角來講事務是徹底肯定的。拿到一個肯定性事務，能夠事先將這些事務排好序。兩個事務之間若是操做相同的記錄，就排個前後，若是不操做相同的記錄，就併發的發出去。使用這種方式能夠作到既不用加鎖，也不用在過後提交的時候作衝突檢測。可是它的要求是事務不能是交互型的。

3.HLC和兩階段提交

混合邏輯時鐘（HLC）格式以下。若是有64個字節，首先預留5字節保證兼容性，在作系統設計的話，一般須要預留一些字節或以防出現一些問題時沒東西可用。中間再留43字節作物理時鐘。後面的16字節作邏輯時鐘。若是時鐘精確到毫秒級，43字節的物理時鐘意味着279年，表示數據庫不斷運行，279年不掛，通常來講這不太可能。若是物理時鐘到天級，一天才能變一位，那物理時鐘就失去了意義。16字節是65536，65536意味着一毫秒內能夠發起65536個事務，。通常開始和結束的時候都要消耗兩個時鐘，除以二，既一毫秒內可處理3萬多的事務，單節點一秒內能夠作到3千多萬事務。

4.HLC時鐘偏移的問題

HLC和事務的吞吐有關係，由於它有物理時鐘，可以展現不一樣的節點之間的時鐘差。若是真的出現了時鐘偏移怎麼辦？下圖提供了一個簡單的公式。沒有誤差的狀況下，理論上節點能夠作到3千萬的TPS，固然在工程上是作不到的。若是兩個節點時鐘之間偏移量是5毫秒，那麼在5毫秒以內只能經過邏輯時鐘去彌補。若是原來6萬個邏輯時鐘在1毫秒內就能作完，如今則須要5毫秒，致使整個事務的吞吐降低了600萬。因此時鐘偏移會致使peakTPS大幅降低。下圖給出了幾種解決方案。比較簡單的是容許設置最大時鐘偏移，若是整個機房或者集羣中兩個節點之間最大偏移超過了100毫秒，就把該異常節點清除。目前來看，機房都有NTP授時服務，因此發生如此大時鐘偏移的機率很是小。另外一種方式是不清除異常節點，可是能夠容許邏輯時鐘overflow到物理時鐘部分，使邏輯時鐘更大，這樣能夠容許更多的事務在當前時鐘內發生。

原文連接 本文爲雲棲社區原創內容，未經容許不得轉載。