一年一度的雙十一又雙叒叕來了，給技術人最好的禮物就是大促技術指南！ 而經過這些年的發展，大促早已不僅僅侷限於電商行業，現在各行各業其實都會採用類似方式做運營活動，汽車界有 818，電商有 618 、11.11 等等，各種各樣的大促場景，對包括資料庫在內的基礎軟體提出了很多新挑戰，同時也積累了諸多最佳實踐。
在雙十一到來前，PingCAP 與汽車之家、易車網、京東、中通等使用者展開一系列深入探討，希望為大家揭祕逐年飆升的銷量背後隱藏著什麼樣的技術難題？用什麼技術架構才能平穩地扛住流量洪峰？
點選此處觀看完整採訪參與互動，有機會獲得 TiDB 定製周邊！
大促中，大家買買買後最期盼的事情就是收到快遞。成立於 2002 年的中通快遞，是一家以快遞為主體，以國際、快運、雲倉、商業、冷鏈、金融、智慧、星聯、傳媒為輔的綜合物流服務品牌。2020年，中通完成業務量 170 億件，市場佔有份額達到 20.4%。
整個快遞的生命週期、轉運週期可以用五個字來概括——收、發、到、派、籤：
而支撐整個快遞生命週期的平臺就是中通大資料平臺。中通從離線到實時的資料相容再到數倉，有著一套比較完善的大資料平臺體系。ETL 建模也會依託該大資料平臺，最終通過大資料平臺對外提供資料應用的支援以及基於離線 OLAP 分析的支援，整個資料建模的頻率可以支援到半小時級別。在這個完善的大資料平臺基礎上，中通開始更多地思考如何增強實時多維分析能力。
中通與 TiDB 的結緣是在 2017 年調研分庫分表場景時開始的。當時中通分庫分表達到 16000 張表，業務上已經無法再繼續擴充套件下去。2018 年底，中通開始測試 TiDB 2.0，主要關注的是大資料量的儲存，以及分析效能。2019 年年初，中通上線了生產應用的支援。目前生產上穩定的版本是 TiDB 3.0.14 。2020 年底，中通開始測試 TiFlash，目標期望有兩點：一是提高時效，二是降低硬體使用情況。
1.0 時代——滿足需求
1.0 是滿足需求的時代，業務需求主要包含以下幾點：
- 業務發展非常快，資料量非常大，每筆訂單更新有 5-6 次，操作有峰值；
- 做過調研的技術方案，很難支撐多維分析的需求；
- 業務方對資料分析的週期要求比較長；
- 對分析時效要求也很高；
- 單機效能瓶頸，包括單點故障、風險高，這些也是在業務上不能忍受的；
- 除此之外，QPS 也很高，應用要求毫秒級響應。
技術需求方面，中通需要打通多個業務場景 + 多個業務指標；需要強一致的分散式事務，在原有業務模式下切換的代價很小；還需要對整個分析計算工程化，下線原來的儲存過程；能夠支援高併發的讀寫、更新；能夠支援線上的維護，保證單點的故障對業務是沒有影響；同時，還要與現有的大資料技術生態緊密結合在一起，做到分鐘級的統計分析；最後是中通一直在探索的，即要建立 100 + 列以上的大寬表，基於這張寬表，要做到多維度的查詢分析。
目前 TiDB 在中通應用的一些落地場景
時效系統應用場景
其中，時效系統是中通原有的一套系統，現在已經進行了重構。這套系統原來的儲存和計算主要是依賴 Oracle 設計的，計算依賴儲存過程。這套架構也比較簡單，一邊是訊息的接入，一邊是負載。
隨著業務體量的增長，這一套架構的效能已經逐漸出現瓶頸。在對這套系統進行架構升級時，中通把整個儲存遷移到 TiDB 上，整個計算遷移到 TiSpark。訊息接入依賴於 Spark Link，通過訊息佇列最終到 TiDB。TiSpark 會提供分鐘級的一些計算，輕度彙總會到 Hive，中度彙總會到 MySQL。基於 Hive，通過 Presto 對外提供應用的服務。相較原來關係型資料庫的分表，無論是 OLTP 還是 OLAP 都極大地降低了開發的工作量，並且和現有的大資料生態技術棧相融合。
1.0 時代中通的資料庫系統架構
遷移帶來的收益有很多：第一是容量的增長，原來的資料中心有三倍的富餘，已有系統資料儲存週期增加到三倍以上；第二，在可擴充套件性方面，支援線上橫向擴充套件，運維可以隨時上下計算和儲存節點，應用的感知很小；第三，滿足了高效能的 OLTP 業務需求，查詢效能雖略有降低的，但是符合業務需求；第四，資料庫單點壓力沒有了，OLTP 和 OLAP 實現“分離”，互不干擾；第五，支援了更多維度的分析需求；第六，整體架構看起來比原來更清晰，可維護性增強，系統的可擴充套件性也增強了許多。
大寬表應用場景
另一個場景是中通一直在做的寬表的建設與摸索。其實之前中通測過很多系統，包括 Hbase、Kudu。Kudu 的寫入效能還是很不錯的，但是其社群活躍度在國內一般。同時，中通使用 impala 作為 OLAP 查詢引擎，但主流使用的是 Presto，相容性有待考慮，也很難滿足所有業務場景需求。此外，中通的業務特性要求系統能夠快速地計算分析幾十億的資料，並能同步到離線的叢集裡與 T+1 資料做融合，還要能提供給資料產品和資料服務直連拉取明細資料。最後是海量資料的處理，中通有很多訊息源的接入，需要針對每一票進行全鏈路路由和時效的預測，定位到每一票的轉運環節，資料量很大，對時效的要求也很高。
中通的大寬表建設
目前，寬表已經建設有 150 多個欄位。資料來源於 10 多個 Topic 。主要的專案接入是通過 Flink 和 Spark ，打通了各個業務產生的資料，彙總到 TiDB 形成業務寬表。額外一部分，依賴於 TiSpark，從業務寬表輸出分析結果，同步 3 億條資料到 Hive。此外，還提供了十分鐘級別的實時資料建設和離線 T+1 的整合。
中通目前的叢集規模在使用過程中，中通也遇到了一些問題，總結起來就是量變引起質變。第一，熱點問題。索引熱點在目前情況下表現較為突出，因為中通的業務量規模十分大，操作存在高峰，在大時候該熱點問題表現特別明顯。第二，記憶體碎片化問題。在之前的低版本里，在穩定執行了一段時間後，因為有業務特性和大量的更新和刪除，導致記憶體碎片化比較嚴重，這個在反饋給了 TiDB 後，已經修復了這個問題。第三，著重介紹一個引數——TiFlash 讀取 index 的引數。通過測試，當讀取的資料量/總資料量大於 1/10 的時候，建議該引數關閉。為什麼這麼說？因為 Test 數可能會變少，但是單位 Test 過渡的時間會變長。
運維監控
使用 TiDB 後會發現它的監控指標特別豐富，使用了流行的 Prometheus + Grafana ，多而全。之前，中通因為在支援線上業務的同時，還會有開發人員來查資料，遇到了 SQL 把 TiKV Server 拉掛的情況。針對這個問題以及監控的問題，中通進行了一些開發定製。第一，相容線上特殊帳號的慢 SQL，會自動殺掉，並通知到相應的應用負責人。第二，中通開發了支援 Spark SQL 去查詢 TiDB 的工具，併發和安全性在開發的過程中得到一些保障。此外，中通還會把一些額外的核心指標，接入到自研的監控體系。核心的告警會電話通知到相關的值班人員。
去年雙十一期間，中通訂單量突破 8.2 億，整個業務規模突破 7.6 億，雙十一當天的 QPS 峰值達到 35 萬 +。整個雙十一期間，資料的更新體量達到了數千億級別，整個叢集上執行的 TiSpark 任務是 100 多個，支援的線上應用 7 個。整個分析的時效在 10 分鐘以下達到了 98% ，整個分析的資料週期達到 7-15 天。
2.0 時代——HTAP 提升
2.0 時代的主要特點是 HTAP 的提升。中通應用 HTAP 主要來自於業務方需求的升級：
基於業務方的需求，中通在 2.0 時代進行了一次架構再升級。首先，引入了 TiFlash 和 TiCDC 。這帶來的收益其實是增強了時效，部分分析進入了分鐘級級別，降低了 Spark 叢集資源的使用情況。
2.0 時代中通的資料系統架構
下圖是 TiSpark 和 TiFlash 的對比，中通線上有兩套叢集，一個基於 3.0，一個基於 5.0。簡單地對比一下 3.0 和 5.0 的情況：3.0 主要的分析是基於 TiSpark，5.0 是基於 TiFlash 。目前 3.0 叢集有 137 個物理節點， 5.0 有 97 個節點。整個執行的週期中，3.0 是 5 - 15 分鐘，基於 5.0 的 TiFlash 已經做到 1-2 分鐘，整個 TiKV 的負載降低是比較明顯的。另外， 在 3.0 上 Spark 的資源大概有 60 臺，而在 5.0 上，線上的加上在測試的，大概有 10 臺就足夠了。
在整個測試周期中，生產的叢集是 3.0 ，4.0 的測試周期其實是非常短的。在測試時，業務的場景有一些維表 Join 的情況，當時 4.0 對 MPP 沒有支援，對一些函式的支援可能也不是那麼完善，測試結果不是很理想。對 HTAP 的測試主要是在 5.0 階段，5.0 已經支援 MPP ，對函式的支援也越來越豐富。目前中通生產上應用的版本是 TiDB 5.1 。
上圖右側是整個 5.0 叢集在 618 期間的負載情況。在剛剛結束的 618 中， 5.0 上線的一些任務已經在支援 618 移動端的大促看板。中通有 6 個核心的指標是基於 TiFlash 計算的。叢集響應整體平穩，報表達到了分鐘級以內的時效。整體的資料體量在 40 億 - 50 億 +，報表分析資料達到 10 億 +。
3.0 時代——展望未來
- 第一是監控。提到監控，由於中通的叢集比較大，所以面臨的問題和遇到的問題可能會多一點。大叢集的例項多，指標載入慢，排查問題的效率得不到保障。監控雖然很全，但是出了問題的時候無法快速定位到問題；
- 第二是解決執行計劃偶發不準的問題。這種偶發不準有時候會影響到一些線上的負載相互影響，拉高叢集的指標，導致業務相互影響。
- 第三是實現自動清理。目前中通資料的清理是通過自己寫成 SQL 清理的，但是過期資料清理比較麻煩。希望之後可以支援舊資料自動 TTL。
- 第四，隨著 5.0 列式儲存的引入，中通計劃把 TiSpark 的任務逐漸全部切到 TiFlash 上面，期望達成提高時效和降低硬體成本的目標。
大促對於企業而言，除了支援業務創新，也是一次對自身技術架構的大練兵和全鏈路演練。通過大促的極致考驗，企業的 IT 架構、組織流程、人才技能都獲得了大幅提升。而在大促中的經驗和思考，也會加速企業日常的業務創新節奏，提升技術驅動的創新效率，打造增長新引擎。