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

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

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

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

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

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

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

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

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

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

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