共享存储多写多读数据库集群技术实践

文章简介：本文结合客户需求及行业发展趋势，阐述共享存储读写多读数据库集群技术如何解决客户问题、满足应用需求的。

首先分析为什么优炫软件要做UXDB，核心业务系统对数据库有什么要求，并且根据需求解释了为什么优炫选择这种技术路线。接下来分享了优炫UXDB使用到的关键技术以及整体的技术架构，最后介绍了优炫UXDB的使用场景。

以下是李勇在DTCC2023中国数据库技术大会的演讲实录：

在核心行业的核心业务里，有一个非常显著的要求那就是：业务要保持最高级别的可用性。如在金融、军事、交通行业里，用户经常会碰到非常复杂的情况。

昨天我在给客房续费的时候银行拒绝支付，同时弹窗可能在进行有风险的交易，这种查询要考察到我过往在全国各地的支付习惯才能判断我是否有风险。这类的核心业务里面的核心要求就需要数据库有很高的处理复杂事务的能力。

核心业务下，除了高可用之外，还有一个是：对业务的一致性、数据的一致性要求是实时的一致性。对于银行帐户之类的核心应用，不能对不上账，所以金融业数据库安全发展报告2022的调查显示，集中式数据库在金融业的总体占比高达89%，银行80%，证券和银行占比超过90%。金融行业里面对数据的一致性要求是即时的，强一致性的要求。

Oracle对核心产业核心业务的回应是什么？基于共享存储的多写多读的集群数据库系统。

2001年Oracle推出Real Application Clusters（Rac），那时候是非常基础的功能。

2003年加入高可用和灾备功能。2005年进入中国市场。

2007年发布Rac 11 g，缩短节点故障转移时间，同时优化工作负载管理，提高了集群的吞吐量。ASM也是在这个版本里引入的。

2010年Rac成为Oracle数据库标准配置，同时在中国市场快速增长。在2010年那段时间是互联网快速增长的过程，在中国10亿人口级别的市场上，有很多应用的复杂程度和困难程度是在世界上其他的市场达不到的，像支付宝、微信这些服务只有在中国统一的支付市场里面才会有。

2013年Oracle发布了Rac 12c，可以容器化，可以上云。

2022年Oracle全球市场是200亿美元，Oracle Rac在中国市场是3亿美元。一直到现在为止，在四大行、九大国企，核心应用绝对性使用Rac。国内在Oracle核心技术是必须在当前国际形势下，是有非常强烈的国产替代的需求。

为什么互联网金融、分布式数据库发展得非常好，并且还是领先的，但是在Rac方面，国产替代的过程还是显得略微有些滞后。

Oracle Rac替代是数据库技术的天花板，有替代的必要性，同时技术上有挑战性。

从市场来看，由于Oracle Rac要求绝对高可用和即时一致性，在这个市场里面，用户的需求并不像分布式市场，一下需要部署十几甚至几百台机器，大的金融企业从每年交易量反推使用Oracle Rac承担的TPS，可以估算一下大概TPS平均下来是2000，考虑到峰值也就是8000TPS左右。

在这些行业里面，Oracle Rac是性价比非常好的解决方案，是专门针对这个市场的。技术上有难度，开发之后市场的规模也有一定限制，所以我觉得这有可能是Rac技术国产替代里面相对比较慢一点的原因，否则我相信以中国程序员的聪明才智，Rac这种20多年前发布的东西，现在硬件发展和计算机技术发展，我们肯定是有能力至少是替代一个十年前技术水平的版本。

优炫比较了这几种方案的特点和优势，我们得出如下结论：

• 中间件模拟方式比较简单。实际上还是读写分离，没有办法完全解决极致的高可用和数据的强一致性的需求；

• 分布式数据库方式在国内依托市场。有技术上的特点和优势，互联网业务的特点就是并发量大，数据量大，有很多业务天然是分布式的，互联网公司对分布式业务的做法通常是将复杂的事务简单化，把数据分区分片多副本。分布式系统实现的是最终的一致性，这种选择更适合于大数据的场景和天然分布式的互联网商贸的场景；

• 类Rac方式。集群选择数据的强一致性和整个系统绝对的可用性，通过集中式的共享存储让所有节点操作同一份数据，对数据不做分片备份，不需要满足分区容错性。Rac的选择保证高可用性和实施一致性，在银行等核心领域都是必不可少的，这也是优炫软件选择用类Rac方式来解决应用场景里需求的原因。

优炫软件今年推出的UXDB SRAC集群从理论和架构设计上来说，规模没有上限，实用集群规模达到八个节点，同等测试环境下，性能和Oracle相当，可以进行关键业务的连续性，进行一些替代。同时优炫和一些合作方进行了适配。

接下来看看优炫软件怎么解决Rac集群的替代问题。Rac集群最重要的特点是必须是全对称的架构，这是实现极致高可用的关键，也是研发当中最大的难点。集群里面由于是全对称，任何节点停机，对整个集群服务都不会停止，只要还有一个节点存活，Rac集群服务就不会停止。

1、SRAC并行内存融合

数据的并发操作，一个节点对另外一个节点的并发操作，要满足数据库的控制要求，物理上虽然共享内存是在不同的节点上，但实际使用中，逻辑上要看起来像是一个整体的。并且对逻辑上整块的内存控制要和数据库的并发控制相配合，做到这点之后，才能作为实现集群里面节点故障恢复的技术基础。整体的思路就是尽可能的使用网络IO换取磁盘IO，提高整个集群的性能。

为了实现这个目的，我们要做到高速一致的并发调度，这个调度主要是通过流式无状态模型处理多节点、大并发、大吞吐的操作。在该架构下，一方面对操作的资源进行维护，另一方面对数据库多版本的并发访问进行控制。与并发控制相配套的，我们需要对数据库底层的加锁控制，IO控制及高速内存资源调度控制做出相应的工作。

多个数据库后台业务进程可以并发，同时操作共享内存，使用内在的机制，协调各个进程的并发控制。多机数据库里面，共享内存会被多节点同时操作，我们为了降低内存融合网络通讯负载，在内存融合方面做了相应的创新。首先，内存融合本身不处理任何冲突，也不管任何锁队列，不接收任何回复确认，这是所谓的无状态。

内存融合模块在处理每一个数据块的请求，发出数据块的调度指令之后，马上就会变更状态，认为请求已经达成了，之后的请求都会建立在这个假设上面，在全部节点已经占有数据库的块和锁的基础上进行调度，这就是所谓流式的操作过程。所有数据块的控制在数据流传输过程当中完成，如果说集群里面网络传输发生问题怎么办？这是一个数据库集群系统，集群系统里面，我们认为各个节点是通过高速内网连接在一起的，不是分布在各地的分布式的系统，在这个系统里面默认连接是稳定高效的。基于这个前提条件，如果某个节点的网络通讯有问题，我们不应该在软件层面来解决并且掩盖这个问题，而是应该早点报警，通过这个方式将数据的传递分享和数据的修复进行解耦。最后如果有节点，在数据块传输当中有问题，我们会尽快修复数据块，如果不能修复，直接把这个节点踢出去，把这个问题交给集群的修复系统去解决。

2、分散PIN并行清理技术和内存融合脏页缓存技术

对于内存融合脏页缓存技术，该技术是RAC架构下数据恢复的重要基础设施。将数据块被传递被修改的过程，保存为数据块的历史信息，某一个节点发生故障的时候，可以根据历史信息恢复这个节点的数据，在内存融合和并发控制里能放心大胆解耦的原因。

3、SRAC实时事务并发控制

为了达成全对称模型下的实时一致的事务控制，我们最基本的想法就是在每个节点上都保留全局的事务状态信息，这样允许每一个节点的数据库连接，仅仅通过访问本机内存，就能获知全局态势，提供集群实时一致的数据事务状态。

事务控制是极高频次的操作类型，但是事务状态的控制位大小并不是那么突出因为事务控制是一种量小但使用频次极高的信息，所以我们不像数据块的传输一样采用点对点的方式，我们使用的是广播的方式，每个事务提交的时候，要将事务的状态进行全局的同步，使每个节点获知全局的事务状态，并进行实时一致的数据库事务控制，里面还有技术细节不再进行介绍了。

4、USM共享存储

除了逻辑上融合的内存要进行并发控制，同时还有持久化存储，集中式共享存储，这个架构下所有节点对于共享存储会进行高频的IO操作，数据保存持久化之后，必须保障这个数据在多个节点之间呈现出严格的一致性。严格的一致性要求一个节点改变了文件元数据之后，在其他节点上迅速得知状态。如果全部把元数据改变都通知到整个集群节点，通讯量和工作量是非常大的，我们采取多种措施，其中一种就是调整重新设计了元数据结构，减少了必须要同步的信息量。同时利用前面提到的两个基础设施，内存融合和事务并发控制，实现元数据同步。

5、SRAC不停机恢复

我们集群里面的节点出现问题之后怎么办，要对集群里面的数据进行恢复，这样才能保证任何一个节点出现问题集群的事务不会断。

在数据库宕机时，会丢失WAL日志流尾部的一部分未提交事务WAL日志，这在单机数据库是正常现象。但是在集群里会有问题，集群里面日志按照时间顺序排起来，形成日志流，如果节点B宕机，丢失了WAL数据，对单个节点没有问题，但是对整个集群来说就出现了空洞，我们必须想办法解决这个问题。Oracle本身也可能遇到过这个问题，因为Oracle Rac之前有一个OracleOPS，在OracleOPS升级成Oracle Rac之后，才解决了系统性能低的问题。 我们解决这个问题方式，尽可能针对高频措施进行日志修复，对于操作涉及到非常难修复的，比如横向分裂、纵向分层，这些恢复不了的，必须落盘之后才能修复。

（b）全局日志序号sno技术

（c）并行多路按需恢复技术

在上面技术的基础上，我们设计并实现了并行多路按需恢复技术。这个技术讲简单点就是一方面并行恢复加快恢复速度；另一方面优先修复被请求的有故障的数据，其他的没有发生故障的数据可以被正常使用，不受影响。我们允许在修复过程当中,在存活节点上建立新连接，在这种方式下用户感受不到集群异常，数据库的业务能正常被执行。

同时，在这个基础上我们还可以尝试做异构节点，在同一个集群里的使用，这个方式可以降低国产替代的难度，整个架构设计过程要考虑到近年来新硬件对于关键性模块性能提升和成本降低的影响，因为整个是自主研发的，所以说后续的国产替代、性能提升都打开了空间。

因为Rac集群整个系统行为和普通集中式数据库非常相似，没有人知道它是一个Rac，我们搭建灾备系统可以利用类似的方案，多个集群可以参与流复制，灾备系统可数据同步以在一定程度上实现并行化。分布式系统里面如果某些关键性节点需要高可用数据一致性，可以用简版Rac集群来替代。