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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

TiDB 底層自動(dòng)分片策略：

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

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

TiDB-Lightning 實(shí)現(xiàn)架構(gòu)圖：

3. 用戶登錄信息

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

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

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

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

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

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

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

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

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

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