--- title: 'TiDB vs MySQL：马上消费金融在高并发、跨中心热备场景下的实践探索' date: '2024-06-04T21:52:41+08:00' status: publish permalink: /blog/tidb-vs-mysql-in-msxf author: '周, 盛虎' excerpt: '本文分享了马上消费金融在选型、使用 TiDB 过程中遇到的一些经验和问题，包括高并发、多活热备等场景下的使用实践，您可以从中了解到 TiDB 和 MySQL 各自应用场景以及优劣势。' type: post id: 6830 category: - 案例实践 tag: - MySQL - 分布式数据库 - 金融 - 高并发 post_format: [] profile: - 段勇 _yoast_wpseo_title: - '%%title%%' --- 导读 -- 在 TiDB 走进多点活动中，来自马上消费金融的 DBA 段勇老师分享了《TiDB vs MySQL：消费金融公司在高并发、跨中心热备场景下的实践探索》，本文为分享实录。 段老师是一枚 TiDB 粉丝，在公司内部主要负责 TiDB 的维护管理工作，他分享了马上消费金融在选型、使用 TiDB 过程中遇到的一些经验和问题，包括高并发、多活热备等场景下的使用实践，您可以从中了解到 TiDB 和 MySQL 各自应用场景以及优劣势。相较于 MySQL，TiDB 在水平扩展能力、高可用性和简化数据栈等方面的优势。希望本文在数据库选型和应用层面对您有所裨益。 ![马上消费金融-段勇](https://img1.pingcap.com/files/2024/06/20240611131621485.webp)马上消费金融股份有限公司（简称“马上消费”）是一家经原中国银保监会批准，持有消费金融牌照的科技驱动型金融机构。从 2015 年 6 月成立以来，完成三次增资扩股，注册资本金达到 40 多亿，累计交易额超过万亿。随着业务数据量的增长，马上消费使用的数据库面临着新的挑战。 消费金融机构为什么使用 MySQL？ ------------------ MySQL 是一个典型的关系型数据库，经过多年深耕发展，已成为业内应用最广泛的数据库。它提供了关系型数据库里典型的功能，如数据安全性、事务处理、高可用以及性能优化等。其稳定性经过多年的考验，不论中小型企业，还是传统金融行业，都有很多的应用场景。 ![MySQL 应用场景](https://img1.pingcap.com/files/2024/06/20240611131738696.webp)大家都知道金融机构对数据安全性的要求非常严苛，MySQL 之所以能够成为金融行业的选择对象，首先是因为它具有很高的可靠性和稳定性，这对于涉及大量交易记录、账户管理和风险管理的金融行业来说至关重要。其次是扩展性、性能表现、成本效益以及安全合规。这里重点介绍扩展性，MySQL 支持主从复制、读写分离、集群部署等多种高可用架构设计，可以有效应对金融行业日益增长的数据处理需求和并发访问量。但 MySQL 如果不做分库分表，就只能通过增加从库的方式进行只读扩展，写扩展需要做分库分表，实现难度大大增加。 ![金融行业选择MySQL](https://img1.pingcap.com/files/2024/06/20240611131941566.webp)在使用 MySQL 过程中遇到的问题 ------------------ MySQL 存在很多局限性，第一是大数据集处理，第二是高并发处理，第三是高可用与容灾恢复。前两个问题可以归结为一个，就是无法突破单机性能瓶颈的问题。高可用和容灾恢复同样也存在问题，比如异步复制，如果主节点的压力过大，就会存在主从延迟。如果选择高一致性，比如 MGR，那性能就会有损耗，这是一个两难的选择。 ![MySQL局限性](https://img1.pingcap.com/files/2024/06/20240611132042769.webp)基于这三个痛点，我们在日常使用 MySQL 的时候，都会经历过三个阶段：首先是单机多库拆分，单库多表拆分，然后到冷热数据分离，最后到表数据分片。这三个处理方案其实都有各自的缺陷，下面一一展开： **集群拆分** ![集群拆分](https://img1.pingcap.com/files/2024/06/20240611132127559.webp)在企业起步阶段，单个集群可能融合了多个数据库。随着业务量的增加，单个集群无法承载压力时，就会做库的拆分，按业务类型各自使用单独的集群，从而分散压力。如果是单库没法拆的情况下，我们会按照业务场景去分拆表，比如说 a 业务使用三个表， b 业务也使用三个表，那 a 业务的三个表就放到一个集群， b 业务放到另一个集群。这个方案局限性在哪？主要是单库的并发量，即使做了拆分，表的数据量达到一定程度之后，也无法满足业务的并发需求。此外，有的业务模型拥有几百张表，它们平常在处理业务的过程中，之间是有相互 join 的，这种情况就不满足拆分场景。还有一种是跨库关联，多个库里的一些表，需要去做一些 join，拆分之后显然无法实现了。 **数据归档** ![数据归档](https://img1.pingcap.com/files/2024/06/20240611132206378.webp)当单库的数据量已经到达一定规模，拆无可拆时，就需要做历史数据归档。比如说三个月前的数据可能用得不是特别频繁，那就可以把这三个月的数据直接放到归档平台。上图是一个典型的数据归档处理逻辑，首先提供一个归档平台，热数据放到在线的数据库集群，历史数据放到归档平台。但这个方案也有一些局限，比如历史数据保存了 3 年，但这 3 年的数据都有比较高频的访问，而且数据量特别大，数据没法做冷热分离，这个场景下归档就无法实现。我们的归档平台很多时候是基于 HBase 大数据平台搭建，对于高频的查询需求无法满足。此外，如果是单集群，近三个月的热点数据已经超过了单机性能瓶颈，这个方案也无法适用。 **分库分表** ![分库分表](https://img1.pingcap.com/files/2024/06/20240611132237350.webp)在 MySQL 层面，最终的解决方案就是大家常说的分库分表。它的基本逻辑就是把一个库拆成多个库，按这个库的 ID 取哈希，取模，然后分成若干个库。这个方案也存在一些难点，一是聚合查询，这么多库如果要关联查询怎么办？二是增加分片的时候，业务改造难度太大，也会导致运维成本增高。比如说有 64 个分片，如果要添加一个字段，在没有自动化管理平台的情况下，需要一个个手动添加这个字段。此外，从单库拆库时的业务改造难度也特别大，每一次拆库都会面临着业务的改造。 ![数据库选型关注事项](https://img1.pingcap.com/files/2024/06/20240611132530971.webp)基于以上这些问题，我们迫切地想要引入分布式数据库。当时，我们做数据库选型主要关注以下几个方面： 1. 开源社区活跃度。社区活跃度直接反映了这个数据库的成熟度，以及它在市场上的使用量； 2. 读写协议兼容统一。我们之前的所有业务基本都是在 MySQL 上使用，要迁到一款新的分布式数据库，必须要兼容 MySQL 所有协议，尽量降低代码改造量； 3. 有明确的服务边界。锚定分布式数据库的使用场景，我不想去挑战数据库的极限，如果这个数据库不支持我的业务场景，那也是不行的； 4. 高可用。这款分布式数据库一定要满足业务对 PTO 和 RTO 的要求。 TiDB 与 MySQL 的关键特性对比：Why TiDB？ ------------------------------ ![TiDB架构特点](https://img1.pingcap.com/files/2024/06/20240611132706776.webp)基于上述这些选型标准，我们来看 TiDB 的架构特点： - 首先，TiDB 在数据一致性、可靠性、高可用以及可扩展性等方面表现成熟，与金融行业的属性比较吻合。 - 其次，TiDB 完全能够满足可扩展性和并发要求高的 OLTP 场景。很多行业可能都把 TiDB 用在 OLAP 场景里，但其实对于大并发的 OLTP 场景，TiDB 也是不错的选择。 - 第三，TiDB 满足 HTAP 场景需求，既做 OLTP 业务，也做 OLAP 业务。 ![MySQL与 TiDB对比](https://img1.pingcap.com/files/2024/06/20240611132919597.webp)基于 TiDB 的这些特性，我们将 TiDB 与 MySQL-MGR 做了关键特性对比。对于 MySQL，我们有完整的 SOP，比如开发规范有严格的标准，数据量必须在什么范围内来使用 MySQL。超过了这个范围，就要去做拆分。此外，哪些参数必须满足，也都形成了严格的规范，比如说关联查询限制在多少个表，这些都是基于 MySQL 的局限性来考虑的。 **支持场景类型**：MySQL 支持 OLTP 的小并发场景，而 TiDB 对于 OLTP、OLAP 都能够支持。如果落地场景是 SQL 并发小，低延迟的交易系统，MySQL 的性能其实相对 TiDB 来说是要更优一点，而对于对账、跑批、归纳分析，以及并发量比较大的交易场景，TiDB 都有比较大的优势。 **数据量要求**：我们在生产环境中对数据量的要求是在 2TB 以下时使用 MySQL，大于 2T 小于 200T 使用 TiDB。目前，我们交易系统的数据量要求是在 50T 范围内，超过 50T 做归档的业务必须拆出去。在 TPS 层面，小于 2, 000 的 TPS 在 MySQL 上表现相对良好。如果业务增长特别快，必须在线扩展，对于 MySQL 来说相对比较困难，TiDB 就可以支持在线横向扩展。 **单表大小**：对单表的限制，我们现在一般在 MySQL 层面要求 5,000w 以内，在 TiDB 层面不会做太多限制。 总体而言，MySQL 在单机性能和成熟度上有明显优势，而 TiDB 在处理分布式、高并发、大规模数据场景下展现出卓越的扩展性和强一致性保证。 真实场景下的应用实践 ---------- ![TiDB 应用实践](https://img1.pingcap.com/files/2024/06/20240611133051404.webp)我们对 TiDB 的应用实践，主要分为以下四个场景： 1. 作为 MySQL 分片数据的聚合库。实现复杂的跨库、跨表、跨业务的实时查询。 2. 三中心多活容灾。MySQL 在实现多活跨中心部署的时候，难度相对来说比较大。因为跨中心访问，要不建立主从，要不引入第三方同步工具，对它的主从延迟都是比较大的考验。而 TiDB 天然支持两地三中心的部署，每一个 zone 可以分别在自己的数据中心部署，任何一个数据中心宕机，数据完整性不受影响。 3. 作为分库分表的替代方案。MySQL 需要做分表的时候，用 Sharding 选取相对比较复杂，分片的扩容难度相对来说也较高，用 TiDB 的话就可以规避这些问题。 4. HTAP 混合计算。TiDB 作为典型的 OLTP 行存数据库，同时又兼具 OLAP 能力，比如 TiFlash、TiSpark 等，我们在真实的生产环境中也在使用。 **海量交易数据存储与检索** ![海量交易数据存储与检索](https://img1.pingcap.com/files/2024/06/20240611133235725.webp)上图是马上消费金融比较典型的在线业务系统消息平台，也是我们的 13 大核心系统之一。当前总数据量三副本已经达到 39 TB，最大表过了上百亿，每个月的增量差不多在 1.9T 左右。 消息平台的业务特点主要有两个： - 日增量大：每天的数据增量大约有 1, 000 多万，推送的跑批数据也有 1, 000 多万。热度数据按三个月计算，已超 18 亿。 - 数据生命周期内高频访问：热数据量大，需要对 7 天内的数据进行多维度的统计计算；对近 2 个月的数据做频繁变更；对 3 个月内的数据进行频繁查询，日访问量达 20 万。 如果这个业务使用 MySQL 会特别困难，需要及时做分库分表，当时估算下来的成本差不多是 TiDB 的 2-3 倍。引入 TiDB 之后，我们使用了 36 个 TiKV，服务器规格都是 40C/128G/2TB，延迟控制在 500 毫秒以内。QPS 虽然看着并不高，但实际这个表都是上百亿的大表，这个 QPS 其实并不小，任何一点波动，它的延迟至少是两三倍。 **数据仓库与分析平台** ![数据仓库与分析平台](https://img1.pingcap.com/files/2024/06/20240611133331220.webp)第二个场景是数据仓库与分析平台。我们的数据库是做了分片的，线上的数据做了 64 个分片，数据通过 DM 汇聚到 TiDB 做分析查询。这个方案特点是 TiDB 横向扩展比较方便，不管业务数据怎么增长，通过 DM 同步过来之后，只要堆机器就行了。使用 DM 合并比较容易，无需通过 HBase 归档平台做复杂的关联查询，不用去想那些复杂的架构去做同步方案。 **多中心部署** ![多中心部署](https://img1.pingcap.com/files/2024/06/20240611133406983.webp)上图是我们目前的多中心部署架构。a 机房作为一个主机房，部署 3 个 TiDB，TiKV 每个分片按 3 个机房部署。其中，第三个机房作为多数派的投票机房，但它也真实存了数据。第二个机房作为热备机房。每个机房的 TiDB 数量一样，TiKV 数量一样。据我所知，目前国内很多金融机构也都是按照这套方案部署的。对于一写多读、双活、多活、RTO、RPO 这些标准，TiDB 都能够非常好地满足。 如果用 MySQL 实现多中心部署是比较困难的，因为主从延迟就没法规避，如果要减降低主从延迟，就得拆库，实现难度很高。对于这个架构而言，选择 TiDB 部署方案就会简单很多，但也有几个难点： - 第一，对网络的延迟要求很高。当时线上跨机房的网络延迟过高时，业务上对延迟的感知会成倍增长。 - 第二，因为涉及到跨中心的网络访问，PD leader 要做合理规划。主机房的 PD leader 肯定要在自己的机房内，所以要做合理的策略调整。 - 第三，TiKV leader 规划和成本间的衡量，需要根据自己的业务做合理的平衡。 总结 -- 总结来说，MySQL 在单机性能和成熟度上有明显优势，这毋庸置疑，毕竟 MySQL 在各个行业都有使用场景，而且深耕了多年。而 TiDB 在处理分布式、高并发、大规模数据场景下展现出卓越的扩展性和强一致性保证。TiDB 的 Raft 协议、多副本原理对一致性都有不错的保证。两者在具体使用时应根据项目需求、数据规模、团队技能等因素综合考量。由于金融行业的特殊性，数据库的选择还要满足监管要求、稳定性、性能、安全性和技术支持等多个因素。 关于数据库选型，我认为没有更好的数据库，适合自己业务的，就是最好的数据库。