免费试用

业务挑战

该企业采用亚马逊 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 后的架构图

用户收益

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

行业:金融

某日本头部金融科技企业提供二维码与条形码等快捷支付方式,拥有 6000 多万用户,在日本二维码支付市场占据三分之二的市场份额。

咨询案例详情

体验全新的一栈式实时 HTAP 数据库

金融行业内容专区上线,为金融机构数据库选型和应用提供深入洞察和可靠参考路径。