安能物流 All in TiDB 背後的故事與成果

PingCAP發表於2024-11-27
TiDB

圖片
導讀

在數字化轉型的浪潮中，安能物流透過技術創新不斷提升物流效率，邁出了全鏈路 All in TiDB 的重要一步。本文將深入探討安能物流如何選擇 TiDB 作為核心資料庫，以應對高併發、資料處理能力和系統可擴充套件性等挑戰。透過 TiDB 的彈性擴充套件能力、金融級高可用性和實時 HTAP 特性，安能物流不僅解決了過去的技術瓶頸，還為未來的數字化發展奠定了堅實基礎。

本文將從業務系統重構到全鏈路應用，講述 TiDB 的技術優勢如何助力安能物流在激烈的市場競爭中保持領先地位。
圖片
在數字化轉型的大潮中，物流行業作為國民經濟的重要組成部分，其資訊化建設的重要性日益凸顯。安能物流，作為國內領先的綜合型物流集團，一直致力於透過技術創新提升物流效率。在本技術分享中，我將與大家一起探討安能物流為何選擇全鏈路 All in TiDB，以及 TiDB 如何助力於安能物流的數字化升級。
圖片

圖片
安能物流成立於 2010 年，經過 14 年的發展，已經成為國內領先的綜合型、創新服務型物流集團。公司以成為中國物流領域高效率的連線者為願景，為企業組織及消費者提供安全、便捷、優質、高效的物流服務。安能物流在全國擁有 20000 名員工，82 個分撥中心，覆蓋全國 99.2% 的鄉鎮，並在 2021 年 11 月 11 日在香港聯合交易所上市，成為“ 港股快運第一股 ”。

圖片

圖片
在業務模式上，我們採用了貨運合作商平臺模式，即中心直營+網點加盟的方式。透過加盟網路，我們迅速整合了本地現有資源，實現了快速擴張。同時，本地網點透過加盟安能，不僅豐富了產品線，提升了品牌知名度，還能實現快速盈利。

我們的產品線非常豐富，包括高階產品如定時達、安心達，重量產品如 3300 產品（3-300kg）和精準零擔（300kg 以上），以及增值服務如保價理賠、送貨上樓、代收貨款和安全包裝。此外，我們還提供特色業務，如整車業務和物流金融，以滿足不同客戶的需求。
圖片

1 業務對系統的挑戰

2018 年之前，安能主要使用 Oracle 作為資料儲存和處理的資料庫，隨著業務高速發展，業務系統對資料庫的併發處理能力和效能提出了越來越高的要求。尤其是每天 16:00-20:00 網點開單業務高峰時段，核心系統 Oracle 資料庫的併發處理能力開始捉襟見肘，導致每天需要專職 DBA 值班處理系統遇到的突發問題。再加上這套業務系統邏輯複雜，涉及到從開單、交易、結算、掃描操作最後到簽收都是一個單體大集合，並且在資料庫中使用了大量的儲過程和定時任務來進行業務邏輯和資料的處理，所以每當系統出現異常，影響業務正常操作時，無論是研發還是運維，都很難快速定位和解決問題，系統故障時常發生，研發和運維也常互相推諉扯皮。

2 去 O 已刻不容緩

自 2018 年開始，IT 決定對這套基於 Oracle 資料庫的大單體垂直架構核心業務系統進行重構，首先選擇將交易算費業務從這套系統中獨立拆分出來。因為在原來這套老的系統中，總部和網點的交易算費是使用 Oracle 儲存過程和定時任務跑批來完成，當時這套核心的 Oracle 資料庫已經出現效能瓶頸，無法在計劃內的時間完成交易算費，而純靠升級伺服器儲存硬體已無法明顯提升資料庫效能（就差上 Exadata，成本太高）。

3 去 O 無奈的選擇

選擇將交易結算業務從原來老系統中拆分獨立進行重構，首先要考慮的問題就是使用什麼資料庫，在 18 年時，業界最主流的資料庫除了 Oracle 外，主流開源的也就 MySQL。在系統重構之初，我們就考慮到 MySQL 的單庫資料處理能力問題，因為在當時業界還沒有一款真正的 MySQL 分散式資料，大部分都是基於中介軟體代理的方式實現 MySQL 的分庫分表，因此我們也採用了比較保守的方案：MySQL+MyCat 中介軟體資料庫架構。

為了避免同一個網點查詢或處理資料時出現跨庫問題，我們採用了以網點編碼作為分庫分表的路由規則，除此以外，為了保證單庫單表資料量的均衡，我們還將產糧區如華東華南和非產糧區如東北西北區域的網點進行相互組合後放在同一個庫同一個表中。即便如此，由於業務的不斷增長，地區產業佈局的變化，網點貨量的變化，導致原結算系統 MySQL 資料庫在上線執行一年左右時間後，面臨越來越大的挑戰，主要表現在：

  1. 基於網點編碼的分表路由規則，導致單庫單表資料分佈不均，存在資料熱點問題；
  2. 基於網點編碼的分表路由規則，當資料量不斷增長，資料庫主庫節點擴充套件複雜度高；
  3. MySQL 5.7 不支援表結構線上變更，系統變更停機時間長，導致業務可用性降低；
  4. MyCat 不完全支援標準 SQL 語法，導致研發側程式碼改動較大；

  5. 資料同步到下游進行分析時需要解決多庫多表資料合併問題。
    圖片

    4 與 TiDB 的起緣

基於結算系統面臨的諸多挑戰，我們大概在 20 年開始考慮，要對這套結算系統 MySQL 資料庫進行換代升級，除了要考慮到結算系統複雜的業務處理流程外，還要考慮業務快速發展所面臨的大規模資料處理的巨大挑戰，我們需要一個能夠處理大規模資料、既能保證高可用性、又支援實時分析的分散式資料庫系統。最終我們選擇了 TiDB 作為替換結算 MySQL 的最佳產品，那為什麼會選擇 TiDB？一切的開始，只因為我們偶然看到了 TiDB 的那句產品介紹： 一款真正的可彈性一鍵擴縮容、金融級高可用、99% 相容 MySQL 的 HTAP 資料庫 。
圖片
在業務痛點急需尋求一款產品來解決的時候，TiDB 正好能夠完全滿足，在經過深入的技術調研和測評後，我們選擇了 TiDB 作為我們業務系統新一代的資料庫產品解決方案。TiDB 在安能首次被應用落地的場景就是“錢”交易結算業務，並且成為該場景下的唯一“候選人”。

  1. 彈性擴充套件能力： TiDB 提供了一鍵水平擴容或者縮容的功能，可以按需對計算、儲存分別進行線上擴容或者縮容。這對於業務量波動較大的物流行業來說，是非常重要的特性，可以有效地應對高峰期的業務需求。
  2. 金融高階可用性： TiDB 採用計算與儲存分離的多副本儲存架構，確保了資料的高可用性和準確性。這對於需要處理大量交易結算資料來說，是保證業務連續性的關鍵。
  3. 大規模資料處理和實時 HTAP 特性： TiDB 具備大規模資料處理能力和實時 HTAP（混合事務/分析處理）特性，這使得我們能夠增加線上資料的生命週期，同時保證系統的快速響應。
  4. 高度相容 MySQL：TiDB 高度相容 MySQL，使得應用程式碼幾乎無需改動即可遷移到 TiDB 上，這種相容性大大降低了技術遷移的成本和風險。
  5. 支援表結構的線上變更： TiDB 支援表結構的線上變更，減少了系統變更時的停機時間，提高了業務的可用性。這對於需要頻繁更新以適應業務發展來說，是一個重要的優勢。
  6. 內建圖形化監控系統： TiDB 內建了圖形化監控系統，提供了完整的閉環監控能力和故障分析能力，降低了運維成本和門檻。這對於 IT 人員相對較少的我們來說，是一個非常有價值的特性。
    圖片
    TiDB 在安能從測試到切換上線經歷了 3 年的時間，主要分為 TiDB 測試 和 資料校驗 兩個階段 。

經驗一：TiDB 測試與效能最佳化

在測試階段，我們從 3.0 版本開始持續到 5.4 版本，在這個過程中我們充分測試了 TiDB 每一個重要版本的核心特性和重要功能，也測試了 TiDB 推出的諸多工具，見證了 TiDB 產品成長。具體測試方法，我們將生產資料透過訊息佇列 1:1 引流到 TiDB 來模擬真實結算業務資料寫入效率，同時針對不同業務場景及多業務場景組合下進行 資料新增、刪除、修改、查詢功能及效能壓測 。
圖片
在 2020 年 3 月，我們首次安裝了 TiDB 叢集 v3.0.11，並開始了一系列的效能測試。初期，我們遇到了壓測效能問題，特別是在高併發場景下，TiDB 的 TPS（每秒事務處理量）表現不盡如人意。為了解決這一問題，我們採取了多種措施：

  1. 增加 TiDB/TiKV 節點： 我們透過增加節點來提升叢集的處理能力。
  2. 配置最佳化： 我們對 TiDB 節點進行了配置最佳化，包括使用 Haproxy 來平衡負載。
  3. 硬體升級： 我們對 TiKV 主機進行了壓測，並更換了磁碟 SSD 以提升 I/O 效能。
  4. 軟體升級： 我們升級了 TiDB 叢集到 v5.0.1，以利用新版本中的效能改進。

透過這些措施，我們成功地將 TPS 提升到了 10000+，滿足了我們的業務需求。此外，我們還發現，在相同業務場景下，使用分割槽表與普通表相比，分割槽表的效能要差 20-30%。這促使我們進一步 最佳化了資料模型和查詢策略 。

經驗二：TiDB 切換與持續最佳化

在資料校驗階段，我們使用 DM 將結算 MySQL8 個庫的資料實時同步到 TiDB 中，按照生產環境 1:1 搭建了一套完整的模擬結算系統，進行了為期快一年的資料校驗工作，最終於 23 年春節，將原結算 MySQL 無縫平滑切換到 TiDB 上。雖然我們不是行業內第一個使用 TiDB 的使用者，但在行業內將所有結算業務 all in TiDB 我們是第一個。
圖片
在 2023 年 2 月，我們將結算系統遷移到 TiDB v6.5。整個遷移過程非常平滑，結算系統的應用程式碼無需改動，這得益於 TiDB 對 MySQL 的高度相容性 。遷移後，我們解決了之前使用 MySQL 資料庫時面臨的所有挑戰，包括線上資料庫生命週期及資料傾斜、擴容等限制。然而，遷移後我們也遇到了一些問題，例如 SQL 最佳化器執行計劃的不穩定，以及子查詢效能較差。為了解決這些問題，我們採取了以下措施：

  1. 持續最佳化 SQL：我們對 SQL 語句進行了持續的最佳化，以提高執行效率。
  2. 切換至 TiDB 後表索引調整： 我們對錶索引進行了調整，以改善查詢效能。

透過這些持續的最佳化措施，我們不僅提高了系統的效能，還降低了運維成本，提升了業務的可持續使用時長。
圖片

快執行業的業務流程相對複雜，涉及從客戶下單、網點收發件、幹線運輸中轉、末端派送和簽收，總部與一級結算、一級與二級調賬、工單、仲裁、理賠、問題件、查件和時效等全鏈路流程。安能在以往系統建設的過程中，每個業務環節按照專案制獨立進行系統設計開發，底層也就使用了不同的資料庫技術棧來實現資料的儲存和處理，導致業務全鏈路資料流轉互動困難，甚至形成資料孤島，運維成本極高。

遇到 TiDB 之前的問題

在遇到 TiDB 之前，我們系統所使用的資料庫技術棧包括但不限於 Oracle、MySQL<em>、PG<em>、MongoDB 等。重要核心系統都有面臨著獨特的挑戰：

  • Oracle： 我們使用了 Oracle 的 RAC+ADG+OGG 架構來實現全鏈路業務的大集中。然而，這種垂直大集中的架構在業務操作和算費交易方面存在瓶頸，尤其是在資料庫 Job 數量龐大時，研發和運維團隊之間的協作變得非常困難。
  • MySQL：為了解決 Oracle 的問題，我們嘗試了 MySQL 分庫分表的方案，並結合 MyCat 進行重構結算業務。但是，這種偽分散式叢集不但在效能上出現了瓶頸，而且還發生了嚴重的資料傾斜且無法靈活擴充套件，無法滿足我們對真正分散式資料庫的需求。

  • PG+Citus：為了尋求一款真的分散式資料庫產品，我們開始測試 PG+Citus 資料庫架構，希望能夠找到這種解決方案。然而，經過 4 個月的全場景測試，我們發現它在效能上無法滿足我們的要求，並不是一個真正的分散式資料庫叢集。
    圖片

    全鏈路採用 TiDB 的決策

TiDB 的出現正好解決了我們這些問題。它以其真正的分散式架構、金融級高可用性、與 MySQL 的高度相容性以及彈性擴縮容能力，滿足了我們對效能、可靠性和未來發展的需求。TiDB 不僅提高了我們的系統效能，還簡化了運維工作，使我們能夠更靈活地應對業務增長。
圖片
基於 TiDB 的這些優勢，我們將業務全鏈路場景都使用了 TiDB。從交易結算到運營操作，從下單簽收到幹線運輸， TiDB 覆蓋了我們 90%以上的業務場景 。這不僅解決了我們之前使用 Oracle、MySQL 和 PG 時遇到的問題，還加速了 TiDB 在安能更多業務場景的落地。

因此，基於 TiDB 的這些優勢和不斷下潛全鏈路業務場景，安能物流 All in TiDB，以支援其業務的持續增長和數字化轉型。我們相信，隨著 TiDB 技術的不斷進步，它將為我們帶來更多的業務價值，幫助我們在激烈的市場競爭中保持領先地位。
圖片
安能之所以作為物流行業領先公司，我們在資訊化建設方面投入了大量的精力和資源，開發了多套系統來支撐公司的業務運營和管理決策。
圖片

安能數字化建設所面臨的挑戰

隨著物流行業資訊化水平的不斷提升，以及管理賦能動作的前移和下沉，我們的數字化升級轉型面臨著新的挑戰。主要表現在如下幾個方面：
圖片

  1. 資料分散： 我們的業務系統眾多，每個系統都承載了業務全鏈路環節中的重要一環，這導致了資料的分散，資料分散在不同的系統中，使得資料整合和分析變得複雜。
  2. 資料不準： 由於不同業務系統的資料採集和統計分析存在口徑差異，即便是相同的資料點，在不同系統或同一時間點上，資料也可能出現不一致的情況。這種資料的不準確性對於決策支援來說是一個巨大的障礙。
  3. 架構複雜： 我們的技術架構非常複雜。不同的業務場景使用了不同的技術棧，如 A 場景使用 A 技術棧，B 場景使用 B 技術棧，C 場景使用 C 技術棧，這種多樣性導致了技術棧的過度使用和管理上的複雜性。
  4. 成本與資源的挑戰： 在公司降本增效的背景下，未來可能會減少對 IT 人員和資源的投入。這給我們提出了一個問題：在資源受限的情況下，IT 如何高效地保障業務的發展和系統的穩定執行？
  5. 系統承載能力的挑戰： 隨著業務的增長，現有的系統可能無法承載高峰期的負載併發。這不僅影響使用者體驗，也對系統的穩定性和可靠性提出了挑戰。我們需要找到解決方案，確保系統能夠在高負載下穩定執行。
  6. 資料處理能力的挑戰： 結構化和非結構化資料的快速增長，對我們的資料查詢和處理能力提出了更高的要求。如果系統無法及時響應資料查詢和處理請求，將直接影響到我們的業務決策和客戶服務。

TiDB 加速安能數字化建設

圖片
TiDB 作為一款 分散式資料庫 ，為安能物流提供了強大的資料處理能力和實時 HTAP 特性，幫助我們構建了新一代的一棧式物流資料平臺的“地基”。以下是 TiDB 對安能數字化建設的幾個關鍵幫助：

  1. 資料整合與實時分析： TiDB 的分散式架構和彈性伸縮能力，使得我們能夠整合分散在不同系統的資料，實現資料的集中管理和實時分析。這對於物流行業來說，意味著可以更快速地響應市場變化，最佳化運營效率。
  2. 高可用性和資料一致性： TiDB 的金融級高可用性和資料一致性，保證了我們的業務連續性和資料的準確性。這對於處理大量的交易結算資料至關重要，尤其是在業務高峰期，確保了服務的穩定性。
  3. 簡化技術棧： TiDB 的高度相容性和易用性，幫助我們簡化了技術棧。我們不再需要維護多種資料庫技術，從而降低了運維成本和複雜性。
  4. 支援業務創新： TiDB 的實時 HTAP 特性，支援我們在業務運營的同時進行資料分析，為業務創新提供了資料支援。例如，透過分析客戶行為和市場趨勢，我們可以開發新的服務產品，提升客戶體驗。
  5. 降低成本，提高效率：TiDB 的開源特性和社群支援，幫助我們降低了資料庫軟體的許可成本。同時，其自動化運維特性減少了對專業 DBA 的依賴，提高了整體的運維效率。

基於 TiDB 的一棧式物流資料平臺“地基”

我們的一棧式物流資料平臺，是建立在 TiDB 基礎之上的。這個平臺整合了多個資料主題，包括 品效主題、財務主題、運營主題和網點主題 等，每個主題都圍繞著物流業務的關鍵方面進行資料的收集、處理和分析。

  • 品效主題： 關注服務質量和路由時效，幫助我們監控和提升客戶滿意度。
  • 財務主題： 管理車線成本和人力成本，最佳化我們的財務結構。
  • 運營主題： 涉及貨物操作和車輛運力，確保我們的運營效率。
  • 網點主題： 關注開單收入和簽收罰款，幫助我們管理網點的業績。
    圖片
    在資料平臺支撐下，我們建立資料模型及標準，強化資料應用與服務分層，完善資料治理體系。這包括資料集市、業務量分析、品效分析、車輛運力分析、財務成本分析等多個方面。透過這樣的架構和產品體系，安能物流能夠實現 資料的集中管理、高效治理和深度應用 ，從而推動其數字化轉型，提升業務決策的效率和準確性。這不僅體現了 TiDB 在處理大規模、高併發場景下的優勢，也展示了我們對於未來物流資料平臺發展的前瞻性思考。
    圖片
    我們從社群使用者轉變成了商業使用者，表達了我們對 TiDB 產品的尊重和支援。TiDB 在交易結算業務場景中的表現，證明了它是一款真正能夠滿足我們需求的資料庫產品。我們相信，隨著 TiDB 技術的不斷進步，它將為我們帶來更多的業務價值，幫助我們在激烈的市場競爭中保持領先地位。
    圖片
    透過全鏈路 All in TiDB，我們不僅解決了現有的技術挑戰，還能為未來的數字化轉型打下了堅實的基礎。TiDB 的 高效能、高可用性<em>和易用性 ，使其成為安能物流技術棧中不可或缺的一部分。隨著 TiDB 的不斷迭代和最佳化，我們相信，安能物流將在數字化的道路上越走越遠。

相關文章