11 月 16 日，OceanBase 在北京順利舉辦 2023 年度發(fā)布會，正式宣布：將持續(xù)踐行“一體化”產(chǎn)品戰(zhàn)略，為關(guān)鍵業(yè)務(wù)負(fù)載打造一體化數(shù)據(jù)庫。OceanBase 產(chǎn)品總經(jīng)理?xiàng)钪矩S發(fā)表了《助力企業(yè)應(yīng)對數(shù)據(jù)庫轉(zhuǎn)型深水區(qū)挑戰(zhàn)》主題演講。

以下為演講全文：

大家好，我今天的分享正好處于承上啟下的位置，主要包括幾方面內(nèi)容：企業(yè)數(shù)字化轉(zhuǎn)型進(jìn)入深水區(qū)的挑戰(zhàn)、OceanBase 如何助力企業(yè)應(yīng)對挑戰(zhàn)以及如何用產(chǎn)品助力客戶真正解決實(shí)踐中的問題。我想通過今天的演講，從產(chǎn)品角度向大家分享 OceanBase 過去幾年在核心系統(tǒng)升級的賽道上，我的感受以及 OceanBase 為了在核心系統(tǒng)升級深水區(qū)，幫助客戶走得更快、更遠(yuǎn)所做的一些工作。

分享伊始，我先給大家介紹一下核心系統(tǒng)升級進(jìn)入深水區(qū)階段后，企業(yè)所面臨的一些挑戰(zhàn)，關(guān)于這部分的內(nèi)容我想首先分享一下賽迪顧問《2023 核心數(shù)據(jù)庫升級選型參考》報(bào)告的幾個信息。

今年上半年，賽迪顧問對 160 家企業(yè)做了深入訪談，在訪談里面有幾個結(jié)論可以分享。第一，目前中國企業(yè)當(dāng)前部署的數(shù)據(jù)庫產(chǎn)品中，OceanBase在中國本土數(shù)據(jù)庫品牌中排名第一；第二，在核心系統(tǒng)升級領(lǐng)域，被調(diào)研企業(yè)客戶闡明了自己所關(guān)注的一些場景，比如穩(wěn)定性、兼容性以及代碼的自主可控等，基于大家所關(guān)注的幾個核心因素，賽迪顧問對市場上一些數(shù)據(jù)庫品牌做了匹配，OceanBase 以 36.5 最高分的匹配度，在未來核心系統(tǒng)升級選型中排名第一；第三，通過采訪這些企業(yè)“未來數(shù)據(jù)庫選型的時(shí)候考慮什么樣的品牌”，OceanBase在未來數(shù)據(jù)庫部署產(chǎn)品預(yù)期中排名第一。

OceanBase 為什么能在核心系統(tǒng)選型場景下成為客戶首選？我們誕生于核心系統(tǒng)場景，2014 年，OceanBase 開始應(yīng)用于支付寶核心交易庫，這種大規(guī)模金融場景對高并發(fā)和高可用要求非常高，可以說 OceanBase 是從非常嚴(yán)苛的場景起步，然后一步步走到外圍。

眾多領(lǐng)域的客戶正在選擇把 OceanBase 應(yīng)用于核心系統(tǒng)，我們總結(jié)了一下他們在使用 OceanBase 過程中的幾條技術(shù)路線，特別是在核心系統(tǒng)的升級場景里。

路線 1：應(yīng)用不動，Oracle 平滑遷移

“應(yīng)用不動，Oracle 平滑遷移”的升級路線是數(shù)據(jù)庫平滑升級最具代表性的一種方式。以某大型保險(xiǎn)集團(tuán)為例，該集團(tuán)用短短一年的時(shí)間，把 300 多套 Oracle 數(shù)據(jù)庫全部升級到了 OceanBase，在一年多的升級過程中，幾乎每周都有新系統(tǒng)在上線，我們非常敬佩客戶的技術(shù)團(tuán)隊(duì)，和我們一起完成了幾乎不可能完成的任務(wù)。在這個過程中，得力于 OceanBase 平滑遷移、兼容 Oracle 等能力，我們很好地保護(hù)了企業(yè)既有軟件投資，比如原有數(shù)千萬行業(yè)務(wù)應(yīng)用系統(tǒng)的代碼幾乎沒有做改造，這種替換比起同時(shí)改應(yīng)用、同時(shí)改數(shù)據(jù)庫這樣的方式更加穩(wěn)妥、更加可控，這也是該案例之所以能夠快速完成的一個關(guān)鍵因素。

路線2：DB2 遷移到 Oracle 兼容，微改動實(shí)現(xiàn)“單核異構(gòu)”

“DB2 遷移到 Oracle 兼容，微改動實(shí)現(xiàn)單核異構(gòu)”的路線是針對使用 DB2 的一些中小銀行為代表的客戶所推出的。市場上提供 DB2 平滑升級的產(chǎn)品不多，而Oracle與 DB2 這樣的商業(yè)數(shù)據(jù)庫能力是互相匹配的，比起開源數(shù)據(jù)庫它們的能力也強(qiáng)很多，所以在 OceanBase 之前，很多客戶會把 DB2 替換成 Oracle，當(dāng)OceanBase 具備了 Oracle 兼容能力以后，以常熟農(nóng)商銀行為代表的客戶，他們把 DB2 小機(jī)應(yīng)用做微小的改動，基本所有的能力都能在 OceanBase 的 Oracle 兼容性能力里找到對應(yīng)的功能去替換。而且 DB2 有一個 Oracle 兼容的功能，模式打開以后會使得這個替換更加平滑。

在升級之后，OceanBase 實(shí)現(xiàn)了和 DB2 雙向長期的同步和過渡，所以 DB2 還可以作為一個備庫進(jìn)行長時(shí)間的運(yùn)行。同時(shí)，OceanBase 可以在同一個庫里去支持不同的 CPU，也可以同時(shí)支持國產(chǎn)化硬件，我們稱之為“一庫多芯”。

路線3：云 + OceanBase + 單元化

“云 + OceanBase + 單元化”的第三條路線，適用于企業(yè)期望在做核心系統(tǒng)升級的同時(shí)，愿意對整個應(yīng)用做比較大的單元化改造場景。如果企業(yè)愿意投入重新寫應(yīng)用的成本，單元化的改造會大大降低應(yīng)用的故障率，對于整個應(yīng)用的高可用能力也會有質(zhì)的提升，在數(shù)據(jù)庫領(lǐng)域之外，實(shí)現(xiàn)綜合效益的提升。

以某國有大型銀行貸記卡項(xiàng)目為例，通過把原來整個 DB2 大機(jī)的應(yīng)用切換到 OceanBase 之上，然后在 OceanBase 里創(chuàng)建 100 多個租戶，單個租戶是獨(dú)立的單元，應(yīng)用也一樣進(jìn)行切分成多個單元，整體減少故障率。但是這種演進(jìn)方式下，由于它是 DB2 的大機(jī)，所以無法做平滑升級，但在此過程中，該銀行得到了單元化的收益，OceanBase 在這個過程里，進(jìn)一步支撐了該銀行在數(shù)據(jù)庫層面應(yīng)該有的能力。

路線4：MySQL 平滑遷移

“MySQL 平滑遷移”的路線適用于以互聯(lián)網(wǎng)、新零售為代表的企業(yè)。這些企業(yè)的核心系統(tǒng)切換到 OceanBase 之上，其主要看中的功能是“集約化降本”能力。以 GCash 為例，原來使用的是 240 多套的 MySQL 數(shù)據(jù)庫，遷移到 OceanBase 以后，使用 OceanBase 的 16 個集群就可以承接原來 DBA 要維護(hù)的 200 多套數(shù)據(jù)庫，現(xiàn)在只需要維護(hù) 16 套，大大簡化了運(yùn)維工作。與此同時(shí)，遷移之前，GCash 的數(shù)據(jù)有 5TB，遷移到 OceanBase 之后僅 500GB，數(shù)據(jù)量降至原來的 1/10，總體成本也降低了 35%。我們做了一個測算，企業(yè)如果 MySQL 規(guī)模在 32 核以上，切換到 OceanBase 之后都會有超過 30% 的成本節(jié)約。

在當(dāng)前的市場背景下，不論是大型企業(yè)還是中小型企業(yè)，包括今天談的中小型銀行，現(xiàn)在都已經(jīng)逐步進(jìn)入到數(shù)字化轉(zhuǎn)型深水區(qū)。我們和很多的客戶進(jìn)行了溝通，深水區(qū)基本上都要經(jīng)過三個階段：

第一階段是邊緣業(yè)務(wù)試點(diǎn)應(yīng)用；第二階段會找一個核心但不是最核心的業(yè)務(wù)去做替換升級，從簡單的邊緣業(yè)務(wù)到稍微復(fù)雜的；如果第二個階段順利，第三階段即希望做規(guī)模化推廣，這個階段無論是小企業(yè)、中小型機(jī)構(gòu)還是大型機(jī)構(gòu)都會面臨幾個問題：

第一， 從邊緣系統(tǒng)進(jìn)入核心系統(tǒng)，會發(fā)現(xiàn)這二者所要求的數(shù)據(jù)庫能力是不一樣的，核心系統(tǒng)往往會要求數(shù)據(jù)庫分析性能力比較強(qiáng)，不能只是單一 KV 型的訪問。

第二， 進(jìn)入大規(guī)模復(fù)制階段以后，中小型企業(yè)會比較在意總體成本，大型機(jī)構(gòu)雖然對成本不會特別敏感，但是也會關(guān)注快速復(fù)制過程中是否迅速，以及在此過程中最關(guān)鍵的性能、穩(wěn)定性這方面，是否有確定性的可控收益。

在過去一年當(dāng)中，OceanBase 的很多客戶已經(jīng)進(jìn)入到第三階段，為了滿足這些客戶的需求，我們在兩方面做了持續(xù)、深入的產(chǎn)品迭代，它們也是 OceanBase 產(chǎn)品兩個關(guān)鍵的演進(jìn)方向。

方向1：更兼容

• 不斷完善兼容性，持續(xù)降低應(yīng)用改造代價(jià)

回到 OceanBase 產(chǎn)品的具體特性，OceanBase 在同一個集群里面同時(shí)支撐 MySQL 和 Oracle 兩種兼容能力。到目前這個階段，OceanBase 已經(jīng)不是三年前了，在功能兼容性迭代的方向上，已經(jīng)開始深入細(xì)節(jié)，做了很多大家可能不怎么關(guān)注得到的特性。比如，在 MySQL、Oracle 兼容性方面都同時(shí)支持了 GB18030-2022，這是國家最新的強(qiáng)制標(biāo)準(zhǔn)，OceanBase 比 Oracle 更早做出了在 Oracle 兼容能力下的 2022 標(biāo)準(zhǔn)。

與此同時(shí)，OceanBase 4.0 有一個比較大的突破——可以支持更多的 DDL。到目前為止，可以說所有的 DDL 類型，OceanBase 都可以去支持，這個得益于我們OFFLINE DDL 框架能力，完整支持全量 DDL。以前 DBA 如果把組件建錯了，只能采取「重新導(dǎo)數(shù)據(jù)」的方式，而現(xiàn)在一個 DDL 就可以輕松將表結(jié)構(gòu)的分區(qū)鍵做比較大的調(diào)整。

未來，OceanBase 也將會在 MySQL 兼容能力方面持續(xù)迭代，做更好的 MySQL。以這里面的特性為例，客戶在選擇用什么樣的兼容模式的時(shí)候，使用 OceanBase 是比較自由的。有些客戶喜歡 MySQL 兼容模式，那也沒有問題，我們會把一些 Oracle 模式下和 OceanBase 這么多年迭代的能力同時(shí)在 MySQL 下提供，所以可以把它理解為是「更好的 MySQL」。比如在 MySQL 模式下支持了 DBLink 能力，使用 Oracle 的很多用戶都了解 DBLink，但現(xiàn)在 OceanBase 在 MySQL 模式下，也已經(jīng)提供了這個能力。

另一方面，類似像 SQL 執(zhí)行計(jì)劃的管理，我們叫 SPM 能力，也在 MySQL 模式進(jìn)行提供。OceanBase 之前做的很多性能的視圖，現(xiàn)在全部在 MySQL 下面提供，包括其他更多的能力都會在兩個模式下同時(shí)提供，對我們來說這件事情很自然，做這件事的目的是讓進(jìn)入深水區(qū)之后的客戶，都可以完成應(yīng)用的平滑遷移。當(dāng)越來越多應(yīng)用遷移上來的時(shí)候，就不需要每一個應(yīng)用都做那么深入的適配和改造，做一個還可以，做多了就會很困難。

• 核心系統(tǒng)要求交易數(shù)據(jù)庫兼具復(fù)雜分析能力

為什么把上面的問題看作是兼容性的問題？比如很多的語法在一個開源數(shù)據(jù)庫上做語法兼容是比較容易的，但真正做核心系統(tǒng)替換的時(shí)候，會發(fā)現(xiàn)換上去以后招數(shù)都有了，但是內(nèi)力不足，這里的關(guān)鍵就是以 Oracle 為代表的這樣一些數(shù)據(jù)庫或者 DB2，早期并不會區(qū)分什么是 TP、什么是 AP，所以在這些數(shù)據(jù)庫上搭建起來的應(yīng)用，在核心系統(tǒng)層面都要求兼具 TP 和 AP 的能力。

OceanBase 從 4.0 版本開始，AP 能力較之前 3.0 版本有了極大的提升，展示幾個數(shù)據(jù)：以 TPC-DS 為代表的復(fù)雜分析性能提升 3.4 倍、以 TPC-H 為代表的性能提升了 6 倍，在 AP 場景、核心系統(tǒng)場景里的導(dǎo)入性能也提升了 6 倍。

此外，OceanBase 在 MySQL 和 Oracle 兩種模式下，都提供了很好的數(shù)據(jù)集成能力。數(shù)據(jù)集成有兩種方式：第一種是在引擎里查詢另外一個數(shù)據(jù)庫，即 DBLink 的能力；第二種如果查詢一個文件的數(shù)據(jù)，即外表的能力，以此快速集成外部數(shù)據(jù)，這些能力 OceanBase 在新版本全面支持。

在 TP 和 AP 混合負(fù)載的隔離能力方面，新版本有兩方面提升：第一資源隔離能力增強(qiáng)（cgroup + CPU/MEM/IOPS...），第二資源隔離粒度變細(xì)（基于 SQL 語句）。?

如果在同一個數(shù)據(jù)庫里可以識別出來一些應(yīng)用，那么它就是跑批的；另外一些是交互式的，可以給這些跑批的應(yīng)用設(shè)置專門的資源隔離組，我們稱之為資源組能力，OceanBase不光可以將資源組以用戶作區(qū)分，最新的版本里還支持綁定特定 SQL，利用這些 SQL 去限定 CPU 和 IOPS 的上限。可以說 OceanBase 在混合負(fù)載方面做了非常多的工作，去應(yīng)對核心系統(tǒng)的諸多挑戰(zhàn)。

• 持續(xù)完善遷移方案，從數(shù)據(jù)遷移到架構(gòu)融合

關(guān)于產(chǎn)品內(nèi)核功能方面的增強(qiáng)，實(shí)踐者大概 50% 的時(shí)間都會關(guān)注同一個問題：在數(shù)據(jù)庫升級過程中，怎么才能夠平滑完成遷移？OceanBase 打磨了 10 余年的核心場景，所有的功能都體現(xiàn)在產(chǎn)品和服務(wù)里，在眾多客戶場景和實(shí)踐中，OceanBase 沉淀出了一整套方法。

客戶在做數(shù)據(jù)遷移之前，即使沒有引入 OceanBase，也可以利用 OceanBase 遷移評估工具 OMA 在自己的環(huán)境里面跑一下，就可以拿到一個完整的評估報(bào)告。包括兼容度是多少、哪些 SQL 需要重寫、智能化診斷建議等，包括什么表要去做分區(qū)？怎么做效果最好？這類問題的診斷建議，在第一個不需要引入 OceanBase 的階段就可以完成評估。

當(dāng)客戶進(jìn)入平滑遷移階段時(shí)，OceanBase 數(shù)據(jù)遷移工具 OMS 可以幫您專門從舊的系統(tǒng)往新的系統(tǒng)遷移，當(dāng)前OceanBase已經(jīng)支持Oracle、MySQL、PostgreSQL、DB2、HBase 等數(shù)據(jù)庫遷往 OceanBase。例如上文提到的某保險(xiǎn)集團(tuán)就利用 OMS 完成了 300 多個系統(tǒng)、好幾百 T 數(shù)據(jù)的遷移，可以說 OMS 的遷移能力是久經(jīng)考驗(yàn)的。

運(yùn)行起來以后，一旦完成了應(yīng)用的切換，OMS 會創(chuàng)建一條往原有數(shù)據(jù)庫回遷的鏈路，這樣一來兩個系統(tǒng)可以并跑比較長的時(shí)間。如果是核心系統(tǒng)，一般作為中間數(shù)據(jù)的節(jié)點(diǎn)，它還要把它的數(shù)據(jù)往下游“吐”，所以 OMS 也支持?jǐn)?shù)據(jù)訂閱的功能。

目前來說 OceanBase 支持 ADB、Hologres 、MaxCompute 等云上服務(wù)的訂閱，并且已經(jīng)集成到內(nèi)部了，還可以通過 Kafka 自己寫程序、從 Kafka 上訂閱消息同步到下游的數(shù)倉。不同于 Oracle，對于 MySQL 用戶來說，MySQL的生態(tài)非常豐富，所以 OceanBase不再為每一個下游產(chǎn)品去做專門的對接，由于 OceanBase 原生的支持了 MySQL 的 Binlog 的服務(wù)，這樣一來，所有為 MySQL 的數(shù)據(jù)訂閱同步所做的那些工具，都可以無縫和 OceanBase 的 Binlog 相集成，這也是我們?nèi)谌?MySQL 生態(tài)的一個動作。

方向2：更穩(wěn)定

穩(wěn)定可靠總是用戶最關(guān)心的方面，過去一年，OceanBase 在強(qiáng)化穩(wěn)定性方面做了很多的事情，比如，我們不再簡單講 RTO、RPO 這樣的概念，而是進(jìn)一步強(qiáng)調(diào)在更多嚴(yán)苛場景下，如何保證數(shù)據(jù)庫、應(yīng)用的連續(xù)性。說起來很簡單，但是技術(shù)上每一個點(diǎn)都需要實(shí)際的去打磨。

• 強(qiáng)化穩(wěn)定性，滿足更嚴(yán)苛條件下的業(yè)務(wù)連續(xù)性

首先，4.0 版本再造“ RPO=0, RTO＜8s”新標(biāo)準(zhǔn)。RTO 從 30 秒降到 8 秒，這個過程涉及到很多細(xì)節(jié)的改動，比如現(xiàn)在是通過在整個集群內(nèi)部廣播節(jié)點(diǎn)宕機(jī)事件，替代以前的輪循方式，通過廣播可以及時(shí)告知前端的應(yīng)用“這個數(shù)據(jù)庫的主發(fā)生了切換”，類似這樣一些工作是非常細(xì)致的。

第二，跨城部署，實(shí)現(xiàn)網(wǎng)絡(luò)帶寬大幅下降。對于支付寶這類非常嚴(yán)苛的金融場景，我作為支付寶“去O”全過程的親歷者，當(dāng)時(shí)其實(shí)不怎么擔(dān)心網(wǎng)絡(luò)帶寬，但是在很多外部客戶場景中，帶寬不是天經(jīng)地義就是非常充足的，特別是跨城的網(wǎng)絡(luò)帶寬。OceanBase 過去兩三年一直在做這件事，一方面，OceanBase 4.0 跨副本之間的網(wǎng)絡(luò)帶寬下降了 30%-40%，以 TPC-C 的負(fù)載為例，其存儲的帶寬降低了 30%。

第三，豐富的靈活的容災(zāi)模式和更全面的安全加固。關(guān)于穩(wěn)定可靠，我還是想談 Paxos，雖然這是一個老生常談的話題，但是這次還是想強(qiáng)調(diào)一下，Paxos 的三副本高可用其實(shí)還有一個額外的收益——對抖動的容忍性。我們一般講高可用的時(shí)候一定要討論「故障類型」，如果是簡單的機(jī)房級故障、斷網(wǎng)、光線挖掉，這其實(shí)對于分布式系統(tǒng)來說是容易處理的故障類型，即對于系統(tǒng)設(shè)計(jì)者來說是非常“干凈”的故障，因?yàn)樵诂F(xiàn)實(shí)生活中，常見的故障是網(wǎng)絡(luò)的抖動，當(dāng)你觀察的時(shí)候它已經(jīng)停掉了，對于網(wǎng)絡(luò)抖動故障，只有 OceanBase 這樣基于 Paxos 多副本高可用的協(xié)議才能容忍這樣的抖動。

• 仲裁服務(wù)：自動選主提升同城自動容災(zāi)能力

4.0 版本發(fā)布以來，我們都在談新版本比較重要的升級特性——仲裁服務(wù)，借這個場合給大家分享一下怎么把這個功能用起來。OceanBase 認(rèn)為有兩個典型的場景，使得我們系統(tǒng)更加穩(wěn)定。

上圖最左邊的部署場景，即原來主備庫的部署模式，在該模式下，主備庫存了兩份數(shù)據(jù)，計(jì)算也是兩份，所以要布兩份的機(jī)器資源，然后主庫、備庫之間的網(wǎng)絡(luò)帶寬是一份，所有的事務(wù)寫入要存一份數(shù)據(jù)，此時(shí)如果發(fā)生故障，會導(dǎo)致數(shù)據(jù)丟失，即 RPO＞0。

OceanBase 通過三節(jié)點(diǎn)的高可用能力提升了該部署場景下的容災(zāi)能力，OceanBase 以前的版本稱其為日志型副本，通過在三個節(jié)點(diǎn)之間做多數(shù)派的投票，相比之前的主備最大的好處是當(dāng)少數(shù)派發(fā)生故障的時(shí)候，數(shù)據(jù)不會丟失。這里的“丟失”不是大家以為的，這個事務(wù)還沒有提交，丟掉就丟掉，而是告訴已經(jīng)應(yīng)用成功寫進(jìn)去的數(shù)據(jù)還是會丟，即在主備模式下還是會丟。OceanBase 在原來的版本里面有一個獨(dú)創(chuàng)的設(shè)計(jì)，雖然日志存了三份，但是數(shù)據(jù)只需要存兩份，就是中間的這個模式。

但是這個模式還有一個問題，大家仔細(xì)看，數(shù)據(jù)本身在網(wǎng)絡(luò)的帶寬上還是要占兩份，網(wǎng)絡(luò)帶寬是有限的場景，帶寬大了可能就會影響穩(wěn)定性。

基于這樣的問題我們引入了一個仲裁的服務(wù)，仲裁服務(wù)大家可以看作它還是圖中綠色的日志副本的升級版，當(dāng)事務(wù)提交的時(shí)候，OceanBase 不會把事務(wù)日志寫到仲裁服務(wù)上，這意味著數(shù)據(jù)不會同步至仲裁副本。但 Paxos 的日志會同步到仲裁副本，仲裁服務(wù)會參與 Paxos 的分布式選舉，這樣可以在確保 RPO = 0 的數(shù)據(jù)強(qiáng)一致性前提下，通過仲裁副本實(shí)現(xiàn)更低的高可用成本，即在主和從之間只有一份帶寬，這件事并不僅是經(jīng)濟(jì)的問題，而是影響穩(wěn)定性。

• 仲裁服務(wù)：降低跨城帶寬提升兩地三中心穩(wěn)定性

與此同時(shí)，仲裁服務(wù)還能通過降低跨城帶寬提升兩地三中心的穩(wěn)定性。

將主備模式和仲裁模式進(jìn)行比較：上圖最左邊就是傳統(tǒng)兩地三中心的部署，在這種部署場景下，當(dāng)主城市發(fā)生故障的時(shí)候，備城市的備數(shù)據(jù)庫被啟用之后它會丟數(shù)據(jù)，且丟多少數(shù)據(jù)是未知的，這是一個痛點(diǎn)。

當(dāng) OceanBase 引入兩地三中心五副本解決方案后，主 IDC 宕機(jī)時(shí)，備 IDC 會自動啟用，且之后不需要再訂正數(shù)據(jù)，也不會丟數(shù)據(jù)；但是當(dāng)主 IDC 宕機(jī)的時(shí)候，剩下的三個副本加上異地副本，它會變成一個多數(shù)派，這時(shí)候雖然可以保證業(yè)務(wù)的連續(xù)性，但是會引起降級，因?yàn)榇藭r(shí)每一筆數(shù)據(jù)的寫入都需要走到備城市，這個問題也會影響穩(wěn)定性。

而當(dāng)我們引入仲裁服務(wù)后，OceanBase 會把異地的副本變成仲裁的節(jié)點(diǎn)，基于這樣的設(shè)計(jì)，當(dāng)主城市的 IDC 宕機(jī)以后，第二個 IDC 會在仲裁副本的參與下，將整個數(shù)據(jù)庫副本數(shù)由五副本降成三副本，從而達(dá)到快速恢復(fù)并且性能不下降的效果。

（一）豐富的可管理手段，保證核心系統(tǒng)業(yè)務(wù)持續(xù)可用

除了上面談到的幾個特性，下面我們來談?wù)剬τ?DBA 很關(guān)心的點(diǎn)——OceanBase 作為數(shù)據(jù)庫產(chǎn)品提供了哪些可管理的手段，助力客戶真正去解決實(shí)踐中遇到的問題。

第一，計(jì)劃運(yùn)維操作。比如擴(kuò)容縮容、滾動升級，一個機(jī)器有故障，OceanBase可以利用運(yùn)維管理工具 OCP 一鍵替換，這類運(yùn)維能力 OceanBase 很早就已經(jīng)具備。

第二，故障自動處理。在 OceanBase 做分布式數(shù)據(jù)庫之前，DBA 經(jīng)常需要在晚上臨時(shí)進(jìn)行故障處理，比如主備庫宕機(jī)以后，DBA 需要連夜進(jìn)行處理，甚至要求在 10 分鐘之內(nèi)就得進(jìn)行處理。在 OceanBase 有自動容災(zāi)處理功能以后，絕大多數(shù)故障場景下解放了 DBA，另外一些少數(shù)派的宕機(jī)，系統(tǒng)在 8 秒鐘之內(nèi)就可以自動恢復(fù)，不需要 DBA 做任何的介入。由此可見，分布式技術(shù)的引入大大提升了分布式的容災(zāi)處理能力。

相對于分庫分表+分布式事務(wù)能力的數(shù)據(jù)庫，OceanBase 原生分布式數(shù)據(jù)庫有什么不同？舉個例子：眾所周知兩階段提交有個問題，當(dāng)協(xié)調(diào)者故障的時(shí)候，分布式事務(wù)會被夯住，無法向前繼續(xù)推進(jìn)，這是協(xié)議層面定義的動作。但是 OceanBase 從一開始就解決了這個問題，因?yàn)?OceanBase 的參與者是高可用的，也就是說參與者不會丟掉自己的狀態(tài)，因?yàn)?OceanBase 有三副本，所以在兩階段提交時(shí)少了一個階段，OceanBase 利用這個特性提升了性能，并且解決了兩階段提交會產(chǎn)生懸掛事務(wù)的問題，這也使得在系統(tǒng)內(nèi)部，DBA 要解決的異常較原來變少。

第三，應(yīng)急處理。OceanBase 內(nèi)置了很多應(yīng)急處理操作。這個操作需要從數(shù)據(jù)庫內(nèi)核的角度進(jìn)行人工發(fā)起，比如切主、SQL 限流，你可以限制單條 SQL 的 QPS 不超過多少，這些能力都是內(nèi)核提供的。基于這些能力還是依賴于 DBA 的經(jīng)驗(yàn)，什么時(shí)候做應(yīng)急以及應(yīng)急時(shí)的判斷能力，由此 OceanBase 推出了一個新的產(chǎn)品工具——數(shù)據(jù)庫自治服務(wù) OAS，我們把過去在眾多核心系統(tǒng)升級過程中的經(jīng)驗(yàn)沉淀到了這個新產(chǎn)品里。

（二）數(shù)據(jù)庫自治服務(wù) OAS，為核心系統(tǒng)穩(wěn)定性保駕護(hù)航

OAS 是 OceanBase 數(shù)據(jù)庫提供的自治服務(wù)，其依賴于對數(shù)據(jù)的采集和分析以及對專家能力的沉淀。通過眾多客戶的核心系統(tǒng)場景打磨，OceanBase 將 DBA、客戶在各種場景下面遇到的問題整理成文檔，再沉淀到產(chǎn)品里。目前 OceanBase 產(chǎn)品有兩個形態(tài)：

其一， 如果有些客戶在使用運(yùn)維管理工具 OCP 最新版，最新版本里面有一個診斷中心，可以看到對應(yīng)資源管理、監(jiān)控告警、備份恢復(fù)、會話診斷等功能已經(jīng)進(jìn)行了更新；其二，對于使用 OCP 老版本的客戶，也無需因?yàn)橄胧褂眯绿匦匀ド壈姹?#xff0c;OceanBase 針對這批用戶提供了獨(dú)立的產(chǎn)品包來體驗(yàn)這些特性。

在內(nèi)部，OCP 會去監(jiān)測一些異常的事件和規(guī)則，當(dāng)發(fā)現(xiàn)異常事件和規(guī)則時(shí)，就會觸發(fā)剛才說到的運(yùn)維應(yīng)急動作，并去做一些自愈的操作。與此同時(shí)，OceanBase在容量規(guī)劃、實(shí)時(shí)的 SQL 診斷等方面也沉淀了很多新功能。

最后，“熱愛可抵歲月漫長”是我們創(chuàng)始人陽老師非常喜歡的一句座右銘，我自己對這句話也非常有感觸。13 年來，我們從一個非常小的內(nèi)部項(xiàng)目做起，我們懷揣著非常樸素的理念，希望用技術(shù)讓海量數(shù)據(jù)的管理和使用更簡單。在上千家客戶的幫助和支持下，OceanBase 從 1.x 到 4.x，從原生分布式到單機(jī)分布式一體化持續(xù)演進(jìn)。未來，我們希望和更多的客戶一起為關(guān)鍵業(yè)務(wù)負(fù)載打造真正實(shí)用、好用的產(chǎn)品，為核心系統(tǒng)升級打造堅(jiān)實(shí)的數(shù)據(jù)庫底座。

給大家分享一個小故事，OceanBase 在做 1.0 分布式版本的階段，即使當(dāng)時(shí)有很多業(yè)務(wù)在進(jìn)行中，但在創(chuàng)始人陽老師的堅(jiān)持下，我們整個項(xiàng)目團(tuán)隊(duì)仍然選擇了停下來，花了一個多月時(shí)間把所有的代碼重構(gòu)了一遍，就是為了去檢查所有 C++ 代碼的返回值?，F(xiàn)在 OceanBase 的代碼是開源的，大家可以看一下 OceanBase 代碼，如果您看到我們的代碼里某一個返回值沒有檢查，都可以給我們提 BUG。這是 OceanBase 想走得更遠(yuǎn)、走得更長的責(zé)任，也是對客戶的責(zé)任。謝謝大家！? ??