作者 | 吳夏，騰訊雲 TDSQL 高級工程師
責編 | 唐小引
頭圖 | CSDN 下載自東方 IC
出品 | CSDN（ID：CSDNnews）
隨著國家有關部門近年來陸續出台相關政策指導文件，推動探索安全可控的金融科技產品，加強銀行業信息安全建設，國內眾多金融政企機構開始探索藉助數字化技術，來實現原有 IT 系統的轉型升級，從而實現降本增效，已經成為行業發展的共識。
近日，騰訊對外透露其自研的金融級分布式資料庫 TDSQL 的金融政企用戶數突破 600 家。作為一款自主研發的金融級資料庫，TDSQL 正在成為眾多金融機構數字化升級過程中的一大擔當。本文將以國內某大型金融機構的資料庫真實遷移的實踐出發，分享國產資料庫的技術架構、遷移歷程以及優化措施。
國產資料庫解決的問題
傳統集中型資料庫，成本高、擴容難、性能受限，傳統模式下靠採購高端設備以及增加硬體來保證資料庫可用性和擴展性的方案正面臨越來越大的壓力。而自主可控分布式資料庫具備高可擴展性、高性能、高可用等特性，可以很好地滿足產業互聯時代線上化、高頻、多維度、高並發的場景需求，能夠幫助金融機構在解決技術瓶頸問題的同時，助力實現降本增效，而節省下來的成本效率，銀行可用於業務快速創新和疊代，發展網際網路線上化業務，在時間和空間上擴大銀行業務服務版圖。
成本方面，國產分布式資料庫同樣表現優勢明顯。舉個例子，基於 TDSQL 的新系統在硬體層面全面採用 x86 伺服器，取代傳統商用資料庫所需的大型機、小型機，成本優勢明顯。最新客戶案例數據顯示，張家港農商行採用 TDSQL 分布式資料庫架構後的硬體成本，只有傳統架構成本的 1/5 甚至更低。而微眾銀行公布的數據看，單客戶 IT 成本能節省為傳統商業資料庫架構的 1/10。
作為技術與智慧財產權自主可控的金融級分布式資料庫，可滿足國家對金融安全自主可控的要求。通過核心技術升級，以新一代分布式資料庫解決過去難以解決的業務問題，同時實現自主可控，是企業數字化轉型的趨勢選擇。
如何遷移？
在金融業務場景中，資料庫遷移升級、數據分發與數據備份是資料庫系統必不可少的基本功能。其中前者是實現數據解耦及匯總的重要基礎，例如保險行業常見的總分系統架構，多個子庫需要實時的將業務數據同步至總庫匯總查詢；銀行核心交易系統中，需要將交易數據實時同步至分析子系統進行報表，跑批等業務員操作。而數據備份則是數據安全的基石，更是金融業務數據的生命線。作為一個金融級資料庫產品來說，TDSQL 在技術層面沉澱了針對資料庫數據遷移、分發、同步和備份的 TDSQL-MULTISRCSYNC（TDSQL-多源同步）解決方案，為資料庫系統國產化轉型的高可用、高可靠提供了有益參考。
▐ TDSQL 多源同步核心架構：數據遷移與同步的關鍵邏輯
分布式資料庫 TDSQL 是騰訊打造的一款分布式資料庫產品，具備強一致、高可用、全球部署架構、分布式水平擴展、高性能、企業級安全等特性，同時提供智能 DBA、自動化運營、監控告警等配套設施。
TDSQL-MULTISRCSYNC（多源同步），是高性能、高一致，支持多種異構數據平台的數據分發服務。該服務支持以 TDSQL 作為源端的數據實時同步分發至 MySQL、Oracle、PostgreSQL、消息隊列等平台，同時也支持以 TDSQL 作為目標端，將 MySQL 或者 Oracle 的數據實時同步至 TDSQL 中,並且部署靈活，支持一對多，多對一等多種複製拓撲結構。
多源同步模塊典型的基於日誌的 DCD 複製技術，其系統架構如下：
從上圖我們可以看到，整個系統可以大致地分成三個部分：producer，store，consumer。
-
producer：增量日誌獲取模塊，主要負責解析獲取源端的增量數據改動日誌，並將獲取到的日誌解析封裝為 JSON 協議的消息體，投送至消息隊列。當源端是 MySQL 或者 TDSQL 時，獲取的增量日誌為 binlog 事件，這裡要求 binlog 必須是 row 格式且為 full-image。當源端是 Oracle，producer 從 Oracle 的物化視圖日誌中獲取增量數據並進行封裝和投送。這裡 producer 在向消息隊列生產消息時，採用 at-least-once 模式，即保證特定消息隊列中至少有一份，不排除在隊列中有消息重複的情況。
-
store：消息隊列中，因為資料庫系統日誌有順序性要求，因此這裡所有的 topic 的 partition 個數均為 1，保證能夠按序消費。
-
consumer：日誌消費和重放模塊，負責從消息隊列中將 CDC 消息消費出來並根據配置重放到目標實例上。這裡因為 producer 端採用 at-least-once 模式生產，因此消費者這裡實現了冪等邏輯保證數據重放的正確。
▐ 核心特性：高性能、高一致、高可用
一、高性能保障：基於行的哈希並發策略
金融業務場景中，往往對數據的實時性要較高，因此對數據同步的性能提出了比較高的要求。為了解決這樣的問題，consumer 採用了基於行的哈希並發策略實現並行重放。下面以 binlog 消息為例來說明該策略的實現。
資料庫系統在記錄 binlog 時，按照事務的提交順序將行的改動寫入 binlog 文件，因此按照 binlog 文件記錄事件的順序進行串行重放，源端和目標端資料庫實例狀態一定會達到一致。但是串行重放因為速度慢，在遇到如批量更新等大事務時，容易產生較大的同步時延，適應不了對數據實時性較高的同步場景。為了提高並發度，這裡 consumer 按照每個行記錄的表名和主鍵值進行 hash，根據 hash 值將消息投送到對應的同步線程中。這樣亂序的重放會導致數據不一致嗎？答案是不會的，因為雖然是將順序的消息序列打亂了，但是同一行的所有操作都是在同一個線程中是有序的，因此只要每個行的改動執行序列正確，最終數據是會一致。這個過程如下圖所示：
二、一致性保障：row 格式 binlog 事件的冪等容錯
實現冪等邏輯的動機有兩個：
-
因為生產者實現的是 at-lease-once 模式進行消息生產，因此 consumer 這裡必須要能否處理消息重複的問題。
-
支持冪等邏輯後，便於數據的修復，且在數據同步的過程中不需要記錄鏡像點，便於運維。
這裡冪等邏輯的設計原則就是，保證按照 binlog 事件的意圖去對目標實例進行修改。如 insert 事件，其意圖就是要在資料庫中有一條 new 值標識的記錄；update 事件的意圖就是，資料庫中沒有 old 值標識的記錄，只有 new 值標識的記錄；delete 操作也是同樣，其結果就是要求目標資料庫中，不包含 old 值標識的記錄。因此針對 insert，update，delete 操作，其冪等邏輯如下：
-
INSERT
根據上圖可以看到，當出現主鍵衝突時，insert 操作會轉變成 delete+insert 操作來保證 insert 動作執行成功。另外圖中的影響行數小於 0 或者等於 0 標識執行 SQL 出錯和主鍵衝突。
-
update
從上圖我們可以看到，update 操作的冪等處理，其實就是保證了在資料庫中，只能有 new 值產生的記錄。
-
delete
這個過程中，delete 結束後大於 0 就成功；小於 0 就是失敗；等於 0 的時候我們認為它可能沒有匹配到行，這個時候我就按照主鍵操作——因為刪除的操作最終的結果就是目標一定沒有了當前刪除的消息主鍵所標識的這一行——這條操作完成後，DB 里一定沒有這行數據，因此僅僅是按照主鍵進行刪除就可以了。這個時候如果影響行數大於 0，則刪除成功。如果等於 0，就認為按照主鍵去匹配，本身刪除不到，匹配不到——意思是本身目標就沒有這條要刪的主鍵所標識的數據——所以實際上它的結果跟要做完刪除的結果，影響是一樣，也就結束這一條刪除的冪等。
三、高可用保障：多機容災保護
這一套同步服務，一定是高可用的，體現在兩個方面：1、災難的情況下，本身消費者的服務能夠在假如機器出現一些不可恢復的故障時能夠及時地感知並且自動遷移和切換；2、要應對本身常規的擴容——垂直擴容或者水平擴容的伸縮性需求，這也是我們比較強調，這一套同步服務要能夠兼容各種災難情況和常規的運維場景下各種各樣的要求來做到服務的高可用。
重點針對資料庫遷移同步的場景而言，TDSQL 多源同步提供多機容災保護機制：
消費者高可用保障層面，一方面消費者服務本身無狀態，所有的任務下發通過 MetaCluster 實現，可以通過多台機器去部署同步服務，這套容災機制通過 manager 進程來實現，也就是說當整個機器掉電，運營這個機器的 consumer 已經不存活，這個時候這些 consumer 在 MetaCluster 上的存活節點的失效就會被其他機器的 manager 節點感知——認為另外一些機器的 consumer 已經不存活，這個時候就會把任務接管過來，並且在自己機器上重新拉起這些服務。
二是我們要做到同一個數據同步的鏈路不能在兩台機器上同時拉起，這是一個互斥的要求。高可用機制會通過一些像唯一標識或者當前的分派節點做到，同一個數據同步的任務在被拉起的時候一定是發生在不同的機器上來實現漂移與互斥的操作，這個多機容災保護總體上就是通過 MetaCluster 和監控的進程，比如說 manager 這樣的服務進行協調完成，保證在機器級別災難或者其他災難情況下這些任務能夠在十秒以內成功遷移到其他的存活節點上。
TDSQL 多源同步金融級應用場景和最佳實踐
TDSQL 多源同步解決方案，過去幾年中，已經在眾多金融政企用戶中得到成功實踐，幫助用戶高效平穩的實現國產資料庫遷移替換。
而作為 TDSQL 模塊中核心的產品服務之一，除了可以實現資料庫全量平穩遷移，TDSQL 多源同步方案還具備支持數據分發、備份等場景應用能力，用戶基於這些能力，探索出各類安全高效實現對業務的數據智能化驅動的姿勢。
-
保單信息實時資料庫匯總
用戶可以通過多源同步對業務進行分布式的改造，直接通過實時同步將單實例往分布式的架構上遷移。比如說保險客戶通過多個分庫、多個分片區或者多個單的業務、邏輯上的劃分，把這些數據通過 TDSQL 這套服務同步到全量庫裡面。
以某大型網際網路保險公司為例，基於 TDSQL 多源同步遷移方案，實現了多對一的一拓撲結構，可以非常高效、穩健地將公司多套大區的業務數據匯總到一個全量庫裡面，繼而實現了對整體數據進行報表分析和抽取。
-
實現資料庫實例間同步，搭建數據倉庫
某大型消費金融公司，在將核心資料庫替換成 TDSQL 後，利用 TDSQL 多源同步服務進行不同資料庫實例之間的同步。這樣的操作帶來業務上的兩大層面驅動：第一個是風控，通過將增量的數據投送到下游消息隊列裡面，可提升智能風控的準確率與效率；第二，實現了數據倉庫，用戶利用多源同步這套系統，將業務實時生產庫裡面的數據源源不斷地、實時地投入到數據倉庫中，繼而實現 OLAP 類的業務，為業務提供智能化決策分析支持。
-
核心交易系統異構資料庫實時備份
2019 年，張家港行基於 TDSQL 打造的新一代核心業務系統，成功上線後便成為業界關注的焦點。將銀行傳統核心系統資料庫遷移到騰訊雲 TDSQL 資料庫後實現了代差級的降本增效。
在這樣的金融級高度敏感業務系統遷移實踐中，TDSQL 的性能和安全的遷移服務策略得到良好的驗證。
在張家港行資料庫遷移實踐中，核心交易集群是 TDSQL，TDSQL 多源同步方案通過內部的區域網，將存量和增量數據，寫入到備份機房，同時也通過全量的數據校驗服務保證數據源、目標是完全一致來進行風險控制。當核心交易系統如果出現一些小機率不可恢復的災難時候，系統可以在短時間內將交易的服務全部切換到備份機房的 Oracle 上，作為銀行傳統核心系統資料庫遷移的安全兜底方案，最後確保資料庫順利遷移。
-
資料庫遷移業務割接
資料庫遷移涉及大量核心數據信息，「快」和「穩」缺一不可。多源同步服務作為 TDSQL 內置功能特性，以某省廣電局遷移案例為例，TDSQL 多源同步遷移服務通過重新部署業務系統的遷移方式，從遷移準備、遷移評估、方案設計、資源準備及資料庫改造、遷移實施、結果驗證一共只使用 30 天。其中最為關鍵的資源準備及資料庫改造環節用時 7 天！將客戶的業務系統資料庫從 Oracle 遷移到 TDSQL，TDSQL 的性能滿足了客戶面臨的現有的業務壓力。而業務系統遷移過程中對數據完整性保障，為後續新業務系統運維提供了良好的數據基礎。
-
跨城跨數據中心災備
以某網際網路人壽保險公司為例，該用戶在公有雲 TDSQL 上的實例是其核心的生產環境，雲下同時也部署了一套 TDSQL 系統，通過多源同步這套系統，用戶實現了雲上的生產環境和雲下的生產環境災備同步，這相當於是，實現了跨城同時也是跨數據中心的數據災備功能。
結語
基於高一致、高性能、高可用這「三高」的特性，TDSQL 多源同步幫助用戶業務實現金融級別或者金融場景的數據對外解耦、數據分發、遷移、同步等能力，並通過這些能力，融合到用戶業務的數字化升級當中。
TDSQL 多源同步作為 TDSQL 產品服務體系的核心模塊，既是如關鍵橋樑般的功能，也是幫助衍生業務價值的服務，在資料庫國產化中從分布式改造、遷移、備份到後續同步、分發等，服務用戶遷移到投產、生產運營的全流程。這也是 TDSQL 在多年的實踐打磨下，呈現的產品化優勢。
作者簡介：吳夏，騰訊雲 TDSQL 高級工程師，多年分布式資料庫系統研發經驗，目前主要負責 TDSQL 異構數據同步與遷移能力的建設，曾支持大量金融行業資料庫遷移同步。
歡迎更多技術人微信搜索「donyintxy」（備註：姓名+公司+職位）向 CSDN 投稿。
☞華為 5G、阿里檢測病毒算法、騰訊 AI 一分鐘診斷，國內抗疫科技大閱兵！
☞Get！讀懂數據科學和機器學習，看這文就夠了！
☞天才程式設計師之隕落：在業餘項目創業 Cloudflare，公司上市前患病失去自理能力
☞Go遠超Python，機器學習人才極度稀缺，全球16,655位程式設計師告訴你這些真相
☞對不起，我把APP也給爬了
☞超級帳本Hyperledger Fabric中的Protobuf到底是什麼？