前阵子和几个国产数据库厂商的朋友谈到高可用架构的时候，有朋友说数据库高可用架构的尽头是 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 研究一下，我觉得目前能力最强的融合数据库就是这个，这也代表了融合数据库的技术发展方向。

回到应用连续性和高可用的话题。数据库的高可用技术是为应用服务的，用户对此的要求是越透明越好，对应用影响越小越好，使用成本越低越好。技术上限会随着软硬件技术的发展而不断进步，我们目前离最高水平差距还相当远。谈哪个地方是尽头还是早了点。