前陣子和幾個國產數據庫廠商的朋友談到高可用架構的時候，有朋友說數據庫高可用架構的盡頭是RAC，今后所有的國產集中式數據庫必須做RAC功能。我問說這話的朋友，你認為的高可用盡頭的RAC，看中了哪方面的能力呢？他說某個節點故障，另外一個節點照樣跑，應用可以快速通過TAF切換到活著的節點，在業務完全不中斷、數據0丟失下實現高可用切換，基本上就能夠滿足用戶的需求了。

干了三十多年IT，親眼目睹了IT技術發展的滾滾洪流，我已經對頂峰、盡頭之類的詞免疫了。未來如何，我是沒有能力去感知的，我只了解歷史和現狀。能夠把現狀搞明白七八成已經是十分高的認知程度了。如果RAC這個誕生于上世紀90年代的數據庫高可用架構就已經是數據庫高可用架構的盡頭了，這三十年來，數據庫從業者都白活了。

事實上，那個朋友說的Oracle RAC的故障切換技術是快30年前的技術了，而這些年中，Oracle在高可用技術方面的技術進步可能已經完全超出了那位朋友的想象了。這些年Oracle 的業務連續性解決方案已經從TAF發展到了FCF(快速連接故障切換），FCF把TAF的分鐘級故障切換縮短到亞秒級，這個技術是Oracle 10g開始支持的，至今已經21年多了。十年前我在對某個行業的Oracle用戶調研的時候，幾乎100%的用戶還在使用TAF，壓根兒不知道還有FCF這個技術。這說明TAF對他們來說已經夠用了，實際上他們的系統并無更高高可用的需求。

2013年的12C，Oracle又推出了GDS和應用連續性解決方案AC。不僅把高可用切換擴展到了Oracle RAC之外的GoldenGate和ADG環境，還提出了一個故障切換應用不失敗的解決方案。在2018年的18C中，AC又升級到TAC，讓應用連續性方案變得對應用更加透明。在隨后的19C中，TAC方案擴展到了ADG。

實際上信息化這幾十年來，人們對系統高可用的需求是不斷提升的。隨著數據存儲與數據處理越來越集中，系統故障所帶來的的負面影響就越來越大，于是關鍵業務系統對數據庫系統高可用的需求就越來越高了。實際上業務連續性的數據庫解決方案的發展目前還是沒有看到盡頭了。只是目前國產數據庫在這方面與最先進的技術之間還存在好幾代的代差。

數據庫業務連續性解決方案的技術發展方向是對應用越來越透明，對應用影響越來越小。Oracle對業務連續性的解決方案已經發展到了全局數據服務GDS，RAC只是其中的一個環節了。不過大多數國產數據庫廠商還是沒有看到這個技術趨勢，還把實現RAC作為自己追求的終極目標，這個技術思路可能不一定是正確的。

共享存儲多讀多寫數據庫要想達到Oracle RAC水平相當困難，這不僅僅是投入研發經費的問題，底層存儲架構如果沒有優化好，哪怕做出了類似RAC的功能，在性能、故障切換的FREEZE時間等技術參數上與Oracle都會有相當大的差距，而且因為存儲引擎的缺陷，這個差距是無法縮小的，這一點我不知道有多少數據庫從業者認可。我交流過的國產數據庫廠商中，好像只有一家和我持相同的觀點。

RAC只是實現較高的業務連續性的一種技術方案，并不是全部。GDS才是目前業務連續性解決方案中相對前沿的技術方案。我建議需要給用戶提供更高業務連續性解決方案的廠商去研究一下。對于國產數據庫廠商，我有一個十分不解的問題就是，似乎他們的產品經理都不去研究Oracle這個目前數據庫中的遙遙領先者。周日和大學生朋友交流的時候，南科大的一位同學問我融合數據庫需要具備哪些能力。我說一兩句話說不清楚，你去下載一套Oracle 23ai研究一下，我覺得目前能力最強的融合數據庫就是這個，這也代表了融合數據庫的技術發展方向。

回到應用連續性和高可用的話題。數據庫的高可用技術是為應用服務的，用戶對此的要求是越透明越好，對應用影響越小越好，使用成本越低越好。技術上限會隨著軟硬件技術的發展而不斷進步，我們目前離最高水平差距還相當遠。談哪個地方是盡頭還是早了點。