本文介绍了东吴证券旗下东吴秀财 APP 在数据库转型中选择 TiDB 的思考与实践。 原有架构使用 MySQL 分库分表和 MongoDB，但面临着架构复杂、业务扩展性不足、性能问题、开发和运维负担重等挑战。为了有效应对这些问题， 东 吴证券选择 将 MySQL 分库分表和 MongoDB 替换为 TiDB。这一举措极大简化了架构，实现了兼容 MySQL 生态、性能飞跃、金融数据强一致性的 HTAP 以及便捷运维等优势，提升了业务效率和管理效能。 未来，东吴证券计划进一步利用 TiDB 的特性，解决存量 MySQL 实例管理成本高的问题，提升资源利用率和运维效率。

本文作者： 东吴证券信息技术部 系统架构师 李豪奇

东吴证券股份有限公司（以下简称“东吴证券”）成立于 1993 年，是拥有全部证券类业务牌照的综合券商。2011 年 12 月 12 日，东吴证券作为全国第 18 家上市券商、首家地级市上市券商在上海证券交易所挂牌上市。东吴证券重新塑造了中国投资银行的业务模式，凭借差异化的领先优势，为客户提供全生命周期的金融服务。目前，东吴证券在全国设有 22 家分公司和 132 家营业网点。

数据库转型势在必行

东吴秀财 APP 是东吴证券倾力打造的新一代移动端财富管理平台，汇集了自助开户、行情交易、业务办理、基金理财、投顾资讯、社交分享等丰富业务功能，不仅满足用户基本的交易需求，还为用户带来个性化的理财体验。用户可以订阅“五牛组合”等资深投资顾问的股票组合，查看最新最全的重磅金融消息，并一站式购买爆款理财产品。东吴秀财 APP 开启了互联网理财服务的新模式，这些业务要求底层数据库具有非常好的开发敏捷性和业务弹性。

长期以来，金融行业主要依赖国外厂商提供的基础软件产品，尤其是在关键的核心数据库领域，使用由 Oracle 等国外科技公司的产品。然而，国外数据库产品存在技术壁垒，其核心技术封闭且不可控，版权费用高昂，存在着潜在的风险。在自主创新的环境下，选择国产数据库替代主流的国外商业和开源数据库，已成为当前的主要趋势之一。

东吴秀财 APP 是一款面向 C 端的应用，具有庞大的活跃用户群和流量，是一个具有强烈互联网属性的产品。其原有架构主要基于 MySQL ，并在部分场景结合使用 NoSQL 数据库，如 MongoDB 提供服务。部分 MySQL 实例基于模块和项目组独立搭建和维护，采用了基于 MyCat + 分库分表架构的逻辑集群。该架构存在以下问题：

• 架构复杂 ：使用多款数据库产品，一个模块的应用使用一个独立的 MySQL，当业务量增长时，还需要采用基于 MyCat 的分库分表数据库，对于一些文档类的场景还，还需要单独使用 MongoDB。多个数据库产品的堆积导致了烟囱式的发展，使得数据架构变得复杂，且无法有效解决业务问题。
• 业务扩展性不足 ：在东吴秀财 APP 的业务中，尤其是用户行为、运营、消息等业务都呈现出明显的互联网特征，数据需要根据业务的需要实现灵活的扩展。然而，无论是单机 MySQL，还是基于 MyCat 的分库分表数据库，都未能满足这种灵活扩展的需求。
• 性能不能满足要求 ：业务对数据插入和查询的效率要求相当高，尤其是在业务高峰期，性能要求更为严格。在一些复杂场景下，查询响应时间甚至超过了 10 秒，这对于 C 端应用来说是无法接受的。
• 开发心智负担重 ：对于分库分表的集群，研发层面需要提前设计好分库分表的逻辑，原本由数据库处理的工作需要应用程序来实现，这给研发人员带来了相当大的心智负担。
• 运维复杂 ：一方面，在监控和运维方面需要投入大量精力。最重要的是，许多独立的 MySQL 实例只是最基本的读写分离或者主备架构，无法做到故障情况下的自动恢复。

使用一个TiDB 替换多个数据技术栈

在经过对多款产品进行严格测试验证并综合考虑研发、运维等方面的因素后，东吴证券最终选择了 TiDB 分布式数据库作为东吴秀财 APP 底层的数据库产品，一举替换了 MySQL、MongoDB、MyCat 等多个数据技术栈，解决了日常业务中的各种需求和痛点。经过三年时间的实践探索，TiDB 在 MySQL 兼容性、功能、性能、运维层面的表现达到了业务预期，主要情况如下：

东吴证券秀财 APP 数据架构示意图

1 兼容 MySQL 生态，应用平滑过渡

在研发层面，无需修改代码即可实现从 MySQL 平滑迁移至 TiDB。 对于涉及大事务或特定函数的场景，可能需要考虑一些优化和调整，但改造成本相对较小。 此外，无需引入额外的数据库驱动，对于使用标准框架进行开发的项目组来说，几乎没有额外的学习成本。 对于遗留项目的迁移，TiDB 提供了一系列与 MySQL 生态兼容的工具，支持多种迁移和并轨的运行模式，可以实现应用的平滑过渡。 总体上做到了对应用研发人员的透明无感知。

2 性能实现质的飞跃

得益于 TiDB 原生分布式架构设计，可按需对计算和存储节点分别进行在线扩容或者缩容，而这个过程对应用运维人员是透明的。 在单机数据库无法应对因数据爆炸性增长的场景下，TiDB 成为一种性价比高的解决方案，其规模可以线性扩展，集群容量已经支持到 PB 级别。

TiDB 提供灵活的可伸缩性，除了实现大容量之外，还带来了高性能。在迁移到 TiDB 后，在结构和查询语句设计合理的前提下，各个项目组基本上都反馈性能得到了大幅提升，从原来的 10+ 秒提升到 100+ 毫秒级别，实现了质的飞跃。TiDB 提供了一系列监控、诊断和巡检工具，通过可视化的方式方便地分析和识别性能瓶颈，并对整个集群进行健康检查。

3 满足金融数据强一致性的 HTAP

TiDB 提供了行存储引擎 TiKV 和列存储引擎 TiFlash 两款存储引擎。 TiFlash 通过 Multi-Raft Learner 协议实时从 TiKV 复制数据，确保行存储引擎 TiKV 和列存储引擎 TiFlash 之间的数据强一致。 在增加少量存储成本的情况下，可以在同一个系统中进行联机交易处理和实时数据分析，极大地节省了数据分析和聚合查询的成本。 以运营和用户行为数据为例，传统的数据处理流程需要经过线上库、数据仓库、数据集市等一系列采集、处理、聚合的流程。 不仅耗时，还涉及到与数据组的对接和合作，对于一些本来就简单直观的业务，整体上线和升级流程显得比较缓慢。

使用 TiDB 的 HTAP 特性后，相关业务的交付效率大幅提升，整个处理流程都在 TiDB 和单一应用内完成，数据链路短，排障难度也大幅降低，极大地节省了人力和时间成本。TiFlash 提供了强一致性的数据保证，确保数据分析结果与业务数据完全一致，避免了数据延迟和不一致的问题。在金融行业中，这一特性显得尤为重要。

4 运维便捷

对于运维人员来说，TiDB 提供直观的监控 Dashboard、管理控制台，集群本身的扩容能力也使得日常的运维监控、服务器上下线、配置升级等操作更加容易。 此外，统一对一个 TiDB 数据库集群进行监控维护的成本也会比维护多个零散的 MySQL 实例更为简洁。 使用 TiDB 集群不仅提高了服务器的资源利用率，也大幅度减少了运维人员时间成本的碎片化，极大地提升了工作效率。

未来展望

TiDB 是目前最受欢迎的开源分布式关系数据库之一，无论是从活跃度、版本迭代速度还是周边工具的完善程度来看，都已经达到了较高的水平。东吴证券的技术人员积极参与到 TiDB 开源社区中，根据应用情况提出了不少 issue。未来，希望在内部培养更多的相关专家和 Contributor，进一步推动分布式数据库在券商场景的深度应用。

当前，很多证券企业遇到了存量 MySQL 实例的标准化和管理成本问题。这些 MySQL 实例部署和使用的周期不同，在版本、配置和工具的使用方面都大相径庭，导致在升级、维护和管理上需要投入大量成本。因此，东吴证券计划引入 TiDB 新版本的资源管控功能，结合 TiDB 的可伸缩特性，通过构建 TiDB 统一集群的方式对通用服务资源进行分配和隔离，实现对存量 MySQL 实例的归集和统一管理，提升资源利用率，降低运维投入，同时解决不同业务之间的资源争抢问题。