作者：樓江航（七鋒）
日前，在阿裡雲PolarDB開發者大會上，阿裡雲PolarDB分布式産品部負責人黃貴發表了《分布式的PolarDB：分布式的能力，一體化的體驗》主題演講。
黃貴表示，PolarDB分布式版（PolarDB for X-scale，簡稱“PolarDB-X”）早期一直聚焦分布式形态，我們在2023年10月公共雲和開源同時新增集中式形态，将分布式中的DN多副本單獨提供服務，支援Paxos多副本、lizard分布式事務引擎，可以100%相容MySQL。同時，PolarDB分布式版核心上具備了集中式分布式一體化的技術融合，支援集中式和分布式兩種形态無縫切換，我們簡稱為“集分一體化”。
阿裡雲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，這對我們團隊來說是很大的提升。”
/ END /