作者介紹
胡盼盼，微眾銀行數據平臺室室經理。碩士畢業于華中科技大學，畢業后加入騰訊，任高級工程師，從事分布式存儲與云數據庫相關的研發與運營工作；2014 年加入微眾銀行，負責微眾銀行的數據庫平臺的建設與運營。
黃蔚，微眾銀行數據庫平臺室高級 DBA。2011 年加入騰訊互動娛樂運營部，擔任英雄聯盟在內的多款海量用戶產品的數據庫運維工作。2015 年加入微眾銀行擔任高級 DBA，負責監控優化、性能優化以及新技術預研，目前致力于行內 的推廣與生態建設。
本文將介紹微眾銀行的數據庫架構演進過程，并分享 TiDB 在微眾銀行實踐經驗和部分業務案例。
一、微眾銀行數據庫架構演進
2014 年微眾銀行成立之時，就非常有前瞻性的確立了微眾銀行的 IT 基礎架構的方向：去 IOE，走互聯網模式的分布式架構。IOE 即 IBM、、EMC，代表了傳統基礎架構領域的服務器、商業數據庫和存儲產品體系，眾所周知傳統銀行 IT 架構體系非常依賴于 IOE，每年也需要巨大的 IT 費用去維護和升級 。從數據庫角度來看，當時除了 ，能滿足金融級銀行場景的數據庫產品并不多，微眾銀行基礎架構團隊經過多輪的評估和測試，最終確定使用騰訊主推的一款金融級別數據庫 TDSQL。
圖 1
TDSQL 是基于 內核 ，結合 mysql-proxy、 等開源組件實現的數據庫集群系統，并且基于 MySQL 半同步的機制，在內核層面做了大量優化，在性能和數據一致性方面都有大幅的提升，同時完全兼容 MySQL 語法，支持 Shard 模式（中間件分庫分表）和 模式（單機實例），同時還集成了管控平臺，智能運維等功能模塊。2014 年，TDSQL 已經支撐了騰訊內部的海量的計費業務，由于計費業務的場景和銀行的場景有所類似，對數據庫的可靠性和可用性要求也相近，所以我們當時選擇了 TDSQL 作為微眾銀行的核心數據庫。
1. 基于 DCN 的分布式架構
圖 2
確定了數據庫的選型之后， 下一步就是架構設計。我們設計了基于 DCN（Data Node）的分布式架構。DCN 可以認為是一個“自包含單位”，它會包含應用層、接入層、數據庫層，每個 DCN 承載規定數據量的用戶，通俗的理解，每個 DCN，就相當于微眾銀行的一個小的分行；基于 DCN 可以實現集群規模的水平擴展。這種架構對于數據庫來說，其實是比較友好的，因為每個 DCN 的用戶規模是確定的，那么對數據庫的容量和性能要求也是可確定的，因此我們不必再采用復雜的中間件分庫分表的方式構建數據庫，而只用單實例模式承載，極大簡化了數據庫架構，也降低了業務開發成本。如圖 2 所示，為了實現 DCN 架構，這里有兩個關鍵組件：RMB 和 GNS。RMB 負責各個模塊以及各個 DCN 之間的消息通信；GNS 負責全局的 DCN 路由，即某個用戶保存在哪個 DCN。另外這里有一個比較特殊的地方就是 ADM 管理區，它是一個統一的管理區，保存著無法進行 DCN 拆分的全局業務數據，和通過各 DCN 進行匯總的數據。后來 ADM 區成為了一個 TDSQL 的瓶頸，這是我們引入 TiDB 的動機之一。
2. IDC 架構
圖 3
接下來看一下我們的 IDC 的架構。目前我們是兩地六中心的架構，深圳的 5 個 IDC 是生產中心，而位于上海的跨城 IDC 是容災中心。同城的任意兩個 IDC 之前的距離控制在 10~50 公里以內，并通過多條專線互聯，以此保證兩個 IDC 之間的平均網絡延遲可以控制在 2ms 左右，并保證網絡的穩定性。
3. 數據庫部署架構
圖 4
基于以上的 DCN 架構和 IDC 架構，我們設計了數據庫的基礎架構，如圖 4 所示：我們采用同城 3 副本+跨城 2 副本的 3+2 部署模式，同城 3 副本為 1 主 2 備，跨 3 個同城 IDC 部署，副本之間采用 TDSQL 強同步，保證同城 3 IDC 之間的 RPO=0，RTO 秒級，跨城的 2 副本通過同城的一個 slave 進行異步復制，實現跨城的數據容災。基于以上架構，我們在同城可以做到應用多活，即同城的業務流量，可以同時從 3 個 IDC 進來，任何一個 IDC 宕機，可以保證數據 0 丟失，同時在秒級內可以恢復數據庫服務。這個架構在微眾銀行內部運行了四年多，當前已有 1500 多個實例在運行，數據量達到 PB 級，承載了銀行數百個核心系統，整體上來說還比較穩定的。但同時也遇到一些瓶頸。因為我們采用的是單實例的部署模式，對于有些無法通過 DCN 拆分進行擴展的業務場景，單實例的性能和容量就很容易到達瓶頸。當然，TDSQL 也提供了 TDSQL-Shard 模式，也就是通過中間件分庫分表的方式把一個表 Shard 之后再處理，但我們當時評估之后認為該模式對應用的侵入性比較大，比如所有的表必須定義 shard-key，有些語法可能不太兼容，有些分布式事務的場景可能會有瓶頸，進而導致業務遷移的成本會比較高。所以在這個背景下，我們開始尋求其它的解決方案，大約在 2018 年， 的概念逐漸被提了出來，同時也有一些商業和開源的 數據庫出現。我們很驚喜的發現， 數據庫的特性，可以較好的解決我們當時面臨的問題。 比較通用的定義是：一個能兼容類似 MySQL 的傳統單機數據庫、可水平擴展、數據強一致性同步、支持分布式事務、存儲與計算分離的關系型數據庫。經過大量的調研，對比與分析，我們最終決定重點考察開源 數據庫產品 TiDB。
二、微眾銀行 TiDB 數據庫實踐
1. Why TiDB ?
圖 5
除了 TiDB 的 特性之外，我們選擇 TiDB 的另一個主要原因，就是 TiDB 是一個開源的項目，而且社區很活躍，版本迭代快速，我們覺得這是一個很好的模式，而且微眾本身也是非常擁抱開源的。
圖 6
這里展示了 TiDB 的基本架構模型，非常簡潔優雅的架構，相信稍微了解 TiDB 的同學，對這個架構都比較熟悉了，在這里就不再贅述。當然，現在 TiDB 3.0 版本有了新的特性以及模塊加入，比如 Titan 引擎， 針對 大 Value 寫放大問題做了很大的優化和性能提升，再比如列式存儲引擎 ，為實現真正的 HTAP 奠定了基礎。
2. 對 TiDB 的評估與測試
圖 7
我們對 TiDB 做了一些評估和測試，對語法和 DDL、負載均衡、一致性、擴容等特性都做了很多測試。下面重點介紹以下 3 點：
3. TiDB 在微眾的部署模型
圖 8
圖 8 是 TiDB 在微眾銀行的部署模型，從一開始就選擇了同城三機房部署，也就是位于最底層的存儲層 TiKV 跨 3 個機房，3 個副本分布在 3 個機房，并且每個機房有 1 套獨立的 TiDB 集群負責接入與計算；PD 模塊也是跨 3 個機房部署。另外，針對比較重要的業務，我們會在容災 IDC 掛一個容災 TiDB 集群，這個容災 TiDB 集群會通過 TiDB 工具從生產集群實時同步數據。
三、微眾銀行 TiDB 業務實踐
TiDB 在微眾銀行的應用場景包括 OLAP、OLTP 及部分混合場景，大部分場景在 TB 級別的業務數據規模。下面詳細介紹貸款核心批量系統在測試 TiDB 過程中的實踐和優化，以及數據存證系統 TiDB 遷移實踐。
1. 貸款核心批量場景下的 TiDB 實踐
圖 9
這個業務場景的特殊性在于每天晚上 0 點之后讓oracle跑得更快2：基于海量數據的數據庫設計與優化，需要通過線上數據庫生成數億級別的批量數據，并進行一系列相關計算，然后 ETL 到大數據平臺去，其中涉及大量的增刪查改操作，并且對總時效要求很高，必須在兩個小時內跑完，不能出現任何問題。存在的問題：所以我們嘗試通過 TiDB 來承載這個批量場景，把每天的批量數據，匯總到一個大的 TiDB 集群中，再進行跑批，最后再 ETL 到大數據平臺中去做處理。整個流程如圖 9 右半部分所示，其中 “DM 工具”即 TiDB DM（TiDB Data ），是由 開發的一體化數據同步任務管理平臺，支持從 MySQL 或 到 TiDB 的全量數據遷移和增量數據同步。我們對應用側和 TiDB 2.1 版本進行了一系列的調優，整體的優化效果達到預期，批量的耗時縮短了 45% 左右。我們同時也測試了 3.0 beta 版本，3.0 相對于 2.1 版本，整體批量耗時又縮短了 30% 左右。整體來看，TiDB 讓我們的貸款核心批量場景下效率得到大幅度的提升。在整個業務測試的過程中。我們在應用側和數據庫側，都做了大量優化，也踩了不少坑，這里也分享幾點。
a. 數據導入過程 熱點集中
圖 10
該業務對批量數據導入的時間很敏感，但我們測試時發現雖然底層有 6 個 TiKV 節點，但每次數據開始導入時有 3 個 TiKV 節點負載特別高，另外 3 個節點負載很低，同時寫入也有瓶頸。通過排查發現這個問題的原因在于，對于快速的超大表的數據寫入，TiKV 的熱點調度并不及時，沒有辦法做到負載均衡，進而導致熱點。我們和 伙伴們討論解決方案后，增加了 預打散的功能。就是在建表時，就對表進行 打散操作 ，相當于一個空表就分散成多個 分布在 6 個 TiKV 節點上，當數據導入的時候就直接寫入各個 。從圖 10 可以看到增加預打散功能后，6 臺 TiKV 的負載非常均衡，并且耗時也變短了。
b. 無效 過多導致系統變慢
圖 11
另外一個遇到問題就是無效 過多的問題。前面提到，該業務數據在每天跑批完成之后需要刪掉，第二天全部數據需要重新生成，所以該場景下每天都有大量的數據表刪除和重建，會累積大量無效 ，導致 PD 元數據管理壓力過大， 副本之間的心跳也會大量增加 grpc 調用，導致整個系統運行比較慢。所以我們后來灰度上線了 merge 功能，這個功能在 TiDB 2.1.8 以后的版本中（含 3.0 GA）引入，從 圖 11 可以看到上線 merge 功能之后， 數量直線下降， 這個功能讓系統性能的提升提升了 30% 左右。
2. 數據存證系統 TiDB 遷移實踐
數據存證系統是微眾銀行非常重要的系統，存儲了具有法律效力的證據類數據，這些數據對客戶來說是非常重要的。
圖 12
隨著越來越多的業務系統的接入，該場景的數據增長速度非?？欤热缑恳淮无D帳都需要生成一個證據，并且不是簡單的一條記錄，而是發生糾紛時法院認可的證據，所以也決定了這些數據不能刪除。這些數據劃分在 ADM 區，沒辦法做橫向擴展，遇到了很大的瓶頸?；谶@些場景特點，微眾選擇了 TiDB 的解決方案。我們有幾個基本的遷移原則：1）數據不能錯、不能丟；2）服務敏感度非常高，需要盡量無縫切換到 TiDB 架構上；3）因為是比較嚴肅的金融場景，如果在遷移過程中有任何困難，我們期望能夠隨時回切到 MySQL。
圖 13
遷移整體方案如圖 13，步驟流程比較長，但會更加安全。接下來介紹每個步驟中我們碰到的困難和解決方案。第一個步驟是前置檢查。首先表必須有主鍵，如果是短時間海量連續寫入，不建議用自增 ID，可以把自增 ID 改成由雪花算法生成，再把雪花算法的時間戳后幾位提到最前面，這樣可以保證主鍵足夠隨機 ，然后使用我們之前提到的 Split 的功能，提前把 切分，并打散到所有的 TiKV 節點里，這樣可以在寫入的時候實現負載均衡，解決短時大量寫入瓶頸問題。
圖 14觸發器、存儲過程、視圖、 這些特性在我們行內是禁止使用的，所以對我們是沒有影響的。整體來看，前置檢查這一步我們重點關注的是性能問題，尤其是保證寫的性能，該場景是大批量數據，短時間的數億數據寫入性能的瓶頸問題還是值得關注并解決的。
圖 15
前置檢查完成后，接下來就是將數據同步到 TiDB， 提供了實時同步工具 TiDB DM，在簡單配置之后可以“一鍵式”將 MySQL 中的數據導入 TiDB，讓數據遷移變得非常便捷。當然，我們也遇到了幾點問題：
圖 16
作為一個金融場景，尤其是異構的數據同步，數據校驗是一個非常嚴肅的確認過程。熟悉 MySQL 的同學應該了解過 pt-table- 工具，它的原理和 提供的數據校驗功能類似，將這個數據切片之后，對數據切片進行 計算，然后比對上下游所有切片的 值是否一樣來判斷數據一致性；但是它當前還做不到類似 pt-table- 的在線校驗，如果上游 MySQL 的數據一直在變，就沒辦法做校驗了。另外，Chunk 切分偶爾不準、上下游排序規則不一致，這兩個問題已經在新版本有了優化。
圖 17
接下來是灰度切讀流量的過程?；诎踩钥紤]，我們先把非關鍵的讀流量灰度切換到 TiDB 中去，觀察一段時間，再把關鍵的讀流量也逐漸切換到 TiDB。當時遇到了執行計劃不準的問題，導致把讀流量切換到 TiDB 后發現，有些 SQL 查詢變慢了，這個問題在新版本中已經解決了，包括 TiDB 3.0 中也有執行計劃綁定（Plan ）、增量統計信息更新等優化。實際上，執行計劃不準的問題在 MySQL 等一些數據庫產品中比較普遍，因為統計信息不能 100% 實時更新。以前使用 MySQL 產品時，用戶可能需要強制指定某個索引 Index，這個操作對業務侵入性很大，而基于上面兩個功能，TiDB 在這點上對業務的侵入是很少的。
圖 18
在讀流量切換到 TiDB 沒有出現什么問題之后，我們再把寫流量切換到 TiDB，但也不是一次性切換，我們選擇先雙寫 TiDB 和 MySQL：先寫 MySQL 返回自增 ID，再用該 ID 加上業務數據異步寫入到 TiDB；上下游的 ID 保存一致方便我們進行數據校驗。在雙寫改造完成后，架構如圖 18 所示。應用準備發版時，為了保證業務暫停的時間足夠短，我們臨時調大了消息隊列 MQ 的長度，因為在整個應用關閉之后，消息隊列仍在存儲消息，可能會把消息隊列存滿。調大消息隊列長度之后，再逐個關閉應用，等到所有應用都停掉后，在確認 DM 的數據同步已經追平后，就可以把 DM 斷開，接下來就可以逐個啟動新版本的應用了。業務停止時間（最后一個應用關閉到新版本第一個應用啟動的時間間隔）控制在 1 分鐘以內，對應用的影響非常小。到這一步驟為止，其實整個服務讀寫都采用了 TiDB，但為了保證數據出現問題時能夠及時回遷，于是我們把灰度上線的的周期拉長，使用 TiDB 把 TiDB 中的數據反向同步到 MySQL，如下圖所示。
圖 19
我們觀察到 與同城 IDC 的下游 MySQL 部署在一起，RPC 延遲會更短，性能會更好。在幾個月之后，我們最終把反向同步關閉了，完全由 TiDB 提供服務。
圖 20
如圖 20 所示，我們還會做例行的數據備份的操作，包括使用 每周全量備份，使用 pb 每 5 分鐘備份增量 ，另外數據備份最好使用單獨的 tidb- 節點，對聯機的請求影響最小。在觀察一段時間之后，觀察到各方面的性能指標都非常穩定，然后決定將反向同步 MySQL 斷掉，也就意味著數據存證系統這樣一個非常重要的系統，完全跑在了 TiDB 上，回顧整個遷移過程，還是比較流暢且順利的。
四、總結
TiDB 是一個很優秀的分布式關系型數據庫產品。對銀行場景來說讓oracle跑得更快2：基于海量數據的數據庫設計與優化，灰度和上線的節奏沒有互聯網行業那么快，隨著 TiDB 產品的日趨成熟，我們正在更多適合的場景試用 TiDB，也會有更多的經驗和大家分享。
本文根據胡盼盼、黃蔚在 TiDB 2019 北京站及深圳站上的演講整理。- END -
典型實踐
知乎|
平安科技|
北京銀行| 1.2.
貝殼金服|
美團點評|
小紅書 |
小米|
愛奇藝|
豐巢|
|
轉轉|
同程藝龍|1.2.
易果生鮮|
今日頭條|
摩拜單車| 1.2.
去哪兒網|
更多：