---
title: 'TiDB x 日本头部金融科技公司 | 从 AWS Aurora 迁移到 TiDB 的最佳实践'
date: '2023-06-30T02:55:01+08:00'
status: publish
permalink: /case/user-case-tidb-in-japan-leading-fintech-company
author: '周, 盛虎'
excerpt: '使用 TiDB 打破 Aurora 在同时写入时遇到的性能瓶颈，提供比 Aurora 多 3 倍的 TPS，支付交易端到端延迟在百毫秒级。'
type: case
id: 5834
thumbnail: https://img1.pingcap.com/files/2023/12/20231221102533334.png
industry:
    - 金融
scene:
    - '规模 OLTP'
banner_image:
    - ''
company_desc:
    - '某日本头部金融科技企业提供二维码与条形码等快捷支付方式，拥有 6000 多万用户，在日本二维码支付市场占据三分之二的市场份额。'
white_paper_link:
    - ''
_yoast_wpseo_title:
    - '从 AWS Aurora 迁移到 TiDB 的最佳实践 %%sep%% %%sitename%%'
---
业务挑战
----

该企业采用亚马逊 AWS 公有云承载业务应用，并在此基础之上搭建了微服务应用架构。业务应用架构由大约 80 个组件构成，使用 Java、Spring Boot 等基础技术及 Amazon Aurora 作为核心数据库，所有的支付交易都传输到 Payment 组件进行管理。

随着业务迅速增长，当 Aurora 数据库遇到许多写入请求时，Binlog 同步会成为瓶颈，在提交过程中，Aurora 数据库等待同步目标返回 ACK，当同步数量增加时，提交延迟也会增加。因此，该企业寻求扩展性更好的云原生数据库方案。

迁移实践
----

在验证阶段，该企业将实际生产流量克隆到另一个 Aurora 数据库和 TiDB 数据库中，并引入 P6spy 开源框架检查数据的完整性，采用 TiDB Sync-Diff Inspector 工具来检查数据库迁移前后的一致性，以及对多种实例故障、集群故障和可用区故障场景进行模拟验证，通过 TiDB Binlog 工具进行数据同步，可以实现 RPO 趋近于零。

实际迁移中，使用增量的方法逐步增加流量，实际迁移耗时小于 2 小时，未出现任何问题，将服务停机时间降至最低。迁移后经过 3 个多月实际业务的运行考验，TiDB 各项指标均达到预期的目标。

新的交易数据库由 TiDB 集群组成，每个集群包括 PD、TiDB 和 TiKV 组件，每个组件都有多个实例，采用 Pump 和 Drainer 设置同步 Binlog 到从集群和灾备站。多个 TiDB 实例位于不同的 AWS 可用区（Region），同时提升了交易业务的容灾能力。

![某日本头部支付企业引入 TiDB 后的架构图](https://img1.pingcap.com/files/2023/12/20231211070132155.png)用户收益
----

- 兼容 MySQL，几乎不需要修改业务代码，支持水平扩展轻松应对数据增长。
- 开发人员不需要在应用层进行分库分表，可以保持应用层的简单。
- 轻松处理比 Aurora 多 3 倍的 TPS，而支付交易端到端延迟在百毫秒级。