分布式資料庫選型測試（三）——模拟實戰

原生的分布式資料庫體驗

​分布式資料庫産品都盡力給使用者一種接近單執行個體資料庫的使用體驗，如原生的 SQL 和事務。在分布式資料庫中間件的功能發展曆史中可以看出這方面的進展。

早期的 DRDS 産品裡，對 SQL 有很多限制。比如說分片字段不支援多個字段組合、SQL不能跨分片(分表或分庫)做表連接配接或者性能不好、SQL 文法有些限制（如不支援複雜的子查詢、統計分析等等）。

後來 SQL 支援跨分片查詢，并且支援一些執行計劃算子下推優化。隻是設計上隐藏了一個問題，各個分片都是獨立查詢資料并傳回到中間件節點内部聚合計算再傳回。各個分片的資料嚴格來說并不是同一個快照（即同一個事務版本SCN之前的合法資料，合法指的是遵循某種事務隔離級别，如 READ COMMITTED 或 REPEATABLE READ ）。再往後發展成熟的 DRDS 産品聲稱支援分布式 MVCC，能提供一緻性快照讀。然而效果如何沒有好的辦法檢驗。

事務方面一開始也是不支援分布式事務，後來支援分布式事務但是需要特殊的開啟文法或者引入分布式事務中間件，以及事務是最終一緻性方案（如 TCC）。到最後成熟的産品把分布式事務中間件跟分庫分表中間件融合在一起，自動判斷是否有分布式事務并支援強一緻。理論上分布式事務要滿足 ACID，必須使用兩階段送出協定。有些産品在中間件層接管事務（如GTM），使用一階段送出協定和自己實作多版本，提供 ACID 的效果。在底層資料庫層面，各個參與者（資料庫）都是本地事務直接送出。産品并不希望使用者繞過GTM 通路資料（那樣可能讀到業務層面尚未送出的事務資料）。如果有參與者故障，業務事務需要復原，GTM 利用自己的 Undo 構造逆向SQL 去復原底層事務已經送出的執行個體裡的資料。

​節點故障引起的麻煩并不隻是部分參與者執行個體的事務要復原，還有故障執行個體的主備執行個體之間的一緻性和同步狀态。傳統的商業資料庫（ORACLE、DB2、SQLServer）都有 Redo 和 Undo 設計，在執行個體故障後拉起時，有相應的崩潰恢複邏輯（即重做故障點附近的全部事務日志，然後再復原未送出的事務日志）。這些資料庫在穩定狀态下其事務日志和資料是保持一緻性狀态。這符合 Writing Aheaad Logging 機制的設計目的，關鍵點是日志要及時落盤。然而 MySQL 資料庫插件式引擎設計改變了這個設計。在 MySQL 有兩套事務日志系統，一是 Server 層 Binlog，二是 Innodb 的 Redolog。MySQL 試圖使用本地兩階段送出協定去保證這兩套日志系統對一個業務事務的變更是一緻的。不過 Binlog 隻記錄已送出的事務日志，不記錄未送出的事務(沒有 Undo 邏輯)。Innodb的 Redolog 才記錄了全部的事務日志（包括未送出的事務及其 Undo 日志）。在 Binlog 和 Redolog 的持久化上，二者并不一緻且有多種落盤政策。讓實際情況變得更複雜的是 MySQL 主備複制同步的是 Binlog。主備在事務日志持久化上也可能不一樣。是以 MySQL 在當機恢複後有一定機率出現丢資料或者主備資料不一緻、複制中斷。GTID 和半同步技術也不能徹底解決所有的複制中斷問題。

基于 MySQL 資料庫建構的分布式資料庫，在節點故障時想把故障處理做到對使用者完全透明，這個挑戰還是非常大的。産品并不希望使用者了解這些細節。包括 SQL 和事務的内部執行細節。使用者如果是開發，往往也樂意如此，隻要能用就行。這種透明往往隻能做到對開發透明，對運維就不一定了。當分布式資料庫到一定規模或者壓力上去後，深入的性能調優、故障處理都不可避免的要接觸到内部細節。即一個多元件內建的自動化的分布式資料庫解決方案。

資料庫技術閑談 發起了一個讀者讨論

除了上面說的 SQL 和事務，讀者朋友覺得原生的分布式資料庫體驗還有哪些要求呢？

精選讨論内容

補充下朋友意見: 還有阻塞和死鎖，主鍵和唯一鍵，任意條件的查詢(跟分片鍵無關)。

​

​

生産環境特點

使用者可以不了解分布式資料庫産品細節，但一定了解資料庫上線後的生産環境特點。後期POC測試案例設計要盡可能跟生産環境特點接近。

生産環境往往有下面這些特點：

• 表都有一定資料量，特别是核心表。這些表有可能要做變更（加字段、加索引等、備份導出）。大表加字段或索引比較耗時，有一定操作風險。
• 跑批業務，有大量資料寫入或更新。
• 卸數業務，有大量資料導出。
• 業務不可中斷，随時都有讀寫通路。資料庫運作中有一定負載有高低峰期，不同時間段變更風險會有些不一樣。
• 資料不能丢，準确的說法是業務相關表資料的業務邏輯始終是保持一緻的。
• 資料庫叢集有一定規模。運作半年一年後可能面臨資料庫擴容需求，三年後還可能臨機器更新換代問題。
• x86 伺服器可能随時有故障。如果是國産伺服器或系統，風險會更高一些。

POC 測試建議POC.測試接近生産特點，模拟生産并不難。隻需要考慮下面幾點即可。

• 不在空表或小表上做功能測試。表的資料量不少于5000萬。
• 不在空閑的表或執行個體上做功能測試。表或執行個體要有一定的并發讀寫請求，要把資料庫CPU壓到約30%左右。
• 測試自始自終運作業務資料一緻性校驗。這裡面會對相關業務表做業務邏輯檢查。功能和性能測試過程中和結束後都抽查校驗日志。
• 不孤立的做高可用測試，而是在每個功能測試和性能測試過程中随機加入節點故障事件。觀察業務恢複情況，業務資料一緻性，運維處理工作等。故障時丢資料和主備不一緻是小機率事件，一次故障測試可能無法發現問題。
• 不孤立的做功能測試，而是在測試中加入業務負載和随機故障，觀察業務資料一緻性、業務恢複和運維恢複過程。
• 不孤立的做性能測試，在性能測試過程中和故障前後校驗業務資料一緻性，随機加入節點故障測試。

• ​​分布式資料庫選型測試(一)——測試需求​​
• ​​分布式資料庫選型測試(二)——測試環境​​
• ​​分布式資料庫選型——資料水準拆分方案​​​​
• ​​說說資料庫事務和開發（下）—— 分布式事務​​