作者： 数据源的 TiDB 学习之路原文来源：https://tidb.net/blog/3755c292

注：本文总结自 TDBC 2024 可信数据库大会上平凯星辰城商行行业首席架构师庄培培内容分享

金融行业数字化转型成为必然趋势

当前金融行业系统升级由 IT 架构重构 及 业务需求升级 两方面共同驱动。在 IT 架构上，传统金融核心系统主要面向业务流程开发，采用大而全的竖井型架构模式，存在产品开发周期长、数据庞大业务繁杂、信息交换和共享效率低等问题。在业务需求上，金融行业需要满足互联网峰值流量、业务需求快速变化、渠道及产品多样化等需求。因此，金融行业迫切需要进行数字化转型升级，从而提升系统可用性、架构灵活性、海量业务承载等能力，分布式、微服务架构、人工智能等新兴技术越来越多的被应用于金融 IT 行业。

银行核心系统在发展历程中进行了多次的架构迭代，从早期的单机 / 网络核心（WTO 时代的胖核心到 SOA 架构的瘦核心）到后来的双核心（稳态集中式 + 敏态微服务），再到如今的分布式核心 / 无核心（微服务架构或单元化架构），架构的迭代对底层的数据库也不断地提出了更高的要求。

杭州银行新一代核心系统金融核心实践

杭州银行的新一代核心系统于 2023 年 11 月份成功投产上线，是国内首个 云原生 + 分布式数据库 + 全栈国产化 银行核心业务系统，数据库采用 TiDB 进行支持。整个项目经历 分布式数据库选型、外围系统试用、第一阶段互联网核心系统上线以及新一代核心系统上线 四个阶段。核心上线后运行平稳至今，联机交易和日终跑批性能均有较大提升，同时实现同城双活、同城 RPO=0 的两地三中心高可用容灾能力。杭州银行拥有近 2 万亿的资产规模，属于头部城商行，其在核心系统的技术选型和实践经验完全可以被其他城商行同业所借鉴。

在整个项目过程中，杭州银行对数据库提出了很多的系统需求。这些需求经过提炼后，大体上可以分为三类：架构视角、运维视角及研发视角。从架构视角来看，可靠性是第一位的、开发的透明化非常重要、重构好于平迁、微服务好于单元化架构（对于城商行体量而言，单元化架构的实现会导致运维和建设成本过高）、数据库厂商应提供标准产品而非定制化能力。从运维视角看，需要实现同城双活 RPO=0、支持通过线性扩展支撑集群未来增长、运维简单、适配多个平台、具备良好的易用性。从研发视角看，数据库应支持良好的分布式事务能力、读写热点的解决方案、适配批量框架实现多任务并发执行提升跑批效率、具有良好的技术生态。

架构视角

• 应用开发透明。TiDB 数据库“把复杂留给自己，把简单给到客户”，这是因为 TiDB 数据库对应用开发十分透明，用户可以像使用传统集中式数据库一样设计应用和开发代码，无需考虑分片键设计 (sharding key) 以及跨单元 join 性能问题等。

• 运维扩容透明。在 TiDB 数据库，应用不需要担心数据库表容量的问题，集群通过横向扩展可以支撑准 PB 级别数据库，单表大小可以无限扩展且性能没有拐点，而分库分表架构中单表容量通常受限于底层单个 MySQL 实例限制。

• 查询分析透明。TiDB 在存储上同时支持行存引擎和列存引擎，行存和列存的数据基于 Raft 协议实时同步。在查询执行时，优化器可以智能选择查询行存或列存，从而提供更高性能的 SQL 执行效率。

• 热点优化透明。读写热点问题在分布式数据库中是必然存在的问题，TiDB 数据库支持对热点数据自动感知且自动打散的能力，降低应用设计的复杂度，用户无需再为如何选择合理的分片键而烦恼。

大型银行通常选择单元化架构实现系统性能的提升，如基于客户号进行单元化拆分。然而对于中小型银行而言，从节约成本和降低运维复杂度角度，微服务架构则是更优的选择。总体原则是使用一套数据库集群来支持整个核心应用，当系统遇到瓶颈时，通常横向扩展应用容器的数量及分布式数据库节点数量来实现集群性能扩展。

TiDB 出色的水平扩展能力以及透明无感的扩缩容能力，使得它非常适合作为微服务架构底层支撑的统一数据库集群。在单元化架构体系中，TiDB 也可以用于承担全局管理单元、全局批量单元或数据汇聚单元的角色。

运维视角

TiDB 的存算分离架构使得 TiDB 可以实现灵活方便的扩缩容能力，可以做到计算层和存储层分别进行扩缩容。计算层 TiDB Server 负责接受应用端连接请求并进行语句的编译解析执行，当应用连接数不够或计算能力不足时，可以按需扩容 TiDB 节点数实现连接数的扩容。存储层 TiKV 负责数据持久化以及部分计算下推能力，当存储资源或下推计算能力遇到瓶颈时，也可以按需扩容相应的 TiKV 节点数。

无论是上层计算节点还是下层存储节点，TiDB 数据库在扩容时都可以进行任意节点扩容 (最少一个节点)，相比有些分布式数据库只能进行多节点扩容时性价比更高。核心系统通常是一个比较稳态的业务系统，但是每当遇到月度或季度结息批量场景时会遇到一个短暂的交易洪峰。基于 TiDB 优秀的扩缩容能力，选择在结算批量前一天临时扩容节点，待批量任务完成后再将新增的节点缩容回去，整个过程对业务完全无感知。

TiDB 在杭州银行核心系统中首次实现 双中心双活 的容灾架构，每个中心都能够接受完全相同的交易且支持按比例接受流量、无须控制交易类型。众所周知，基于多数派协议的分布式架构在容灾部署上，为了保证数据副本数为奇数，通常会选择采用三中心部署，如 2-2-1。

TiDB 实现了 DR Auto-Sync 技术，解决了很多城商行只有两个数据中心的容灾需求。基于 TiDB 的双中心双活容灾架构在中心切换时对应用层完全无感，这已经在今年 3 月份人行参与的容灾切换演练中得到充分证明，整个切换过程中交易没有任何损失。

在同城两中心基础上，核心系统为了满足更高等级的容灾保护能力，在异地增加一套独立的 TiDB 集群，通过 TiCDC 复制技术实现异步数据复制。基于同城双活 + 异地灾备方案，共同形成一套金融级高可用两地三中心方案。在完整的灾备方案中，还包含了其他几套辅助集群，如只读集群、测试集群、近线库、逃生库等，此处不作详细介绍。

研发视角

针对读、写热点问题，TiDB 拥有诸多的解决方案实践。在写热点方面，针对银行使用十分频繁的交易流水表，数据库支持散列写入的方式；在索引热点问题上，TiDB 基于 LSM Tree 的存储模型 可以很好的避免传统数据库中索引分裂造成的问题。

在读热点方面，TiDB 也做了多方面优化，比如对于不经常修改的参数表，支持缓存表功能，这就相当于在 TiDB 中内置了 Redis 能力。在业务层面，在交易逻辑中尽可能合并了高频请求。

在热点账号问题上，在与业务沟通后，将一些实时锁的问题替换为异步交易的方式，从而大大提升热点账户场景下的吞吐能力，尤其是内部户、集团户等场景。

前面提到核心架构目前主要采用单元化架构或微服务架构两种，在单元化架构下，TiDB 非常适合作为批量单元的后台数据库使用。通过 TiDB 产品方案中的 DM 数据同步工具，可以将多个 MySQL 分片库中的数据同步到 TiDB 集群，从而得到一份合库合表后的完整数据。在此基础上，通过区间分段方式将一个大的批量任务进行拆分，结合 TiDB 多节点并发执行能力，实现批处理效率的大幅提升。使用 TiDB 作为批量单元后台库可以实现批量任务和联机业务的完全剥离，从而有效保证联机业务的稳定性和批量任务的执行效率。

TiDB 作为分布式数据库本身在测试和发布的阶段沉淀了一套方法论，这种方法论后来也贡献给 CNCF 基金会，其开源产品为 Chaos Mesh。杭州银行核心项目过程中也充分利用了这套混沌工程体系来验证产品功能边界和非功能性需求，从而全面检验和提升分布式系统的稳定性。

银行引入分布式数据库是一个技术体系的革新，TiDB 在整个过程中与客户共同成长，提供了完善的培训机制，协助甲方共同锤炼人才队伍、培养人才梯队，并建立从开发到测试、从发布到监控再到运维的完整技术生态。