RAC解释

• RAC一词最早出现是在Oracle上。它是real application cluster的缩写，译为“实时应用集群”。就是Oracle9i开始有的一种高可用架构。架构简图大致如下：

• 其实多年前我在接触RAC之前看到的是其他技术的集群，也类似这样。我当时年少无知的其实不以为然（在多个场合我都承认过自己的无知）。我说这就像一个人长出来两个头，砍掉一个是不影响。但是如果身子坏了呢？的确如果共享磁盘毁灭了，那么整个集群就毁灭了。直到后来我才知道几个问题：

• 1、这不是最佳架构，为了防止这种共享磁盘毁灭的极端场景，Oracle也想到了。就是在RAC的基础上再做一个ADG。这就是MAA了（Maximum Availability Architecture）所以单做一个RAC不是防止机房级别灾难的。正所谓同城或者异地这种极端场景。但是对于99.99%的来说总是遇到机房级的灾难，那真的要找找数据库以外的原因了。不过有需要的话异地容灾也是可以考虑的。

• 2、即使是本地做了RAC，共享磁盘这里也没那么脆弱。存储有RAID，控制器和光纤交换机都是双路还有HBA卡这些都是双路的。共享磁盘这里出问题的概率极低。与其担心这个还不如担心磁盘用满了造成的问题。整个阵列全坏的我亲身没经历过，但是磁盘满的我倒是经历过。那如果有人问阵列还是有概率坏的。是的。所以请选好点的硬件。以前说IOE中的E就是EMC，为什么这样组合。就是EMC的质量好性能高。数据库作为核心，重中之重，不要拿便宜货来存储。可以找专业的存储，数据库属性之一就是IO密集型产品，对IO的依赖是很高的。这种高不仅体现在性能上，还有在可靠性和稳定性上。甚至在智能化上。几乎所有的数据库优化主要都集中在减少IO上。可见存储的选择性非常重要。说个题外话，当初我有一个数据库有1T的碎片。对，你没看错。我的碎片一个T，我整个库很大。而就这个碎片的大小足以碾压不少公司的生产库了。我在这个库上做了一次碎片整理，历时55个小时（不影响业务读写），而我同事在另外一个项目，显然没有我这么好运气。他遇到的是一个差的存储。他用了550个小时。是我的十倍。

• 3、如果不用共享存储，那么两个计算节点写入的数据如何保证一致性？当初刚入行时候就是没有考虑到这个关键的点才会犯无知的错误。主备除非是Oracle的最大保护模式否则都不能绝对意义上说数据一致的。其他数据库也类似。但是几乎每哪个生产系统设置最大保护模式。因为这个模式就是备库不行的话，主库也不行。所以一致性是绕不开的话题。
  分库分表一时爽，但是发现当遇到跨库的事务一致性就是问题。本来简单的事情，就要架构层面介入，却依然不能100%保证一致性。由于拆分以后使得数据链路长。那么根据CAP理论，如果要求一致性的话，那么性能必然受到影响。那么要考虑的问题就越来越多，然后反复叠加最后架构复杂还没解决问题。

那么RAC这种有什么好处？

• 上面的问题都可以通过RAC进行解决。

• 首先，任意一个节点宕机数据库还能继续提供服务。这里有人会说进行一下主备切换也能做到。是的也可以。但是需要人工或者脚本化的干预。在有些时候应用的连接需要修改连接地址，即使不需要修改地址的那种架构下，也会有链接中断事务回滚的情况发生。而RAC下是对应用透明，无需任何人工和脚本干预。就这一个特点就是的其他主备架构在连续性上是无法比拟的。这解决了应用重连的问题，使得运维团队对外（对业务部门）和对内（DBA和其他运维）之间的矛盾与工作量。

• 其次，在这种架构下每个节点的数据读写是一致的。主备架构下几乎做不到。

• 再次，每个节点进行维护性质的重启，对外不影响使用。这在主备架构也也无法做到。

• 可能说到这里有人会说现如今哪个分布式数据库不是高可用呢？

• 在这种情况下，也能做到以上说的，RAC不是必选项吧。

• 这里就要提一下场景：互联网场景的确不太需要RAC（即使这样阿里去IOE之前是拥有全国最多节点的RAC）。

• 但是我国是互联网公司多还是非互联网公司多？答案显而易见。在非互联网公司的企业重度使用数据库，有人说替换Oracle是因为有存储过程。那么这个不全面。难道没有存储过程就能替换吗？在SQL复杂无比的情况下还不如存储过程好改造。在普遍的企业中都是这样，SQL的数据是全量或者关联较多。这种如果用分布式数据库，那么无论是跨节点访问数据还是跨节点关联数据，对数据库的冲击都比RAC架构下大。这是CAP原理所决定的。

而多年以来大家使用RAC都各有各的独特用法和场景

• 有的是用来负载均衡，

• 有的是用来读写分离（一个应用就写A节点，另外一个应用就是读B节点），

• 还有的是不同的模块读写不同的节点等等就不一一列举了。

• 在这个架构下大家都找到了符合自己企业自身的使用方式和方法还是比较灵活的。这些都开发和运维为自己业务量身定做的架构，最符合自己情况。这种下如果让企业放弃原来最适配的架构，那么原本语法兼容、性能兼容等难度较大的基础上又增加了架构适配。

• 正因为以上这些优点和这些优点所对应的痛点，让用户在经历了这些年分库分表和sharding的架构在经历过数据一致性的问题、业务连续性的中断和应用连接适配的苦恼以后重新审时度势从数据架构上来看待究竟哪种架构能最大限度的满足要求解决痛点。最后发现似乎当初的才是最合适的。所以在国产数据库中不乏有仿造RAC架构的改进。有涉及的包括但不限于以下：达梦、金仓、崖山、Cantian等等。

• Oracle的安装现在可以做到一键安装，但是ADG会稍微复杂一点。唯独到了RAC这里安装其实是比较麻烦的。因为实实在在的要和存储打交道，要有多路径软件等工作要做。这是RAC安装中最难的一步。可见难就难在数据库和存储的高度融合。我个人观点Oracle在RAC上的技术，是后来软硬一体（一体机）的基础。

数据库除了和操作系统打交道，也和存储打交道

• 对于前者很多数据库厂商都知道。但是对于后者有不少数据库商场不在意这里。尤其是云原生数据库，哪里不足弹性处理。但是云原生的前提是要有公有云。在很多无法使用公有云的场景下，那么就必须面对存储环节这个来展开数据库研发。注意：私有云是无法做到公有云的那种弹性缩扩容的。

• 所以有RAC这种架构的数据库产品在私有云和自建环境中就没有在存储上做文章的产品会有一些优势。数据库一定也必须要充分利用硬件，信通院2021年的数据库发展研究报告白皮书中提到数据库的七大趋势之一就是：充分利用新兴硬件。这里的硬件包括存储。

• 其实对于RAC的博大精深，远不是我这几千字能说清楚的。看到国内很多厂商都在做，说明用户还是有需求的。厂商都意识到了这种架构还是有一定的市场。

说到这里RAC的缓存融合的问题是难点之一

• 多个节点运行时，缓存节点中用到数据库的时候要进行同步。

• 还有不同节点中锁的处理就更加难了，要看的不仅仅是自己节点的锁，还要看整个全局其他节点上的锁，而且这些还不能放大，要巧妙的解决这些的同步，这些都涉及到算法。一旦上升到算法级别就不仅仅是简单的软件开发了。数学领域没有长期持续的投入很难有成果产出。这些必然是要投入大量的人力资源，而且是高质量的资源。单纯投入人解决不了核心问题，无法攻坚。有高端人才但是人不够也不行。

• 所以从数据架构的角度来说要做成这样的集群架构，数量和质量缺一不可。

• 当做成这样的架构后，其整体的可靠性、稳定性和一致性是水平拆分数据库无法比拟的。

• 在数据库领域中ACID和CAP原理的约束没改变的情况下，1+1可能还小于2，10个1相加还真未必干得过一个1.再举一个例子，第一个节点如果重启，那么第二个节点还要讲第一个节点的会话和未完成的事务无缝接管过去。这是其他数据架构无法做到的。

RAC其实作为一个分布式架构

• 他的维护其实比主从架构和单机模式的维护要复杂的多。单机出问题实在不行就重启实例，而分布式数据库多个节点时候不一定重启一个实例就有用。极端的情况要重启所有节点的数据库。不过如果培训到位和能力合格的话，可以准确定位问题则不需要极端的处理手段。这对维护的人来说也提出了更高的要求。这就像管理一个人和管理一个团队来说，要求是不一样的。

• 一旦做好了，好处也很多。多个节点可以轮流重启进行预防性维护（比如升级、补丁）而不需要中断服务。

从不认可到认可

• 我自己也从不了解，不认可，到理解，到认可这个过程中，都是实践教育了我。
• 现如今需要这种架构的数据库不在少数。可以说还是一个主流趋势。