愛奇藝，中國高品質視頻娛樂服務提供者，2010 年 4 月 22 日正式上線，推崇品質、青春、時尚的品牌內涵如今已深入人心，網羅了全球廣大的年輕用戶羣體，積極推動產品、技術、內容、營銷等全方位創新。企業願景爲做一家以科技創新爲驅動的偉大娛樂公司。我們在前沿技術領域也保持一定的關注度。
隨着公司業務的快速發展，原來普遍使用的 MySQL 集羣遇到了很多瓶頸，比如單機 MySQL 實例支撐的數據量有限，只能通過不停刪除較舊的數據來維持數據庫的運轉。同時單表的數據行數不斷增大導致查詢速度變慢。急需一種可擴展、高可用同時又兼容 MySQL 訪問方式的數據庫來支撐業務的高速發展。
我司從 2017 年年中開始調研 TiDB，並且在數據庫雲部門內部系統中使用了 TiDB 集羣。從今年 TiDB 推出 2.0 之後，TiDB 愈發成熟，穩定性與查詢效率都有很大提升。今年陸續接入了邊控中心、視頻轉碼、用戶登錄信息等幾個業務，這幾個業務背景和接入方式如下詳述。
項目介紹
1. 邊控中心
邊控中心存儲的是機器的安全統計信息，包括根據 DC、IP、PORT 等不同維度統計的流量信息。上層業務會不定期做統計查詢，其業務頁面如下：
<center>圖 1 邊控中心上層業務頁面（一）</center>
<center>圖 2 邊控中心上層業務頁面（二）</center>
在選型過程中，也考慮過時序型數據庫 Apache Druid（http://druid.io），但是 Druid 聚合查詢不夠靈活，最終放棄 Druid 選擇了 TiDB 數據庫。TiDB 幾乎完全兼容 MySQL 的訪問協議，可以使用現有的 MySQL 連接池組件訪問 TiDB，業務遷移成本低，開發效率高。
邊控中心是愛奇藝第一個在線業務使用 TiDB 的項目，所以我們制定了詳細的上線計劃。
- 第一，部署單獨的 TiDB 集羣。然後，爲了數據安全，部署了 TokuDB 集羣，用作 TiDB 集羣的備份數據庫。
- 第二，我們通過 TiDB-Binlog 將 TiDB 集羣的數據變更實時同步到 TokuDB 集羣中，作爲 TiDB 的災備方案。
- 第三，前端部署了自研的負載均衡中間件，以最大化利用多個 TiDB 節點的計算能力，同時保證 TiDB 節點的高可用。
- 第四，部署 Prometheus 和 Grafana 監控 TiDB 集羣健康狀況，同時 Grafana 接入了公司的告警平臺，會及時將告警信息通過短信、郵件等方式通知到運維值班同事。
邊控中心上線過程中，也遇到了一些問題，都比較順利的解決了：
- 最常見的問題是連接超時。經過仔細排查發現是統計信息嚴重過時導致執行計劃無法選擇最優解造成的，這個問題其實是關係型數據庫普遍存在的問題，普遍的解決思路是手工進行統計信息收集，或者通過 hint 的方式來固定執行計劃，這兩種方式對使用者都有一定的要求，而最新版本的 TiDB 完善了統計信息收集策略，比如增加了自動分析功能，目前這個問題已經解決。
- 還遇到了加索引時間較長的問題。這一方面是由於 DDL 執行信息更新不及時，造成查詢 DDL 進度時看到的是滯後的信息。另一方面是由於有時會存在 size 過大的 Region，導致加索引時間變長。這個問題反饋給 PingCAP 官方後得到比較積極的響應，大 Region 已經通過增加 Batch split 等功能在新版的 TiDB 中修復了。
邊控中心上線以後，在不中斷業務的情況下成功做過版本升級，修改 TiKV 節點內部參數等操作，基本對業務沒有影響。在升級 TiKV 節點過程中會有少量報錯，如“region is unvailable[try again later]、tikv server timeout”等。這是由於緩存信息滯後性造成的，在分佈式系統中是不可避免的，只要業務端有重試機制就不會造成影響。
邊控中心上線以後，數據量一直在穩定增長，但查詢性能保持穩定，響應時間基本保持不變，能做到這點殊爲不易，我個人的理解，這個主要依賴 TiDB 底層自動分片的策略，TiDB 會根據表數據量，按照等長大小的策略（默認 96M）自動分裂出一個分片，然後通過一系列複雜的調度算法打散到各個分佈式存儲節點上，對一個特定的查詢，不管原表數據量多大，都能通過很快定位到某一個具體分片進行數據查詢，保證了查詢響應時間的穩定。
邊控中心數據量增長情況如下：
<center>圖 3 邊控中心數據量增長情況</center>
TiDB 底層自動分片策略：
<center>圖 4 TiDB 底層自動分片策略</center>
2. 視頻轉碼
視頻轉碼業務是很早就接入 TiDB 集羣的一個業務。視頻轉碼數據庫中主要存儲的是轉碼生產過程中的歷史數據，這些數據在生產完成後還需要進一步分析處理，使用 MySQL 集羣時因爲容量問題只好保留最近幾個月的數據，較早的數據都會刪掉，失去了做分析處理的機會。
針對業務痛點，在 2017 年年底部署了 TiDB 獨立集羣，並全量+增量導入數據，保證原有 MySQL 集羣和新建 TiDB 集羣的數據一致性。在全量同步數據過程中，起初採用 Mydumper+Loader 方式。Loader 是 PingCAP 開發的全量導入工具，但是導入過程總遇到導入過慢的問題，爲解決這個問題，PingCAP 研發了 TiDB-Lightning 作爲全量同步工具。TiDB-Lightning 會直接將導出的數據直接轉化爲 sst 格式的文件導入到 TiKV 節點中，極大的提高了效率，1T 數據量在 5-6 個小時內就能完成，在穩定運行一段時間後將流量遷移到了 TiDB 集羣，並且擴充了業務功能，迄今穩定運行。
TiDB-Lightning 實現架構圖：
<center>圖 5 TiDB-Lightning 實現架構圖</center>
3. 用戶登錄信息
用戶登錄信息項目的數據量一直在穩定增長，MySQL 主備集羣在不久的將來不能滿足存儲容量的需求。另外，由於單表數據量巨大，不得不在業務上進行分表處理，業務數據訪問層代碼變得複雜和缺乏擴展性。在遷移到 TiDB 後，直接去掉了分庫分表，簡化了業務的使用方式。另外，在 MySQL 中存在雙散表並進行雙寫。在 TiDB 中進一步合併成了一種表，利用 TiDB 的索引支持多種快速查詢，進一步簡化了業務代碼。
在部署增量同步的過程中使用了官方的 Syncer 工具。Syncer 支持通過通配符的方式將多源多表數據匯聚到一個表當中，是個實用的功能，大大簡化了我們的增量同步工作。目前的 Syncer 工具還不支持在 Grafana 中展示實時延遲信息，這對同步延遲敏感的業務是個缺點，據官方的消息稱已經在改進中，同時 PingCAP 他們重構了整個 Syncer，能自動處理分表主鍵衝突，多源同時 DDL 自動過濾等功能，總之通過這套工具，可以快速部署 TiDB “實時”同步多個 MySQL，數據遷移體驗超讚。
<center>圖 6 Syncer 架構</center>
在我們公司業務對數據庫高可用有兩個需求：一個是機房宕機了，服務仍然可用。另一個是，多機房的業務，提供本機房的只讀從庫，提升響應速度。針對這些不同的需求，TiDB 集羣採用了多機房部署的方式，保證其中任一個機房不可用時仍然正常對外提供服務（如下圖）。對每個 TiKV 節點設置 label 後，TiDB 集羣在每個機房都有一份數據的副本，PD 集羣會自動調度到合適的副本進行讀操作，也可以滿足第二個要求。爲了滿足遷移過程中的高可用性，會在流量遷移完成後部署 TiDB 到 MySQL 的實時同步。Drainer 支持指定同步開始的時間戳，有力支持了反向同步功能。
<center>圖 7 TiDB 集羣多機房部署形式</center>
在整個運維過程中，PingCAP 的小夥伴們提供了及時的幫助，幫助我們定位問題並提出建議，保證了業務的有序運行。在此表示由衷的感謝！
適用範圍
在實踐過程中感受到 TiDB 解決的痛點主要是橫向擴展和高可用。單機數據庫支撐的數據量有限，如果採用分庫分表 + proxy 的方式，無論 proxy 是在客戶端還是服務端都增加了運維的成本。同時 proxy 的查詢效率在很多場景下不能滿足要求。另外，proxy 對事務的支持都比較弱，不能滿足數據強一致性的要求。TiDB 可以直接替代 proxy+MySQL 的架構，服務高可用性、數據高可用性、橫向擴展性都由 TiDB 集羣完成，完美解決了數據量增量情況下出現的很多問題。而且，TiDB 在數據量越大的情況下性能表現得比 MySQL 越驚豔。
一些改進建議
- 統計信息的收集期望更加的智能化，選擇更好的時機自動完成而且不影響線上業務。
- OLTP 和 OLAP 混合場景下相互間的隔離和儘量互不影響還有許多工作值得推進。
- 一些外圍工具還需要提供高可用特性。
未來計劃
我司仍有其它業務在接入 TiDB 服務，目前正在評估測試中。一些業務場景是 OLTP+OLAP 混合的場景，TiSpark 正好可以大展身手。目前在測試集羣發現 TiSpark 查詢時對 OLTP 業務的影響還是比較大的，必須限制 TiSpark 對 TiDB 集羣造成的壓力。還部署了單獨 TiDB 集羣做 OLAP 場景的測試，對內部參數做了針對性的優化。未來計劃會繼續加大對 TiDB 的投入，貢獻一些 PR 到社區，其中很大的一部分工作是增強 TiDB-Binlog 的功能，和現有的一些數據同步組件整合起來，支持 TiDB 到 Kudu、HBase 等的同步。
作者：朱博帥，愛奇藝資深數據庫架構師