摘要：愛奇藝，中國高品質視頻娛樂服務提供者，年月日正式上線，推崇品質青春時尚的品牌內(nèi)涵如今已深入人心，網(wǎng)羅了全球廣大的年輕用戶群體，積極推動產(chǎn)品技術內(nèi)容營銷等全方位創(chuàng)新。邊控中心是愛奇藝第一個在線業(yè)務使用的項目，所以我們制定了詳細的上線計劃。

愛奇藝，中國高品質視頻娛樂服務提供者，2010 年 4 月 22 日正式上線，推崇品質、青春、時尚的品牌內(nèi)涵如今已深入人心，網(wǎng)羅了全球廣大的年輕用戶群體，積極推動產(chǎn)品、技術、內(nèi)容、營銷等全方位創(chuàng)新。企業(yè)愿景為做一家以科技創(chuàng)新為驅動的偉大娛樂公司。我們在前沿技術領域也保持一定的關注度。

隨著公司業(yè)務的快速發(fā)展，原來普遍使用的 MySQL 集群遇到了很多瓶頸，比如單機 MySQL 實例支撐的數(shù)據(jù)量有限，只能通過不停刪除較舊的數(shù)據(jù)來維持數(shù)據(jù)庫的運轉。同時單表的數(shù)據(jù)行數(shù)不斷增大導致查詢速度變慢。急需一種可擴展、高可用同時又兼容 MySQL 訪問方式的數(shù)據(jù)庫來支撐業(yè)務的高速發(fā)展。

我司從 2017 年年中開始調(diào)研 TiDB，并且在數(shù)據(jù)庫云部門內(nèi)部系統(tǒng)中使用了 TiDB 集群。從今年 TiDB 推出 2.0 之后，TiDB 愈發(fā)成熟，穩(wěn)定性與查詢效率都有很大提升。今年陸續(xù)接入了邊控中心、視頻轉碼、用戶登錄信息等幾個業(yè)務，這幾個業(yè)務背景和接入方式如下詳述。

邊控中心存儲的是機器的安全統(tǒng)計信息，包括根據(jù) DC、IP、PORT 等不同維度統(tǒng)計的流量信息。上層業(yè)務會不定期做統(tǒng)計查詢，其業(yè)務頁面如下：

在選型過程中，也考慮過時序型數(shù)據(jù)庫 Apache Druid（http://druid.io），但是 Druid 聚合查詢不夠靈活，最終放棄 Druid 選擇了 TiDB 數(shù)據(jù)庫。TiDB 幾乎完全兼容 MySQL 的訪問協(xié)議，可以使用現(xiàn)有的 MySQL 連接池組件訪問 TiDB，業(yè)務遷移成本低，開發(fā)效率高。

邊控中心是愛奇藝第一個在線業(yè)務使用 TiDB 的項目，所以我們制定了詳細的上線計劃。

第一，部署多帶帶的 TiDB 集群。然后，為了數(shù)據(jù)安全，部署了 TokuDB 集群，用作 TiDB 集群的備份數(shù)據(jù)庫。

第二，我們通過 TiDB-Binlog 將 TiDB 集群的數(shù)據(jù)變更實時同步到 TokuDB 集群中，作為 TiDB 的災備方案。

第三，前端部署了自研的負載均衡中間件，以最大化利用多個 TiDB 節(jié)點的計算能力，同時保證 TiDB 節(jié)點的高可用。

第四，部署 Prometheus 和 Grafana 監(jiān)控 TiDB 集群健康狀況，同時 Grafana 接入了公司的告警平臺，會及時將告警信息通過短信、郵件等方式通知到運維值班同事。

邊控中心上線過程中，也遇到了一些問題，都比較順利的解決了：

最常見的問題是連接超時。經(jīng)過仔細排查發(fā)現(xiàn)是統(tǒng)計信息嚴重過時導致執(zhí)行計劃無法選擇最優(yōu)解造成的，這個問題其實是關系型數(shù)據(jù)庫普遍存在的問題，普遍的解決思路是手工進行統(tǒng)計信息收集，或者通過 hint 的方式來固定執(zhí)行計劃，這兩種方式對使用者都有一定的要求，而最新版本的 TiDB 完善了統(tǒng)計信息收集策略，比如增加了自動分析功能，目前這個問題已經(jīng)解決。

還遇到了加索引時間較長的問題。這一方面是由于 DDL 執(zhí)行信息更新不及時，造成查詢 DDL 進度時看到的是滯后的信息。另一方面是由于有時會存在 size 過大的 Region，導致加索引時間變長。這個問題反饋給 PingCAP 官方后得到比較積極的響應，大 Region 已經(jīng)通過增加 Batch split 等功能在新版的 TiDB 中修復了。

邊控中心上線以后，在不中斷業(yè)務的情況下成功做過版本升級，修改 TiKV 節(jié)點內(nèi)部參數(shù)等操作，基本對業(yè)務沒有影響。在升級 TiKV 節(jié)點過程中會有少量報錯，如“region is unvailable[try again later]、tikv server timeout”等。這是由于緩存信息滯后性造成的，在分布式系統(tǒng)中是不可避免的，只要業(yè)務端有重試機制就不會造成影響。

邊控中心上線以后，數(shù)據(jù)量一直在穩(wěn)定增長，但查詢性能保持穩(wěn)定，響應時間基本保持不變，能做到這點殊為不易，我個人的理解，這個主要依賴 TiDB 底層自動分片的策略，TiDB 會根據(jù)表數(shù)據(jù)量，按照等長大小的策略（默認 96M）自動分裂出一個分片，然后通過一系列復雜的調(diào)度算法打散到各個分布式存儲節(jié)點上，對一個特定的查詢，不管原表數(shù)據(jù)量多大，都能通過很快定位到某一個具體分片進行數(shù)據(jù)查詢，保證了查詢響應時間的穩(wěn)定。

邊控中心數(shù)據(jù)量增長情況如下：

TiDB 底層自動分片策略：

視頻轉碼業(yè)務是很早就接入 TiDB 集群的一個業(yè)務。視頻轉碼數(shù)據(jù)庫中主要存儲的是轉碼生產(chǎn)過程中的歷史數(shù)據(jù)，這些數(shù)據(jù)在生產(chǎn)完成后還需要進一步分析處理，使用 MySQL 集群時因為容量問題只好保留最近幾個月的數(shù)據(jù)，較早的數(shù)據(jù)都會刪掉，失去了做分析處理的機會。

針對業(yè)務痛點，在 2017 年年底部署了 TiDB 獨立集群，并全量+增量導入數(shù)據(jù)，保證原有 MySQL 集群和新建 TiDB 集群的數(shù)據(jù)一致性。在全量同步數(shù)據(jù)過程中，起初采用 Mydumper+Loader 方式。Loader 是 PingCAP 開發(fā)的全量導入工具，但是導入過程總遇到導入過慢的問題，為解決這個問題，PingCAP 研發(fā)了 TiDB-Lightning 作為全量同步工具。TiDB-Lightning 會直接將導出的數(shù)據(jù)直接轉化為 sst 格式的文件導入到 TiKV 節(jié)點中，極大的提高了效率，1T 數(shù)據(jù)量在 5-6 個小時內(nèi)就能完成，在穩(wěn)定運行一段時間后將流量遷移到了 TiDB 集群，并且擴充了業(yè)務功能，迄今穩(wěn)定運行。

TiDB-Lightning 實現(xiàn)架構圖：

3. 用戶登錄信息

用戶登錄信息項目的數(shù)據(jù)量一直在穩(wěn)定增長，MySQL 主備集群在不久的將來不能滿足存儲容量的需求。另外，由于單表數(shù)據(jù)量巨大，不得不在業(yè)務上進行分表處理，業(yè)務數(shù)據(jù)訪問層代碼變得復雜和缺乏擴展性。在遷移到 TiDB 后，直接去掉了分庫分表，簡化了業(yè)務的使用方式。另外，在 MySQL 中存在雙散表并進行雙寫。在 TiDB 中進一步合并成了一種表，利用 TiDB 的索引支持多種快速查詢，進一步簡化了業(yè)務代碼。

在部署增量同步的過程中使用了官方的 Syncer 工具。Syncer 支持通過通配符的方式將多源多表數(shù)據(jù)匯聚到一個表當中，是個實用的功能，大大簡化了我們的增量同步工作。目前的 Syncer 工具還不支持在 Grafana 中展示實時延遲信息，這對同步延遲敏感的業(yè)務是個缺點，據(jù)官方的消息稱已經(jīng)在改進中，同時 PingCAP 他們重構了整個 Syncer，能自動處理分表主鍵沖突，多源同時 DDL 自動過濾等功能，總之通過這套工具，可以快速部署 TiDB “實時”同步多個 MySQL，數(shù)據(jù)遷移體驗超贊。

在我們公司業(yè)務對數(shù)據(jù)庫高可用有兩個需求：一個是機房宕機了，服務仍然可用。另一個是，多機房的業(yè)務，提供本機房的只讀從庫，提升響應速度。針對這些不同的需求，TiDB 集群采用了多機房部署的方式，保證其中任一個機房不可用時仍然正常對外提供服務（如下圖）。對每個 TiKV 節(jié)點設置 label 后，TiDB 集群在每個機房都有一份數(shù)據(jù)的副本，PD 集群會自動調(diào)度到合適的副本進行讀操作，也可以滿足第二個要求。為了滿足遷移過程中的高可用性，會在流量遷移完成后部署 TiDB 到 MySQL 的實時同步。Drainer 支持指定同步開始的時間戳，有力支持了反向同步功能。

在整個運維過程中，PingCAP 的小伙伴們提供了及時的幫助，幫助我們定位問題并提出建議，保證了業(yè)務的有序運行。在此表示由衷的感謝！

在實踐過程中感受到 TiDB 解決的痛點主要是橫向擴展和高可用。單機數(shù)據(jù)庫支撐的數(shù)據(jù)量有限，如果采用分庫分表 + proxy 的方式，無論 proxy 是在客戶端還是服務端都增加了運維的成本。同時 proxy 的查詢效率在很多場景下不能滿足要求。另外，proxy 對事務的支持都比較弱，不能滿足數(shù)據(jù)強一致性的要求。TiDB 可以直接替代 proxy+MySQL 的架構，服務高可用性、數(shù)據(jù)高可用性、橫向擴展性都由 TiDB 集群完成，完美解決了數(shù)據(jù)量增量情況下出現(xiàn)的很多問題。而且，TiDB 在數(shù)據(jù)量越大的情況下性能表現(xiàn)得比 MySQL 越驚艷。

統(tǒng)計信息的收集期望更加的智能化，選擇更好的時機自動完成而且不影響線上業(yè)務。

OLTP 和 OLAP 混合場景下相互間的隔離和盡量互不影響還有許多工作值得推進。

一些外圍工具還需要提供高可用特性。

我司仍有其它業(yè)務在接入 TiDB 服務，目前正在評估測試中。一些業(yè)務場景是 OLTP+OLAP 混合的場景，TiSpark 正好可以大展身手。目前在測試集群發(fā)現(xiàn) TiSpark 查詢時對 OLTP 業(yè)務的影響還是比較大的，必須限制 TiSpark 對 TiDB 集群造成的壓力。還部署了多帶帶 TiDB 集群做 OLAP 場景的測試，對內(nèi)部參數(shù)做了針對性的優(yōu)化。未來計劃會繼續(xù)加大對 TiDB 的投入，貢獻一些 PR 到社區(qū)，其中很大的一部分工作是增強 TiDB-Binlog 的功能，和現(xiàn)有的一些數(shù)據(jù)同步組件整合起來，支持 TiDB 到 Kudu、HBase 等的同步。

作者：朱博帥，愛奇藝資深數(shù)據(jù)庫架構師