演讲嘉宾介绍：

　　李勇，北京大学数学力学系获得学士，硕士学位，麻省理工学院机械工程系获得高性能计算博士学位。先后在卡特皮勒全球研究中心，丰田北美研究中心，麻省理工学院斯隆能源实验室，达索系统等众多研究机构，从事超大规模并行计算，AI及数据建模等工作，担任设计师，主任研究员。

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

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

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

　　1. 核心业务需求

　　没有一种数据库能够覆盖所有的业务的需求。优炫根据以往业务经验，客户在核心系统的选型上，需要根据多方面因素（比如业务数据的特点、业务数据的类型、数据增长的趋势是不是存在高并发访问）决定数据库的容量规模以及处理能力，还有业务的响应要求，要多快才能得到反应，哪种才能保证业务的连续性。最后还有成本、数据一致性要求，以及业务可用性要求。

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

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

　　核心业务下，除了高可用之外，还有一个是：对业务的一致性、数据的一致性要求是实时的一致性。对于银行帐户之类的核心应用，不能对不上账，所以金融业数据库安全发展报告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多年前发布的东西，现在硬件发展和计算机技术发展，我们肯定是有能力至少是替代一个十年前技术水平的版本。

　　2. UXDB 技术路线选择

　　接下来介绍一下优炫软件，面对多写多读集群国产替代的必要性，我们选择迎难而上。国内对Rac替换大多数采用三种方式：（1）中间件模拟方式，屏蔽客户对后端数据库实例的连接和切换；（2）分布式方式，原生的分布式数据库可以通过内核里面数据的自动复制和负载均衡，来实现高可用；（3）RAC方式，这种方式可以进行直接的替代，在用户方面可以避免应用改动，用户迁移和替换节省成本，提供最高效的解决方案。

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

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

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

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

　　优炫之所以选择了RAC路线，研发并实现了UXDB SRAC共享存储集群数据库系统，一方面是响应国家去IOE路线以及方针；另一方面是优炫注意到目前在国产数据库领域尚无真正的可以替代Oracle RAC的产品。

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

　　3. UXDB SRAC关键技术

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

　　基于这种特性，在应用程序层面，即使是集群里面有多个节点发生故障，也没有感知。全对称性要求每个节点要对所有的数据百分之百相同的读写操作能力，每个节点都可以操作全部的数据。这些就要求Rac集群要有几个非常基本的关键性的功能。

　　首先针对集群内数据的共享以及一致性的控制，我们不仅要让每个节点都能够了解其他节点里面共享内存的状态；同时在集群事务的状态控制方面，我们在每个节点上有一致性的控制。网络连接发生故障的时候，要有能力及时将业务转移到其他还存活的节点上去，保证业务不中断。多机的共享存储里面，不同的节点同时对一个数据块进行操作的时候，我们需要对高并发多写的集群文件系统进行定制性改造。同时，考虑到国产替换，整个应用框架是选用和Oracle Rac相同的应用架构、部署架构。但这并不意味着我们能从Oracle公开的资料里面直接学到什么样的东西，我们只是知道我们要做成一个什么样的集群，具体怎么样去做，这些东西都要从头开始，内核级别上进行自主的研发和实现。当然了，多写多读集群里面有很多难点，数据库作为发展非常完善的理论，里面并没有什么东西是神秘的、不可解决的。对于各种各样的问题都有解决方案，在整体系统搭建当中，满足了这个需求就不能满足另外一个。我们主要是要选择，在各种各样解决方案当中进行取舍，创新，最后才能达成稳定的能满足我们需求的系统。

　　3.1 SRAC并行内存融合

　　内存融合技术，它就是要保证集群里面每一个节点数据缓冲区要相互连通，数据资源节点从共享存储上读上来之后，保证在每一个节点上不同的进程里面，不同的实例里面能够共享数据，但是不同节点要穿过节点之间的物理障碍去获得其他节点共享内存的数据，要通过高速内网进行分享。

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

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

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

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

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

　　这两个技术是内存融合的关键配套维护设施。对于分散pin并行清理技术，因为数据库系统执行大并发Update业务时，将会产生巨量的老旧版本数据而需要被及时清理，而这种现象在SRAC集群中将会更加严峻。为了解决这个问题，我们重新设计并实现了一套MVCC清理机制。我们设计了一种更适合RAC架构尤其是适合SRAC内存融合的清理时机与清理方法，使用并行分散的模型对全局数据进行维护清理。

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

　　3.3 SRAC实时事务并发控制

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

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

　　3.4 USM共享存储

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

　　3.5 SRAC不停机恢复

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

　　（a）双层WAL技术

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

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

　　因为有了前置各种技术，同时还需要在集群里面将不同时间发生的事务进行排序的能力，每一个节点单独来看都像是单独的小宇宙，所有事务排在一起，怎么保证这个序列就是正确的，按照这个序列恢复日志，能完全恢复集群的状态，这是非常重要的问题。在分布式系统里面，为了保证能完美的复原这个系统的WAL的顺序，在全球各地超大规模分布式系统里面要配置GPS的接收端以及时间服务器，保证非常明确的事件顺序。对于Rac集群，因为这些节点操作的是同一份数据，没有多个副本，所以当两个节点之间相互之间没有数据交换的时候，本地事务顺序是不会影响结果的。 只有发生数据交换的时候，才会增长全局事务号。本地的事务号根据本地事务需求进行增长。只要是相同的全局事务号之间的事务，把这些事务排序的时候，无论是ABC123还是A1B2C3，都没有问题。

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

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

　　4. UXDB SRAC技术架构

　　最后回顾一下整体的技术架构要达到的目的，我们提供服务的使用场景。

　　首先内存融合，事务控制，共享文件系统以及其他基础性组件，整体的技术架构就是这样，我们完成的就是内存数据共享，以及一致性控制，事务一致性控制，以及业务不中断高可用保障，还有多机共享的存储。整个系统里面存储与存储连接是单独的网络，把存储操作的网络流量和节点之间数据块的流量分割开来，这也是标准的类Rac集群的结构，任何一个节点停机都不会带来问题，并且还有额外的好处，可以有计划的停机，滚动停机，我们想对系统进行维护的时候，可以有计划的将其中单个节点停下来，然后进行维护。

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

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

　　5. UXDB SRAC使用场景

　　Rac集群使用场景重复一下，业务的连续性要求高，绝对的高可用性，性能要求高，同时有一定的可扩展性，业务并发量大，尽管横向扩展性没有办法和分布式系统相比，但是在集群范围内还是可以根据业务变化动态的调整集群的节点数。优炫跟某些银行账户系统，还有实时仿真系统，高速公路的计费系统以及重卡调度系统已经开始了Rac集群的适配。