1月17日，在阿里雲PolarDB開發者大會上，阿里雲PolarDB分佈式產品部負責人黃貴發表了《分佈式的PolarDB：分佈式的能力，一體化的體驗》主題演講。
黃貴表示，PolarDB分佈式版（簡稱“PolarDB-X”） 早期一直聚焦分佈式形態，我們在 2023 年 10 月公有云和開源同時新增集中式形態，將分佈式中的DN 多副本單獨提供服務，支持 Paxos 多副本、lizard分佈式事務引擎，可以100%兼容MySQL。同時，PolarDB-X 內核上具備了集中式分佈式一體化的技術融合，支持集中式和分佈式兩種形態可以無縫切換，我們簡稱爲“集分一體化”。
阿里雲PolarDB分佈式產品部負責人黃貴
1. 什麼是PolarDB分佈式版集分一體化
我們可以用一個買房子的場景來做簡單的類比：
集中式數據庫可以類比爲90平米的小平層。大部分情況下，對於大部分三口之家來說，買一個90平米左右的兩室一廳小平層就足夠了。這樣的房子面積適中，價格適中，打掃起來也不用花費太多的精力，能滿足一家人日常的需求。但有可能偶爾也會出現房子不夠住的情況，比如，有親戚朋友來的時候。同樣地，大部分情況下，對於大部分中小企業來說，集中式數據庫就能滿足其日常的業務需求，其資源規模適中，成本適中，運維起來也比較簡單。但在少部分場景下，中小企業可能也會出現業務突增的情況，需要高併發高吞吐的數據庫來處理業務，對數據庫的擴展性有一定的要求。
分佈式數據庫可以類比爲300平米的複式別墅。複式別墅的一個優點是空間大，足夠一個三世同堂甚至四世同堂的大家庭居住。複式別墅的設施也比較齊全，餐廳、會客廳、衣帽間、化妝間、儲藏室、車庫、花園等等一應俱全，功能豐富。但它的缺點也很明顯，價格昂貴，普通家庭很難負擔。另外，由於空間較大，使用起來也不太方便。例如，需要上下樓梯；樓層之間的WiFi信號可能不太好，可能需要組個局域網；打掃起來不太方便，可能需要僱傭專門的人打掃。同樣地，分佈式數據庫具備較高的性能，能夠處理複雜的業務場景，滿足客戶對高吞吐、大存儲、低延時、易擴展和超高可用數據庫服務的需求。但是，分佈式數據庫的價格較高，技術門檻和運維成本都較高，對大部分中小企業來說其適用範圍比較窄。
那麼，偶爾需要擴展居住空間的小家庭應該怎麼辦呢？有沒有這樣一種房子，既有複式別墅的大空間和齊全設施，又不需要業主爲此付出高昂的成本呢？在現實生活中，這應該是不太容易實現的，但在數據庫這個領域，我們正在努力通過集分一體化技術滿足客戶的這種訴求。
所謂集分一體化，就是兼具分佈式數據庫的擴展性和集中式數據庫的功能和單機性能，兩種形態可以無縫切換。在集分一體化數據庫中，數據節點被獨立出來作爲集中式形態，完全兼容單機數據庫形態。當業務增長到需要分佈式擴展的時候，架構會原地升級成分佈式形態，分佈式組件無縫對接到原有的數據節點上進行擴展，不需要數據遷移，也不需要應用側做改造。
2. PolarDB分佈式版爲什麼要做集分一體化
可能有人會問，既然大部分中小企業都沒有使用分佈式數據庫的需求，那分佈式數據庫還是不是真正有效的需求？答案是肯定的，分佈式數據庫的需求是顯性的，我們已經有客戶在使用分佈式數據庫了，可擴展、高併發、高吞吐的分佈式數據庫已經運行了很多年了。
我們現在應該探討的問題是，分佈式數據庫能不能給大部分情況下沒有分佈式需求、但偶爾有分佈式需求的客戶來用？從功能上講，分佈式數據庫當然可以給沒有分佈式需求的客戶用，就好比300平米的複式別墅當然可以給一個普通的三口之家用。但問題是分佈式數據庫的成本太高了，在常規的業務場景裏，沒有分佈式的需求，使用分佈式數據庫是否有一種“殺雞用牛刀”的感覺？對此，我們秉持的理念是“在業務無需分佈式時，客戶不應爲此付出成本”。
PolarDB分佈式版之所以要做集分一體化，就是要解決一個問題：擴展使用場景來降低用戶的使用門檻，同時省去分佈式數據庫帶來的額外成本。
我們用Demo來展示下PolarDB分佈式版集分一體化的產品體驗。
3. PolarDB分佈式版怎樣實現集分一體化
要實現集分一體化，需要突破一系列的關鍵技術，我們的核心技術理念：
- 用分佈式技術提升集中式的可靠性與擴展性。
- 用集中式優化分佈式的性能與體驗。
3.1 Paxos多副本高可用
Paxos是一種解決分佈式系統一致性問題的共識協議。
PolarDB分佈式版的集中式形態，基於分佈式中的DN節點提供單獨服務，全面享受了分佈式的技術紅利，基於Paxos協議的多副本，保障數據多副本之間的一致性，滿足RPO=0以及RTO<30秒，可以很好地滿足金融級場景的容災訴求。
3.2 無縫升級切換
PolarDB分佈式版跨形態的無縫升級切換，支持將集中式形態下的DN，逆向恢復爲分佈式下掛的DN節點（過程中需要構建分佈式元數據、以及帶DNS域名的一鍵切換），整個升級過程中原有集中式的數據不動，分鐘級完成分佈式的整體切換。
3.3 分佈式事務優化
PolarDB分佈式版結合DN存儲節點複製組的邊界，引入TableGroup（簡稱表組）的概念，其中一個表有多個分區，表組內所有表相同序號的分區稱爲分區組（Partition Group）。分佈式水平擴展後會自動調度數據，但會根據調度算法保持一個分區組內涉及的多張表數據都在相同的DN存儲節點上。
例如，user、orders這兩張表都以hash（user_id）作爲分區函數，屬於一個表組，對應的分區按照分區組進行綁定調度，確保相同user_id的數據都在一個DN存儲節點上，這樣的事務稱爲單分區組事務，因爲所有的事務狀態都發生在一個DN存儲節點上，針對該場景的事務讀和寫都可以簡化交互流程，我們稱爲集中式場景的下推優化。
事務下推
PolarDB分佈式版針對分佈式事務的標準流程是採用2PC（Two-Phase Commit）機制，CN節點（作爲TM事務管理器）會通過XA協議接口和DN節點(作爲RM資源管理器)進行事務交互。標準2PC事務提交的流程會有1次全局時間戳獲取+2次協議交互，整體的網絡交互成本會比較高，影響分佈式事務的響應時間。
上圖展示了PolarDB分佈式版基於表組模型下的單分區組事務的相關優化：
針對autocommit=true的單分區讀和寫場景，可以利用單個DN節點的單機事務機制，可以減少通過GMS元數據獲取GCN，與集中式相比並不會增加任何多餘的網絡請求，我們稱之爲事務 0 PC。
針對autocommit=false的單分區寫場景，可以利用單個DN節點的單機事務機制，採用COMMIT ONE PHASE語義，與分佈式2PC相比少了一次PREPARE的網絡階段，我們稱之爲事務1PC。
其餘不滿足單分區組的事務場景，採用標準的2PC事務提交流程。
3.4 按需分佈式演進
如上圖，PolarDB分佈式版在面向分佈式線性擴展設計上，針對集中式的能力，引入存儲池和Locality的概念：
- 存儲池：指的是將DN存儲節點劃分爲互不交叉的池，支持在單個存儲池維度通過添加/減少DN存儲節點
- Locality：指的是將數據庫中的對象（數據庫、表、分區）通過Locality屬性關聯到不同的資源池。
典型的按需演進分佈式的場景：
原始業務的多個單表，可以繼續保持單表的形態，演進爲分佈式的垂直拆分，通過擴展單個存儲池內的分佈式節點後，可以實現多個單表在存儲池多DN節點上的均衡分佈。
原始業務的大表，可以在線變更爲分佈式表，演進爲分佈式的水平擴展，通過擴展單個存儲池內的分佈式節點後，分佈式表的partition會自動進行數據均衡調度。
原始業務的多張表，大表在線變更爲分佈式表，單表繼續保持並劃分到多個存儲池，整體演進爲分佈式的垂直拆分、水平拆分的組合場景，通過資源擴展實現線性能力。
按需演進分佈式，除了基礎的存儲池模型定義，核心技術挑戰在於如何支持更靈活的在線表變更能力（分佈式DDL），目前PolarDB分佈式版支持了完整的多種表類型之間的在線變更、遷移、分裂和合並等。
4. PolarDB分佈式版集分一體化的落地實踐
PolarDB分佈式版的集分一體化自發布以來，已經在客戶的業務場景中得到了實踐，爲客戶提供了絲滑的無縫升級切換體驗，解決了客戶的業務痛點。識貨APP的案例就是一個典型的案例。
4.1 客戶痛點
識貨APP是一個幫助消費者做網購決策的平臺，爲喜歡追求性價比的消費者提供網購優惠資訊，產品覆蓋國內外主流購物商城，提供的商品比價、價格訂閱等特色服務爲消費者在選購商品時提供了及時而精準的推薦。
這一切歸功於識貨的數據加工平臺，該平臺負責收集同類商品全網渠道的價格信息、折扣信息、滿減政策，並計算出同類商品在不同平臺不同渠道的售價，然後通過數據服務平臺推送給消費者，便於消費者準確鎖定性價比最高的渠道。
4.1.1 大促期間，數據加工性能難以保證
現在各渠道平臺大促期間滿減、折扣越來越多樣，越來越複雜。商品價格變更瞬息萬變，爲了在第一時間向消費者推送最及時的價格信息，數據加工的性能就尤爲關鍵。
在以往的大促期間，最核心的價格變更動作就需要數小時完成，導致大促期間商品價格波動情況更新不及時，業務部門投訴比較多。客戶也曾嘗試使用頂配MySQL實例（104核），通過增加只讀節點、讀寫分離、業務模塊剝離等一系列舉措，但問題始終得不到有效的解決。
4.1.2 商城擴品在即，平臺處理能力捉襟見肘
識貨的商品交易總額（GMV）已突破百億，規模持續增長，預計未來幾年內商城將擴品3~5倍，對識貨整個數據加工平臺的存儲和計算能力都是很嚴峻的考驗。目前核心業務的數據庫已經是集中式的最高規格，升無可升，在過去的幾年大促裏，資源使用率偏高，處理能力急需突破。
4.2 PolarDB分佈式版的解決方案
4.2.1 集中分佈式一體化，性能提升400%
在過去的幾年裏，客戶試圖通過各種方式解決加工平臺的性能瓶頸，也調研過市面上主流的分佈式數據庫產品，但是市面上的分佈式數據庫產品架構、技術各不相同，爲了發揮其最佳性能，都需要遵循各自的最佳實踐。識貨的核心渠道庫經過十多年的沉澱，積累了衆多的業務模塊，各個業務板塊相互依賴關係錯綜複雜，且開發設計完全是單機習慣。一方面，客戶很難將業務進行剝離。另一方面，短期內也不具備分佈式改造的可能。所以客戶一直未能堅定地邁出分佈式升級這條路。
PolarDB分佈式版爲客戶指出了一條不一樣的分佈式升級之路。PolarDB分佈式版是一個集中式分佈式一體化的數據庫，每一個表既可以打散到不同的節點，也可以單節點存儲。識貨核心渠道庫的特點是表的個數非常多，但單表體量有限，最大的日誌表也只到億級別。結合這兩個特性，PolarDB分佈式版給出瞭如下方案：
- 按業務模塊區分，各個模塊的表以單表形式存儲在不同節點。
- 通過不同規格的DN支撐不同業務的特性，避免同一規格的DN帶來的資源浪費。
- 通過Locality+存儲池的能力，確保任何表都具備在任意節點間騰挪的能力，應對未來業務模型發生變化帶來的挑戰。
識貨運維總監翟晟榮是這樣介紹這次分佈式升級的：“這就好比，我們拿出一個大規格的DN當做垃圾桶，所有理不清的業務邏輯的表先統一放在這裏，一些核心流程上的關鍵業務表，我們給它提供單獨的DN處理，上層通過分佈式CN統一管理調度，對業務代碼完全無感，而底層已經悄悄地完成了分佈式改造。”
大促實戰證明，經過這樣的分佈式改造後，數據處理能力提升了6倍，價格變更場景性能提升了4倍，從小時級別縮短到分鐘級別。
整體的業務效果：
4.2.2 平滑遷移，性價比提升500%
PolarDB分佈式版自身除了提供極致的MySQL兼容，確保了客戶業務代碼的0修改之外，在整個遷移過程中，也提供了豐富的功能，使遷移更絲滑。
▶︎ 熱力分區圖
從集中式向分佈式演進的過程中，數據會被打散到不同的節點，客戶普遍擔心的問題包括：相關聯的表是否被打散到了不同的節點帶來了性能瓶頸？訪問頻繁的表是否被打散到了同一個節點上？爲了解決這樣的困擾，PolarDB分佈式版提供了分區熱力圖的功能，可視化實時觀測各節點的容量和訪問的瓶頸，通過準確定位大幅降低了遷移和日常運維的難度。
▶︎ 智能壓測
核心渠道庫的大量信息是來自淘寶、亞馬遜、拼多多等渠道的實時價格信息，在測試環境下無法模擬這些信息，導致客戶無法在測試環境進行有效業務壓測，這給割接帶來了很大的風險。
阿里雲提供了智能壓測方案CMH-DOA（也稱frodo)，frodo可以全量採集原生產端MySQL的SQL審計，在目標端PolarDB分佈式版進行完整的流量回放，同時支持倍速回放模擬更大的生產壓力場景。通過真實流量的壓測驗證，有效降低了割接的風險，也爲未來大促擴容提供了很好的參考依據，目前該工具目前已開源。
▶︎ 性價比大幅提升
以往在大促期間，識貨MySQL的QPS一旦超過15w之後，性能明顯下降，通過只讀實例、應用限流等一系列手段後，整體QPS也只能勉強接近20w。遷移到PolarDB分佈式版之後，客戶在大促期間可以增加數據加工的併發，QPS峯值可以達到60w，而資源使用不超過50%。通過國際公認的性價比計算公式：price/performance，也就是月消費/QPS峯值，計算出每個QPS的成本，可以發現性價比提升了500%。
4.2.3 平臺突破瓶頸，未來可期
渠道、商品、用戶是整個識貨最核心的板塊，藉助PolarDB分佈式版集分一體化的能力輕鬆完成分佈式演進，識貨運維總監翟晟榮表示：“一次識貨核心業務的分佈式改造，我們沒有讓研發部門修改任何一行代碼，性能就得到了質的飛躍。去年雙11期間我們價格清洗需要4小時完成，而今年只花了15分鐘，真正做到了代碼0修改的分佈式遷移。在618、雙11等多個大促期間，我們做到了數據庫0故障的表現。我們運維部門今年也真正做到了4個9的SLA，這對我們團隊來說是很大的提升。”
本文爲阿里雲原創內容，未經允許不得轉載。