如果你对该问题感兴趣的话，推荐你看看《分布式数据库金融应用发展报告》这篇报告，下面是部分摘录的内容，具体请以原报告为准。
1.应用设计灵活性
以银行为例，银行信息系统架构由应用架构，数据架构， 基础架构三部分组成。应用架构主要关注业务功能如何实 现，定义应用与应用系统，及其交互集成关系；数据架构主 要负责数据的全生命周期，包括数据产生、流转、整合、应 用、归档；基础架构就是计算、网络、存储、基础软件、灾 备、安全等。
（1）该架构的灵活性方面可能存在如下挑战
复杂核心系统难管理和迭代。现有架构中，所有业务流 程均要走到核心的会计/账务系统，一旦核心系统崩溃，将导致银行所有业务全部停业。具体来看即是业务连续性差和 可迭代性差。
架构缺乏弹性的系统设计。目前大多金融应用架构很难 应对业务突发流量，即不够“弹性”。例如在应对“网购日” 业务的增长时，对网上银行系统 WEB 节点、APP 节点进行扩 容。整个扩容过程需要经过 4 个部门多个专业领域的人员相 互配合，进行 50 个操作步骤，耗时数周才完成。
系统建设周期过长。现基于“大集中”的应用设计方式， 产品创新升级迭代需要经历“原系统改造”、“设计开发” “测试”“试点”“上线”等阶段，整个生命周期大概需要 三个月到半年。
（2）应用设计建议如下
金融业务可以通过分布式架构动态扩容等技术应对业 务洪峰的来临，依靠天然的“数据分散”能力使得真正的业 务双活，甚至多活得以实现，让业务上线更平滑更快速。 具体的应用设计思路与流程可以做如下参考：
金融核心系统由集中式走向分布式架构的总体设计大 致有两个方面，一方面是业务由外围到核心逐步下移至开放 平台或开放分布式平台，直至完成分布式改造；另一方面是 建设双核心，在原来集中式核心基础上将二三类账户独立出 来，建设互联网金融分布式核心系统。就实施流程来看，从 集中式往分布式架构演进可分为五个阶段：API 化改造，即 核心业务进行 API 化改造，用 API 网关替代传统 ESB，这个 阶段可以支持开放银行。部分业务卸载，即启用“大核心小外围”策略，将小部分业务卸载到开放平台。部分核心保留， 即过渡到“大核心大外围”状态，将少数业务（账务、存款 等）模块保留在传统核心，其他业务系统（账务系统的查询 等）都卸载到开放平台。双轨并行，即“传统核心”和“分 布式新核心”双轨并行（一般Ⅱ/Ⅲ类账户基于新核心，Ⅰ 类账户保留在传统核心）。全面核心升级，即全部完成分布 式新核心替换，Ⅱ/Ⅲ/Ⅰ类等账户均在新核心。
2.运维管理易用性
目前国内金融机构面临大量的运维人力成本和资源成 本，有大量的遗留陈旧系统运维困难。
（1）挑战如下
平台自动化程度低。传统的银行应用系统及基础设施平 台，采用非云的部署方式。各个应用部门各自负责自身应用 的生命周期管理，各自采用不同的运维管理工具和技术栈， 自动化程度依赖个人技术能力，不同企业不同部门之间差异 较大。
架构标准化程度低。过于复杂的分层 IT 架构让整个系 统分成了网络传输层/存储设备层/服务器层/操作系统层/ 数据库层/中间件&运行库/应用软件等。企业一般会从不同 的供应商分层采购不同的设备及软件。IT 行业在标准化还在 起步阶段，导致不同厂家的异构设备之间接口不同，适配困 难，模型不统一，没有办法使用一套通用的管理系统进行运 维管理。
设备管理操作复杂。传统的集中式架构主要是以 IOE（即IBM、Oracle、EMC）三家厂商主导的信息系统架构。随着 IBM/Oracle/EMC 在中国的市场空间逐步缩小，相应的人才获 取也更加困难，有经验的人才更是稀缺，导致系统的运维管 理出现人员真空。
（2）建议如下
推荐采用本地化部署结合公/私有云共同管理的设计思 路。在核心业务系统，采用业务本地化部署与分布式数据库 结合的方案，在加强安全性、可靠性，也能让应用数据具有 “物理集中逻辑隔离的特性”。在非核心业务系统，可依托 云服务提供商的云管能力，构建多云一体化管理和 IT 服务 平台，使多资源统一纳管，多地域统一权限，多服务统一入 口。实现银行 IT 资源统一管理、灵活调度，支持应用多活 部署，组件版本同步更新，支撑业务跨区灰度发布，充分发 挥分布式计算功能，快速建立统一运维人才培养体系，满足 分布式架构转型建设需求。
3.资源成本利用率
金融机构业务运转所需要的各类资源需求相比各行业 来说属于较高的水平，尤其是硬件资源。但是目前的应用经 过长期“堆叠式”建设，在利用率上问题凸显。在资源成本 利用方面，金融应用综合建设成本较高，面临着“复用困难” 和“成本高昂”的双重问题，结合实践情况来看，采用资源 共享是提升资源利用率的较优方案。
（1）挑战如下
“烟囱式”架构利用率低、复用困难。传统的 IT 系统采用静态资源分配、分散管理：各分散的业务部门通常按照 规划的最大资源申请物理机、虚拟机资源，物理资源仍被私 有化，无法实现共享，利用率低。同时，从银行业务系统来 看，复杂的业务流程和架构导致企业中应用系统数据库繁多 且分散，并且各个应用之间的数据是隔离的，无法完全共享。
集中式架构设备成本高昂。基于 IBM 大型主机的银行集 中式系统总成本（购买+维护）远超过基于 x86/ARM 的分布 式系统，成本压力愈发明显。在存量博弈时代，银行业竞争 加剧，更低的 IT 维护投入带来更强的成本优势和更大的创 新空间。互联网银行的崛起进一步考验传统银行的成本控制 能力。
（2）硬件、软件和数据资源共享建议如下
硬件资源共享。通过底层虚拟化/云化技术，将硬件资 源池化，各应用系统按需动态申请资源，共享资源池。采用 跨 CPU 架构的云体系，最大程度利用原有本地服务器资源。
软件资源共享。通过将应用软件微服务化、组件化，不 同应用之间共享相同的公共服务，灵活安装卸载功能组件， 避免二次开发。通过云化多租户特性实现多用户环境下共用 相同的系统或程序组件，并且可确保各用户间数据的隔离 性。
数据存储共享。首先采用分布式数据库，将业务的数据 物理集中起来，实现打破数据孤岛的能力。再设立数据标准、 进行数据立法，采用统一的数据库设计规范，让业务对数据 的使用标准化。最后通过不同应用之间或者不同数据处理系统之间数据流动、同步，实现数据源头的统一，数据一次加 工，多次使用。
4.数据库设计合理性
金融应用在数据使用方式快速变化的冲击下，往往需要 灵活调整其数据模型，尤其是数据库的设计方案。但是调研 得出应用数据库的设计并不能最好地发挥出数据库管理系 统软件的能力。金融应用在数据库设计时不够严密和谨慎， 可能导致后期产生诸多问题，例如“应用逻辑与数据库绑定 难运维开发”“应用双写方案欠缺导致迁移难”“应用设计 前瞻性不足未能充分利用分布式产品能力”等。
（1）挑战如下
应用逻辑与数据库耦合度过高。由于历史原因，受限于 早期的网络带宽和延时瓶颈，应用开发者往往选择将业务逻 辑下沉至数据库端，以减少网络反复开销。但是有利有弊， 此类方案在应用开发采用大量存储过程，就导致难以拆解运 维升级。不同数据库的存储过程语法定义不同，这给数据库 迁移带来了极大的困难，应用迁移至新的分布式数据库需要 做大量的改造工作。以工行为例，某应用存储过程代码上千 万行，即使通过迁移工具自动迁移 90%，仍有百万级代码需 要人工迁移。这些代码往往比较陈旧，已无人有能力维护改 造。
应用标准双写方案缺乏。应用双写是保障应用与数据库 解耦的良好手段。整个双写方案涉及数据库并行、回切、监 控、同步等多个技术点和策略。同一个银行不同应用使用的方案都不一样，导致在数据库迁移的过程中每个应用都需要 自行开发一套方案，没有标准化方案。
数据库设计未考虑分布式化。分布式数据库的数据存储 原理与传统集中式数据库原理不相同，对于数据的使用高效 性可能因为应用侧表设计不合理导致而降低。所以需要针对 应用侧的库表进行分布式设计，例如热点拆分和数据对齐。
（2）针对这种情况，建议如下
注重应用逻辑设计的通用性。对于未来有业务扩展性需 求的（敏态应用）应用系统，在设计业务逻辑的时候，尽可 能避免采用存储过程等下沉业务逻辑至数据库的技术，并采 用分布式设计思路改造。对于未来没有业务扩展需求的（稳 态应用），保留原有存储过程等下沉业务逻辑至数据库的技 术，并通过完善自动化迁移工具的迁移效率，降低应用改造 成本。
设计应用层双写方案。在应用侧设计数据双写方案，考 虑可对数据库更换的情况，以避免出现部分数据库无法完成 数据同步的情况。具体来看，可以应用侧改造做双写表，利 用数据同步工具同步应用相关参数表，由于目标库的数据有 延迟，比对的数据以成功写入目标库的部分为基准，反向与 源数据库数据进行校验。
进行分布式数据库设计。分布式数据库基于其数据物理 分散的原理可以利用更多的物理资源提供数据服务，但同时 也需要更为严苛的网络环境。在此情况下数据的分布方式会 直接关系到应用的性能，所以按业务数据使用特性选择数据分布策略才能更好地利用分布式数据库能力。举例来说：一 般分布式数据库有两种数据分布方式，复制表方式将表中的 全量数据在集群的每一个数据节点上保留一份，适用于小 表、维度表；哈希表方式将表中某一个或几个字段进行 hash 运算后，生成对应的 hash 值，根据数据节点实例与哈希值 的映射关系获得该元组的目标存储位置，适用于数据量较大 的事实表。
分布式数据库产业化时间较短，不管是产品成熟度还是 生态工具层面都还不太完善。金融机构在使用分布式数据库 的过程中也发现了较多不足，性能和兼容性是金融机构使用 分布式数据库时面临的突出问题，需要金融机构与产业机构 通力合作，通过实际应用场景验证打磨产品，促使产品不断 成熟。
1.产品高性能
金融应用数据库是现代金融企业的业务基础。金融应用 数据库复杂的数据结构和业务逻辑。
（1）目前金融机构的分布式数据库性能挑战如下。
系统复杂性增强。金融应用系统需要和同一个企业内部 的其他系统通信，易造成数据库在复杂逻辑下的性能衰减。
系统压力增大。区别于早期的金融业务，目前的应用系 统有来自不同的数据使用方式，通常需要支持大量并发用户 同时进行数据查询和修改操作，对数据库并发处理能力要求 较高。
历史数据迁移。开发新的系统时，需要迁移已有的数据， 由于数据转换规则复杂、数据量大，容易出现性能问题。
数据资源争用。由于应用程序代码没有很好利用底层数 据库的功能，导致多用户并发访问系统时，对共享的资源造 成过度的竞争，致使系统性能受到严重的限制。
以上的客观问题会导致分布式数据库的研发存在很多 的挑战，具体来看有如下几个方面：
物理资源利用不充分。现在金融业分布式数据库架构设 计大多沿用成熟开源/闭源代码进行迭代。受限于数据库稳 定性考量，底层物理资源调度模块大多没有进行重做或改 造，所以在对多核芯片和新型网络设备使用上还不足。
内核调度设计过于陈旧。以 PostgreSQL 为例，早期设 计考虑如今大数据压力，采用多进程调度方式设计，会带来 性能不足。
数据库中间件臃肿。在分布式数据库设计中，采用中间 件来对数据库实例进行调度的方案如果考虑不完备会在业 务复杂性较强的情况下导致中间件压力增大从而引起性能 恶化。
（2）从数据库产品角度建议如下。
加大对真实场景的研究。提升最佳实践能力，将数据库 特性更精确地转化为业务性能。对数据库底层框架需要更多 的自主设计和原创性设计，从架构设计之初就需要考虑到如 今和未来的大数据、大压力情况下的高效应用。同时也需要提升对如 NVME 磁盘、RDMA 网络、NUMA 架构芯片的支持，将 更先进的硬件充分利用起来完成应用的性能需求。
采用方案进行性能优化，例如：减少磁盘访问。通过创 建并使用正确的数据库索引和优化 SQL 路径来减少直接的堆 数据磁盘访问。减少内部网络传输。采用数据分页、精简字 段和算子下推等数据库优化方式，降低网络开销，提升分布 式数据库网络利用率，从而加速性能。减少外部网络吞吐。 通过预处理、批处理、存储过程、结果集游标等方案，将业 务逻辑后推至数据库端，减少大量数据吞吐，从而加速性能。 减少 CPU 资源消耗。业务层设计时绑定变量方式参数传递、 减少不必要排序、减少比较算子来降低数据库算力浪费。通 过 NUMA 绑核等减少跨核、跨处理器竞争，编译执行（LLVM）， 从解释执行向编译执行转变来降低 CPU 中断频繁引起的性能 下降。
2.数据安全性
数字经济时代，数据的价值得到了普遍认可。中央也将 “数据”作为五大生产要素之一写入文件。金融业所拥有的 包含个人可识别信息及账户资金状况的数据关键且重要，如 有泄露会造成巨大损失。同时，随着计算机网络技术的高速 发展和金融电子化的逐渐深入，越来越多的银行业务系统通 过网络将数据集中起来，利用功能强大的数据库来存储和管 理业务数据、客户资料等重要的金融信息。因此，金融数据 库的安全已成为金融计算机信息系统安全的关键。
（1）常见的数据库安全问题如下。
敏感数据的共享安全问题。对敏感数据使用范畴定位不 清晰，导致敏感数据泄露； 违规操作造成的数据泄露和非法篡改风险。黑客或犯罪 分子在用户存取数据库时盗用用户名和用户口令，假冒合法 用户偷取、修改甚至破坏数据； 安全事件难以定责与取证。出现安全事件后，如何留痕 取证，如何定责以防止后续安全事件发生； 脆弱的用户账号设置。如果密码相对简单或不进行定时 修改，黑客或犯罪分子会更容易破解数据库； 粗粒度的数据库存取控制。对数据库的存取控制应以更 细粒度操控，否则将会倾向于给应用超过其需求的权限，造 成使用风险； 密码以明文方式存储。 数据库方面的安全漏洞。
（2）建议如下。
对数据库提供商来说，除了依赖数据库外部的安全防护 手段以外，在数据库内核中也需要设计更高维度的安全防护 手段，包括但不限于采用国密 SM 体系及更严格的标准来设 计数据加密体系；提供强制访问策略对用户和实体进行权限 设计；设计黑白名单管理，让用户能在数据库访问侧屏蔽非 授信访问；定义更严密的口令系统，提供多维混合加密的默 认选择甚至提供硬件加密接口等；引入隐私计算、区块链等 前沿安全技术对数据文件进行加密；定期同步数据库安全补 丁等等。
对数据库使用者来说，也可以采取一定方案提升数据库 安全等级，包括但不限于：采用严格的身份认证提升数据库 防攻击能力，包括但不限于使用更复杂的口令、采用电子令 牌和数字证书等。使用更细致的数据访问控制解决敏感数据 “物理集中逻辑隔离”的难点，包括但不限于将控制权与访 问权分离，对行级数据进行访问控制。提升数据保密性缓解 数据泄露和篡改问题，包括但不限于选择更合理的选择加密 字段、安全高效的加密算法、对密钥的妥善管理、对动态数 据脱敏以及全密态数据库等值查询等。加强审计追踪和漏洞 扫描解决事件发生后追责问题，包括但不限于启用系统使用 审核和用户操作审核。加强数据库状态监控以预警安全事 件。
3.架构可用性
没有任何一个单一的系统可以保证长期无差错的平稳 运行，但是在金融这样一个特殊的领域，无论是从监管要求 来看，还是从业务需求本身来看，7*24 小时不间断的服务都 属于基本要求，二者之间的矛盾就是高可用的问题。
数据库高可用（High Availability）是金融系统架构 设计中必须考虑的因素之一，它通常是指，通过设计以减少 数据库不能提供服务的时间。如果一台数据库能够不间断的 提供服务，那么这台数据库的可用性为 100%。如果数据库每 运行 100 个时间单位，就会出现 1 个时间单位无法提供服务， 那么该台系统的可用性是 99%。
高可用不能简单归类为“容灾”，即大范围、高烈度的故障，例如火灾、地震、洪水、大范围的停电，由于这种情 况往往导致本地环境全部不可用，所以一般称为异地容灾。 除异地容灾需求外，银行业真正关心的高可用是泛指非正常 情况下的故障停机，以及由于 IT 运维工作等原因带来的计 划内停机。
一个系统可能包含很多模块，如数据库、前端、缓存、 搜索、消息队列等，每个模块都需要做到高可用，才能保证 整个系统的高可用。
（1）常见的数据库高可用问题如下。
如何提供 7*24 小时持续不间断的服务。高可用的基础 需求，要求应用数据库在某一台机器宕机后，在某一时间范 围内可快速恢复访问。
如何应对机房整体故障和城市灾难等极端情况，保证数 据库在各种意外情况下都能持续提供服务。即异地容灾需 求，在本地机房全部故障后可启用异地机房提供服务。
如何保证切换后的数据库是最新数据，且在切换过程中 数据不会丢失。需保证不同可切换数据库的数据一致性；在 切换过程中，不提供数据库服务，且不会丢失旧数据。
如何提高高可用的运维效率。高可用应为系统自动判断 和切换，无需运维人员手动操作；如有异地容灾需求确实需 要手动操作的，应尽量简化运维操作流程，节省运维操作时 间。
数据库的高可用是内核与外部配套软件的共同保障，对 数据库提供商来说，需要提供相应的接口和功能。高可用分为两个维度，即内部和外部，内部主要是需要内核支持，外 部则是可以内核支持或者依靠外部工具支持。
（2）综合建议如下。
数据库内高可用。系统采用一个主库和多个备库方式， 其实现原理主要是基于日志的主备复制，主库操作以日志的 形式发送给各个备库，备库接收到日志后进行数据备份。这 种方式的好处是一个主库可以连接多个备库，能很方便地实 现读写分离，同时，因为每个备库都在运行中，所以备库里 面的数据基本上都是热数据，容灾切换也非常快。这个方案 也并非完美无缺，如容灾切换时，备库一定要同步完最新数 据以后才能升级为主库，否则极有可能发生数据丢失的情 况。针对传统主备架构的一些问题，业界也逐渐研发出对应 的改进技术，如双主架构、日志自动寻址、异步复制改进、 多级流水线日志回放等。
数据库间高可用。基于一致性算法来做数据的同步，数 据库提供多节点一致性同步机制，利用该机制构建多节点同 步集群。多节点之间构建成了一个一致性的同步集群，客户 端可以读写其中的任何一个节点，任意一节点写入，其他节 点都能够将数据进行同步，因此，理论上每个节点都可以进 行读写操作。这种方式的容灾实现也比较简单，假设第二个 节点出现故障，系统只需要断开客户端对第二个节点的访问 路径，其他节点照常访问就可以了。
数据库也可以提供同城双 AZ（可用区）或者同城三 AZ 的容灾能力。当主用 AZ 故障后，能在 1 分钟内自动切换到备用 AZ，并且 RPO=O。同时，同城两个 AZ 可以双活，同时 对外提供服务。通过两地三中心等部署方式提供 Region 级 的容灾能力。当主用 Region 集群故障后，能切换灾备集群 接管业务。
4.数据库迁移
随着银行业务的不断发展，导致金融应用数据规模体量 的不断增大；同时，银行数据库由国外商业数据库向自研开 源数据库和国内数据库演进加快，这些变化都面临一个共同 场景：数据库迁移。
（1）大部分金融应用数据库的迁移面临的挑战如下。
异构数据库迁移难。异构数据库之间往往存在语法兼容 性问题，银行业前期使用的数据库往往为 DB2、Oracle 等商 业数据库，国内数据库对于它们的兼容性不足增加了对数据 迁移的难度，应用不仅要进行语法的兼容性改造，还需对国 内数据库不支持的传统商用数据库特性进行改造。
不同体系数据库迁移难。DB2、Oracle 等商业数据库为 集中式架构，目前主流的国内数据库支持通过分布式架构提 供更强的处理能力，其数据分布和银行业前期的架构完全不 同，造成了数据迁移前对数据库改造设计的复杂和困难。单 机数据库迁移到分布式数据库，其中涉及如何分库分表的改 造；分布式数据库有两种模式：一种是原生分布式数据库， 这种数据库屏蔽了分库分表的过程，由数据库层面进行解 决；一种是以集中式数据库为基础，在上层搭建分布式组件 的数据库，这种数据库可以屏蔽一部分分库分表过程，但仍需应用设计分库分表的依据和方式。
不中断业务迁移难。在金融数据库迁移时，诸多业务存 在严格的停机时间窗口，要求数据库在规定时间内完成数据 库的迁移；但由于银行业数据库数据量较大，在较短的时间 内无法完成离线数据迁移。在这种背景下，就要求数据库应 支持在线迁移方式，在不停机时在线同步数据，在停机后仅 迁移未同步完的少量新增数据。 数据库的迁移具体包括迁移事前、事中、事后三个阶段， 由数据库提供商配合数据库迁移方共同完成。
（2）建议参考方案如下。
迁移事前评估阶段。首先需要进行数据库画像，包括收 集系统环境信息（如硬件、操作系统、性能等）、收集数据 库实例信息（如架构、参数、数据规模、运行态信息等）、 收集数据库对象级信息（如结构信息、统计信息、访问特征、 预警类等）、收集数据库语句级信息（如 SQL 文本、执行特 征、执行计划等）；收集复杂应用信息（如存储过程、触发 器、函数以及执行特征等）。再次要对应用画像，包括对应 用架构、应用与 DB 关系、应用访问特征等进行描述。除此 以外还需要进行风险评估，包括但不限于源库使用集群、分 库分表等架构，做出提示；源库使用复杂结构（如分区表）、 不支持结构（LOB、可更新视图等），做出提示；源库使用 复杂 SQL（如多表关联）、特殊语法或方言等给出提示；源 库大量使用存储过程、触发器、函数等；应用使用何种访问 方式（如 java、c、go 等），对于某些旧有的方式予以提示；源库存在明显的性能访问高峰，明显的热点对象；源端数据 库总体或单体对象规模较大的情况。最后给出选型建议，即 迁移目标端在架构、结构、应用、性能指标等方面的基础抽 象后，根据源端和目标端情况，结合风险及性能要求给出适 配选型建议。
迁移事中改造阶段。首先需要对数据库对象进行改造， 即根据迁移目标端给出待迁移端到目标端的结构映射规范。 通过工具或者手动方式，基于给定输入，输出改造后的对象 结构。再次需要对 SQL 语句进行改造，通过工具或者手动方 式给定输入，给出改造后的 SQL；提供优化改写能力，而非 基于简单规则。此处需注意，语义等价性问题。接着是对应 用改造，应用改造包括对上层应用框架的兼容和对下沉逻辑 的改造，前者主要是提供对数据库驱动、访问链接、方言等 内容进行改造；后者主要是对存储过程的兼容和盖章。改造 完成后对比两侧的实现，验证处理逻辑是否一致。最后才是 全量和增量数据的迁移，全量迁移指的是基于指定时间戳前 的数据进行的数据迁移，增量迁移指的是基于指定时间戳后 的增量数据迁移，在迁移后需要进行数据比对。
迁移事后并线运行阶段。在并线运行阶段主要是进行数 据的同步，需要数据库提供商提供异构数据库间数据实时同 步能力。在数据同步的同时一定阶段时需要进行异步数据对 比，即提供异构数据源之间全量、增量数据对比能力。 在迁移完成后需要提供基础的运维保障，包括但不限于回切 演练支持、数据比对支持等。
