业务挑战
金融行业对数据安全性、事务处理能力、高可用性和性能都有严格的要求，随着业务量的增长，马上消费金融传统的 MySQL 架构面临单机性能瓶颈和高可用与容灾恢复两方面的考验，通过集群拆分、数据归档和分库分表都无法满足业务高并发、海量历史数据高频查询、多库关联查询等需求，反而造成了业务改造难度大，运维成本增高等问题。
解决方案
经过深入调研，马上消费金融将 TiDB 与 MySQL-MGR 做了关键特性对比，根据支持场景类型、数据量和单表大小对使用 MySQL 和 TiDB 的使用场景进行了严格的区分：
- MySQL 支持 OLTP 小并发场景，对于对账、跑批、归纳分析，以及并发量比较大的交易场景使用 TiDB；
- 集群规模 2TB 以下、TPS 小于 2000 时使用 MySQL，大于 2T 小于 200T 以及增长特别快、必须在线扩展的业务使用 TiDB；
- 单表数据量大于 5,000w 时采用 TiDB。
TiDB 主要应用在以下业务场景：
- 作为MySQL分片数据的聚合库：能够实现复杂的跨库、跨表、跨业务的实时查询功能；
- 三中心多活容灾：主机房部署 3 个 TiDB，TiKV 每个分片按 3 个机房部署。其中，第三个机房作为多数派的投票机房的同时也存储数据；第二个机房作为热备机房，每个机房的 TiDB 和 TiKV 数量一致；
- 分库分表的替代方案：利用 TiKV 实现水平扩展，应对海量交易数据；
- HTAP混合计算：将线上数据分片，通过 DM 汇聚到 TiDB 做分析查询。
客户收益
- 支持海量数据处理： 在日增数据量超 1,000 万、单表数据量达 100 亿的在线业务消息平台中，实现 7 天内多维度统计计算、2 个月内数据频繁状态更新，以及 3 个月内超 18 亿条数据的高频查询，日访问量超 20 万，延迟保持在 500ms 内；相比 MySQL 分库分表，成本降低 2-3 倍。
- 保障业务连续性： 实现多中心部署，支持业务 3AZ 多活架构，一写多读、双活和多活模式；单 AZ 故障可自动恢复，RTO < 30 秒，RPO = 0，全面保障业务系统的安全与稳定。
- 提升实时分析能力： 数据平台具备便捷的横向扩展能力，满足复杂查询需求（如数据关联等），无需依赖 HBase 归档平台进行繁琐的关联查询。
客户简介
行业：金融
马上消费金融股份有限公司是一家经原中国银保监会批准，持有消费金融牌照的科技驱动型金融机构。自 2015 年成立以来，注册资本金达到 40 多亿，累计交易额超过万亿。
