螞蟻金服日照：OceanBase如何實現透明可擴展的企業級數據庫？

企業級數據庫逐漸暴露無法解決可拓展性的問題，於是螞蟻金服、阿里巴巴完全自主研發了金融級分佈式關係數據庫 OceanBase 來應對這一挑戰，對傳統的關係數據庫進行了開創性的革新。本文整理自螞蟻金服研究員、OceanBase 主架構師楊傳輝（日照）在 QCon 北京 2019 的分享。

作者丨楊傳輝（日照）

首先跟大家探討一個問題：分佈式技術的最高境界是什麼？這個問題見仁見智，從個人的角度而言，我認為分佈式技術的最高境界就是沒有分佈式。

通過分佈式技術可以實現大數據的處理，通過分佈式技術也可以把數據庫由一臺機器變成一百臺一千臺一萬臺，甚至 Google 的上百萬臺服務器。但是從用戶的角度來看，我們需要做到讓用戶完全感知不到分佈式，它可以像以前使用傳統數據庫一樣來使用分佈式數據庫的企業級功能。

今天演講的主題是《OceanBase：透明可擴展的企業級數據庫》，我們會從四個部分展開：

什麼是透明可擴展

數據庫是一個非常古老的行業，從計算機誕生之初數據庫就存在了。Oracle 第一個版本在 1979 年發佈，迄今為止已經超過 40 年的時間。今天數據庫行業在全球範圍內創造了超過 400 億美金的產值，而且這還僅僅是數據庫本身，不包括數據庫上層的一系列應用。

上圖是 2018 年 Gartner 的魔力四象限圖所示，它跟過去幾年相比發生了什麼變化？我認為主要有兩方面的變化：

首先看第一象限——LEADERS 領導者象限，以前的 Gartner 魔力四象限主要上榜的都是傳統的企業級數據庫，比如 Oracle，Microsoft SQL Server，IBM DB2。今天我們發現領導者象限已經多了幾個比較新的選手，一個是 SAP，還有一個是雲數據庫 AWS。

再來看第四象限——VISIONARIES 遠見者象限，只有兩家公司上榜，一家是阿里雲，還有一家公司是 Google。

這兩家公司都是雲計算公司，雲計算公司過去其實不做數據庫。但是今天我們發現隨著雲計算的發展，互聯網公司和雲計算公司已經有能力跟傳統的企業級數據庫公司做正面的抗衡。

企業級數據庫發展超過了 40 多年的時間，很多方面都已經做得非常出色了，包括企業級數據庫的功能，SQL 的優化，SQL 的執行效率，以及整個企業級數據庫的生態體系等。

企業級數據庫面臨的問題

企業級數據庫經過數十年的發展已經非常成熟了，但是有一個比較大的問題，也是企業級數據庫從設計之初就沒有考慮也不想解決的問題——

如果容量不足怎麼辦？可以採用垂直擴展的方式。通過不斷擴展容量，雖然穩定性也能做得還不錯，但是成本的代價會變得非常的高。我們都知道大型機的成本跟一個普通的 PC 服務器的成本完全不在一個數量級。

雲數據庫 != 透明可擴展

那麼，雲數據庫是不是完全解決了透明可擴展的問題？雲數據庫的概念很時髦，可以稱為雲數據庫，雲時代的數據庫，也可以叫做雲原生的數據庫。

從技術的角度來看，我們會發現雲數據庫的本質其實還是開源數據庫加存儲計算分離，不管是 AWS 還是阿里雲或者其他的雲計算公司，雲數據庫最主要的營收來自於開源數據庫，尤其是 MySQL。

AWS 做了一項創新，除了支持本地存儲，也可以支持遠程的分佈式存儲，相當於給傳統的開源數據庫加了一塊雲盤。這種方式解決了存儲可擴展的問題，而且非常適合公有云這種部署模式。因為公有云往往用戶規模比較小，一臺機器處理的能力已足夠，但是它的存儲是不夠的。數據庫的核心部件除了存儲以外，還有兩個更加關鍵的部件——一個叫事務處理，這是數據庫的核心，還有一個是 SQL。雲數據庫的模式採用的是存儲計算分離的方式，解決了存儲可擴展的問題，但是沒有解決更關鍵的問題，那就是事務與 SQL 可擴展的問題。

今天雲數據庫所使用的開源數據庫的核心能力相比企業級數據庫還有巨大的差距，不管是 SQL 優化器，SQL 的執行性能，甚至包括各種各樣的安全數據管理的能力，存儲優化的能力，都跟企業級數據庫存在巨大的差距。

剛剛召開的一個 A 類國際會議 ICDE 裡發生了一個很有意思的討論——雲數據庫能否替代企業級數據庫？參加討論的都是世界上知名的學者，其中一位學者他是來自 IBM 的 C. Mohan，他認為雲數據庫肯定是不能替代企業級數據庫的，至少今天還不行。今天雲數據庫不管是在存儲架構、內存架構、數據管理架構，SQL 優化能力以及 SQL 執行能力跟現有的企業級數據庫相比，都有很大的差距，未來需要的是一個分佈式企業級 OLTP 數據庫。

分庫分表 != 透明可擴展

在互聯網裡我們還會用另外一個方案叫做分庫分表。這個方案非常好，用一個形象的比喻來說它其實有點像狗皮膏藥。如果哪裡有擴展性問題，就把它往哪裡貼就好了。但是這種方案有很多問題並沒有解決，它沒有實現透明可擴展。

數據庫裡有一個最基本的功能叫做全局索引，當實現分庫分表以後，對用戶來講原來是一張表格，現在被劃分為多張表格，表格的語義都發生了區別。分庫分表的方案從理論上講就永遠不可能實現全區索引這個功能。另外整個分庫分表方案往往會在上面架一層中間件，通過中間件做簡單的 SQL 轉發、路由、聚合，以及一些比較基礎的數據查詢功能。

通過中間件提供的 SQL 能力相比真正的企業級數據庫的能力，有非常大的差距，它不支持很多功能，包括全局快照——跨多臺機器的全局快照，包括複雜查詢——跨服務器的複雜查詢，跨服務器的寫入操作，也包括一個很重要的能力——帶容錯能力的分佈式事務。

很多中間件是支持分佈式事務的，但是中間件支持的分佈式事務是不帶容錯能力的分佈式事務。當服務器出現故障的時候，整個事務會被夯住，需要人肉去做容錯。這種方案跟真正的分佈式數據庫裡帶容錯的分佈式事務是兩個方案，有本質的差別。後面會詳細的講這個問題。

透明可擴展的企業級數據庫

透明可擴展的企業級分佈式數據庫需要具備一些基本的屬性：

透明可擴展的理論基礎

事務是一個非常古老的概念，必須遵循 ACID 特性：

分佈式事務不是一個新鮮的概念，分佈式事務的協議是 1978 年由 Jim Gray 提出的兩階段提交協議。

兩階段提交協議本身並不複雜。當我們需要把多臺機器連起來做協調的時候，所有機器都叫做參與者，然後其中有一臺機器會選出來做協調者。當要進行事務提交的時候，協調者先給所有的參與者發送 prepare 消息，如果所有的參與者都 prepare 成功，最終協調者認為整個事務可以提交了，然後再發出 commit 消息，讓每一個參與者都提交事務。如果其中某個參與者因為各種情況比如資源不足最後沒法提交事務，整個事務提交失敗，協調者給參與者發送回滾消息。

這個協議看起來很簡單，但沒有考慮容錯，是一個理論上的協議，而不是一個工業級的工程實現。當我們去考慮工業級的工程實現的時候，我們必須考慮容錯，這時候就會出現一個最關鍵的問題——阻塞。

假設協調者出現了故障，整個數據就會被 hung 住，即使是參與者出現故障，那參與者所在的那臺機器也會被 hung 住。在一個高併發的系統裡只要有一臺機器被 hung 住，就意味著客戶端被 hung 住。客戶端被 hung 住就意味著整個系統被 hung 住。所以一臺機器故障最終會導致整個集群的不可服務。

分佈式事務：Paxos + 2PC

分佈式事務不支持容錯——這個是在工程應用時面臨的最大的問題。那麼支持容錯其實有很多種方案。

其中的一種方案就是中間件 XA。中間件 XA 是一種分佈式事務的實踐方法， XA 的本質是把協調者跟參與者的狀態持久化到數據庫裡，由數據庫來支持容錯，所以中間件是無狀態的。但是我們自己是分佈式事務數據庫的設計者，不可能再把狀態持久化到另外一個分佈式數據庫裡來支持容錯。

另外一個思路是 NOSQL 系統中的 CAP 理論。CAP 三者不可兼得。在一個需要考慮容錯的系統設計裡面，P（分區容錯）是不可選擇的，一定會出現網絡分區的情況。C（一致性）跟 A（可用性）二者只能取其一，要麼要一致性，要麼要可用性。

其實 NOSQL 系統從理論上就已經比較“巧妙”的迴避了一致性分佈式問題。分佈式事務的問題就不處理了，或者根本就不支持分佈式事務。

身處雲時代，作為一個有追求的技術人員，我們的方案應該不是去規避問題，而是直面問題，直接採用 Paxos 加上兩階段提交協議來解決帶容錯的分佈式事務的問題。

其實這個協議也沒有特別新鮮的內容，由兩個圖靈獎得主，一個是事務的圖靈獎得主——Jim Gray，一個是 Paxos 的圖靈獎得主——Leslie Lamport，他們在 2004 年發表了一篇關於 Paxos + 2PC 的論文。但是這個協議從理論走向工程實踐，經過了十多年的時間。

CAP 與 Paxos

CAP 理論跟 Paxos 是什麼關係呢？CAP 理論中 P（分區容錯）是沒有辦法規避的，所以 C 跟 A 兩者是不可兼得的。CAP 理論告訴我們，要麼強一致，要麼高可用。Paxos 卻能同時實現強一致和高可用，那麼 Paxos 協議是不是違背了 CAP 理論呢？我認為其實是沒有違背的，本質在於 Paxos 裡的高可用跟 CAP 裡的可用性是兩個不同的概念。

在分佈式系統裡面經常會有一些概念容易引起混淆，比如這裡講的可用性和一致性，這兩個概念在不同的場景的語義是不同的。Paxos 是從系統整體的角度來看的，哪怕出現單個節點故障的時候，只要多數派能夠快速恢復使得整個系統繼續服務，它就是高可用的。

但是 CAP 理論是從故障節點的角度來看的，當單個節點出現故障的時候，這個故障的節點能不能在有限的時間被訪問到，這是 CAP 理論裡可用性的意思。

所以雖然可能滿足不了 CAP 的可用性，當出現了一個故障節點，有可能這個系統出現故障的節點永遠沒有辦法恢復，所以永遠滿足不了 CAP 的高可用。但是這個系統仍然能夠滿足 Paxos 的高可用，因為系統中其他多數派的節點能夠提供服務，整個系統就能夠最終提供服務。Paxos 的高可用才是真正有工程意義的高可用。

Raft or Paxos

Paxos 協議有很多的變種，其中一個比較著名協議叫做 raft 協議。我從 2007 年接觸 Paxos 協議，前後花了至少三年多的時間才覺得自己開始慢慢理解它。

以前 Paxos 協議是一個貴族協議，但是自從誕生 raft 以後，他的出現把 Paxos 的協議變成一個平民協議。為什麼這麼說呢？

Paxos 協議有一個很大的設計假設，它要求支持多個投票，也就是數據庫裡的多條日誌之間是可以亂序提交的，可以並行處理的。但是 raft 協議的做了一個約束，數據庫的多個投票多條日誌一定要按照順序執行，只能前一個日誌被確認了才能確認後一個日誌。

這種簡化使得 Paxos 協議走進了千家萬戶。

第二個是可用性的問題。如果採用 Paxos 協議，當一臺機器新上線的時候很快就能提供服務了，因為不需要等前面的數據確認它就能提供服務，但是如果使用的是 raft 協議，需要等前面的所有日誌確認以後才能提供服務，所以說 raft 協議存在可用性的風險。在某些場景尤其是異地部署和比較差的網絡環境下是有風險的。

在所有分佈式系統裡分為兩個陣營，一個是 Paxos 的陣營，包括 Google Spanner，螞蟻金服 OceanBase 1.0 以及 1.0 之後的版本，Amazon DynamoDB 等。Raft 陣營，包括螞蟻金服 OceanBase 0.5 版本，也包括騰訊的 TDSQL 以及一系列的開源的系統，基於 mysql 的系統基本上都是通過 Raft 協議來實現的。

選擇哪一個陣營其實也就說明了你想要實現的目標。如果說你想快速拿到業務結果，而且希望技術風險可控，我建議大家採用 Raft 協議。如果你希望追求極致，做世界一流的系統，那麼我們應該嘗試用 Paxos。

透明可擴展的關鍵設計

分佈式分區表

在 OceanBase 的設計過程中，我們遇到的第一個問題就是分區表。分佈式要解決的第一件事就是如何對數據進行切片。在數據庫裡切片有兩種方式，一種方式是分表，一種方式是分區表。

分表從邏輯上改變了表格的語義。用戶原來是一張表格，如果說應用層做了一層分表以後，在數據庫裡有了多張表格，多張表格就意味著很多的特性其實丟掉了，包括全局索引這個非常重要的特性。

分區表是企業級數據庫裡一直都有的一個功能。以前的企業級數據庫，它的分區表只能把每一個分區放在一臺機器裡，而分佈式數據庫可以把它的分區表按一定的規則，在後臺把它分散到整個分佈式的集群裡。分區的模式能夠實現全局的一致性，而且能夠支持強一致的全局索引，這個很關鍵。分區表支持多種數據分佈的方式，包括 NOSQL 或者存儲系統裡會用到的哈希分區，範圍分區，列表分區以及兩種分區方式的組合。

自動負載均衡

有了分區表，把整個數據打散成很多數據分片以後，我們接下來要做的一件事就是把這些數據分片均勻的分佈到整個後臺的分佈式集群裡，這個過程我們稱為

負載均衡裡有一點想特別強調一下，就是複製的方式。複製的方式有兩種：一種方式叫邏輯複製，一種方式叫物理複製。

顧名思義，邏輯複製相當於把數據一行一行讀出來再寫，這叫邏輯複製。物理複製，就是直接拷貝最終的數據文件或者是數據塊。物理複製的性能很好，但是實現難度卻很高。按照以往經驗來看，物理複製的性能可以做到邏輯複製的 5 到 10 倍。

在大部分的分佈式存儲系統裡面，負載均衡都實現了自動化。但是目前絕大部分的分佈式數據庫的負載均衡都是人肉負載均衡。

分佈式數據庫裡的自動負載均衡實現難度很大。因為分佈式數據庫裡面臨的負載均衡本質上是一個多因子負載均衡的問題，它需要考慮兩種負載，一種負載叫做計算負載，主要考慮的是 CPU 跟內存。另外一種負載叫存儲負載，主要考慮的是磁盤的佔用量。

當計算負載比較高的時候，存儲負載可能是比較低的。相反，當存儲負載比較高的時候，計算負載又是比較低的。而且我們會發現計算存儲的資源配比跟業務實際的計算存儲負載是不一致的。同時，存儲的遷移耗時很長。

分區容錯

當我們有了分區表，假設已經把負載自動均衡到所有的機器後，下面我們要考慮的就是如何做容錯的問題。容錯分為兩種情況，一種是分區自身發生的故障如何容錯，還有一種情況是外部的用戶請求如何動態的處理故障。

當發生主備切換的時候，需要做到新的事務在新的分區裡開啟，老的事務還需要動態地由原來的主分區一行一行遷移到新的主分區，整個過程需要做到事務的在線遷移。大家可以想象這是一個分佈式場景的併發處理問題，它的難點在於怎麼做多機的併發問題以及如何做異常的處理。

分區分裂是我們內部的一個操作，這樣的一個操作是不能殺事務的。如果殺事務用戶就會感知到，感知到後臺做了一些操作。而且數據庫的事務可能是一個執行非常長的一個事務，有的甚至執行一到兩天。我們需要做到新的事務在新的分區裡執行，老的事務還能動態的一行一行遷移到新的分區裡，整個過程需要做到對用戶透明，這是其中最大的難點。

全鏈路請求容錯

全鏈路的請求容錯，難點在於請求涉及的環節特別多。從應用過來一個請求，首先會到一個叫 Proxy 的代理服務器，Proxy 再請求後端的分佈式數據庫的集群，整個過程是一臺機器請求另外一臺機器，一臺機器再請求另外一臺機器，任何一個過程都可能會發生故障。

在發生故障的時候都需要做到讀寫請求的重試，但是重試其實是一個很危險的操作。AWS 之前曾經因為重試產生了重試風暴導致大面積的故障。重試可能會產生連鎖反應。原來用戶發了一個請求，最後重試變成了一百個請求，整個系統就崩潰了，而且永遠不可恢復，只能把用戶的請求停掉，最後才能恢復。

重試也要做的，但是我們追求一點，就是需要做到任務級的重試。一個請求可能涉及的數據量很大，這個過程中會處理很多的數據分片，某一個數據分片出現故障的時候只重試這一個數據分片。整個請求的鏈路涉及到 Proxy 到數據庫，當 Proxy 跟數據庫做動態調整或者在線升級的時候，我們需要做到將它上面正在進行的請求動態的遷移到其他還能夠工作的機器上。這是這件事情的難點，它需要做動態，但不能殺事務。

異常處理也有一個比較大的難點——是半死不活。當請求一個磁盤，它一會好一會不好，網絡時好時壞。如何處理這種半死不活的狀況。這個情況在大規模系統裡面叫 hung 住。hung 住比失敗要可怕得多。

企業級查詢優化器

企業級數據庫裡有一個很重要的功能叫優化器。優化器在企業級數據庫裡面都是基於代價來實現的。因為優化器帶來的問題特別多，我這裡面只提兩個問題。

第一個是大小賬號的問題，很多人在互聯網公司都經歷過，比如一張表格有很多的用戶，有的用戶數據量很大，有的數據量很小。假設一個企業級數據庫，同樣一條 SQL 進來的時候，能夠動態的判斷請求的用戶是哪個，並且可以根據統計信息來選擇執行計劃。如果請求的是大賬號，就選擇一個全表掃描的執行計劃，如果小賬號選擇一個索引回表的執行計劃來達到最優。

數據庫後臺調整的時候，特別讓人害怕的一點就是數據庫後臺調整以後執行計劃變了，使得原來執行很快的執行計劃變得很慢，這個時候該怎麼辦呢？在企業級數據庫裡，有執行計劃演進這樣的一個功能。

當有調整的時候也會生成新的執行計劃，但是新的執行計劃並不會立刻生效，而是把流量一點一點從老的執行計劃切到新的執行計劃，等到最終內部驗證了整個新的執行計劃的性能沒有回退以後，我們再用新的執行計劃完全替代老的執行計劃。這是企業級數據庫裡面優化器的一些基本的功能。

分佈式數據庫相比企業級數據庫又多了一個問題，主要是並行優化的問題。假設一個單機數據庫，以 Oracle 為例，優化器的實現會把整個優化分成兩個階段，第一個階段叫串行優化，不會考慮一些分佈式的問題，也不會考慮網絡開銷的問題。第二個階段它會對第一個階段串行優化結果裡部分的算子做局部的並行化。所以大家可以想象，分成了這兩個階段以後，它的搜索空間並不是那麼的全面，有一些應該搜索的這樣的一些執行計劃就被忽略掉了。

但是如果是一個分佈式數據庫，我們一開始就應該考慮並行優化器，一開始就應該考慮所有的單機的開銷以及分佈式的開銷，直接搜索全部的空間，然後生成一個涉及全部開銷的並行執行計劃，最終才可能達到一個最優。

螞蟻金服 OceanBase 的業務實踐

最後簡單的給大家介紹一下螞蟻金服 OceanBase 的實踐經驗。OceanBase 從 2010 年立項，是由阿里巴巴和螞蟻金服 100% 自主研發的具備完全自主知識產權的企業級的分佈式數據庫。

2014 年，OceanBase 第一次將 Paxos 協議引入到關係數據庫領域。因為這項創新，最終 OceanBase 數據庫成功替代了螞蟻金服交易庫中的 Oracle 數據庫，實現了金融級的持續可用。這是金融行業過去沒有的一項重大創新。

OceanBase 是一個工業級的 share-nothing 透明可擴展的分佈式架構，可以無限擴展。OceanBase 可以給用戶提供全局一致的數據庫視圖，並且能夠支持跨服務器任意的複雜查詢。OceanBase 對 MySQL 全兼容，還支持部分 Oracle 版本的兼容。

OceanBase 設計之初，其實就是一個原生的多租戶支持的系統，當有多個業務同時使用 OceanBase 集群，一個業務有問題，它不會影響別的業務，這是面向雲設計的一個系統。

OceanBase 使用情況

OceanBase 在螞蟻以及整個金融行業使用已經非常廣泛了。螞蟻金服幾乎所有的業務都是由 OceanBase 所支撐，包括雙 11 大促，618 以及春節紅包等等各種類型的市場活動，其中支付交易賬務百分之百的流量都是由 OceanBase 所承載。並且隨著螞蟻金服的國際化，OceanBase 已經全面進軍國際業務。OceanBase 在浙商銀行、南京銀行、蘇州銀行、廣東農信、人保健康險等外部客戶的互聯網核心系統中，承擔了交易數據庫的重要角色。

OceanBase 應用場景

場景一：交易支付透明拆分

交易支付是螞蟻金服最核心的一個業務，原來交易支付是按照 UserID 拆分成 N 份的，後來發現容量不夠，要拆分成 M*N 份。以前做拆分都是中間件跟業務一起來改造，每一次拆分都需要技術部門幾百人的開發花費一年的時候來完成改造。導致一方面耗時耗力，另外一方面技術風險非常高。

OceanBase 的解決方案：

OceanBase 解決的方案就是使用 OceanBase 分區表實現透明拆分。通過 OceanBase 分區表在數據庫底層實現拆分，業務完全沒有感知，也基本上不需要任何的改造。

場景二：會員系統全局索引

每個公司無論大小，肯定都會有自己的會員系統，而且這一定是公司的核心繫統，它存儲了用戶的重要信息。一個用戶的信息是多維度的，除了根據 userID 還可能根據用戶名，郵箱手機號碼等進行查詢。

這樣的一個數據庫，本質上就是全局索引的需求，但是我們都知道分庫分表的方案是不支持全局索引的，帶來的問題就是單機數據庫只能垂直擴展，沒有辦法做到水平擴展。

OceanBase 的解決方案：

OceanBase 的解決方案就是 OceanBase 分區表 + 強一致的全局索引，通過這樣的方案在數據庫底層實現可擴展，而且對用戶透明。

場景三：結算系統小機下移

外部業務相比螞蟻的業務對透明可擴展的要求更高，在螞蟻內部我們有非常強大的 DBA ，有很強大的開發能力可以改造，但是在外部客戶基本上是不能改造的。這裡舉一個金融機構例子，某金融機構有大量批處理場景，有多張大表關聯的複雜計算，並且涉及到大量的數據更新。批處理意味著每一次處理的數據量很大，而且有很多張大表要做關聯，經常要做一些比較複雜的查詢，並且更新量也比較大。業務的痛點在於傳統的集中式數據庫，單點出現了瓶頸，並且小型機的成本很高。如果擴容只能擴容成大型機，成本就變得不可接受。

OceanBase 的解決方案：

OceanBase 的解決方案就是透明可擴展的 OceanBase，通過 OceanBase 的 HTAP 場景的並行處理能力，使得處理時間相比現有的時間縮短了一半，並且 TCO 得到了大幅度的降低。通過 OceanBase 遷移服務（又名 OMS）進行平滑遷移實現了可灰度可回滾。過去金融行業進行業務遷移都是停機遷移，OceanBase 做到了在線遷移並且可灰度可回滾在金融行業是一件非常了不起的事情。

關於 OceanBase

OceanBase 是由螞蟻金服、阿里巴巴完全自主研發的金融級分佈式關係數據庫，始創於 2010 年。OceanBase 對傳統的關係數據庫進行了開創性的革新。在普通硬件上實現金融級高可用，在金融行業首創“三地五中心”城市級故障自動無損容災新標準，同時具備在線水平擴展能力。在 2017 年天貓雙 11 中創造了 4200 萬次 / 秒處理峰值的世界紀錄。在 2018 年天貓雙 11 中，OceanBase 2.0 版本支撐了支付寶的核心鏈路，性能比去年提升了 50%，真正實現了“零成本”支撐大促。歡迎關注“OceanBase”公眾號，瞭解更多數據庫乾貨，破解更多技術密碼。

Tips：關注“OceanBase”微信公眾號回覆“Qcon”獲取日照現場PPT