數(shù)據(jù)庫高可用是企業(yè)級用戶在關(guān)鍵業(yè)務(wù)系統(tǒng)中對數(shù)據(jù)庫的基本要求，在高可用方面，怎么提高能力都不為過。也正是因為高可用的問題，很多金融企業(yè)在選擇核心系統(tǒng)數(shù)據(jù)庫的時候，都被迫選擇分布式數(shù)據(jù)庫。因為目前國產(chǎn)集中式數(shù)據(jù)庫在高可用切換方面與分布式數(shù)據(jù)庫相比還存在較大的差距。前段時間在一個會議上，有一家券商就對某個國產(chǎn)集中式數(shù)據(jù)庫廠商提出了高可用的需求，問他們有沒有能力在證券交易系統(tǒng)上實現(xiàn)對Oracle的替代。

實現(xiàn)自動切換，RPO為零，RTO越低越好是關(guān)鍵業(yè)務(wù)系統(tǒng)給國產(chǎn)數(shù)據(jù)庫廠商出的一道考題。在這方面Oracle用TAC給出了一個近乎完美的答案。在Oracle RAC集群中，如果某個節(jié)點故障，應(yīng)用系統(tǒng)的連接可以快速的以秒級的速度切換到存活的節(jié)點，SELECT查詢以及絕大多數(shù)DML/DDL也可以直接切過去繼續(xù)執(zhí)行。這意味著一個建表操作或者一個數(shù)百萬數(shù)據(jù)寫入的事務(wù)可以在用戶無感知的情況下在一個實例故障時完成透明切換。頂多最終用戶會感覺某筆交易的延時長了一點點。在23C中，TAC不僅僅支持RAC，還支持ADG，當(dāng)ADG SWITCHOVER的時候，或者是ADG是采用同步模式的時候，主庫故障或者切換的的時候，應(yīng)用可以通過TAC切換到ADG備庫。

看起來好像這個功能也不算太難實現(xiàn)，不過為了這個功能，Oracle從98那年的TAF推出到實現(xiàn)TAC FOR JAVA整整花了20年時間，而推出比較全面的TAC功能，要到明年了。Oracle花了25年完成的革命性的功能提升，其背后到底有什么秘密呢？

一個外行來看數(shù)據(jù)庫產(chǎn)品的時候，往往覺得某些功能似乎很簡單，似乎只要開發(fā)人員代碼寫得好一點，實現(xiàn)起來很容易。其實有些看似很簡單的功能的背后有著十分復(fù)雜的邏輯。就像大家一直吐槽的XID64，十多年過去了，在PG 16里依然跳票了，雖然這個功能對于PG來說很必要，但是要想真正擁有這個功能沒那么簡單。TAC可能不一定有XID 64復(fù)雜，但是已經(jīng)足夠復(fù)雜了。當(dāng)RAC某個節(jié)點故障的時候，應(yīng)用的客戶端感知RAC節(jié)點故障，自動重連到備用實例，如果是只讀事務(wù)，則根據(jù)PGA中的CURSOR數(shù)據(jù)以及SELECT發(fā)起時的SCN在新實例上繼續(xù)完成沒有完成的SQL PLAN余下的操作。如果是寫操作事務(wù)，事務(wù)守護模塊在新的連接中重放當(dāng)前沒有完成的事務(wù)，實現(xiàn)無感知的自動切換。我們看上面的描述似乎實現(xiàn)起來并不難，實際上要想實現(xiàn)TAC功能，有很多基礎(chǔ)能力需要具備。    

首先是數(shù)據(jù)庫產(chǎn)品必須擁有一個RPO為0的備機方案，這是確保TAC切換能順利完成繞不過去的技術(shù)點。業(yè)務(wù)系統(tǒng)高可用全自動快速切換中很重要的一點是數(shù)據(jù)0丟失。共享存儲多讀多寫，共享存儲強一致性讀寫分離、同步備機等都是可以實現(xiàn)RPO為0的備節(jié)點解決方案。如果是同步備機，一般而言可以選擇FAR-SYNC方案來避免備機對主庫產(chǎn)生的性能影響。

其次是高可用切換的備節(jié)點選擇問題，在多節(jié)點RAC上，如果某個節(jié)點故障時，無計劃，無策略的隨意切換會帶來很多不可知的問題，放大集群自研動態(tài)REMASTER的開銷，嚴(yán)重時甚至?xí)l(fā)集群性能問題。Oracle在這方面設(shè)計了SERVICE HA，需要做TAC的應(yīng)用必須連接到某個設(shè)定好的SERVICE NAME，而每個需要TAC切換的SERVICE實現(xiàn)都已經(jīng)配置好了HA切換策略。通過合理的SERVICE HA策略，可以確保切換的有序性。在這里，就需要數(shù)據(jù)庫產(chǎn)品有SERVICE和SERVICE HA的能力。

數(shù)據(jù)庫核心具備了上述能力后，還需要客戶端能夠快速切換的能力。在TAF里，是客戶端感知到服務(wù)器端的異常后，主動采取的切換動作，因為網(wǎng)絡(luò)超時、數(shù)據(jù)庫訪問超時等的判斷有一定的TIMEOUT限制，以及RETRY的需求，因此這樣的切換往往是分鐘級的，存在較大的 延時。為了更快的切換，必須采取其他的方案。Oracle為了實現(xiàn)快速切換，在服務(wù)端引入了一個服務(wù)—Oracle Notify Service（ONS），當(dāng)某個數(shù)據(jù)庫實例故障時，ONS會很快發(fā)現(xiàn)，并通過Fast Application Notification（FAN）快速通知到每個連接到這個數(shù)據(jù)庫實例的會話。而每個BackEnd也都必須有接受FAN消息，并且根據(jù)FAN消息自動決策的能力。    

當(dāng)會話自動切換到新的數(shù)據(jù)庫實例上的時候，對于存在寫操作的會話，還需要能夠正在進行中的寫操作的能力。Oracle是通過Transaction Guard(TG)來實現(xiàn)的 ，TG通過當(dāng)前會話正在進行的事務(wù)的完成情況自動完成未完成的事務(wù)。為了實現(xiàn)這個功能，Oracle引入了LTXID。LTXID的全稱是Logical Transaction ID，即邏輯事務(wù)ID。LTXID由以下四個部分組成：分支限定符（branch qualifier），用于標(biāo)識事務(wù)的分支；全局事務(wù)ID（global transaction ID），用于標(biāo)識事務(wù)的全局范圍；事務(wù)分支號（transaction branch number），用于標(biāo)識事務(wù)的分支序號；事務(wù)序列號（transaction sequence number），用于標(biāo)識事務(wù)的序列號。在TG中，把一個本地事務(wù)模擬成一個分布式事務(wù)，并將這個邏輯分布式事務(wù)的 ID與一個真實的本地事務(wù)做關(guān)聯(lián)。本地事務(wù)的變化也會同步到TG中的邏輯映射中，當(dāng)發(fā)生故障切換時，TG可以根據(jù)當(dāng)前操作的狀態(tài)（Prepared、committed、rolled back、complete、unknown等）采取不同的 自動化動作，完成寫操作的自動切換。如果事務(wù)的狀態(tài)是未知（unknown），事務(wù)協(xié)調(diào)器會重新查詢各個分支的狀態(tài)，并根據(jù)多數(shù)派原則（majority rule）決定事務(wù)的最終狀態(tài)，并選擇回滾還是提交。

似乎到這里TAC所需要的功能基本上都羅列了，不過還沒完，還有很多很重要的小地方的改造。比如判斷當(dāng)前數(shù)據(jù)庫切換時發(fā)生的哪些錯誤是可以恢復(fù)的，哪些錯誤是無法恢復(fù)的。比如當(dāng)前事務(wù)中存在一個當(dāng)前數(shù)據(jù)庫無法恢復(fù)的錯誤，那么再去嘗試無損切換是不合理的，此時最好的辦法是向客戶端報個措，讓應(yīng)用程序去處理這個故障。Oracle的處理方式是對每個故障增加了一個OracleException.IsRecoverable屬性，來標(biāo)志故障是否可恢復(fù)，對于可恢復(fù)的故障才采取TAC無損切換，否則立馬向客戶端報錯。  

前幾天我寫了一篇關(guān)于Oracle TAC的文章，當(dāng)時就有好幾個國產(chǎn)數(shù)據(jù)庫廠商的朋友和我溝通，說他們想在自己的數(shù)據(jù)庫產(chǎn)品中實現(xiàn)TAC，從而更好的改善用戶體驗。我當(dāng)時就和他們說，TAC對用戶來說是個十分棒的功能，但是要實現(xiàn)TAC其實并不容易。當(dāng)時我承諾有空了再寫篇詳細(xì)一點的文章來介紹一些TAC的實現(xiàn)細(xì)節(jié)，這個周末正好想起了了，于是開始構(gòu)思，今早約好了10點去拜訪一家國產(chǎn)數(shù)據(jù)庫廠家，因此早上的時間比較充裕，就寫了上面的內(nèi)容。

實際上對于實現(xiàn)TAC來說，還有最后一個難關(guān)，那就是Oracle在TAC上的專利壁壘。作為參與全球化競爭的中國數(shù)據(jù)庫企業(yè)，遵守國際規(guī)則，尊重知識產(chǎn)權(quán)是必須要做的事情。在TAC實現(xiàn)路徑上，Oracle已經(jīng)擁有了大量的專利，因此我們的國產(chǎn)廠商直接照著Oracle一頓猛抄肯定是不行的。首先我們要去研究明白在這方面哪些是Oracle的專利，必須在實現(xiàn)中對這些進行規(guī)避。