TMT观察网_独特视角观察TMT行业

05年騰訊充值和財付通起步開始，騰訊就已經將MySQL/MariaDB全面應用在金融交易類系統中。在近13年支付、充值等海量業務的打磨下，騰訊云數據庫團隊修復大量MySQL/MariaDB的bug，并優化回饋社區，向MySQL/MariaDB社區貢獻了眾多代碼補丁(Patch )。騰訊云數據庫團隊與金融云團隊共同維護了金融級分布式架構TDSQL，目前，騰訊 90% 的金融、計費、交易類業務核心系統承載在 TDSQL 中。目前TDSQL 可以提供公有云、專有云兩種部署方案，可以分配基于MySQL協議的CDB(關系型數據庫)實例、DCDB(分布式數據庫)實例、ADB(分析型數據庫)實例。

我們選擇了一部分針對金融交易類業務場景的優化，看看金融交易類業務特點。

金融級高可用和數據強一致

高可用和數據強一致，是金融行業最基本的需求。因此，通常會配置主從架構和強同步復制來保證高可用和強一致，為了防止從機復制執行過慢，一般選擇使用row格式的binlog復制。而金融業務系統大量的批處理，會導致一次性更新/刪除了很多行數據，此時復制到從機時，則需要使用索引掃描或者全表掃描來找到這個行，可能導致復制效率變得非常慢，這將導致嚴重的從機數據延遲，進而產生更多問題。

例如，創建一張沒有主鍵的表，假設現在’test’表有100萬條記錄，在主機上執行一個批處理DELETE FROM test，假如刪除了10萬行，則會記錄10萬條binlog記錄，如：

delete from test where id=1;

delete from test where id=2;

...

delete from test where id=100000;

binlog被同步到備機，會執行10萬個單行刪除事件。對于具體每一個單行刪除事件，、因為目標表沒有主鍵，需要采用全表掃描，每次執行約100萬行，那么共需要掃描10萬 × 100萬= 1000億條記錄。這可能直接導致從機一直卡住好幾天。

為了避免這些問題，我們支持“自動增加主鍵”。

自動增加主鍵，該功能主要是在用戶創建表(且未定義主鍵時)，自動在表中添加一列自增列作為主鍵。為此，我們新增了reject_table_no_pk這個參數，該參數設置為 1 時，如果在建表語句中，顯示指定主鍵，系統將自動為該表創建一列自增行作為主鍵。

而為避免“自動增加主鍵”功能關閉時(即reject_table_no_pk=0)用戶創建表，如果create table語句沒有創建主鍵和唯一索引的子句，那么系統將返回建表錯誤，錯誤碼為“1173”，提示信息為“This table type requires a primary key”。如果alter table語句刪除了主鍵或者唯一索引，導致這個表沒有了主鍵和唯一索引，也會返回這個錯誤。

分布式事務大量應用于真實金融級場景

金融交易類系統，會使用大量事務(例如銀行轉賬)，且隨著數據量逐漸變大，某些系統會選擇采用分布式數據庫作為核心交易系統，這時又需要支持分布式事務。 騰訊云TDSQL不僅優化了事務處理效率，而且在修復MySQL 5.7 分布式事務的大量Bug，還為社區貢獻眾多代碼補丁(Patch );并且完整實現了MySQL-5.7在分布式事務處理在binlog復制相關功能中的事務災難恢復處理功能。填補了MySQL在分布式事務處理方面的眾多重大缺陷和空白。目前，TDSQL是有限幾個在將分布式事務大量應用在真實金融交易場景中的數據庫。

例如，社區版本在某些情況下，從機IO線程獲取xa事務(分布式事務)的事件期間中斷連接后，如果當前relay log上面最后一個事務正好是不完整的XA事務，那么sql線程會卡住。另外官方版本中，沒有處理XA 事務分支的二進制日志與存儲引擎(binlog + engine) 災難恢復，而TDSQL不僅處理了XA PREPARE事務分支的災難恢復，還包括 XA COMMIT ... ONE PHASE以及XA COMMIT/XA ROLLBACK 語句的災難恢復。還考慮到金融高可用場景下，如果事務未執行完成，主機故障從機上面可能無法繼續執行或反復切換等Bug。

金融級安全優化，系統安全機制更加健全

安全性是金融行業非常重要的需求，而安全管理制度和安全設備是有可能存在不完善的，為確保不會被非法用戶利用，騰訊云做了這幾點優化能力：

l 根據大量的入侵案例和報告中，非法用戶經常通過select into out file來把其本地的攻擊程序傳輸到服務器端，或采用目錄穿越攻擊(Path Traversal攻擊)隨意地打開、查看，甚至執行網站內的文件。騰訊云TDSQL對于tcp/ip登錄的用戶，即使該賬號有權限，也禁止用戶通過以下SQL語句在mysqld運行的服務器上面創建或者打開文件select ... into dump file; select ... into outfile; load data infile ... ;并禁止寫入"路徑變量不是正常路徑，而是由字符串組成的 “真值”，或“變量”" 這樣的語法來讀寫路徑變量的值。有了這些禁止措施，用戶將無法通過TCP/IP連接的客戶端在mysqld服務器上面創建或打開任意文件，用戶創建的文件只有數據表文件等完全受mysqld掌控的文件。用戶只能傳輸DDL/DML等SQL語句字符串以及得到它們的查詢結果。

l 在另外某些案例中，有一些非法用戶通過可能通過一些未知的業務系統漏洞去修改系統表，進而提權、做破壞或放開更多漏洞，禁止這種方式后可有效避免類似情況發生;也有用戶誤刪除了系統數據庫或表，然后試圖挽回，于是自己重新創建了一個系統表，可想而知，其他地方copy過來的系統表，與原系統表會有差異，結果導致各種系統異常。只允許 unix socket 連接且具有權限的用戶刪除系統數據庫 mysql, information/performance_schema, xa, sys, sysdb及其中的表，并且禁止非 unix socket 連接或不具有權限的用戶 對mysql.user表進行Drop/alter/truncate 表，或插入、更新、刪除這些表中的行。

l MySQL提供了標準的接口允許用戶實現自定義的功能(安裝插件)，這個機制雖然靈活，但也是巨大的安全隱患。如果被非法用戶利用，就可以在mysqld服務器上面以linux用戶的身份執行任意代碼。所以，我們禁止通過TCP/IP連接上來的用戶執行INSTALL PLUGIN語句安裝插件。

l 我們在MySQL5.7版本以后，全面支持表空間加密和連接加密，加密的主要目的是方式主要對硬盤上的數據庫件的透明加密，如果該數據文件被盜取(盜取磁盤、機器)，在沒有密鑰的前提下無法恢復出數據內容。當然，TDSQL在分布式數據庫DCDB方案基礎上，也實現了加密

l 為在靈活性與安全性中間予以平衡，上述安全機制都有開關控制(默認打開)，為避免非法用戶關閉以越過安全機制，我們禁止遠程用戶修改和讀取這些開關變量，防止非法用戶關閉上述安全措施。

生產系統非標操作限制，降低系統負載

在某些情況下，開發或運維不得不直連數據庫做某些操作。而某個不合理的SQL語句會直接導致數據庫開銷過大，會嚴重增加系統負載，降低系統的TPS，甚至影響系統可用性。有時候，某些SQL開銷過大并不是用戶需求，可能只是人為錯誤，甚至SQL注入等。因此，騰訊在數據庫內核中可以限制SQL語句執行的規模。即通過限制臨時表的大小，或強制delete/update/select增加limit子句。

對于創建在myisam上面的臨時表，用戶可以設置全局變量 max_temp_table_size來限定臨時表的大小，該值默認是0，表示沒有限制。 例如，可以設置max_temp_table_size=16K，當查詢執行過程中任意一個臨時表的temp_table_size大于這個限定值時候，查詢直接返回失敗，服務器端錯誤號：1114，錯誤字符串是：“The table 'xxx' is full?！?/p>

用戶可以設置select_rows_limit/delete_rows_limit/update_rows_limit 3個動態的全局變量，來強制添加用戶必須顯示指定limit子句來做規模限制，例如設置比如 set global delete_rows_limit=10000; 這樣的話，delete語句就不可以刪除超過10000行代碼，否則就失敗了。當然，開啟變量后，用戶也可以顯示指定NO_LIMIT關鍵字，來避免這個限制。

為了防止計劃外的超大事務導致鎖表;或binlog量過大會導致強同步等待超時;或某些異常操作，比如用戶誤操作無條件刪表等;我們通過參數max_binlog_write_threshold限制一個事務中寫入的binlog總量，當達到配置的最大值時候，當前DML語句返回錯誤，并在數據庫中回滾該事務。檢查在DML執行時即做，而不是在事務提交時刻，這樣可以有效提高效率。

除了上述之外，騰訊云TDSQL還有大量其他優化，由于篇幅有限，我們會在未來逐步在騰訊云社區中公開;另外，我們已將大量優化和改動都提交社區開源。