今天早上南京下暴雨，我有走路上班的习惯，今天也不例外。不过不巧的是家里的两把大伞都被我放在办公室里忘记带回来了，只能拿着一把遮阳的小伞出门。可想而知，在瓢泼大雨之下，没走到草场门大桥，我浑身上下除了脑袋都已经湿透了。突然间我想起了国产数据库和Oracle，和这把小伞似乎类似。虽然外观和功能差不多，都是可以用来防雨的，挡个太阳或者雨小的时候看不出太大的分别，遇到这样的暴雨，才能看出差别来。

今天不讨论国产数据库行不行的问题，而是讨论一下RAC这种技术。前些年国产数据库兴起的时候，大多数都是使用分布式架构的。和一些国产数据库的从业人员交流的时候，他们都认为分布式架构可以突破Oracle RAC的限制，实现PB级的OLTP系统，而RAC这种共享存储架构的数据库，节点数量超过8个就很难使用了，因此顶多能处理100TB左右的数据。因此说，共享存储架构的代表性技术RAC是一种过时技术，早晚会被淘汰。

快10年过去了，真正能够很好地支持PB级的OLTP分布式数据库系统我还没有见到，RAC技术被淘汰同样也没有见到。倒是今年的DTCC上，看到很多国产数据库厂商纷纷发布了类似RAC技术的产品。达梦DSC已经在部分用户那边商用了，优炫再次发布了SuperRAC，人大金仓也很快会推出共享存储多读多写的产品，高斯的RAC版本已经在路上了，虚谷伟业的RAC也在开发中。连万里开源都联合华为发布了支持共享存储多读多写的MySQL产品。从这些情况来看，似乎RAC技术并没有被人遗弃，一大波国产RAC马上就要登场了。

仔细想想这个现象为什么会出现，我想主要是两方面的问题，一方面是IT技术发展的速度与方向比较难以预测，另外一方面是很多数据库从业者对用户需求的掌握也存在偏差。

实际上，预言一种技术是否有前途并不是一件简单的事情，特别是在IT领域。二十多年前，当我第一次看到Oracle RAC的前身Oracle OPS（Oracle Parallel Server）的时候也是不屑一顾的，因为我觉得基于VAXCLUSTER的RDB才代表着集群数据库最高水平。

通过CI耦合器连接起来的VAX小型机和HSC-50存储系统可以以70MB/S的速度互联，在任何一台小型机上都可以无差别地通过VMS系统的锁来并发访问RDB数据库中的数据，VAX/Cluster的分布式锁为RDB数据库从底层提供了并行访问能力。而基于缓慢的10M网络的Oracle OPS肯定就不被看好了。不过随着1000M网络的普及，Oracle 9i推出了革命性的Oracle RAC，通过网络传输CURRENT BLOCK替代了效率极低的通过写盘解决缓冲区中脏数据的低效机制，效率上的提升让Oracle的并发处理性能得到了质的提升。而VAX/CLUSTER在这场技术竞争中彻底消失了。

Oracle OPS和RAC都是为了弥补Oracle只能SCALE UP无法SCALE OUT的缺陷的。主要是怕当时的小型机单机性能遇到瓶颈后，数据库算力无法横向扩展的问题。随着时间的推移，2节点RAC，甚至4节点、8节点的RAC都可能无法处理一些超高并发的应用场景了，因为网络和IO都可能成为RAC增加节点的拦路虎。

事实上这个情况到现在还没有出现，万兆甚至10万兆网络的出现与普及、SSD盘替代传统的SAS HDD，这一切似乎让那些十年前十分令人担忧的问题迎刃而解了。10年前Oracle公司也曾动摇过，在12c中十分匆忙的推出了sharding数据库技术。不过到了2019年，随着计算机硬件出现的突破性发展，Oracle的战略又回归到了以RAC为核心的技术层面，在2019年的OOW上提出了融合数据库（Coverage database）的概念。学习了智能手机对用户提供的友好互动能力的理念，回归到给用户提供便捷的应用支出上。我想这是Oracle针对IT基础硬件发展后的重要修正。

目前我见过的绝大多数使用Oracle RAC的用户，都不是因为单机处理能力不足，主要还是为了系统的高可用。而我见到过的绝大多数分布式数据库用户，也在用着高射炮打蚊子这样的超级豪华配置小心翼翼的使用着分布式数据库，因为他们发现一旦分布式数据库的某个节点的硬件资源出现了瓶颈，会导致数据库很容易出现一些莫名其妙的问题，而对他们而言，多配点硬件并没有什么压力，让数据库更稳定的运行才是他们最需要的。

另外一个十分值得数据库从业人员注意的方面是应用于计算模式的改变，已经让SALE-OUT不是刚需了。历史数据归档平台、大数据平台、数据湖、流批一体实时数仓的建设，让OLTP数据库不会无限扩大到集中式数据库无法管理的规模了。在我们脑子里十分需要SCALE-OUT，生怕SCALEUP无法满足业务需求的时候，没有大数据平台的概念，甚至没有OLTP/OLAP分离的概念。而当数据处理技术发展后，实际上对SALE-UP的恐慌应该消失了。现在再拿SCALEOUT说事，似乎已经有点不合时宜了。

从上面两方面来看，我们需要分布式数据库，不是因为需要SCALE-OUT，大多数用户使用分布式数据库需要的只是高可用。我曾经和一个金融用户讨论过分布式数据库，他说他们选择分布式数据库，是考虑一旦某个硬件故障后，系统只会有部分不可用，因此在考核中，不会算他们是系统故障。如果从这个角度看，如果一个分布式数据库的节点故障，最坏的情况是在几十秒钟到一两分钟内业务全停。而如果是RAC系统，当一个节点故障时，RAC RECONFIGATION导致的业务全停时间最多只有几秒钟，在最坏情况下RAC并不落下风。

实际上讨论一种技术的好坏，主要还是看用户的应用需求以及技术与用户应用的匹配度。从我目前见过的用户的情况来看，说RAC是一种过时的技术，似乎还有些武断。