360 x TiDB｜性能提高 10 倍，360 如何輕鬆抗住雙十一流量

「咱們已經用起來了」，是咱們最喜歡聽到的話，簡簡單單幾個字的背後表明着沉甸甸的信任和託付。從今天開始，咱們將經過「相信開放的力量」系列深度案例分享，從業務的角度，看看一個數據庫爲各行業用戶帶來的業務價值。 本篇文章將介紹 TiDB 在 360 網盾業務、智慧商業業務、廣告物料數據業務等核心場景的應用與實踐。

以科技爲驅動力，讓世界更安全更美好

360 公司創立於 2005 年，是中國領先的互聯網和安全服務提供商，前後推出 360 安全衛士、360 手機衛士、360 安全瀏覽器等安全產品。

隨着全社會、全行業數字化程度的深化，「大安全」時代加速到來，360 以「讓世界更安全更美好」爲使命，致力於實現「不斷創造黑科技，作全方位守護者」的願景，隨之而來的業務發展也更加全面，包括：政企服務、金融科技、直播、我的服務、智能穿戴等多方面業務。

業務挑戰

網盾業務

360 網盾是一款免費的上網保護軟件，能夠攔截木馬、欺詐網站等等保護消費者不受到病毒及虛假網站的欺詐。它的運行機制是會針對每一條 URL 進行分析，通過網址檢測系統判別後，可以精準識別出該 URL 屬於哪一個類別。對有問題的 URL 發佈到雲，其餘安全服務商就能夠經過訂閱雲服務，來檢測相關的 URL 是否安全，以向本身用戶提供更加安全的網頁內容服務。

目前整個網盾業務核心場景能夠分爲如下四個部分：

• 網址威脅監測：天天入庫 1 億條數據，8 億多資源連接數據；
• 關聯分析場景：進行大規模惡意網址、黃賭毒等網站的關聯分析；
• 高速返回：897 億條數據表，每一個場景 100+ 條數的查詢須要在 5 秒內返回；
• 人工運營分析：天天每一個人不斷反覆查詢統計、分析。

針對業務爆發式增加的數據量，讀寫上 MySQL 已經出現瓶頸。例如磁盤空間，雖然能夠經過分庫分表的方式，拆分出來，但這對業務和 DBA 來講都是不小的工做量；最痛苦的無異於這些大表的改表，對一張大表執行 DDL 的代價是很是大的。總的來講，MySQL 已經沒法知足網盾業務需求，這對負責底層數據平臺支撐的 360 雲平臺技術團隊提出了新的選型需求。

360 雲平臺負責對 360 集團各大業務線提供服務支持，涉及的數據庫支持方案有：MySQL、Redis、MongoDB、ElasticSearch、Greenplum、PiKA。在通過充分的市場調研後，360 雲平臺團隊決定引入 TiDB 來知足業務這一需求。

總體架構如上，使用 TiDB 的業務主要有兩種：

• 原有 MySQL 業務遷移。因單機磁盤受限，致使單實例磁盤沒法支撐爆炸式增加的數據量，數據比較重要，須要備份和支持 7*24 小時的恢復。這類業務經過 DM 套件來實現無障礙遷移，1TB 的導入時間在 16 小時，若是是比較大的數據源，且 TiDB 是全新集羣，可使用 TiDB Lightning 進行數據導入，速度能夠達到 100G/小時。
• 全新的業務。全新的業務目前所有都會放到 TiDB 中，這種業務數據量通常都會比較大，目前網盾業務有多張表都過 10 億級別，其中有張表到達了 100億+。

智慧商業業務

360 智慧商業依託覆蓋用戶全場景的互聯網產品，爲企業提供全生命週期服務。經過智能營銷、企業服務、創新平臺等多元業務佈局，知足多維增加需求，全面鏈接用戶與企業，打造共生共長的智慧商業生態，其中互聯網廣告是流量商業變現的重要途徑之一，也是 360 集團重要的營收來源，其中涉及企業服務平臺、廣告主投放、算法策略、數據工程等多個方向。廣告投放過程當中實時/離線報表業務以及廣告物料投放對廣告主來講是最重要、最核心的業務。

廣告主實時 & 離線報表業務

廣告主的實時報表業務流程：業務數據入 Kafka，一條處理鏈路是經過 Druid 獲取 Kafka 的數據提供實時分析，另外一條鏈路經過 Flink 進行聚合後寫入 MySQL 分庫分表數據庫，而後經過廣告主維度提供實時查詢需求。

廣告主的離線報表業務流程：天天凌晨，數倉從 MySQL 分庫分表中抽取前一天的全部數據入 Hive，經過 Spark 或者業務程序統計聚合後將結果數據寫入 MySQL 結果表，提供給離線報表平臺或者 Console 平臺查詢。

報表做爲廣告平臺的核心業務，面臨的問題以下：

• 數據量大：總數據千億級別，單表數據量 1.2~1.5 億。
• 響應延時低：須要對用戶的任意週期及關鍵詞的查詢進行實時反饋。
• 查詢複雜：時間維度、地域、行業、關鍵詞等等，同時知足多樣化的展現。
• 架構複雜：基於 MySQL 的分庫分表沒法進行全局統計，只能基於廣告主 UID 來出明細報表，全局的統計須要引入 Druid 來輔助處理；離線報表須要 Hive 數倉抽取全量數據來實現。

數據庫選型：MySQL or TiDB?

在部署 TiDB 以前，360 曾經嘗試過單實例 MySQL 去應對業務需求，測試完後發現單實例 MySQL 壓力較大，爲了分散寫壓力，又必須走 MySQL 分庫、分表這條老路，並且大數據量下的分庫分表，常常須要變更拆分規則，每次規則變更均可能涉及到數據的從新搬遷，而且業務端還須要投入大量的人力去維護路由規則，而且要知足廣告主的報表需求須要引入其餘的數據庫，離線 ETL 天天凌晨對 MySQL 的抽取形成網卡滿載，也會影響了凌晨的其餘業務操做。

部署 TiDB 後，TiDB 良好的擴展性徹底解決了分庫分表的問題，同時通過性能壓測，2 小時 1.5 億的數據存儲(TPS：2W/s)，整個系統負載徹底知足業務需求，經過搭配 TiFlash （TiDB 的實時分析引擎插件），咱們能夠對合並後的單表進行各類維度的全局以及明細的實時分析，而且實現了離線報表的在線統計，免去了離線數倉這種 T+1 的時效和同步流程，同時還提供金融級別的強一致性保證。

廣告物料數據業務

對於廣告主而言，在搜索推廣中，基於安全、精準、可信賴的新一代搜索引擎360搜索，經過關鍵詞技術匹配，定位目標網民，精準展示企業推廣信息，物料創意的做用則是幫助廣告主吸引潛客，進而產生轉化行爲，好比註冊、在線提交訂單、電話諮詢、上門訪問等等。

目前 360 廣告的物料平臺會承載客戶製做圖片、文字、視頻等的信息，支持對推廣帳戶、推廣計劃、推廣組、關鍵詞、推廣創意、高級樣式各個層級的物料進行上傳、下載、導入、導 出、添加、編輯、刪除等操做。

在使用 TiDB 以前，點睛物料數據底層使用了 16 套分庫 * 4 的 MySQL 架構，每套分庫 MySQL 單表已經到達 10 億，單表數據規模在 370G，對於單庫 QPS 過萬的 SQL 請求，MySQL 表已經到達性能瓶頸，高峯期頻繁抖動，而且新業務想對大表新增字段，因爲硬盤空間不足，也不能支持新業務上線。若是繼續使用 MySQL ，則須要將目前的 16 套分庫拆分紅 64 套分庫(須要新增約上百服務器)，除了新增服務器，遷移和運維成本也很是高。

360 商業化業務線技術團隊經過技術選型調研，最終肯定了以 TiDB 做爲物料平臺底層的數據庫。目前支撐物料平臺的 TiDB 集羣規模爲 63 個節點，日 SQL請求在 70 億次以上，在剛剛過去的雙十一 QPS 最高達 25 W/s，工做日 99% 的 SQL 請求都在 15ms 之內，響應快、穩定性、擴展性都達到預期。

經過部署 TiDB 收益以下：

• 成本節約

1. 相較以前 MySQL 部署模式，節約了 40% 的服務器成本。
2. 以前是業務維護的分庫分表路由規則，如今對於業務來講都是一張表，提高了業務的開發效率，讓研發更多的關注在業務上。
3. 運維成本下降，TiDB 提供豐富的工具鏈生態，覆蓋數據遷移、同步、備份等多種場景，提高了運維效率。

• 性能提高

1. 61八、雙十一 QPS 最高能到 25 W/s，工做日 99% 的 SQL 請求都在 15 ms。
2. 相對於基於 VIP 切換的 MySQL 主從架構，TiDB 的可用性超過 99.95%。
3. 純分佈式架構，擁有良好的擴展性，支持彈性的擴縮容，吞吐跟存儲均可以在線平滑擴容，數據庫擴展能力提高了 1~2 個數據量級。

將來，360 技術團隊也計劃將 TiDB 推上 360 HULK 雲平臺，爲 360 集團安全大腦、360 遊戲、核心安全服務平臺等更多業務線提供穩定可靠的數據庫服務。

與客戶同行，相信開放的力量

每次數據庫架構改善與落地，不管是 TB 級仍是 PB 級，都須要付出努力，但這也值得每個企業去實踐。在當下這個時代，無論企業的規模如何，都要學會藉助開源的力量，避免去重複的造輪子。每個看似輕鬆的背後都有鮮爲人知的努力，每個看似光鮮亮麗的背後，都有鮮爲人知的付出。分佈式數據庫建設之路道阻且長，TiDB 願與 360 及每一個客戶一塊兒，攜手並肩把事情作好。