TiDB 在愛奇藝的應用及實踐

愛奇藝，中國高品質視頻娛樂服務提供者，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 等的同步。

做者：朱博帥，愛奇藝資深數據庫架構師