作者：傅少峰，新東方資料服務團隊（資料庫和大資料）負責人，TiDB User Group Ambassador
前言
我從 2016 年開始關注分布式資料庫，但分布式資料庫其實很早就被Google 提出來了。Google 是全球的技術标杆和技術論文産出工廠，從幾年前的 BigTable 到現在的 Spanner，引領了大資料和資料庫的發展趨勢，随着時間的推進 Google 又拉開了 NewSQL 的大幕 。近幾年，國内外出現了很多優秀的 NewSQL 産品，如：Spanner、CRDB、TiDB、OceanBase、TBase、GaussDB 等。
本文主要和大家分享三個部分的内容：
- 新東方集團的基礎服務架構介紹
- 業務前台 APP 系統平滑上遷 TiDB
- TiDB 如何承載業務中台交易系統
新東方基礎服務架構
我簡單介紹一下新東方。新東方是國内規模最大的綜合性教育集團，包括基礎教育、線上教育、外語教育訓練等。2018 年下半年集團提出三化建設。目前我們對分庫分表的核心業務，例如報名、一卡通、支付等業務系統都在進行中心化建設，把全國 120 多所學校的業務資料上遷到新東方集團，由我們資料服務團隊做集中式管理。
下圖是新東方集團的雲服務體系。我們是混合雲架構，包括私有雲（虛拟化和容器化）、公有雲、實體機。雖然是混合雲架構，但 DC、IDC、公有雲已經建構成萬兆環網，實作了跨機房資料庫部署的基礎條件。
我們對中心化建設的業務資料庫有以下 4 個要求：
- 高性能
- 高可用
- 易擴充
- 易運維
近一兩年業務資料大量增長和業務資料集中上遷，是以擴充性是我們首先要考慮的。于是我們就開始了 NewSQL 的調研和選型。期間調研過 OB、CRDB 、TiDB，由于 TiDB 是完全開源的分布式資料庫，文檔和社群比較友好，高度相容 MySQL，并且是國産資料庫，是以我們最終選擇了 TiDB。
TiDB 在新東方業務前台 APP 系統的應用
TiDB 在新東方試用的第一個項目是集團的 OA 系統，該系統大概有 7W+ 使用者使用。經過多年積累，系統和流程非常複雜。當時 OA 系統遇到的問題是流程辦理步驟表資料量過億并且資料分布不均，業務需要進行大表的關聯查詢。
初期我們想使用 HBase 分布式架構解決單表數量過大問題，因為這塊業務對事務沒有要求，但在 POC 時發現研發成本很高，後來我們選擇了 TiDB。
在 OA 系統試用時候我們用的是 TiDB 2.0 版本，當時該 TiDB 版本在倒排序性能相對較差，無法滿足我們業務對倒排序場景的要求，最終我們選擇了傳統的分庫分表解決方案。現在 TiDB 3.0 版本的穩定性和性能都上來了，我們考慮将 OA 系統從 MySQL 遷到 TiDB。
新東方 APP 系統這塊沒有複雜的業務邏輯，過去我們的解決方案是 MySQL+ MHA + HAProxy，現在是 TiDB + HAProxy/ Nginx。 從 MySQL 遷移到 TiDB 的過程，我們主要通過 TiDB 的生态工具 Mydumper、Loader、Syncer，把資料實時傳到下遊 TiDB，把 TiDB 作為 MySQL 的一個從庫，然後做性能和功能驗證。雖然資料可以平滑過去，但是業務不一定，是以我們遷移以後遇到了 TiDB 不支援大小寫敏感、自增 ID 、外鍵、觸發器、索引優化等問題。這裡詳細說一下索引優化的問題。我們從 MySQL 直接遷到 TiDB，索引也需要和 TiDB 相相容。在 TiDB 中，A 和 B 這兩個條件，A 加索引，B 也有索引，但隻能走一個索引，這也是遷移過程中我們要考慮的。
如果上述說的幾個問題都解決了，業務就可以很平滑地進行遷移。我們 2018 年年初開始測試 TiDB， 2018 年 5 月份正式上線。上線後一年半以來，沒有出現資料丢失和資料不一緻的問題。運作期間，雖然出現過資料庫負載很高導緻響應變慢的情況，但沒有出現資料庫宕掉的問題，還是相對比較穩定的。上線時資料量在 400G +（目前 900G+），節點數 15 個，一直線上平滑滾動更新。
TiDB 在新東方業務中台系統的應用
剛才講的是我們的一個前端業務，現在來講講我們的業務中台。
以前我們核心交易系統就是報名系統，它承載了新東方線上和線下所有報名交易業務，就像一個功能龐大的 ERP 系統。2018 年集團提出三化建設，我們開始對現有的核心報名系統進行重構，完成業務中台的建設。目前我們業務中台包括八大中心，其中三個中心應用了 TiDB 資料庫：報名中心、行課中心、支付中心。
首先來看看報名中心。報名中心對事務有嚴格的要求。剛才的前台 APP 業務對事務沒有要求，事務到底是強一緻性，還是最終一緻，不是很重要。但是報名場景要求學生家長報名交了錢要馬上可以查到報名資訊，如果隻是最終一緻，就不能得到實時回報，使用體驗不好。是以這塊我們要求一定要保證事務的強一緻性，達到 ACID 事務标準。我們老報名系統的資料庫是基于 SQL Server 的，報名中心是完全重新基于分布式資料庫 TiDB 開發的。
目前我們的架構是多中心部署的，但沒有異地，都在北京。我們在不同的機房做了部署，即使後期需要再遷新機房，也可以按照 lable 把每個機房的 TiDB 進行動态遷移，加入新機器動态替換叢集。
但也有個問題：萬一機房出故障，資料怎麼辦？這時我們用 TiDB 的第二套叢集災備方案，同步到下遊的災備叢集裡，這個災備叢集也在動态提供 AP 業務查詢服務。
目前報名中心還沒有完全實作 TP 和 AP 業務低耦合，由于之前的 TiDB 還沒有 TiFlash 列存，無法很好地實作 HTAP 業務場景資源實體隔離和互不影響。目前 TiDB 叢集如果有大量的 AP 業務進行導資料或即席查詢操作，會影響整體 TP 業務的 SQL 響應時間。是以我們在 TiFlash 正式 GA 前，做了一個和 MySQL 底層架構一樣的 Binlog 服務，往下遊的 TiDB 叢集進行同步。但都在異步的情況下，MySQL 在毫秒級别就同步完了，TiDB 一般同步延時在 1~2 秒。
目前我們在報名中心開發過程中遇到了一些問題。
首先是事務的隔離級别， SQL Server 是 RC 模式，但 TiDB 是 SI 模式。
還有一個就是悲觀鎖，這在交易系統中是非常重要的。TiDB 不适合用于鎖庫存、秒殺的場景，因為它沖突率比較高。作為替代，可以使用 select for update。但事務實際是被排成隊列以串行的方式執行的，性能不高。我們使用 Redis 緩存級的分布式鎖解決了這個問題。Redis 緩存做到串行化處理是非常快的，并且損耗不是很大，也有着較大的性能優勢。如果當時 TiDB 釋出了悲觀鎖的功能，就可以通過高并發的形式，放到分布式裡去。值得欣慰的是，TiDB 3.0 版本已經支援了悲觀鎖功能。另外還有字元集和排序規則、外鍵、觸發器和存儲過程，以及自增且唯一并不保證連續的問題。