1??OceanBase 整體架構(gòu)

OceanBase 數(shù)據(jù)庫采用 Shared-Nothing 架構(gòu)，各個節(jié)點(diǎn)之間完全對等，每個節(jié)點(diǎn)都有自己的 SQL 引擎、存儲引擎、事務(wù)引擎，運(yùn)行在普通 PC 服務(wù)器組成的集群之上，具備高可擴(kuò)展性、高可用性、高性能、低成本、與主流數(shù)據(jù)庫高兼容等核心特性。

1.1 分區(qū)

OceanBase 數(shù)據(jù)庫的一個集群由若干個節(jié)點(diǎn)組成。這些節(jié)點(diǎn)分屬于若干個可用區(qū)（Zone），每個節(jié)點(diǎn)屬于一個可用區(qū)?？捎脜^(qū)是一個邏輯概念，表示集群內(nèi)具有相似硬件可用性的一組節(jié)點(diǎn)，它在不同的部署模式下代表不同的含義。例如，當(dāng)整個集群部署在同一個數(shù)據(jù)中心（IDC）內(nèi)的時(shí)候，一個可用區(qū)的節(jié)點(diǎn)可以屬于同一個機(jī)架，同一個交換機(jī)等。當(dāng)集群分布在多個數(shù)據(jù)中心的時(shí)候，每個可用區(qū)可以對應(yīng)于一個數(shù)據(jù)中心。每個可用區(qū)具有 IDC 和地域（Region）兩個屬性，描述該可用區(qū)所在的 IDC 及 IDC 所屬的地域。一般地，地域指 IDC 所在的城市。可用區(qū)的 IDC 和 Region 屬性需要反映部署時(shí)候的實(shí)際情況，以便集群內(nèi)的自動容災(zāi)處理和優(yōu)化策略能更好地工作。根據(jù)業(yè)務(wù)對數(shù)據(jù)庫系統(tǒng)不同的高可用性需求，OceanBase 集群提供了多種部署模式。

1.2 分片

在 OceanBase 數(shù)據(jù)庫中，一個表的數(shù)據(jù)可以按照某種劃分規(guī)則水平拆分為多個分片，每個分片叫做一個表分區(qū)，簡稱分區(qū)（Partition）。某行數(shù)據(jù)屬于且只屬于一個分區(qū)。分區(qū)的規(guī)則由用戶在建表的時(shí)候指定，包括hash、range、list等類型的分區(qū)，還支持二級分區(qū)。例如，交易庫中的訂單表，可以先按照用戶 ID 劃分為若干一級分區(qū)，再按照月份把每個一級分區(qū)劃分為若干二級分區(qū)。對于二級分區(qū)表，第二級的每個子分區(qū)是一個物理分區(qū)，而第一級分區(qū)只是邏輯概念。一個表的若干個分區(qū)可以分布在一個可用區(qū)內(nèi)的多個節(jié)點(diǎn)上。每個物理分區(qū)有一個用于存儲數(shù)據(jù)的存儲層對象，叫做 Tablet，用于存儲有序的數(shù)據(jù)記錄。

1.3 日志流

當(dāng)用戶對 Tablet 中記錄進(jìn)行修改的時(shí)候，為了保證數(shù)據(jù)持久化，需要記錄重做日志（REDO）到 Tablet 對應(yīng)的日志流（Log Stream）里。每個日志流服務(wù)了其所在節(jié)點(diǎn)上的多個 Tablet。為了能夠保護(hù)數(shù)據(jù)，并在節(jié)點(diǎn)發(fā)生故障的時(shí)候不中斷服務(wù)，每個日志流及其所屬的 Tablet 有多個副本。一般來說，多個副本分散在多個不同的可用區(qū)里。多個副本中有且只有一個副本接受修改操作，叫做主副本（Leader），其他副本叫做從副本（Follower）。主從副本之間通過基于 Multi-Paxos 的分布式共識協(xié)議實(shí)現(xiàn)了副本之間數(shù)據(jù)的一致性。當(dāng)主副本所在節(jié)點(diǎn)發(fā)生故障的時(shí)候，一個從副本會被選舉為新的主副本并繼續(xù)提供服務(wù)。

1.4 對等節(jié)點(diǎn)

在集群的每個節(jié)點(diǎn)上會運(yùn)行一個叫做 observer 的服務(wù)進(jìn)程，它內(nèi)部包含多個操作系統(tǒng)線程。節(jié)點(diǎn)的功能都是對等的。每個服務(wù)負(fù)責(zé)自己所在節(jié)點(diǎn)上分區(qū)數(shù)據(jù)的存取，也負(fù)責(zé)路由到本機(jī)的 SQL 語句的解析和執(zhí)行。這些服務(wù)進(jìn)程之間通過 TCP/IP 協(xié)議進(jìn)行通信。同時(shí)，每個服務(wù)會監(jiān)聽來自外部應(yīng)用的連接請求，建立連接和數(shù)據(jù)庫會話，并提供數(shù)據(jù)庫服務(wù)。

1.5 多租戶

為了簡化大規(guī)模部署多個業(yè)務(wù)數(shù)據(jù)庫的管理并降低資源成本，OceanBase 數(shù)據(jù)庫提供了獨(dú)特的多租戶特性。在一個 OceanBase 集群內(nèi)，可以創(chuàng)建很多個互相之間隔離的數(shù)據(jù)庫"實(shí)例"，叫做一個租戶。從應(yīng)用程序的視角來看，每個租戶等同于一個獨(dú)立的數(shù)據(jù)庫實(shí)例。不僅如此，每個租戶可以選擇 MySQL 或 Oracle 兼容模式。應(yīng)用連接到 MySQL 租戶后，可以在租戶下創(chuàng)建用戶、database，與一個獨(dú)立的 MySQL 庫的使用體驗(yàn)是一樣的。同樣的，應(yīng)用連接到 Oracle 租戶后，可以在租戶下創(chuàng)建 schema、管理角色等，與一個獨(dú)立的 Oracle 庫的使用體驗(yàn)是一樣的。一個新的集群初始化之后，就會存在一個特殊的名為 sys 的租戶，叫做系統(tǒng)租戶。系統(tǒng)租戶中保存了集群的元數(shù)據(jù)，是一個 MySQL 兼容模式的租戶。

2??OceanBase 架構(gòu)與組件詳解

OceanBase 使用通用服務(wù)器硬件，依賴本地存儲，分布式部署使用的多個服務(wù)器也是對等的，沒有特殊的硬件要求。OceanBase 的分布式數(shù)據(jù)庫處理采用 Shared Nothing 架構(gòu)，數(shù)據(jù)庫內(nèi)的 SQL 執(zhí)行引擎具有分布式執(zhí)行能力。

OceanBase 在服務(wù)器上會運(yùn)行叫做 observer 的單進(jìn)程程序作為數(shù)據(jù)庫的運(yùn)行實(shí)例，使用本地的文件存儲數(shù)據(jù)和事務(wù) Redo 日志。

OceanBase 集群部署需要配置可用區(qū)（Zone），由若干個服務(wù)器組成?？捎脜^(qū)是一個邏輯概念，表示集群內(nèi)具有相似硬件可用性的一組節(jié)點(diǎn)，它在不同的部署模式下代表不同的含義。例如，當(dāng)整個集群部署在同一個數(shù)據(jù)中心（IDC）內(nèi)的時(shí)候，一個可用區(qū)的節(jié)點(diǎn)可以屬于同一個機(jī)架，同一個交換機(jī)等。當(dāng)集群分布在多個數(shù)據(jù)中心的時(shí)候，每個可用區(qū)可以對應(yīng)于一個數(shù)據(jù)中心。

用戶存儲的數(shù)據(jù)在分布式集群內(nèi)部可以存儲多個副本，用于故障容災(zāi)，也可以用于分散讀取壓力。同一個租戶在一個可用區(qū)內(nèi)的數(shù)據(jù)只有一個副本，不同的可用區(qū)可以存儲同一個數(shù)據(jù)的多個副本，副本之間由共識協(xié)議保證數(shù)據(jù)的一致性。

OceanBase 內(nèi)置多租戶特性，每個租戶對于使用者是一個獨(dú)立的數(shù)據(jù)庫，一個租戶能夠在租戶級別設(shè)置租戶的分布式部署方式。租戶之間 CPU、內(nèi)存和 IO 都是隔離的。

OceanBase 的數(shù)據(jù)庫實(shí)例內(nèi)部由不同的組件相互協(xié)作，這些組件從底層向上由存儲層、復(fù)制層、均衡層、事務(wù)層、SQL 層、接入層組成。

2.1 存儲層

存儲層以一張表或者一個分區(qū)為粒度提供數(shù)據(jù)存儲與訪問，每個分區(qū)對應(yīng)一個用于存儲數(shù)據(jù)的Tablet（分片），用戶定義的非分區(qū)表也會對應(yīng)一個 Tablet。

Tablet 的內(nèi)部是分層存儲的結(jié)構(gòu)，總共有 4 層。DML 操作插入、更新、刪除等首先寫入 MemTable，等到 MemTable 達(dá)到一定大小時(shí)轉(zhuǎn)儲到磁盤成為 L0 SSTable。L0 SSTable 個數(shù)達(dá)到閾值后會將多個 L0 SSTable 合并成一個 L1 SSTable。在每天配置的業(yè)務(wù)低峰期，系統(tǒng)會將所有的 MemTable、L0 SSTable 和 L1 SSTable 合并成一個 Major SSTable。

每個 SSTable 內(nèi)部是以 2MB 定長宏塊為基本單位，每個宏塊內(nèi)部由多個不定長微塊組成。

Major SSTable 的微塊會在合并過程中用編碼方式進(jìn)行格式轉(zhuǎn)換，微塊內(nèi)的數(shù)據(jù)會按照列維度分別進(jìn)行列內(nèi)的編碼，編碼規(guī)則包括字典/游程/常量/差值等，每一列壓縮結(jié)束后，還會進(jìn)一步對多列進(jìn)行列間等值/子串等規(guī)則編碼。編碼能對數(shù)據(jù)大幅壓縮，同時(shí)提煉的列內(nèi)特征信息還能進(jìn)一步加速后續(xù)的查詢速度。

在編碼壓縮之后，還可以根據(jù)用戶指定的通用壓縮算法進(jìn)行無損壓縮，進(jìn)一步提升數(shù)據(jù)壓縮率。

2.2 復(fù)制層

復(fù)制層使用日志流（LS、Log Stream）在多副本之間同步狀態(tài)。每個 Tablet 都會對應(yīng)一個確定的日志流，每個日志流對應(yīng)多個 Tablet，DML 操作寫入 Tablet 的數(shù)據(jù)所產(chǎn)生的 Redo 日志會持久化在日志流中。日志流的多個副本會分布在不同的可用區(qū)中，多個副本之間維持了共識算法，選擇其中一個副本作為主副本，其他的副本皆為從副本。Tablet 的 DML 和強(qiáng)一致性查詢只在其對應(yīng)的日志流的主副本上進(jìn)行。

通常情況下，每個租戶在每臺機(jī)器上只會有一個日志流的主副本，可能存在多個其他日志流的從副本。租戶的總?cè)罩玖鱾€數(shù)取決于 Primary Zone 和 Locality 的配置。

日志流使用自研的 Paxos 協(xié)議實(shí)現(xiàn)了將 Redo 日志在本服務(wù)器持久化，同時(shí)通過網(wǎng)絡(luò)發(fā)送給日志流的從副本，從副本在完成各自持久化后應(yīng)答主副本，主副本在確認(rèn)有多數(shù)派副本都持久化成功后確認(rèn)對應(yīng)的 Redo 日志持久化成功。從副本利用 Redo 日志的內(nèi)容實(shí)時(shí)回放，保證自己的狀態(tài)與主副本一致。

日志流的主副本在被選舉成為主后會獲得租約（Lease），正常工作的主副本在租約有效期內(nèi)會不停的通過選舉協(xié)議延長租約期。主副本只會在租約有效時(shí)執(zhí)行主的工作，租約機(jī)制保證了數(shù)據(jù)庫異常處理的能力。

復(fù)制層能夠自動應(yīng)對服務(wù)器故障，保障數(shù)據(jù)庫服務(wù)的持續(xù)可用。如果出現(xiàn)少于半數(shù)的從副本所在服務(wù)器故障，因?yàn)檫€有多于半數(shù)的副本正常工作，數(shù)據(jù)庫的服務(wù)不受影響。如果主副本所在服務(wù)器出現(xiàn)問題，其租約會得不到延續(xù)，待其租約失效后，其他從副本會通過選舉協(xié)議選舉出新的主副本并授予新的租約，之后即可恢復(fù)數(shù)據(jù)庫的服務(wù)。

2.3 均衡層

新建表和新增分區(qū)時(shí)，系統(tǒng)會按照均衡原則選擇合適的日志流創(chuàng)建 Tablet。當(dāng)租戶的屬性發(fā)生變更，新增了機(jī)器資源，或者經(jīng)過長時(shí)間使用后，Tablet 在各臺機(jī)器上不再均衡時(shí)，均衡層通過日志流的分裂和合并操作，并在這個過程中配合日志流副本的移動，讓數(shù)據(jù)和服務(wù)在多個服務(wù)器之間再次均衡。

當(dāng)租戶有擴(kuò)容操作，獲得更多服務(wù)器資源時(shí)，均衡層會將租戶內(nèi)已有的日志流進(jìn)行分裂，并選擇合適數(shù)量的 Tablet 一同分裂到新的日志流中，再將新日志流遷移到新增的服務(wù)器上，以充分利用擴(kuò)容后的資源。當(dāng)租戶有縮容操作時(shí)，均衡層會把需要縮減的服務(wù)器上的日志流遷移到其他服務(wù)器上，并和其他服務(wù)器上已有的日志流進(jìn)行合并，以縮減機(jī)器的資源占用。

當(dāng)數(shù)據(jù)庫長期使用后，隨著持續(xù)創(chuàng)建刪除表，并且寫入更多的數(shù)據(jù)，即使沒有服務(wù)器資源數(shù)量變化，原本均衡的情況可能被破壞。最常見的情況是，當(dāng)用戶刪除了一批表后，刪除的表可能原本聚集在某一些機(jī)器上，刪除后這些機(jī)器上的 Tablet 數(shù)量就變少了，應(yīng)該把其他機(jī)器的 Tablet 均衡一些到這些少的機(jī)器上。均衡層會定期生成均衡計(jì)劃，將 Tablet 多的服務(wù)器上日志流分裂出臨時(shí)日志流并攜帶需要移動的 Tablet，臨時(shí)日志流遷移到目的服務(wù)器后再和目的服務(wù)器上的日志流進(jìn)行合并，以達(dá)成均衡的效果。

2.4 事務(wù)層

事務(wù)層保證了單個日志流和多個日志流DML操作提交的原子性，也保證了并發(fā)事務(wù)之間的多版本隔離能力。

原子性

一個日志流上事務(wù)的修改，即使涉及多個 Tablet，通過日志流的 write-ahead log 可以保證事務(wù)提交的原子性。事務(wù)的修改涉及多個日志流時(shí)，每個日志流會產(chǎn)生并持久化各自的write-ahead log，事務(wù)層通過優(yōu)化的兩階段提交協(xié)議來保證事務(wù)提交的原子性。

當(dāng)涉及到多個日志流的事務(wù)發(fā)起提交時(shí)，事務(wù)會選擇其中一個日志流作為兩階段提交的協(xié)調(diào)者，協(xié)調(diào)者會與事務(wù)修改的所有日志流通信，判斷 write-ahead log 是否持久化，當(dāng)所有日志流都完成持久化后，事務(wù)進(jìn)入提交狀態(tài)，協(xié)調(diào)者會再驅(qū)動所有日志流寫下這個事務(wù)的 Commit 日志，表示事務(wù)最終的提交狀態(tài)。當(dāng)從副本回放或者數(shù)據(jù)庫重啟時(shí)，已經(jīng)完成提交的事務(wù)都會通過 Commit 日志確定各自日志流事務(wù)的狀態(tài)。

宕機(jī)重啟場景下，宕機(jī)前還未完成的事務(wù)，會出現(xiàn)寫完 write-ahead log 但是還沒有Commit 日志的情況，每個日志流的 write-ahead log 都會包含事務(wù)的所有日志流列表，通過此信息可以重新確定哪個日志流是協(xié)調(diào)者并恢復(fù)協(xié)調(diào)者的狀態(tài)，再次推進(jìn)兩階段提交協(xié)議，直到事務(wù)最終的 Commit 或 Abort 狀態(tài)。

隔離性

GTS 服務(wù)是一個租戶內(nèi)產(chǎn)生連續(xù)增長的時(shí)間戳的服務(wù)，其通過多副本保證可用性，底層機(jī)制與上面復(fù)制層所描述的日志流副本同步機(jī)制是一樣的。

每個事務(wù)在提交時(shí)會從 GTS 獲取一個時(shí)間戳作為事務(wù)的提交版本號并持久化在日志流的write-ahead log 中，事務(wù)內(nèi)所有修改的數(shù)據(jù)都以此提交版本號標(biāo)記。

每個語句開始時(shí)（對于 Read Committed 隔離級別）或者每個事務(wù)開始時(shí)（對于Repeatable Read 和 Serializable 隔離級別）會從 GTS 獲取一個時(shí)間戳作為語句或事務(wù)的讀取版本號。在讀取數(shù)據(jù)時(shí)，會跳過事務(wù)版本號比讀取版本號大的數(shù)據(jù)，通過這種方式為讀取操作提供了統(tǒng)一的全局?jǐn)?shù)據(jù)快照。

2.5 SQL 層

SQL 層將用戶的 SQL 請求轉(zhuǎn)化成對一個或多個 Tablet 的數(shù)據(jù)訪問。

SQL 層組件
SQL 層處理一個請求的執(zhí)行流程是：Parser、Resolver、Transformer、Optimizer、Code Generator、Executor。

Parser 負(fù)責(zé)詞法/語法解析，Parser 會將用戶的 SQL 分成一個個的 “Token”，并根據(jù)預(yù)先設(shè)定好的語法規(guī)則解析整個請求，轉(zhuǎn)換成語法樹（Syntax Tree）。

Resolver 負(fù)責(zé)語義解析，將根據(jù)數(shù)據(jù)庫元信息將 SQL 請求中的 Token 翻譯成對應(yīng)的對象（例如庫、表、列、索引等），生成的數(shù)據(jù)結(jié)構(gòu)叫做 Statement Tree。

Transformer 負(fù)責(zé)邏輯改寫，根據(jù)內(nèi)部的規(guī)則或代價(jià)模型，將 SQL 改寫為與之等價(jià)的其他形式，并將其提供給后續(xù)的優(yōu)化器做進(jìn)一步的優(yōu)化。Transformer 的工作方式是在原Statement Tree 上做等價(jià)變換，變換的結(jié)果仍然是一棵 Statement Tree。

Optimizer（優(yōu)化器）為 SQL 請求生成最佳的執(zhí)行計(jì)劃，需要綜合考慮 SQL 請求的語義、對象數(shù)據(jù)特征、對象物理分布等多方面因素，解決訪問路徑選擇、聯(lián)接順序選擇、聯(lián)接算法選擇、分布式計(jì)劃生成等問題，最終生成執(zhí)行計(jì)劃。

Code Generator（代碼生成器）將執(zhí)行計(jì)劃轉(zhuǎn)換為可執(zhí)行的代碼，但是不做任何優(yōu)化選擇。

Executor（執(zhí)行器）啟動 SQL 的執(zhí)行過程。

在標(biāo)準(zhǔn)的 SQL 流程之外，SQL 層還有 Plan Cache 能力，將歷史的執(zhí)行計(jì)劃緩存在內(nèi)存中，后續(xù)的執(zhí)行可以反復(fù)執(zhí)行這個計(jì)劃，避免了重復(fù)查詢優(yōu)化的過程。配合 Fast-parser 模塊，僅使用詞法分析對文本串直接參數(shù)化，獲取參數(shù)化后的文本及常量參數(shù)，讓 SQL 直接命中 Plan Cache，加速頻繁執(zhí)行的 SQL。

2.5 多種計(jì)劃

SQL 層的執(zhí)行計(jì)劃分為本地、遠(yuǎn)程和分布式三種。本地執(zhí)行計(jì)劃只訪問本服務(wù)器的數(shù)據(jù)。遠(yuǎn)程執(zhí)行計(jì)劃只訪問非本地的一臺服務(wù)器的數(shù)據(jù)。分布式計(jì)劃會訪問超過一臺服務(wù)器的數(shù)據(jù)，執(zhí)行計(jì)劃會分成多個子計(jì)劃在多個服務(wù)器上執(zhí)行。

SQL 層并行化執(zhí)行能力可以將執(zhí)行計(jì)劃分解成多個部分，由多個執(zhí)行線程執(zhí)行，通過一定的調(diào)度的方式，實(shí)現(xiàn)執(zhí)行計(jì)劃的并行處理。并行化執(zhí)行可以充分發(fā)揮服務(wù)器 CPU 和 IO 處理能力，縮短單個查詢的響應(yīng)時(shí)間。并行查詢技術(shù)可以用于分布式執(zhí)行計(jì)劃，也可以用于本地執(zhí)行計(jì)劃。

2.6 接入層

OceanBase 數(shù)據(jù)庫代理（OceanBase Database Proxy，ODP）是 OceanBase 數(shù)據(jù)庫的接入層，負(fù)責(zé)將用戶的請求轉(zhuǎn)發(fā)到合適的 OceanBase 實(shí)例上進(jìn)行處理。

ODP 是獨(dú)立的進(jìn)程實(shí)例，獨(dú)立于 OceanBase 的數(shù)據(jù)庫實(shí)例部署。ODP 監(jiān)聽網(wǎng)絡(luò)端口，兼容 MySQL 網(wǎng)絡(luò)協(xié)議，支持使用 MySQL 驅(qū)動的應(yīng)用直接連接 OceanBase。

ODP 能夠自動發(fā)現(xiàn) OceanBase 集群的數(shù)據(jù)分布信息，對于代理的每一條 SQL 語句，會盡可能識別出語句將訪問的數(shù)據(jù)，并將語句直接轉(zhuǎn)發(fā)到數(shù)據(jù)所在服務(wù)器的 OceanBase 實(shí)例。

ODP 有兩種部署方式，一種是部署在每一個需要訪問數(shù)據(jù)庫的應(yīng)用服務(wù)器上，另一種是部署在與 OceanBase 相同的機(jī)器上。第一種部署方式下，應(yīng)用程序直接連接部署在同一臺服務(wù)器上的 obproxy，所有的請求會由 ODP 發(fā)送到合適的 OceanBase 服務(wù)器。第二種部署方式下，需要使用網(wǎng)絡(luò)負(fù)載均衡服務(wù)將多個 ODP 聚合成同一個對應(yīng)用提供服務(wù)的入口地址。

3?? 核心組件與功能概述

基礎(chǔ)架特性

OceanBase 是一個分布式數(shù)據(jù)庫系統(tǒng)，它采用通用服務(wù)器硬件，不依賴特定的高性能硬件。它在本地存儲數(shù)據(jù)，并通過分布式部署在多個對等的服務(wù)器上實(shí)現(xiàn)高可用性和可擴(kuò)展性。OceanBase 遵循 Shared Nothing 架構(gòu)，其 SQL 執(zhí)行引擎具備分布式執(zhí)行能力。

核心組件與功能

1. Observer：

   • OceanBase 在每個服務(wù)器上運(yùn)行一個單進(jìn)程程序，稱為 observer，作為數(shù)據(jù)庫的運(yùn)行實(shí)例。
   • 使用本地文件存儲數(shù)據(jù)和事務(wù) Redo 日志。

2. 集群與可用區(qū)（Zone）：

   • OceanBase 集群由多個服務(wù)器組成，配置為不同的可用區(qū)。
   • 可用區(qū)是邏輯概念，代表集群內(nèi)硬件可用性相似的一組節(jié)點(diǎn)。

3. 數(shù)據(jù)副本與一致性：

   • 用戶數(shù)據(jù)在集群內(nèi)部存儲多個副本，用于故障恢復(fù)和讀取擴(kuò)展。
   • 副本之間通過共識協(xié)議保持?jǐn)?shù)據(jù)一致性。

4. 多租戶特性：

   • OceanBase 內(nèi)置多租戶支持，每個租戶表現(xiàn)為一個獨(dú)立的數(shù)據(jù)庫。
   • 租戶之間在 CPU、內(nèi)存和 IO 方面實(shí)現(xiàn)隔離。

數(shù)據(jù)庫實(shí)例內(nèi)部組件

• 存儲層：以表或分區(qū)為單位提供數(shù)據(jù)存儲與訪問，采用分層存儲結(jié)構(gòu)，包括 MemTable、L0/L1 SSTable 和 Major SSTable，支持?jǐn)?shù)據(jù)壓縮和編碼。

• 復(fù)制層：使用日志流（LS）在多個副本之間同步狀態(tài)，通過 Paxos 協(xié)議保證數(shù)據(jù)一致性，能自動處理服務(wù)器故障。

• 均衡層：負(fù)責(zé)數(shù)據(jù)的均衡分布，通過日志流的分裂、合并和遷移操作，確保數(shù)據(jù)和服務(wù)在多個服務(wù)器之間保持均衡。

• 事務(wù)層：保證 DML 操作的原子性和事務(wù)之間的多版本隔離能力，通過優(yōu)化的兩階段提交協(xié)議和 GTS 服務(wù)實(shí)現(xiàn)。

• SQL 層：將 SQL 請求轉(zhuǎn)化為對 Tablet 的數(shù)據(jù)訪問，包括解析、語義解析、邏輯改寫、優(yōu)化、代碼生成和執(zhí)行等步驟。

• 接入層：通過 OceanBase 數(shù)據(jù)庫代理（ODP）實(shí)現(xiàn)用戶請求的接入和轉(zhuǎn)發(fā)，支持 MySQL 網(wǎng)絡(luò)協(xié)議，能夠自動發(fā)現(xiàn)數(shù)據(jù)分布信息。

結(jié)語

OceanBase 通過其分布式架構(gòu)和核心組件的協(xié)作，提供了高可用、可擴(kuò)展的數(shù)據(jù)庫服務(wù)，適用于需要處理大量數(shù)據(jù)和復(fù)雜事務(wù)的應(yīng)用場景。其多租戶特性和靈活的部署選項(xiàng)進(jìn)一步增強(qiáng)了其作為企業(yè)級數(shù)據(jù)庫解決方案的吸引力。

文章來源地址http://www.zghlxwxcb.cn/news/detail-848649.html

到了這里，關(guān)于深入OceanBase內(nèi)部機(jī)制：系統(tǒng)架構(gòu)與組件精講的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！