oracle数据库缓存机制-oracle数据库锁机制

摘要：银行企业使用云的方式有自建云、公有云和私有云三种。 无论哪种方式，您都将面临最重要的任务之一，就是将数据库迁移到云端。 问题来了，为什么很多公司选择云原生数据库？ 他们在构建自己的云原生数据库时会面临哪些挑战？ 如何正确选择云原生路由？ 本文将分析渤海银行云原生数据库的实践，梳理云原生数据库建设要点，谨防踩坑。

本期分享嘉宾：渤海银行总行科技部高级经理曹晓

简介：在金融科技领域拥有近十年的工作经验，曾就职于国有龙头银行和股份制商业银行。 具有丰富的银行科技系统开发运维经验，关键技术领域集中于各类数据库的架构设计和生产运维。 近年来专注于开源数据库、国产数据库、云计算技术等领域，对云原生数据库和开源数据库的底层运行机制和源码分析也有研究。

环顾四周，银行企业上云的方式不外乎三种：自建云、公有云、专有云。

所谓“自建云”，是基于开源技术，基于银行自有IDC建设的。 这期间会用到虚拟化技术和K8S容器技术。 自主控制程度高，运维成本相对较高。 对技术人员的要求也很高。 因为，小到每台服务器和上面的操作系统软件，大到整个云平台的IaaS、PaaS层都是银行自己搭建的。

公有云意味着银行会选择购买第三方云厂商的服务。 服务器和产品部署在云厂商的基础设施上，所有底层技术都由云厂商完成。 这种方法的优点是比较简单方便。 操作和维护要求非常低。 但是这种方式也有一个缺点，就是定制化程度比较高，银行只能沿用云厂商的架构，对于很多关键业务或者重要度比较高的系统并不适用。 此外，由于业务性质的要求，不可能将银行的所有关键业务都部署在公有云上。

专有云也被一些企业称为混合云。 其实基本形态是类似的，就是把公有云的业务模型全部输出在银行机房，包括通过云原生技术能力为银行的各个业务提供服务。 专有云带来的最大优势是降低了自建云平台的难度，让技术人员更专注于业务应用开发，配套的运维体系也比较完善，让云运维难度降低。 问题在于银行业务云并不完善。 虽然专有云是大多数银行的最佳选择，但银行自身的可控能力相对较高； 但是由于比较封闭，想要了解内部应用的每一个细节和逻辑，需要花费很多时间。 同时，对于由专有云提供商提供运维服务的银行来说，自主可控难度更大，定制化程度较低。

为什么选择云原生数据库？

银行核心业务上云最重要的工作就是将数据库上云。 那么，我们应该如何理解众多企业所推崇的云原生数据库呢？ 与传统数据库相比，云原生数据库有哪些优势？

总体来说，我们可以从5个方面进行比较：

1.并发处理能力。

基于云原生本身的特性，在弹性扩展和高性能支持方面有着出色的表现，因此高并发处理能力比传统数据库要强。 目前，随着银行互联网业务的快速发展，传统数据库的单机模式及相关硬件资源配置已经难以满足业务量快速增长的需求。

2. 可扩展性。

云原生数据库一般具有较高的扩展性和数据再分发能力，对业务的影响相对较小。 相对来说，传统数据库的扩展性比较困难。 此前，银行业也曾尝试基于Oracle、MySQL等实现数据库弹性扩展机制，但受限于传统数据库的技术能力和技术架构，难以实现。

3.架构统一。

云原生数据库具有内在的技术统一性和集成性。 有了云端的数据库系统和相关逻辑，就可以依托云平台能力解决架构统一性问题。 但如果是传统数据库，需要分别考虑各个产品的使用和特殊场景的集成能力，比如：AP数据库、TP数据库或者缓存数据库路径集成，需要对应到哪个产品，只有通过深入的掌握和理解，才能更好的融合。

4.运维复杂。

云原生提供的产品种类繁多，关联性强，但排查问题的能力相对较低，需要依赖云原生能力； 而传统数据库基于现有的硬件、IO、内存、CPU，运维起来相对容易一些。 定位产品问题，便于纵向深入探索。 当然，最终的运维水平还是要看人的能力。

5.场景灵活。

在场景灵活性上，云原生数据库比传统数据库要低，因为所有的能力都比较封装，定制和DIY的能力比传统数据库差。

那么问题来了，了解了云原生数据库与传统数据库的差异化能力后，我们应该如何构建云原生数据库呢？ 渤海银行的一些经验，或许可以为更多的银行企业提供借鉴和参考。

2018年起，渤海银行引入专有云。 经过三年多的技术平台建设和操作系统的不断完善，基本形成了应用改造上云的标准流程体系。 升级部分重点和通用业务系统。 上云工作已经逐步完成，上云最重要的系统是互联网金融核心业务系统，承载了大部分的互联网业务和对外接口。 未来计划进一步完善多中心专有云系统，构建同城多活动、多地多中心的云系统。

如何按照规划搭建云原生数据库？

那么，从实践的角度来看，云原生数据库建设应该如何按照规划逐步落地呢？

首先，要完成同城三机房布局，巩固异地机房建设，形成同城三中心、多地多中心的格局。 另外，同城中心生产云有两个主机房，计算节点双活，包括缓存和MQ双活或双活模式，可支持同城机房快速切换. 其中，数据库采用同城三副本，更能满足RPO和RTO的要求； 存储层主要采用同城双活。 开发测试云与生产云处于同构状态，主要用于跨同城三中心，支持云上应用开发测试和全平台应用的版本升级。

二是在关键业务系统承载能力方面，建设互联网金融核心数据库系统和互联网业务中台。 网上银行等。 目前，该系统已完成云上建设和生产。 由于业务系统本身非常复杂，对数据库技术的要求更高。

如图所示，业务逻辑层包括账户中心、鉴权中心、产品中心、配置中心，都是微服务中心； 向上是OLAP系统，包括流计算、列存、BI、实时分析的消息队列； 往下是数据缓存层，也是应用层和数据库之间的过渡层。 数据库使用云原生缓存数据库。 其中，关系型数据库有两种架构：一种是分布式的； 另一种是主备集群，通过数据库中间层进行管理。 数据迁移模块是数据从Oracle等云下数据库迁移到云上关系型数据库的通道； 数据集成模块是实现数据共享和互联的有效途径； 数据同步模块支持各种系统实时数据同步的各种需求； 集中监控模块对所有数据库产品进行统一管理和监控。

云原生数据库实践如何避免踩坑？

总的来说，云原生数据库的实践并不是什么“拍脑袋行为”，而是从云平台创建之初就依靠平台架构思维对数据库系统进行统筹规划。

具体而言，企业应关注三个关键点：

一、云专网与经典网络的融合； 部署私有云平台时，一般使用私有网络。 问题是专有网络如何与原有的IDC经典网络融合。 这是一个无法回避的话题，必须在初期规划时解决。 渤海银行的建设思路是减少不必要的网络交换机和防火墙限制，避免云端系统和云端系统相互访问时对数据库网络节点造成不必要的开销。 如果网络整合没做好，数据库整个链路会产生一定的网络延迟，对业务影响很大。

第二，根据数据库产品特点和业务应用场景，提前规划好数据库产品部署方式。 现在，大多数云厂商都可以提供多种部署方式，包括容器部署、虚拟机部署、裸机部署等等。 那么，如何部署关系型数据库就需要根据实际场景来规划了。 目标是充分发挥各种数据库产品的优势，提高整体性能，提高资源利用率。

第三，必须提前设置云内外互系统的访问规则。 云内外的互访数据库和数据库之间的场景需要提前规划，并梳理出相应的场景。 在后续应用上云、上云改造过程中，必须进行场景限制。 应用程序不能基于云，架构可以随意更改。 而是需要在场景范围内做建筑设计。 最终建设目标是降低数据库链接异常的概率，方便后续问题的排查，提高云上云下应用互访效率。

众所周知，银行在使用传统数据库时有很多规定，在项目开发过程中必须严格遵守。 其实云原生数据库也是如此oracle数据库缓存机制，只不过云原生数据库需要使用多种架构来对应多套开发规范。 比如事务型数据库、缓存数据库、大数据产品都有自己的通用规范； 在云原生系统中，也必须遵循相应的通用规则。

同时，银行重点业务对连续性要求较高，同城异地灾备能力尤为重要。 与传统架构相比，云架构的同城容灾能力更加复杂，实现难度也更大，其中数据库容灾系统的规划建设最为重要。

对于容灾系统的建设，无论是国内领先的厂商还是新兴的厂商，在对银行业务的理解和系统架构的部署上还有进一步提升的空间，尤其是内部系统的建设和规划。同城容灾和异地容灾系统，还比较简陋，所以在云原生系统和云原生数据库的选择上，必须在最初的架构设计时就做好同城容灾和异地容灾的选择。

容灾架构的选择：一是集群内容灾； 另一个是集群之间的容灾。 集群内容灾采用MySQL主从或Oracle RAC架构部署在同城跨机房环境中。 一个集群的每个节点被打散，分布到不同的机房。 事实上，这种方法有利也有弊。 好处是可以利用数据库集群原生的容灾能力，实现同城高可用。 实现难度很小oracle数据库缓存机制，几乎没有二次开发的地方，切换能力也可以复用； 缺点是在扩大集群的同时，大大增加了集群各节点间的距离，提高了节点间的通信延迟。 对比很多银行的机房环境，同城机房之间的距离大多在40-70公里之间，对应的光纤距离在50-100公里左右。 因此，需要详细评估对集群节点分离的影响。 因为延迟会直接影响数据库各个节点之间的通信，也会影响业务交易的响应时间。 集群间容灾是指数据库的两个或三个集群之间进行数据同步，以保证各机房数据的可用性。 但是集群切换时数据的一致性很难保证。

值得一提的是，银行关键业务系统的容灾对RPO和RTO有着严格的要求。 例如，RPO 的大小衡量数据在同城切换中可能丢失多长时间。 RPO=0 的要求是不得丢失任何数据。 RTO表示同城切换后整个数据库需要多长时间才能恢复，一般是几秒或者十几秒。

总的来说，专有云架构的同城容灾需要从整个平台层面进行管控，包括三个机房的应用和数据库部署架构，难度比传统架构技术高，而且在同时，要保证同城RPO为零，所有数据都能完整保留。

构建容灾系统最大的难点在于应用之间的关系。 传统的银行体系包括大型国有银行、股份制银行和城市商业银行。 大多数机构目前处于结构转型阶段，许多大型银行的关键业务仍在IBM大型机上运行。 从国家的角度来看，云架构和传统架构必须长期维护和使用。 无论是自建云还是专有云，都必须存在云上的关联访问场景。 除了应用链路和访问效率问题，容灾系统的建设也面临着很大的挑战。 因为在大多数情况下，云上和云下切换应用的规则和逻辑是不同的，单边切换时如何保持系统间的互访？ 同时，如何保持各项业务的连续性？

渤海银行的解决方案是通过全球DNS改造和全球域名解析来解决应用系统关联问题。 目前商用私有云基本可以在云端实现全DNS访问，数据库集群和中间件产品也可以通过域名访问，但是传统银行架构下的大部分应用都是通过IP直连或者VIP访问方式。 DNS改造就是用一个域名对应多个服务IP或VIP。 即使切换集群时VIP发生变化，只要多个VIP中有一个处于活动状态，就可以成功解析。 无论应用如何上云下云，相互访问的规则是不变的。

总结：其实根据经验，云原生数据库和云架构并没有统一的选择标准。 企业如何选择云架构，如何对待云原生，要根据自身的实际情况进行分析判断。

整理：李黛丽