導語：一年一度的 11.11 又雙叒叕來了，給技術人最好的禮物就是技術指南！ 而經過這些年的發展，購物節早已不僅僅侷限於電商行業，現在各行各業其實都會採用類似方式做運營活動，汽車界有 818，小米有米粉節等等，這對包括資料庫在內的基礎軟體提出了很多新挑戰，同時也積累了諸多最佳實踐。
在 11.11 到來前，PingCAP 與汽車之家、易車網、京東、中通等使用者展開一系列深入探討，希望為大家揭祕逐年飆漲的銷量背後隱藏著什麼樣的技術難題？用什麼技術架構才能平穩地抗住流量洪峰？
京東 11.11 的技術挑戰
每年的 618、11.11 對於京東而言都是一次大考，而京東雲作為京東集團技術保障的基石，在此期間需要扛住京東零售核心業務和京東物流系統 PB 級別的資料增長壓力。面對每年京東 11.11 訂單量和成交額迅猛的增速，京東雲資料庫作為大部分京東背後業務系統的核心，壓力自然不小。
京東雲資深產品經理楊牧對此深有感觸：許多和京東 11.11 有關的業務系統都需要資料庫的支援，如分析看板、報表資料、運單資料等等。受商品活動和優惠時間的影響，使用者下單高峰往往在固定時間段，這些資料庫的訪問量會急速上升。
他所在的資料庫團隊，從後臺監控可以很明顯地看到一個個峰值。當京東 11.11 全面開啟的瞬間，海量消費者和訂單湧入，大量品牌和商家迅速創造了新的紀錄，CPU、QPS 等也開始飆升，有時候持續若干分鐘，有時候則會持續數小時不等。
如何做好保障？
京東雲資料庫需要在京東11.11期間平穩支撐京東集團已經上雲的上千個核心業務系統，前期的預案准備和壓測、預案演練和實時監控都是必不可少的環節。而京東雲資料庫團隊對此已經積累起豐富的經驗，他們將備戰分為 8 個步驟：
- 識別保障範圍；
- 業務量預估及預檢查；
- 預案整理；
- 監控及報警梳理；
- 業務壓測；
- 預案演練；
- 11.11 值班；
- 技術覆盤。
根據以往經驗，楊牧認為京東 11.11 時的業務量會達到平時的 10 倍之多。這個資料量的峰值增長必須準備額外的資源來滿足，但由於京東雲的資料庫已經跑在雲上，他們只需根據預先估計好的資料量做好資源規劃和分配，並做足壓力測試，確保後面資料庫的儲存容納量和效能就可以滿足要求。到流量洪峰真正到來時，往往只需要靜靜等待就會平穩度過，並不會出現什麼極端情況。
特別像京東物流大部分業務已經上雲，保障和準備其實是無時無刻都在進行中。雲資料庫通過高可用架構、自動故障切換、彈性擴容機制等一系列資料庫級別的技術手段，保證資料可備份，故障可切換，增量可擴容，從容應對京東11.11期間海量資料壓力。
而在應用 TiDB 後，這些工作變得更加簡單。TiDB 採用的分散式架構支撐海量資料擴充套件，可以有效地解決單機 MySQL 容量和效能的瓶頸問題。楊牧形容，在擴容時只需根據業務方需要提前對 TiDB、TiKV 進行擴容。而擴容的工作也僅需在控制檯上點一點滑鼠，然後安心地喝著茶等待就行了，大大提高了 DBA 的工作效率。同時，TiDB 是開源的，不存在技術鎖定問題，也更容易在雲上使用，甚至跨雲部署。
為了降低集團內部各團隊使用 TiDB 的技術門檻，京東雲與 PingCAP 聯合推出了雲上的分散式資料庫 —— Cloud-TiDB，在京東雲上提供 TiDB 服務。這樣一來，業務方所有和資料庫服務有關的事情不再需要設定自己的 DBA，完全委託給京東雲即可。
今年的 京東 618 和 11.11 中，Cloud-TiDB 就已成功應用於京東物流內的物流業務費用系統、物流大件分揀系統、運單計提明細系統等多個業務中，應用規模總體接近 6000 核，達到 30 個 TiDB 叢集，在成本、效率和體驗三大方面帶來了大幅提升。楊牧笑言，研發再也不用整天忙著優化系統了，可以早點回家。運維同學也不用再熬夜支援系統運維，頭髮都可以少掉幾根。
物流某業務系統
11.11 中，大家買買買後最期盼的事情就是收到快遞。而在京東中，京東物流就承擔了將下單物品送到買家手中的職責。可想而知，京東物流業務系統的資料量肯定非常大，幾個主表的數量分別是 20 億、50 億和 100 億，系統上線半年後資料翻倍到了 220 億。原先 MySQL 分庫分表的架構就遇到了一些複雜的 SQL 不支援、跨分片統計報表難於實現等問題。
系統遷移到 TiDB 之後，整體的效能表現優秀，寫入和更新的效率在 100 毫秒左右，查詢和 Sum 查詢只有二三十毫秒。一個幾百億資料量的系統從 MySQL 遷移到 TiDB，實際業務程式碼零修改，系統只是更換了 JDBC 連線的使用者名稱和密碼，真正地實現了從 MySQL 到 TiDB 的零程式碼修改和無縫遷移。TiDB 和 MySQL 良好的相容性，降低了使用者的試錯、測試和遷移的成本，且收益週期短，見效快。
此外，楊牧特別指出，遷移到 TiDB 還給業務方帶來一個意外的驚喜。如果按兩年的週期計算，TiDB 的使用成本只有 MySQL 的 37%。這主要是因為 TiDB 對資料的壓縮率非常好。比如在 MySQL 裡資料佔到 10.8 TB，遷移到 TiDB 之後只有 3.2TB，而且這還是三副本的總資料量，TiDB 實實在在地幫助整個業務部分極大降低了 IT 的投入成本。
物流大件分揀系統
京東物流大件分揀系統的一些實時看板和核心報表跑在 MySQL 上。隨著資料量增加，而且 SQL 比較複雜，報表和看板的效能比較低，使用者體驗不佳。分庫分表的方式對程式碼侵入性比較大，架構需要大幅調整，風險較高。
在 618 期間，京東物流採用 TiDB 支撐業務的實時看板和核心報表，在 MySQL 和 TiDB 之間，用自研的蜂巢系統進行資料的準實時同步。從 MySQL 遷移到 TiDB 後，總共數百個指標，整體效能實現了 8 倍提升。
運單計提明細系統
運單計提明細系統用來記錄部分運單的明細資料，每天的資料增長在千萬級別，單表最大記錄接近 200 億條。從資料量看用 MySQL 難以支撐，京東物流嘗試過使用 Presto，但使用成本比較高，後來使用 ElasticSearch 做查詢，但也存在著不穩定的情況，維護工作量很大。
業務系統遷移到 TiDB 之後解決了海量資料的問題，TiDB 可以毫無壓力地支撐百億級的資料量。TiDB 成本比起以前使用的 MySQL + ElasticSearch 方案降低了 30%。TiDB 效能滿足業務的要求，從百億的單表裡面查詢出業務資料的 TP99 大概在 500 毫秒左右。此外，TiDB 整個表結構的調整修改操作非常簡單，帶來了運維敏捷和成本下降。
經過 618 、11.11 的嚴酷考驗，TiDB 在京東集團的多個 0 級系統中應用穩定，沒有出現任何事故，各業務方反饋都比較好，已經成為集團內部的標杆案例。這也給了楊牧他們充足的信心，在接下來的時間中可以繼續在集團內部推動使用 TiDB ，以技術的進步推動業務發展，預計 2021 年底規模還將再翻一倍，達到 10000 核規模。
大促對於企業而言，除了支援業務創新，也是一次對自身技術架構的大練兵和全鏈路演練。通過大促的極致考驗，企業的 IT 架構、組織流程、人才技能都獲得了大幅提升。而在大促中的經驗和思考，也會加速企業日常的業務創新節奏，提升技術驅動的創新效率，打造增長新引擎。