作者：卢秀红
编者按
互联网银行的业务模式天然具备“海量用户、高频并发、长交易链路”的特征，传统集中式数据库架构在应对互联网贷款业务的爆发式增长时也会遭遇严峻挑战。基于对技术架构先进性的深度考量，该银行将 TiDB 确立为核心数据库技术。
TiDB 成为支撑其互联网贷款、支付清算、经营分析等核心业务的重要引擎已有八年时间。该银行根据不同业务的特点和需求，将 TiDB 集群进行了精细化划分，形成了五大核心集群，每个集群专注于不同的业务场景，实现了资源的优化配置和性能的最大化，下文将对其数据库实践和历程进行详细分享。
五大集群架构的 TiDB 全场景技术与收益验证
金融连接器集群：高并发贷款业务的“最佳拍档”
金融连接器集群是该银行最早应用 TiDB 的场景之一，主要承载互联网贷款系统。作为一家互联网银行，其贷款业务具有典型的"小额高频"特点，并且交易链条长。从用户提交申请到最终放款，需要经过多个环节，包括风控模型计算、多方数据查询等。虽然用户对延迟的容忍度相对较高（分钟级响应），但高并发和海量数据处理是该场景的核心挑战。TiDB 的分布式架构正好满足了这些需求，能够轻松应对十几万笔/天的贷款申请量，确保系统在高并发下的稳定性。
最早用单机库的时候，系统经常被高并发的贷款申请冲垮。2018 年以后，这个系统就一直稳定运行在 TiDB 上，从 v2.1 版本到现在的 v7.1 版本，从未出现过重大故障。如今，该集群中的单表数据量已经达到 4-5 T，性能依然保持稳定。不需要做任何分库分表操作，只需要将数据直接存入 TiDB，它就能自动处理，这大大减轻了 DBA 的工作负担。
连接交易集群：海量数据的高效查询支撑
连接交易集群主要承载两个关键业务系统：统一用户中心和综合作业柜面。
统一用户中心是该银行的用户数据核心，存储了全行 4000 多万用户的基本信息，包括身份证号、手机号、卡号等。该系统的特点是数据插入操作频繁，但更新操作较少，因为用户的基本信息相对稳定。4000 多万用户的数据，在传统数据库中管理起来非常困难，尤其是在高并发的查询场景下。TiDB 的分布式架构使得我们能够轻松管理如此海量的数据，同时保证了查询的高性能。
综合作业柜面系统则是该银行内部业务人员使用的系统，主要用于资金圈存、内部账调配等操作。虽然使用人数较少，但该系统涉及核心业务操作，对数据的准确性和可靠性要求极高。TiDB 的强一致性特性确保了这些操作的安全性和可靠性。
经营分析集群：海量数据的处理与加工利器
经营分析集群主要用于处理银行的批量业务，这是银行日常运营中不可或缺的环节，集群需应对二代征信报送、成本分摊系统、统一对账平台、一表通报送等场景。
批量场景的最大特点是海量数据处理和复杂的数据加工，每一天该银行都需要运行大量批量任务，包括财务核算、贷款统计、利息计算等。每天需要将大量的明细数据加工成汇总数据，生成各种报表，并向监管机构报送数据。TiDB 在这方面表现出色，能够高效处理这些批量任务。
在线归档平台：海量历史数据查询的最佳选择
在线归档平台是该银行解决支付业务历史数据查询的关键方案。作为一家拥有支付牌照的银行，该银行每天处理大量支付交易，鉴于支付长链路特性，这些交易记录需要保存一定时间以便查询和对账。
支付业务每天有百万级的交易量，在线库只能保存 7 天的数据。但有时候用户可能需要查询更久以前的交易记录，这时候 TiDB 就发挥了重要作用。我们通过 DM 工具将在线库的数据实时复制到 TiDB 中，可以查询长达一年的交易记录。这种方案不仅解决了历史数据存储的问题，还利用了 TiDB 的海量查询能力，确保了查询的高效性。
进线归档平台：单机库数据归档的理想选择
进线归档平台是该银行解决单机库数据膨胀问题的重要手段。在银行系统中，许多单机库的数据量会随着时间的推移而不断增长，这不仅会影响数据库性能，还会增加维护成本。对于 DBA 来说，单机库数据量级失控是首要痛点。数据规模每提升一个数量级，维护复杂度与性能风险都会同步攀升。
因此，该银行技术团队制定了严格的归档策略，定期将单机库的数据归档到 TiDB 中。归档到 TiDB 的数据仍然需要保持可查询性，但查询频率相对较低。TiDB 的海量存储和高效查询能力正好满足了这一需求。我们可以将大量的历史数据归档到 TiDB 中，而不用担心查询性能问题。这不仅解决了单机库的数据膨胀问题，还保证了历史数据的可查询性。
TiDB 架构方案与最佳实践
在八年的 TiDB 使用过程中，该银行积累了丰富的架构优化和最佳实践经验。这些经验帮助该银行更好地发挥了 TiDB 的性能。
- 开发规范
要想充分发挥 TiDB 的性能，制定严格的开发规范是必不可少的。在长期的实践中，该银行形成了一套完善的开发规范，这些规范涵盖了事务管理、存储过程使用等多个方面，如对事务大小进行严格控制，有助于减轻数据库的提交和回滚压力，提高整体性能。
在存储过程和触发器的使用上，该银行前期采取了谨慎的态度，研发团队尽量避免在数据库中使用复杂的存储过程和触发器，而是将这些逻辑放在应用层处理。认为这样可以减轻数据库的负担，使其更加轻量化，专注于数据存储和管理。这种做法的背后是该银行对数据库和应用层职责的清晰划分。
该数据库做的事就让数据库做，无需强推应用层解决。意味着将回归数据库核心能力，部分场景功能下沉。
- 场景选择
该银行的实践表明，根据不同业务场景的特点选择合适的数据库技术至关重要。该银行的数据库策略是”因地制宜“，根据实际需求进行选择，尽可能发挥数据库技术的优势。对于简单的业务场景，银行可能会选择 MySQL；然而对于高并发、海量数据的场景，TiDB 是首选。
2019 年，该银行在贷款系统中正式上线 TiDB。当时 TiDB 的研发团队在银行现场支持了很长时间，确保系统的顺利上线。
- 硬件配置
在 TiDB 的硬件配置方面，该银行也积累了丰富的经验。合适的硬件配置是充分发挥 TiDB 性能的重要基础。从 2017 年开始，该银行就使用 NVMe 硬盘和万兆网卡来部署 TiDB，这些高性能的硬件设备对于分布式数据库来说至关重要，能够显著提升数据读写速度和网络传输效率。
TiDB 使用收益：性能提升与成本优化显著
在八年的使用历程中，该银行携手 TiDB 实现了收益的显著增长，这些收益不仅体现在性能提升和系统稳定性上，还体现在成本优化和运维效率提升等多个方面。
性能提升：从单机瓶颈到分布式扩展
TiDB 的分布式架构彻底解决了该银行面临的单机数据库性能瓶颈问题。以贷款系统为例，从最初的单机库无法支撑高并发交易，到如今在 TiDB 上稳定运行，单表数据量达到近 5T，性能依然保持稳定，这充分体现了TiDB 在性能方面的优势。
我们发现，对于那些不愿意进行分库分表的业务，使用 TiDB 是一个非常好的选择。只需要对 TiDB 的一些规范进行调整，就可以满足业务需求，这比进行分库分表改造的成本低得多，研发团队也更愿意接受。
今年，该银行将 TiDB 全部升级到 7.1 版本后，实现了性能的多倍提升，这不仅满足了银行当前的业务需求，还为未来的业务增长预留了充足的空间。
成本优化：服务器数量大幅减少
性能的提升直接带来了成本的优化。通过版本升级，该银行成功将 TiDB 服务器数量减少了 60-70%。不仅降低了硬件采购成本，还减少了机房空间、电力和冷却等方面的支出。这种成本优化不仅体现在硬件方面，还体现在运维成本上。服务器数量的减少意味着运维工作量的降低，DBA 可以将更多精力放在业务优化和创新上，而不是繁琐的服务器维护工作。
稳定性提升：从频繁故障到全年无休
在使用 TiDB 的早期版本（如 V3.0、V4.0）时，该银行也曾遇到过一些稳定性问题，如 DM 同步性能问题等。但随着 TiDB 版本的不断升级，尤其是在升级到 7.1 版本后，系统的稳定性得到了显著提升。“升级到 7.1 版本后，这一年来系统非常稳定，我们几乎没有再向 TiDB 团队寻求支持。”卢秀红表示。这充分说明 TiDB 已经成为一个成熟可靠的数据库产品，完全可以满足银行核心业务的需求。
技术演进：从功能满足到创新驱动
该银行在使用 TiDB 的过程中，也见证了 TiDB 的技术演进。从 2.0 版本解决单机库扩展问题，到 3.0 版本引入悲观锁支持核心金融场景，再到 4.0/5.0 版本解决热点问题和提升性能，每一次版本升级都为该银行带来了新的功能和性能提升。
3.0 版本引入的悲观锁对我们来说非常重要。在这之前，我们一直认为乐观锁不适合银行核心场景，因此迟迟没有将 TiDB 应用于核心业务。悲观锁的引入改变了这一局面，使我们能够将 TiDB 应用于更多关键场景。
金融级数据库选型建议与规划思考
基于八年实践，该银行提炼出金融级场景化数据库选型建议。这些建议不仅基于技术考量，还充分考虑了业务需求、成本效益和未来发展等因素。
-
优先推荐 TiDB 的场景：
- 支付/贷款业务：长交易链路、高并发、海量（历史）数据存储（如贷款与支付归档）；
- 批量处理：监管报送、日终跑批等大规模数据加工；
- 历史数据查询：超过单机库承载能力的冷数据访问。
-
需应用适配的场景：
- 低延迟联机交易：如手机银行登录、热点账户更新（可通过应用层分桶或缓冲表优化）；
- 核心系统热点记账：分布式事务延迟高于单机库，架构使然需理性看待，可考虑通过应用来改造。
结语
在该银行八年的数据库实践中，TiDB 以存储级分布式架构、全局事务支持与 HTAP 能力为核心优势，有效解决大表处理、实时同步等业务难题，支撑其数字化转型。该行部署的 5 大集群覆盖核心交易、线上贷款及经营分析等关键场景，管理超 600 TB 数据，服务器规模逾 50 台。
TiDB 历经版本迭代后稳定性与性能显著增强（如 7.1 版本实现几乎全年零故障运行）。未来，在计划测试 TiDB 8.0 的同时，该银行的数据库规划将围绕 "协议聚焦、架构精简、能力回归、容器审慎" 展开，在分布式优势与金融场景特性间保持务实平衡。