Plaid 从 Aurora 迁移到分布式 SQL 的零停机实践

当 Plaid 的 Amazon Aurora MySQL 集群面临大版本升级时，估算结果是六个工程月和数十分钟的停机时间。对于一家 API 支撑着数千个金融应用的公司来说，这不是一项维护任务。这是一次产品冻结。Plaid 将那份精力转而投入到迁移至分布式 SQL，而其首次在 TiDB 上的升级在一周内覆盖了六个生产集群，且零停机。

这就是一个决策中所体现的金融科技可扩展性危机。交易量和正常运行时间预期超出数据库承受能力的速度，比团队打补丁的速度更快，而补丁的成本开始超过它们本应支撑的增长。从嵌入式支付和 AI 驱动的欺诈检测到实时信用评分，金融服务变得越来越快、越来越个性化，而许多平台仍然运行在遗留数据库和为另一个时代构建的架构之上。

单体数据库在高并发工作负载下举步维艰，在区域性流量高峰面前不堪重负，并迫使团队采用复杂的分片模型。其后果是错失增长、基础设施成本上升，以及工程时间被用于救火而非产品开发。金融科技领导者需要一个能够横向扩展、实时处理事务和分析，并在全球运营中保持一致性和正常运行时间的数据基础。

本文涵盖金融科技公司面临的架构挑战、分布式 SQL如何应对这些挑战，以及 Plaid 的迁移在生产环境中运行它的启示。

什么是分布式 SQL，金融科技为何需要它？

分布式 SQL 是一种数据库架构，它将数据和查询处理分散到许多节点上，同时保持传统关系型数据库的强一致性和 SQL 兼容性。金融科技平台需要它，因为它们同时面临三项需求，而单服务器 RDBMS 无法兼顾。交易量超出单台机器的承载能力，分析必须运行在实时事务数据上，而审计人员会检查每一项一致性保证。

像 TiDB 这样的分布式 SQL 数据库直接满足每一项需求。它们通过添加节点横向扩展，在同一份数据上运行事务和分析工作负载，并通过 Raft 共识协议复制每一次写入。团队无需在应用中构建和维护分片逻辑，即可获得这三者。

金融科技平台为何正在达到临界点

金融科技平台所面临的数据需求是该行业以往从未处理过的。

• 交易量正在爆发式增长。仅数字支付领域就以每年近 20% 的速度增长，即时支付预计到 2028 年将达到 58 万亿美元。
• 实时分析已是基本要求。欺诈检测、个性化推荐和信贷决策不能等待批处理作业。
• 监管压力正在加剧。从 GDPR 到 PSD2 再到印度的《数字个人数据保护（DPDP）法》，金融科技公司必须始终确保可审计性、加密和数据完整性。

遗留 RDBMS 和手动分片的 MySQL 集群并非为这种组合而构建。它们难以扩展且难以维护，并迫使团队仅仅为了跟上需求而外挂额外工具。

当金融科技增长超过数据基础设施时会发生什么

金融科技公司不仅仅是在构建应用。它们运营着高速数据引擎，而随着增长，五种压力会叠加起来。

• 不可预测的需求高峰。假日高峰、病毒式推荐活动或动荡的市场都可能在几分钟内使流量成倍增长。垂直扩展力有不逮，人工干预成为常态，而为峰值需求进行容量配置意味着一年中大部分时间都在为闲置容量付费。
• 一切都要实时。欺诈检测、风险评分、个性化和合规触发不能等待批处理。大多数遗留架构将 OLTP 和 OLAP 分离，迫使团队运行 ETL 管道或操作独立系统，这在最痛的地方增加了成本、复杂性和延迟。
• 跨区域复杂性。金融科技公司很早就走向全球。跨区域协调数据会引入延迟、可用性风险和一致性权衡，而许多数据库选择可用性而非强一致性。在准确性和可审计性不可或缺的金融系统中，这种妥协行不通。
• 分片制造隐藏的运营债务。分片看起来像是一个快速修复方案。然后管理模式变更、平衡负载、路由查询以及维护跨分片的可观测性就变成了一项全职工作，工程时间从产品转向基础设施故障排查。
• 合规负担持续上升。在 GDPR、PCI DSS、DPDP 法以及行业特定审计之间，金融科技公司处于显微镜下运营。满足加密、审计追踪和灾难恢复的要求，需要从一开始就内置这些功能的基础设施。

金融科技领导者如何以分布式 SQL 应对

领先的金融科技公司正在淘汰为事务、分析和缓存分别建立独立系统的旧模式，这种模式已被证明过于复杂、脆弱且缓慢。分布式 SQL 正是它们正在转向的架构。

金融科技公司为何采用分布式 SQL？

• 横向扩展。过去，扩展意味着分片、迁移和风险。分布式 SQL 系统通过添加节点来吸收激增的需求，且无需停机，这意味着更平滑的发布和更少的技术债务。
• 统一架构。团队将 OLTP、OLAP 和实时工作负载整合到一个平台上。分布式 SQL 原生支持混合工作负载处理，消除了 ETL 管道，只留下一个事实来源。
• 实时洞察。分析运行在实时事务数据上，而不是等待批处理作业，这缩短了从数据到决策的循环。
• 内置可用性和一致性。分布式 SQL 系统提供ACID 保证和自动故障转移。数据库复制每一笔事务并默认使其持久化，因此数据在硬件故障和网络中断期间仍保持准确。
• 更简单的运营和更低的成本。更少的移动部件和云原生自动化减少了工具泛滥、运营开销和人员需求。
• 从底层实现合规。加密、审计追踪、访问控制和灾难恢复都是内置的，而非昂贵的附加组件。

这些选择背后的模式是一致的。金融科技领导者希望在不牺牲速度、简单性或控制力的情况下为规模而构建。在分布式 SQL 数据库中，TiDB 将水平可扩展性、内置一致性和实时分析结合在一个云原生系统中。

TiDB 有何不同？为金融科技规模而生的专用数据库

TiDB是一个开源分布式 SQL 数据库，为金融科技的三个现实而构建。增长不可预测，洞察必须实时，合规要求严格。TiDB 将 NoSQL 的水平可扩展性与传统 RDBMS 的强一致性和 SQL 兼容性结合在一起。

水平可扩展性

传统数据库在流量增长时会遇到瓶颈，迫使团队进行成本高昂的迁移或容易出错的分片。TiDB 将计算和存储解耦，使每一层都能独立扩展。无状态的 TiDB 服务器层处理 SQL 处理。TiKV 存储层是一个分布式键值引擎，自动将数据拆分为 Region，并使用 Raft 共识协议 复制每个 Region。当流量激增时，你添加节点，TiDB 在线在它们之间重新平衡数据，无需停机。

这使得突发的流量高峰、区域扩张和长期增长都变得可控，而无需每次都重新架构。

混合工作负载处理

许多金融科技应用需要同时进行快速事务和实时分析。传统技术栈将 OLTP 和 OLAP 拆分为由 ETL 管道 拼接在一起的独立系统。TiDB 在同一份数据上同时运行两者。TiFlash 是其列式存储引擎，通过 Raft 日志从 TiKV 行存储复制实时数据，并且从 TiFlash 读取的数据与最新提交的事务保持一致。TiDB 优化器将分析查询路由到 TiFlash，将事务查询路由到 TiKV，全部在一个数据库内完成。

其结果是一个更简单的技术栈，无需维护管道即可在新鲜数据上支持欺诈检测和客户个性化。

强一致性（ACID）和高可用性

在金融系统中，一致性不容妥协。单个乱序事务或失败的写入都会产生现实世界的后果。TiDB 默认通过快照隔离强制执行 ACID 事务。每次写入在提交前都通过 Raft 复制到多数副本，因此数据在硬件故障和网络分区期间保持一致。

借助自动故障转移和多区域部署，TiDB 在故障期间持续提供正确的数据。这种韧性对于跨区域、合规框架和高风险工作负载运营的金融科技公司至关重要。

云原生灵活性

TiDB 可运行在公有云、私有基础设施或混合环境中。它通过 TiDB Operator 支持在 Kubernetes 上进行容器化部署，该 Operator 可自动化配置、扩展、升级、备份和恢复。平台和 SRE 团队可以完全控制其部署，同时减少手动操作的时间。

Plaid 如何通过零停机升级将数据库升级工作量减少 96%

Plaid 将数千个应用和金融机构连接到消费者金融数据。随着其最大、最关键的服务不断增长，其 Amazon Aurora MySQL 技术栈成为制约因素。可用性问题、缓慢的架构变更以及耗费数月工程努力升级已成为常态。

Plaid 采用 TiDB 来 消除分片的负担并使其数据基础设施面向未来。TiDB 的 MySQL 兼容性使应用变更很小，一个由六名工程师组成的团队 将 100 个服务中的 234 个数据库 在大约两年半的时间内从 Aurora 迁移到自托管的 TiDB。

主要结果包括以下内容。

• 升级工作量减少 96%，零停机。 Aurora 上的升级曾经耗费六个工程月和数十分钟的停机时间。2025 年，Plaid 在一个工程周内升级了其所有 TiDB 集群，没有停机，减少了 96% 的工作量。
• 在多 TB 级表上在线变更架构。 在 MySQL 上需要维护窗口的架构变更现在可以无停机运行，即使在数据超过 5 TB 且包含数百亿到数千亿行的表上也是如此。
• 更快、更安全的切换。 Plaid 的自动化将每个服务的切换时间从三到四周缩短到约一周，写入停机时间从约五分钟降至 60 秒以下。
• 分析余量。 Plaid 可以稍后通过 TiDB 的混合工作负载处理添加实时分析，而无需重新架构。

“借助 TiDB，我们现在可以零停机执行升级和大表架构迁移，”Plaid 平台架构负责人 Zander Hill 表示。这一转变提高了可靠性，并改变了 Plaid 团队发布的速度和安全性。

Plaid 的迁移表明，早期做出正确的架构选择如何为长期规模、合规性和开发者效率奠定基础。

下载我们的金融科技韧性完整指南

传统数据库并非为当今金融科技的需求而构建。随着数字服务变得更加个性化、智能化和合规密集型，基础设施必须能够扩展、无中断运行并支持实时决策。

我们的白皮书涵盖了金融科技领导者如何使用分布式 SQL（特别是 TiDB）来现代化其数据架构，从全球支付处理商到数字银行和嵌入式金融平台。 下载完整指南 了解 TiDB 如何大规模支持金融科技的增长、合规性和韧性。有关金融服务中分布式 SQL 的更多信息，请参阅 TiDB for fintech。

用 25 GiB 的免费资源启动一个数据库。立即开始。

金融科技可扩展性与分布式 SQL 常见问题解答

什么是分布式 SQL，它与传统 RDBMS 有何不同？

分布式 SQL 是一种关系型数据库架构，它将数据和查询处理分散到多个节点上，而不是单个服务器上，同时保持 SQL 兼容性和 ACID 事务。传统 RDBMS 通过迁移到更大的服务器进行垂直扩展，或通过手动分片扩展，这会将路由和一致性逻辑推入应用程序。分布式 SQL 自动拆分和重新平衡数据，并使用 Raft 等共识协议复制每次写入，因此容量通过添加节点即可增长，无需更改应用程序。

分布式 SQL 能否在不停机的情况下扩展金融科技平台？

可以。在 TiDB 这样的分布式 SQL 数据库中，你可以向正在运行的集群添加节点，数据库会在继续处理流量的同时将数据重新平衡到这些节点上。滚动升级和在线 schema 变更也无需使数据库离线即可运行。Plaid 以零停机时间升级了其 TiDB 集群，并在大于 5 TB 的表上在线运行 schema 变更，而此前在其 Amazon Aurora MySQL 栈上，这类工作需要在维护窗口内进行。

分布式 SQL 是否同时支持事务和实时分析？

有些分布式 SQL 数据库可以，通过混合工作负载处理，也称为 HTAP。TiDB 将事务数据存储在 TiKV（一种行存储）中，并通过 Raft 日志将其复制到 TiFlash（一种为分析查询构建的列式存储）。从 TiFlash 读取的数据与最新已提交事务保持一致，优化器将每个查询路由到正确的引擎。金融科技团队可以在实时数据上运行欺诈检测和报告，而无需单独的仓库或 ETL 管道。

TiDB 如何帮助金融科技公司满足 PCI DSS 和 GDPR 等合规要求？

没有哪个数据库能独自让平台合规，而 TiDB 提供了合规框架所期望的控制措施。每次写入只有在大多数副本通过 Raft 确认后才会提交，这保护了数据完整性。TiDB 支持传输中和静态加密以及基于角色的访问控制，TiDB Cloud 增加了数据库审计日志记录，而具有自动故障转移的多区域部署支持灾难恢复要求。有关认证和安全文档，请参阅 TiDB 信任中心。\

文章 金融科技可扩展性危机：分布式 SQL 如何以零停机运维解锁创新 首次出现在 TiDB 上。