![](https://img.alicdn.com/imgextra/i1/O1CN017M9LKN22Vl95fmjSb_!!6000000007126-2-tps-1080-171.png)

8 月 10 日，2022 OceanBase 年度釋出會在京滬深三地同時召開，**支付寶資深資料庫專家鄧榮偉在會上分享了《從“小”到“大”，支付寶分散式升級之路》的主題演講** ，為我們帶來了支付寶的架構演進以及上線 OceanBase 的故事。

![](https://img.alicdn.com/imgextra/i3/O1CN01z8ZS9I1jFICt4lNGF_!!6000000004518-0-tps-900-383.jpg)

以下為演講實錄分享：

大家都知道支付寶是 OceanBase 的“元老級”使用者，支付寶的每一次架構演進都與 OceanBase 的版本迭代息息相關。今天，我將從支付寶的資料庫架構演進展開，主要圍繞以下三個方面進行分享：

第一， 支付寶線上庫架構演進；

第二，支付寶曆史庫架構，面對 PB 級資料歸檔，如何橫向無限擴充套件；

第三，面對多樣化儲存需求，支付寶的未來探索。

## 支付寶線上庫架構演進

### 過去式：OceanBase 1.0時代的進化

支付寶一開始誕生在“IOE”時代，資料庫首選 IBM 小型機+Oracle 資料庫+EMC 的傳統搭配。然而，當支付寶迎來第一個“雙 11”，與之而來出現“峰值脈衝”，原單庫單表的集中式資料庫方案自然扛不住如此高的流量。所以，支付寶在很早期就進行了拆庫拆表，由此誕生了基於中介軟體方案的第一代分散式架構。

隨著支付寶的使用者規模不斷增長，以及歷年“雙 11”都需要應對超高併發，傳統架構效能瓶頸凸顯，資料儲存成本攀升。2013 年 5 月，支付寶下線最後一臺 IBM 小型機之後，開始下一步的升級迭代，眾所周知，核心底層儲存的替換挑戰非常大，支付寶對新資料庫不僅要求成本低，還要求具備高效能、可擴充套件、高可用等特性，OceanBase 就在這種背景下誕生了。

如下圖所示，是支付寶在 2017 年之前整個資料庫架構的演進。首先是底層儲存全部替換為 X86，然後是資料庫從 Oracle 升級為 OceanBase 0.5、再到 OceanBase 1.0。

![](https://img.alicdn.com/imgextra/i4/O1CN01NBz3In27TXIoN05nz_!!6000000007798-2-tps-865-475.png)

陽老師在《OceanBase 4.0 核心技術解讀》中分享了 OceanBase 的版本迭代歷程。在 0.5 時代，OceanBase 因為讀是分散式的，寫是集中式的，所以沒有辦法將效能做到極致。在 1.0 時代，OceanBase 實現了一個叢集內所有節點都是對等的，每個節點都可以進行讀寫，成為真正的分散式資料庫。

OceanBase 1.0 是支付寶投產時間最長、應用範圍最廣的版本，主要有以下三個特點：

多租戶。多租戶能在中小資料庫整合場景中很好地提升資源利用率，例如，我們上線一套 MySQL 或 Oracle，遇到流量激增時會不得不進行拆庫拆表，但 OceanBase 能以租戶為資源載體的方式進行動態擴容。

高可用。支付寶的金融場景，要求資料庫必須滿足機房級容災、城市級容災，OceanBase 是基於 Paxos 協議的分散式資料庫，先天滿足這些訴求。

彈性伸縮。歷年“雙 11”，支付寶都會轉移一部分流量去一個“泡”在湖水中的資料中心——千島湖資料中心。當支付寶還在使用傳統關係型資料庫時，資料庫彈出只能透過主備庫的方式先在千島湖資料中心搭一個備庫，然後主備切換過去。但這種方式會有切換閃斷問題，業務有感知。遷移至 OceanBase 後，資料庫彈出可以直接使用 OceanBase 的加減副本、平滑切主特性，在使用者不感知的情況下完成彈出。此外，OceanBase 可以做到在大促峰值結束 30 分鐘內釋放數千臺伺服器給其他業務使用。

### 現在式：穩定支撐每秒百萬筆支付請求

大家都知道，每年雙 11 的各項資料都在增長，到了 2017 年的雙 11時期， 1 %的壓力峰值就已經超過了單庫單機的最大容量。傳統資料庫擴容方案主要依賴分庫分表拆分進行水平擴容，用多套庫的方式共同扛流量峰值。雖然這種方案可行，但存在很多弊端，比如多套資料來源、多套 DB 叢集，增加了配置管理、日常管理成本。

我們需要更優雅的分散式資料庫解決方案，即只使用一個庫，就可以支援百萬甚至更高的支付峰值，讓橫向擴容直接在資料庫閉環，做到應用不感知，OceanBase 2.0 分割槽提供了完美的解決方案。

OceanBase 2.0 分割槽方案思路和傳統的分庫分表拆分一樣。我們在交易支付核心庫上，在原有百庫百表的基礎上繼續按使用者 UID 進行更深層次拆分，每個分表再拆成一百個 Partition，應用端只看到一張表，在使用者無感知的前提下把資料拆分到更多的機器上，突破單機效能瓶頸，自動負載均衡，從而實現穩定支撐每秒百萬筆支付請求的能力。

這時候大家可能會有兩個疑問，為什麼已經擁有分割槽能力，還要用分表加上分割槽的方案。支付寶是一個單元化部署架構，分庫分表是架構的一個基礎，所以分庫分表不能變，在此基礎上可以繼續分割槽。這樣，使用者看起來還是百庫百表，然後透過 OceanBase 自動負載均衡，把 1% 的表自動均攤到多臺機器上，以此突破單機容量上限。

那麼，OceanBase 能否在不分割槽的前提下使用多臺機器資源？答案是可以的，支付寶內部也有很多系統沒有分割槽，直接將單庫多表均攤到多臺機上的應用場景。以及，OceanBase 的分割槽表，是否一定要業務指定分割槽 ID，這其實需要根據業務場景而定，如果業務場景追求極致效能，建議指定分割槽 ID，我們可以按照一定的規則分割槽，透過應用或中介軟體計算出分割槽 ID，只要讓 OBProxy 感知到分割槽，SQL 路由到正確的機器上即可，否則需要 OceanBase 內部二次路由，效能稍有衰減。

同時，OceanBase 2.0 為了極致效能引入 Partition Group，將業務使用了一組邏輯表的相同分割槽，聚集在相同的 OceanBase 節點，使分散式事務退化為單機事務做到極致效能。具體來說，假設現在是單庫單表，當某業務做一筆支付請求要在這三張表裡落資料時，現在是按照使用者的 UID 維度，按照相同的分表分割槽規則做拆分，使用者支付之後一定是在這三個表的同一個分割槽落資料，也就是說，這三個表相同分割槽就可以滿足使用者的整個業務邏輯，所有操作不需要跨機、不需要產生分散式事務。

現在，OceanBase 2.0 版本在支付寶也承擔了非常多的核心業務，主要有以下三個特點：

高相容。OceanBase 支援 MySQL/Oracle 語法，讓支付寶在資料庫遷移時成本代價更低。

效能提升，成本下降。單庫單表可以擴充套件到多機，單庫容量不再受限於單機硬體能力。相對 OceanBase 1.0，資料庫整體效能提升 50%，儲存空間節省 30%。

更低的運維成本，更好的彈效能力。以前支付寶做資料庫彈出的時候，需要業務配合。現在，OceanBase 資料庫可以橫向伸縮，在資料庫上就已經閉環，業務不感知，基本一鍵完成了這件事。

### 遷移OceanBase之路

Oracle/MySQL 是支付寶最早投入使用的資料庫，體量非常大，這種傳統關係型資料庫在擴充套件、容災等能力上存在短板，沒辦法滿足支付寶的發展訴求。此外，對於我們 DBA 來說，一是經常要去擔心資料一致性問題，二是不得不重複維護多套運維體系、容災體系以及生態工具，代價非常大。所以，支付寶開始規模化地將Oracle/MySQL 全部遷移至 OceanBase。現在，支付寶全棧都執行在 OceanBase 上。

異構資料庫遷移是一個複雜的過程——主要是相容性和資料質量的問題。為了高效遷移， OMS（OceanBase Migration Service，OceanBase 資料遷移工具）提供一站式的異構資料庫上 OceanBase，首先為了應對相容性問題，平臺提供靜態程式碼評估，動態流量回放評估，其次資料質量透過全量校驗，增量校驗，離線校驗等多重手段實時保證資料一致性。

遷移至 OceanBase 後，一方面是效率提升，DBA 可以更從容地應對日常的容量容災問題，日常容量應急、故障切換配合運維體系已經完全自動化，計劃內的大促彈性和容災演練都可以一鍵完成；一方面是成本降低，首先是 OceanBase 的多租戶整合 Oracle/MySQL 長尾業務，最佳化碎片資源，其次是 OceanBase 的超高資料壓縮比。讓我印象非常深刻的是，當時支付寶最後一批傳統集中式資料庫下線，原本需要上百臺機器，遷移至 OceanBase 後，10 臺左右機器就解決了。

## PB級資料歸檔

隨著越來越多的業務遷移到 OceanBase，以及支付寶的業務發展迅猛，我們面臨生產庫磁碟不足、IOPS 效能下降，以及備份時間變長等問題，資料歸檔就變得非常重要。

如何高效且低成本地把這些資料歸檔呢？過去，我們要麼引入高階商業儲存陣列，要麼引入新一代分散式儲存。現在，我們只需要用 SATA 盤 X86 加 OceanBase 的分散式能力，就可以輕鬆搞定單庫 PB 級儲存。

其實，歷史庫總結起來就兩個核心點，即負載均衡和故障恢復。

![圖片](https://img.alicdn.com/imgextra/i2/O1CN01pnRpEj20JH7V1Qel7_!!6000000006828-2-tps-865-473.png)

### 核心點一：負載均衡

負載均衡最主要的目的就是在成本儘量低的情況下讓儲存利用率和計算資源利用率儘量高。

儲存利用率最大化。隨著叢集規模不斷變大，不斷接入更多業務，再加上不同年份採購機器型號的差異，會逐漸出現木桶短板效應，少部分機器影響整個叢集磁碟使用率，浪費儲存的問題。OceanBase 針對該問題做了特殊最佳化——基於分割槽級別進行動態的負載均衡，能最大限度利用每臺機器的磁碟空間。

計算資源利用率最大化。歷史庫一般按照時間分割槽，很容易出現相同月份的分割槽聚集在少量機器，導致寫入熱點，壓力不均衡。OceanBase 針對該問題也做了特殊最佳化——為了充分發揮每臺機器的計算資源，OceanBase 將不同表相同月份的分割槽打散到不同機器，所有 Parition 的 leader 也均衡打散到所有機器，分散寫入，防止寫入熱點。

### 核心點二：故障恢復

不論故障機器是否徹底當機，替換的新機器都會作為目標遷入資料，瓶頸都在新機器單機的寫入能力。按照普通 SATA 盤 200MB/s 的寫入能力計算，100TB 資料遷移幾乎需要一週時間。過長的替換時間會帶來非常多的弊端，如可能出現二次當機出現單副本，變更週期過長，容易出現失誤。

鑑於常規替換時間長的種種弊病，我們利用 OceanBase 的原生分散式能力，加速替換。只需要兩步，首先新機器上線，其次故障機器直接永久下線，OceanBase的總控服務 RootService 檢測副本缺失，直接走補副本模式，補副本是多機到多機複製，生產可達 30-50GB/s，100TB 資料遷移只需兩三個小時就可以完成。

## 支付寶的未來探索

支付寶的業務場景非常豐富，對儲存能力的需求也是多樣化的，未來，我們 DBA 團隊主要會圍繞 HTAP 和多模這兩方面做一些探索，持續打磨 OceanBase 的能力。

一是 HTAP 方面的探索。目前螞蟻實現 HTAP 鏈路複雜，和傳統方案一樣，訂閱線上日誌到數倉進行計算，不僅維護成本過高，而且過多依賴第三方元件，經常出現可用性事件。未來我們將在 OceanBase OLTP 能力的基礎上擴充套件 OLAP 的能力，可以實現一個系統、一份資料同時處理交易和實時分析的高價效比方案，“一份資料”的多個副本可以儲存成多種形態（行存/列存），用於不同的工作負載。

二是多模方面的探索。過去為了滿足一種業務場景對儲存的需求，比如文件、KV、時序等，我們需要引入全新的一種資料庫，維護多套運維繫統，重複建設容災體系。在未來，我們將在 OceanBase 統一的儲存引擎和分散式引擎之上發展多模型能力，實現一份資料，多種訪問方式，更加輕鬆應對多樣化的儲存需求。

我今天的分享就到這裡，希望能對大家有所幫助，謝謝大家。

鄧榮偉：穩定支撐每秒百萬筆支付請求，支付寶資料庫架構的過去、現在與未來

相關文章