一、背景與挑戰
這幾年随着轉轉二手業務的快速發展，訂單系統的基礎性能問題也愈發嚴重，作為系統運轉的基石，訂單庫壓力不容小觑。 面臨的問題：
- 大促期間DB壓力大，單庫查詢qps上萬占用大量資料庫資源，寫性能大大降低；
- 資料與日俱增，單庫中包含非常多資料量過數億的大表，占用空間接近伺服器的容量上限；
- 資料量太大，資料備份和恢複需要耗費很長時間，極端情況下丢失資料的風險越高。
二、為什麼選ShardingSphere
迫于上述所說的DB壓力問題，起初我們做了一些緩解措施，其中包括:
- 優化大事務，縮小事務範圍，甚至消除事務
通過調整原有業務邏輯順序将核心的生單步驟放置在最後 ，僅在訂單主表保持事務，主表操作異常時其他訂單相關的表允許有髒資料産生。
- 訂單資料添加緩存
- 緩存這塊最重要同時最麻煩的地方是保證資料的一緻性，訂單資訊涉及結算抽傭等，資料的不實時或不一緻會造成嚴重事故。
- 嚴格保證緩存資料的一緻性，代碼實作比較複雜同時會降低系統的并發，是以緩存方案實作這塊我們做了一定的妥協：
- 允許資料緩存失敗情況下請求直接查庫;
- 給緩存key添加版本号，通過讀最新版本号的資料確定資料的實時性。
- 複雜查詢走ES、主從分離、一些大表進行冷熱資料分離等
通過上述幾個方面的優化DB壓力雖有所下降，但面對大促等一些高并發場景時仍顯得力不從心。為了從根本上解決訂單庫的性能問題，我們決定對訂單庫進行資料分片（分庫分表）改造，使得未來3-5年内不需要擔心訂單容量問題。
資料分片元件選型這塊，我們從效率、穩定性、學習成本和時間多個方面對比，最終選擇了ShardingSphere。
ShardingSphere優勢如下:
提供标準化的資料分片、分布式事務和資料庫治理功能，可适用于如Java同構、異構語言、容器、雲原生等各種多樣化的應用場景； 分片政策靈活，支援多種分片方式； 內建友善、業務侵入程度低； 文檔豐富、社群活躍。 ShardingShpere提出DB Plus的理念，采用可插拔的架構設計，子產品互相獨立，可以單獨使用，亦可以靈活組合使用。目前ShardingSphere 由 JDBC、Proxy 和 Sidecar（規劃中）這 3 款既能夠獨立部署，又支援混合部署配合使用的産品組成。 3款産品特性對比如下：
通過上圖對比，結合訂單高并發特性，本次資料分片中間件選擇了ShardingSphere-JDBC。 ShardingSphere-JDBC定位為輕量級 Java 架構，在JDBC層提供的額外服務。它使用用戶端直連資料庫，以 jar 包形式提供服務，無需額外部署和依賴，可了解為增強版的 JDBC 驅動，完全相容 JDBC 和各種 ORM 架構。
随着5.x版本的釋出，ShardingSphere還提供了許多新特性：
- 全新 distsql 用于加載及展示 shardingsphere配置資訊
- 支援跨不同資料庫執行個體的分片 join sql 查詢
- 增加資料網關能力，支援異構資料庫存儲
- 支援線上動态建立及修改使用者權限
- 新增自動化探針子產品
三、項目落地中的關鍵點
- 分片key的選擇
目前訂單id的生成，采用了時間戳+使用者辨別碼+機器碼+遞增序列的方式，其中使用者辨別碼取自買家id的第9~16位，該碼是使用者id生成時的真随機位，很适合作為分片key。
- 選擇該使用者辨別碼作為分片key有如下優勢：
- 可以使分到各個庫表的資料盡可能均勻；
- 無論是以訂單id、還是以買家id作為查詢條件，都可以快速定位到具體分片位置；
- 同一買家的資料能分布到相同的庫表，友善買家次元的聚合查詢。
具體分片政策上：我們采用了16庫16表，使用者辨別碼取模分庫，使用者辨別碼高四位取模分表。
- 新老庫資料遷移
- 遷移必須是線上的，不考慮停機遷移，遷移的過程中還會有資料的寫入；
- 資料應該是完整的，C端體驗是無感覺的，遷移之後需要保證新庫和舊庫的資料是嚴格一緻的；
- 遷移過程中需要做到可以復原，一旦遷移過程中出現問題，可以立即復原到源庫，不會對系統可用性造成影響。
資料遷移步驟如下：雙寫->遷移曆史資料->校驗->老庫下線。
四、效果&收益
- 解決了單庫容量上限問題;
- 資料分片後單庫表的資料量大大減少，單表資料量由原來的近億降為百萬級别，總體性能大大提高;
- 降低了因單庫、單表資料過大極端情況資料丢失風險，減輕運維壓力。 以下是兩次大促期間，下單服務接口調用量與接口耗時對比。
改造前：
改造後：
五、總結感悟
任何公司的“分庫分表項目”說白了，都不是一個考驗點子思路的常見項目，更多的反而是對一個人、一個團隊幹活的細緻程度、上下遊部門的溝通協作、工程化的操作實施以及抗壓能力的綜合考驗。 同時業務的不斷發展，又促使系統資料架構需要跟着不斷更新，ShardingSphere以其良好的架構設計、高度靈活、可插拔和可擴充的能力簡化了資料分片的開發難度，使研發團隊隻需關注業務本身，進而實作了資料架構的靈活擴充。
附，最終技術方案目錄：
作者：轉轉技術團隊
連結：https://juejin.cn/post/7182493303705698364