行業背景
隨着全球經濟下行壓力增大，中美貿易摩擦愈演愈烈，美國一系列的經濟制裁和技術封鎖使得我們有種被扼住咽喉的感覺，數據庫作爲基礎軟件中的重要一環有着很深的技術含量，在這樣的大背景下國產數據庫廠商開始發力，這其中分佈式數據庫如雨後春筍般出現，良性的競爭環境使它們都得到了長足的發展，其中不乏優秀的產品，本文主要挑選目前幾個相對成熟數據庫進行架構特點介紹。
分佈式數據庫總體架構
其實分佈式數據庫總體設計有兩個思路和方向，一個是基於共享存儲的架構（share everything），另一個是基於數據分片的架構（share nothing）。
共享存儲的架構特點是底層存儲共用一份數據池子，上層數據庫server層可以彈性擴展，典型的案例像DB2 purescale，Oracle RAC，阿里雲PolarDB等，這種架構的好處是天然適合做雲數據庫，比如阿里雲，上層的sql引擎可以是mysql也可以是pg，而且可以無限擴展，底層的存儲其實是一起的，用戶申請只是申請幾個上層的mysql或者pg server同時在底層存儲開闢一塊空間給用戶，這樣的話可以做到資源的彈性伸縮。這種架構的數據庫其實嚴格意義上不能稱之爲分佈式數據庫。
數據分片架構的特點是底層數據通過一定的規則比如hash或者range讓數據打散分別分佈到不同的數據節點上，計算時底層多個節點共同參與計算，可以算是一種mpp並行計算的架構，同時數據節點可以擴展，上層由協調節點進行sql解析和轉發，這是目前典型的分佈式數據庫架構，也是本文討論的重點。
目前分佈式數據庫的總體架構設計基本都和下圖相差不大，每種產品在不同組件的實現上存在差異，但大體架構上類似。
從圖中可以看到分佈式數據庫三大組件：協調節點、數據節點、全局事務管理器。協調節點負責sql解析轉發，充當的是類似proxy的角色，數據節點負責計算和數據存儲，全局事務管理器負責全局事務讀一致性的保證。
下面分別介紹一下目前主流的分佈式數據庫的架構以及設計差異。
TiDB
TiDB是目前在互聯網界風靡的一款分佈式數據庫，由PingCAP公司研發，由三大組件構成，底層tikv server是github開源組件，是一個分佈式的kv存儲引擎，做數據存儲，對應數據節點；上層tidb server由pingcap公司研發，用作sql解析和轉發，對應協調節點；pd server複製全局時間戳分配，對應全局事務管理器。下面列舉了它的架構特點：
①輕量化，深受互聯網公司喜愛，適合與容器進行集成，當前目前pingcap公司也再做tidb operator，將tidb容器化。
②部署簡便，基於ansible playbook實現自動化部署。
③實現了基於region級別的raft複製，將數據表拆分成一個個的region，region一主兩備基於raft協議做複製，同時region還會根據負載情況進行合併和分裂，由pd server進行負載均衡調度。
④使用隱藏列作爲分佈列，分佈列不佔用真實列，這樣在進行數據修改時數據不需要進行重分佈，大致原理是使用表名和主鍵前面加上前綴信息作爲隱藏列，再使用該列進行hash分佈。
⑤tidb server總體兼容mysql語法，這個兼容並不是將mysql server直接拿過來使用，因爲tikv底層是kv的存儲模型，所以tidb在執行sql的時候需要做sql到kv的映射。
⑥tikv可以看成一個大的數據池子，在物理機層面不存在哪個機器是主，哪個是備，所有機器都是主節點，熱點數據會自動進行動態負載均衡，數據是動態移動的。
⑦總體借鑑了google spanner f1和bigtable的論文，pd server實現了邏輯上的時間戳，谷歌論文也提出了原子鐘的概念，從物理上保證事務號全局有序。
OceanBase
OceanBase是螞蟻金服自研的分佈式數據庫，號稱代碼從第一行完全自研。最近ob也屢屢刷新新聞頭條，刷榜TPCC官網測試結果，刷新天貓交易額和tps記錄，不過金融行業比如銀行的應用案例並不多，也許是銀行和支付寶可能天然有鴻溝吧。ob架構比較特殊，下面介紹一下它的架構特點：
①最底層是ob server，每個ob server集成了總控服務、sql引擎、存儲引擎和數據分區。
②上層是ob proxy，實現sql的路由，這個不止是應用到observer的路由，也有observer之間的路由。
③數據拆成一個個分區，每個分區做paxos複製，保證強一致，主分區宕機不可用會自動切換到備分區。
④checkpoint時間改變，將checkpoint週期拉長爲1天，所有交易都落在內存，然後每天夜裏去刷一次盤，redo日誌實時記錄，這樣避免了隨機寫的性能損耗，只有順序寫，更像內存數據庫，性能更好，這樣也帶來一些問題，比如宕機後恢復時間變長，還有查詢剛剛做的修改需要先查基礎數據，再去應用redo條目，得到最新數據。
⑤兩階段提交併不使用ob proxy節點充當協調者，而是將ob proxy路由到的第一個主數據分區作爲協調者，同時兩階段提交的prepare和commit等信息會進行持久化，如果寫協調節點宕機，那麼備分區會啓用，同時讀取持久化信息，這個設計和一般的分佈式數據庫不太一樣。
⑥集羣維護一個partition cache，分區的分佈信息會通過obproxy在不同observer間傳遞。
⑦ob最早的時候曾經開源過一段時間，隨後基於它也誕生了cbase、obase這些產品。
GaussDB
華爲gaussdb分爲三個產品線，gauss100前身是華爲自研的內存數據庫gmdb，目前已經開源，gauss200是基於pgxc架構研發的OLAP分析型數據庫，gauss300是在200的基礎上繼續研發的HTAP數據庫，這裏主要介紹gauss300數據庫，gauss300就是上圖中典型的架構：
①協調節點負責sql解析、轉發的同時也充當了兩階段提交的協調者的角色，協調節點上面存儲有部分元數據信息，元數據需要在多個協調節點之間進行同步，如果協調節點宕機，會影響ddl相關操作，還可能造成兩階段提交的殘留信息，需要有兩階段殘留清理機制。
②數據節點通過quorum-based流複製實現高可用，主備數據節點是實例級別的，一個主節點就是一個主pg實例，一臺機器可以有多個主數據節點。
③GTM複製分配全局事務id，gtm一主多備，gtm主備之間要同步gxid信息，而且是強同步，那麼帶來一個問題，備gtm節點宕機會造成主gtm不可用，造成全局可用性問題，這塊華爲將gtm的高可用轉移到etcd中，將gtm生成的xid寫入到etcd中，etcd自身就是一個高可用強一致的集羣，這樣就保證了gtm的高可用，主gtm宕機那麼備gtm會接替，然後繼續從etcd集羣中讀寫事務號。
④gtm的事務號是批量分配的，如果在高併發的情況下，gxid如果一條一條分配則會有性能瓶頸，華爲將事務號改爲一次分配幾萬甚至幾十萬，避免了gtm事務號分配的瓶頸。
⑤事務id由32位改爲64位。Pg的事務號是32位的，最大到42億，所以事務號在pg中是很珍貴的資源，用完了就會循環使用，循環使用會帶來很多嚴重問題，華爲將事務號由32位改爲了64位，這樣事務號根本不可能用盡，那麼一次分配幾十萬也不足爲奇了。
⑥爲了提升性能，華爲也正在研發gtm-lite功能，該功能可以實現本地事務不走gtm，因爲生產環境大部分是本地事務，因而能大大提升性能。
⑦gauss300是基於pgxc架構演進而來的，類似基於pgxc的還有亞信antdb、騰訊Tbase。
SequoiaDB
Sequoiadb是巨杉自主研發的分佈式數據庫，最初的應用場景主要是歷史數據歸檔和非結構化數據存檔，但是近期來巨杉也在積極開發oltp功能，包括研發gtm，支持mysql協議等。下面介紹一下它的架構特點：
①包括協調節點、編目節點、數據節點、pg節點等。協調節點負責sql轉發，編目節點存儲元數據，數據節點存儲真實數據，pg節點做sql引擎。
②巨杉數據庫底層存儲是nosql的，數據都是json格式進行存儲，優點類似MongoDB。
③pg節點是將pg server拿過來做sql存儲引擎，支持sql語法，在pg上創建外表，同時創建外部服務器，存取巨杉中的數據，近期也支持了mysql，將巨杉作爲可插拔的存儲引擎嵌入到mysql中。
④目前巨杉用作交易類場景其實不多，現在最大的一個應用案例是某大行一百多物理節點的巨杉集羣，用作數據歸檔和影像管理。
⑤巨杉底層是多模存儲引擎，既支持結構化數據，也支持非結構化數據，實現了統一管理。
當然還有很多分佈式數據庫，像達夢、人大金倉、南大通用、萬里開源、中興等企業都有分佈式數據庫產品，這裏不再一一介紹了。
歡迎關注我的公衆號：數據庫架構之美
