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

倉庫地址：

https://gitee.com/openeuler/cantian

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

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

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

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

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

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

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

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

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

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

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

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