識貨APP致力於爲廣大用戶提供專業的網購決策指導，爲喜歡追求性價比的網購朋友帶來及時勁爆的運動、潮流、生活、時尚等網購優惠資訊，產品覆蓋國內外主流購物商城。它提供了全球範圍內的時尚品牌、潮流單品的信息，幫助用戶發現和購買最新、最熱、最具性價比的時尚商品。近年來，各大電商平臺上的商品信息持續增加，海量商品信息增加了消費者的選購成本。識貨從用戶視角出發，不斷整合行業渠道供給，降低發現和篩選成本，幫助用戶更高效地購買到最具性價比的產品。
1. 業務高速發展，平臺挑戰加劇
識貨作爲一個購物商城，爲用戶提供最核心的價值就是性價比。它提供的商品比價、價格訂閱等特色服務爲消費者在選購商品時提供了及時而精準的推薦。這一切歸功於識貨的數據加工平臺，它負責收集同類商品全網渠道的價格信息、折扣信息、滿減政策，並計算出同類商品在不同平臺不同渠道的售價，通過數據服務平臺推送給消費者，以便於準確鎖定性價比最高的渠道。然而，隨着商品種類的不斷增加，大促政策的日趨複雜，數據加工平臺面臨着巨大的挑戰。
1.1 大促期間，數據加工性能難以保證
現在各渠道平臺大促期間滿減、折扣越來越多樣，越來越複雜。商品價格變更瞬息萬變，爲了在第一時間向消費者推送最及時的價格信息，數據加工性能尤爲關鍵。在以往大促期間，最核心的價格變更動作就需要數小時完成，導致大促期間經常會接到業務部門的投訴，比如商品渠道價格波動、更新不及時等。我們也曾嘗試使用更大規格的MySQL(104核)，通過增加多個只讀節點、讀寫分離、業務模塊剝離等一系列舉措，但問題始終得不到有效解決。
1.2 傳統讀寫分離，延遲不可控，穩定性堪憂
爲了緩解數據加工的壓力，我們嘗試剝離部分只讀業務，通過只讀實例實現讀寫分離，這也是大部分業務都會做的選擇。然而，識貨的情況有些特別，核心數據加工場景的複雜度和併發度都非常高，對數據庫的寫壓力非常大，高峯期單單寫的QPS就能突破20萬，所以主備延遲是擺在我們面前很嚴峻的問題，當只讀業務長時間讀不到準確的數據時，我們又會被迫將其臨時搬回主實例，又進一步加劇了主實例的壓力，陷入了無窮的死循環當中。同時，過高的主備延遲，也給數據庫自身穩定性帶來了極大風險。
1.3 商城擴品在即，平臺處理能力捉襟見肘
識貨的GMV已突破百億，規模持續增長，預計未來幾年商城將擴品3~5倍，對識貨整個數據加工平臺的存儲和計算能力都是非常嚴峻的考驗。目前核心業務數據庫已經是最高規格，升無可升，在過去的幾年大促裏，資源使用率偏高，處理能力急需突破。
2. 集中分佈式一體化，性能提升400%
在過去的幾年裏，識貨試圖通過各種方式突破加工平臺的性能瓶頸，也調研過市面上主流的分佈式數據庫產品，嘗試通過分佈式數據庫的替換來解決當下問題。但是，市面上分佈式數據庫產品的架構、技術各不相同，爲了發揮其最佳性能，都需要遵循各自的最佳實踐。然而，識貨的核心渠道庫是自2012年創業以來的第一個庫，經過十多年的沉澱，積累了衆多業務模塊，相互依賴關係錯綜複雜，且開發設計完全是單機習慣。一來很難將業務進行剝離，二來短期內也不具備分佈式改造的可能，所以我們一直未能堅定地邁出分佈式升級這條道路。
在我們躊躇不前、極度迷茫的時候，阿里雲瑤池數據庫技術團隊從實際情況出發，爲我們指出了一條不一樣的分佈式升級道路。PolarDB分佈式版（PolarDB for Xscale，簡稱PolarDB-X）是集中分佈式一體化的分佈式數據庫，對每一個表來說，既可以打散到不同的節點，也可以單節點存儲。我們核心庫的特點是表的個數非常多，並且單表體量也達到了億級別，數據量仍然保持持續增長的勢頭。結合這兩個特性，阿里雲瑤池數據庫技術團隊給出瞭如下方案：
按業務模塊區分，各個模塊的表：
以單表形式存儲在不同節點；
- 通過不同規格的DN支撐不同業務的特性，避免同一規格的DN帶來的資源浪費；
- 通過Locality能力，確保任何表都具備任意節點間騰挪的能力，應對未來業務模型發生變化。
識貨運維總監瞿晟榮表示：“這就好比我們拿出一個大規格的DN當作收納桶，所有理不清業務邏輯的表先統一放在這裏，一些核心流程上的關鍵業務表，我們進行單獨的DN處理，上面通過CN統一管理調度，對業務代碼完全無感，而底層已經悄悄完成了分佈式的改造。”
在進行分佈式改造後，經過大促實戰驗證，數據處理能力提升6倍，價格變更場景性能提升4倍，從小時級別縮短到分鐘級別。
3. 平滑遷移，性價比提升500%
PolarDB分佈式版除了提供極致的MySQL兼容，確保識貨APP業務代碼0修改之外，在整個遷移過程中，也提供了豐富的手段，助力我們完成絲滑地遷移。
3.1 熱力分區圖
集中式往分佈式的演進過程中，數據會被打散到不同節點，大家普遍擔心的問題是：關聯的表是否被打散到了不同的節點帶來了性能瓶頸？是否訪問頻繁的表被打散到了同一個節點上？導致該節點資源消耗過大。
爲了解決上述困擾，PolarDB分佈式版提供了熱力分區的功能，通過可視化的方式，實時觀測各個節點的容量瓶頸和訪問瓶頸，準確定位大大降低了遷移和日常運維的難度。
3.2智能壓測
核心渠道庫數據加工邏輯的大量信息是來自淘寶、亞馬遜、拼多多等渠道的實時價格信息，在測試環境下無法模擬，導致我們無法在測試環境進行業務壓測，這給割接帶來了很大風險。阿里雲提供了智能壓測方案CMH-DOA（也稱frodo），CMH-DOA可以全量錄製原生產端MySQL的全量SQL，在目標端PolarDB分佈式版進行完整回放。不僅保證執行順序與生產保持一致，同時也支持倍速回放，能夠模擬更大的生產壓力場景。讓我們對當前數據庫實例的處理能力擁有非常好的判斷基準，不僅降低了割接風險，也爲未來大促擴容提供了很好的參考依據。該工具目前已開源，相信未來會幫助更多的開源或商業用戶，讓分佈式這條路更加絲滑平順：
https://github.com/polardb/polardbx-tools/tree/frodo-v1.0.0/frodo
3.3 性價比大幅提升
在以往大促期間，我們MySQL的QPS一旦超過15w之後，性能就會明顯下降，需要採取只讀實例、應用限流等一系列措施，整體QPS勉強接近20w。遷移到PolarDB分佈式版之後，識貨在大促期間可以增加數據加工的併發，QPS峯值可以達到60w，而資源使用不超過50%。通過國際公認的性價比計算公式：price/performanc，也就是月消費/QPS峯值，計算出每個QPS成本之後，我們發現，性價比提升了500%。
4. 突破瓶頸，未來可期
渠道、商品、用戶是整個識貨最核心的板塊，我們藉助PolarDB分佈式版集中分佈式一體化的能力輕鬆完成了分佈式演進。通過這次升級，數據加工平臺的性能和整體支撐能力得到了顯著提升。
識貨運維總監瞿晟榮表示：“這一次識貨核心業務的分佈式改造，我們沒有讓研發部門修改任何一行代碼，性能就得到了質的飛躍。去年雙11期間，我們價格清洗需要4小時完成，而今年只花了15分鐘，真正做到了代碼0修改的分佈式遷移。在經歷了618、雙11多個大促，我們做到了數據庫0故障的表現，我們運維部門今年也真正做到了4個9的SLO，這對整個團隊來說是很大的提升。”
作者：識貨運維總監 瞿晟榮
本文爲阿里雲原創內容，未經允許不得轉載。