在前陣子的DTCC 2023上，華為團(tuán)隊(duì)與萬里開源聯(lián)合發(fā)布了一個(gè)Mysql的共享存儲(chǔ)并發(fā)讀寫的解決方案，其核心技術(shù)就是Cantian引擎。Cantian是一個(gè)能讓普通的單機(jī)數(shù)據(jù)庫變成具有類似Oracle RAC能力數(shù)據(jù)庫的中間件，目前支持innodb，今后將支持更多的數(shù)據(jù)庫存儲(chǔ)引擎。目前已經(jīng)在openEuler社區(qū)開源。

倉庫地址：

https://gitee.com/openeuler/cantian

上圖是Cantian的一個(gè)邏輯架構(gòu)圖，基于企業(yè)級(jí)集中式存儲(chǔ)，Cantian引擎在MySQL的SQL引擎與innodb存儲(chǔ)引擎之間構(gòu)建了一個(gè)中間層，這個(gè)中間層可以模擬innodb的行為，因此MySQL的SQL引擎可以十分方便地與之對(duì)接。因?yàn)閕nnodb和事務(wù)控制是緊密相關(guān)的，因此Cantian里除了包含MySQL的存儲(chǔ)層外還包含了MySQL的事務(wù)管理層。

在MySQL中引入Cantian引擎的好處是，加入這個(gè)中間層后，MySQL就具備了多節(jié)點(diǎn)并發(fā)讀寫的能力，搖身一變就變成了MySQL RAC了。上面這張圖能夠讓大家更好地理解參天引擎。

在Cantian中，undo/temp/log雖然也存儲(chǔ)在共享存儲(chǔ)中，不過是實(shí)例獨(dú)占式訪問的，不在集群層面共享，平時(shí)只能在實(shí)例內(nèi)讀寫。只有故障恢復(fù)時(shí)，集群中的其他實(shí)例才能讀取。控制文件、system/users等表空間是可以在集群中并發(fā)讀寫的。

那么Cantian是如何實(shí)現(xiàn)多實(shí)例并發(fā)讀寫的呢？在本文第一張圖中有一個(gè)Global Cache的示意，在多個(gè)實(shí)例之間通過緩沖區(qū)融合技術(shù)實(shí)現(xiàn)了多實(shí)例一致性訪問。

Cantian實(shí)現(xiàn)全局緩沖的算法與Oracle 9I RAC有些類似，根據(jù)算法，可以確定某個(gè)緩沖塊的Master實(shí)例，當(dāng)某實(shí)例擁有current block的時(shí)候可以直接訪問，否則需要通過Master咨詢?cè)揵lock是否在某個(gè)實(shí)例的緩沖中。Master通知該塊的持有者將其發(fā)送給需要的數(shù)據(jù)庫實(shí)例。

大家看看上面這張Oracle 9i RAC Cache fusion的示意圖，是不是有點(diǎn)和上面的圖十分相似的感覺。不過Cantian在緩沖區(qū)融合算法的實(shí)現(xiàn)上和Oracle Cache Fusion有較大的差別，并且由于UNDO的訪問特性限制，當(dāng)MVCC需要一個(gè)經(jīng)過多個(gè)實(shí)例多次變更的PRE-IMAGE的時(shí)候，在Cantian引擎里的組裝過程有些復(fù)雜，需要一級(jí)級(jí)的向前傳遞，最終才能完成獲取。

這種模式的數(shù)據(jù)訪問如果發(fā)生在一個(gè)多實(shí)例環(huán)境下，Cantian引擎可能存在一定的性能問題。如果能夠?qū)崿F(xiàn)在一個(gè)實(shí)例完成多次構(gòu)建，則效率要高很多，只不過這可能會(huì)讓分布式鎖管理更為復(fù)雜。目前Cantian實(shí)現(xiàn)的Cache Fusion算法還只是第一代，隨著該項(xiàng)目的發(fā)展，我想這方面的算法會(huì)進(jìn)一步優(yōu)化。

目前Cantian已經(jīng)實(shí)現(xiàn)了與MySQL的對(duì)接。MySQL SQL 層與 CTC 通過 MySQL 預(yù)定義的 hanlder/handlerton 接口進(jìn)行交互，CTC插件接收到 MySQL SQL 引擎調(diào)用存儲(chǔ)引擎插件執(zhí)行的請(qǐng)求，通過共享內(nèi)存通信模塊以及對(duì)接層邏輯將請(qǐng)求轉(zhuǎn)到 Cantian 引擎內(nèi)核，CTC 插件與 Cantian 引擎通信模塊設(shè)計(jì)為統(tǒng)一接口，動(dòng)態(tài)可替換機(jī)制，支持單進(jìn)程接口直接綁定、雙進(jìn)程共享內(nèi)存通信兩種部署模式。一個(gè) Cantian 引擎進(jìn)程可以對(duì)接一至多個(gè) MySQL 實(shí)例，不同實(shí)例間通過不同的共享內(nèi)存通道與 Cantian 引擎進(jìn)行通信，CTC 插件會(huì)維護(hù)實(shí)例的啟停時(shí)集群資源的分配與釋放。MySQL 元數(shù)據(jù)仍通過 InnoDB 引擎存儲(chǔ)與維護(hù)，但 MySQL 對(duì)元數(shù)據(jù)的修改操作會(huì)通過 CTC 與 Cantian 引擎廣播到集群中存活的其他 MySQL 實(shí)例以保證集群的元數(shù)據(jù)一致性。廣播過程中遠(yuǎn)端 MySQL 實(shí)例會(huì)使用對(duì)應(yīng)權(quán)限的代理用戶執(zhí)行修改操作，從而保證集群執(zhí)行語句時(shí)的用戶權(quán)限的一致性。

在高可用方面，Cantian引擎加持下的MySQL數(shù)據(jù)庫無需主從架構(gòu)的故障切換，應(yīng)用可以在0數(shù)據(jù)丟失的情況下實(shí)現(xiàn)秒鐘級(jí)切換。這對(duì)于關(guān)鍵業(yè)務(wù)來說至關(guān)重要。

Cantian引擎中的另外一個(gè)重要組件是DBStor，DBStor 通過直接提供數(shù)據(jù)庫 Log 和 Page 的存儲(chǔ)接口，將數(shù)據(jù)庫業(yè)務(wù)的存儲(chǔ)邏輯卸載，實(shí)現(xiàn)計(jì)算和存儲(chǔ)的分離。DBStor 采用 c/s 架構(gòu)，客戶端部署在計(jì)算側(cè)，提供給計(jì)算節(jié)點(diǎn) Log和 Page 存儲(chǔ)接口；服務(wù)端部署在存儲(chǔ)節(jié)點(diǎn)，實(shí)現(xiàn) Log 和 Page 的存儲(chǔ)能力；客戶端和服務(wù)端基于 TCP/RDMA 來進(jìn)行通信。

DBStor私有接口適配其他友商的存儲(chǔ)需要一定的適配工作。項(xiàng)目組也會(huì)陸續(xù)開展一些國內(nèi)外存儲(chǔ)系統(tǒng)的適配工作。這是一個(gè)生態(tài)構(gòu)建的過程，需要通過社區(qū)生態(tài)來共同工作才能完成。在數(shù)據(jù)庫存儲(chǔ)引擎方面，Cantian目前已經(jīng)適配了innodb，PostgreSQL存儲(chǔ)引擎也在開發(fā)中，我想依托開源社區(qū)的力量，會(huì)有越來越多的數(shù)據(jù)庫適配Cantian。

最后再分析一下Cantian的應(yīng)用場(chǎng)景，我首先想到的是做數(shù)據(jù)庫一體機(jī)。Cantian可以讓一個(gè)單機(jī)集中式數(shù)據(jù)庫快速地變成一個(gè)高性能、多讀多寫或者強(qiáng)一致性讀寫分離的數(shù)據(jù)庫系統(tǒng)。如果在后端用高性能分布式存儲(chǔ)替代集中式存儲(chǔ)，還可以形成一個(gè)全軟的解決方案。只不過目前Cantian引擎要想獲得高性能，還必須依賴高速CMS網(wǎng)絡(luò)和高性能低延時(shí)的集中式存儲(chǔ)系統(tǒng)，因此全軟的方案還不是目前的選項(xiàng)，不過作為一個(gè)開源項(xiàng)目，隨著Cantian引擎的迭代發(fā)展，一切都是可能的。