一年一度的京東11.11又雙叒叕來了，給技術人最好的禮物就是技術指南！而經過這些年的發展，購物節早已不僅僅局限于電商行業，現在各行各業其實都會采用類似方式做運營活動，汽車界有 818，小米有米粉節等等，這對包括數據庫在內的基礎軟件提出了很多新挑戰，同時也積累了諸多最佳實踐。

在京東11.11到來前，PingCAP與汽車之家、易車網、京東、小米等用戶展開一系列深入探討，希望為大家揭秘逐年飆漲的銷量背后隱藏著什么樣的技術難題？用什么技術架構才能平穩地抗住流量洪峰？

京東11.11的技術挑戰

每年的 618、11.11對于京東而言都是一次大考，而京東云作為京東集團技術保障的基石，在此期間需要扛住京東零售核心業務和京東物流系統 PB 級別的數據增長壓力。面對每年京東11.11訂單量和成交額迅猛的增速，京東云數據庫作為大部分京東背后業務系統的核心，壓力自然不小。京東云資深產品經理楊牧對此深有感觸：許多和京東11.11有關的業務系統都需要數據庫的支持，如訂單、分析看板、報表數據、運單數據等等。受商品活動和優惠時間的影響，用戶下單高峰往往在固定時間段，這些數據庫的訪問量會急速上升。他所在的數據庫團隊，從后臺監控可以很明顯地看到一個個峰值。當京東11.11全面開啟的瞬間，海量消費者和訂單涌入，大量品牌和商家迅速創造了新的紀錄，CPU、QPS 等也開始飆升，有時候持續若干分鐘，有時候則會持續數小時不等。

如何做好保障？

京東云數據庫需要在京東11.11期間平穩支撐京東集團已經上云的上千個核心業務系統，前期的預案準備和壓測、預案演練和實時監控都是必不可少的環節。而京東云數據庫團隊對此已經積累起豐富的經驗，他們將備戰分為 8 個步驟：（1）識別保障范圍；（2）業務量預估及預檢查；（3）預案整理；（4）監控及報警梳理；（5）業務壓測；（6）預案演練；（7）11.11值班；（8）技術復盤。根據以往經驗，楊牧認為京東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 核規模。