美柚TiDB高并发实践：消息推送系统架构演进与配置调优

美柚作为一家专注于女性健康管理的互联网公司，自2013年成立以来，已发展成为拥有多款应用、日活跃用户超千万的平台。随着业务的快速发展，尤其是在海外市场的拓展，其底层数据库架构面临着严峻的挑战。本文探讨了美柚如何在技术选型的十字路口，坚定地选择了分布式数据库 TiDB，并将其成功应用于核心业务系统，最终实现了运维成本的降低和业务性能的显著提升。

从探索性应用到沉淀 TiDB 知识库

初识 TiDB（2020 年）

美柚与 TiDB 的故事始于2020年。当时使用的是4.0版本，抱着尝试的心态，我们将其用于离线业务查询。通过 TiDB 自带的 DM（Data Migration）工具，我们把 MySQL 的全量数据加增量同步到 TiDB 集群，为业务提供支持。令人惊喜的是，这些后台离线业务的性能得到了极大提升，原本在 MySQL 上需要分钟级别执行时间的操作，在 TiDB 上秒级就能完成，性能提升数十倍之多，这让我们看到了 TiDB 的巨大潜力。

深入接触 TiDB（2022-2023 年）

此后，对 TiDB 的探索从未停止。2022年到2023年，我投入更多精力学习 TiDB，通过研读官方文档、观看视频课程，深入了解其架构原理、功能特性，并考取了相关证书。

为了让公司内部更多人了解 TiDB，我们在公司开展了持续约半年的技术分享活动，平均每两周一次，向开发人员和运维人员普及 TiDB 知识。目的是让开发同学熟悉 TiDB，在后续数据库选型时能多一种选择。

我们还进行了 TiDB 知识库的沉淀，针对 TiDB 做了诸多测试，如故障模拟、SQL 的限流熔断测试以及两地三中心部署测试等。通过这些充分的测试，我们对 TiDB 的各项性能和可能出现的问题有了更清晰的把握，为后续的上线应用奠定了坚实基础。

痛点催生变革：海外消息推送系统的架构演进

2024年，我们迎来了将 TiDB 应用于实际业务的机会。当时，海外的消息推送业务1.0版本存在较大问题。其架构涉及三个数据中心（IDC），MySQL 主库位于新加坡，通过主从同步到圣保罗和法兰克福，每个IDC都有一份消息系统。这导致查询链路复杂，推送状态不可追溯，系统使用体验糟糕。

基于这些问题，我们考虑在消息系统2.0版本中更换数据库，当时主要在 TiDB 和 PolarDB 之间做选择。通过 SQL 流量回放的方式进行性能对比，发现无论是性能耗时还是总成本，TiDB 都明显优于 PolarDB。尤其是在海外，机器费用单价高且折扣少，使用 TiDB 能显著降低成本，因此我们最终选择了 TiDB。

目前，我们上线了 TiDB 的系统主要有三个：

• 消息推送系统：采用 2 台 TiDB、3 台 PD、4 台 TiKV 加 2 台 TiFlash 的配置，全部独立部署，数据量约 3T。
• 订单聚合系统：有 3 台 TiDB，其中 1 台专门提供给大数据做离线分析，不影响在线业务。
• 内部系统：由于重要性没那么高，采用混合部署以节省成本，数据量 140G。

新的架构将 MySQL 下线，只在新加坡机房部署 TiDB 集群，同时将圣保罗和法兰克福的应用层系统也进行整合，直接通过一个集中的消息系统进行推送。这种架构的革新，极大地简化了数据同步链路，查询速度也获得了数倍的提升。

上线前的严谨准备：系统性配置优化

对于首次使用 TiDB 的人来说，上线前的配置是否合适、是否最优是一个令人困扰的问题。为此，我们团队仔细研究了 TiDB 官方文档中的系统变量和各个组件的配置文件，总结出适合自身业务的配置。

1. PD（Placement Driver）组件配置

我们为 PD 设置了云厂商、可用区和主机名的标签，并将隔离级别设为可用区级，以保证副本分布在不同可用区，提升系统的稳定性。在经历过阿里云新加坡可用区 C 的火灾故障后，更能体现出这种配置的优势，TiDB 在故障中表现稳定。

副本数采用默认的 3，日志保留时间设为 7 天。对于磁盘充足和不足的阈值，默认不足阈值为 80%，考虑到使用 TiDB 通常数据量大、磁盘大，80% 的剩余空间仍很充足，我们将其调整为 90%，当达到该阈值时，PD 节点不再往该 tikv 节点调度数据。

2. TiDB Server 配置

TiDB Server 的临时目录设置在数据目录下，因为默认的 temp 目录所在的根目录通常空间不大，担心会被撑爆。其中，第一个临时目录是创建索引时回填的目录，第二个是 SQL 执行时内存不足产生的落盘位置。

日志保留时间统一设为 7 天，单个节点的最大连接数设置为 5000，在满足业务需求的同时，防止突增流量导致数据库挂掉，起到保护 TiDB 的作用。

3. TiKV（TiDB Key-Value）配置

TiKV 的日志同样保留 7 天。考虑到海外业务跨可用区，为降低延迟，我们对 GRPC 的消息采用 gzip 压缩方式，默认是没有压缩的。

对于分裂后的 region 大小，默认配置是 64 MB，在数据量较大的情况下，会导致 region 数量过多，给 PD 的压力管理带来很大负担。因此，我们将其调整为 128 MB，以防止 region 数量过多。需要注意的是，TiDB v8.4 以后这个值已变为 256 MB，无需再手动调整。

4. 系统变量调整

TiDB Server 的系统变量中，与超时相关的锁超时和空闲连接超时，我们基于目前生产的配置做了统一设置。SQL 的最长执行耗时设为 600 秒（10 分钟），超过这个时间的 SQL 通常会扫描大量数据，属于不合格的 SQL，会被终止，这也是对 TiDB 的一种保护。

TiDB 自动收集表统计信息的执行时间范围，默认是全天，可能在高峰时段触发，影响正常使用。我们将其调整到凌晨，以避免对白天业务造成影响。

SQL Mode 是一个重要参数，尤其对于从 MySQL 迁移过来的业务，其设置会影响 SQL 执行的成败。在之前的 MySQL 迁移中，就曾因 SQL mode 不一样，导致在源库能正常执行的 SQL 在目标库执行失败，因此需要注意保持一致。

显著的收益：四大核心价值的体现

成功上线 TiDB 后，美柚的数据库架构迎来了质的飞跃，主要体现在以下四个方面：

• 可扩展性提升：与 MySQL 只能扩展读能力不同，TiDB 能够通过增加计算节点（TiDB）和存储节点（TiKV），实现读写能力的线性扩展，这为美柚未来业务的快速增长提供了坚实的基础。
• 性能与负载能力显著优化：TiDB 凭借其高并发处理能力和低延迟响应，极大地提升了业务性能。同时，它出色的混合负载能力（HTAP）使得业务可以在一个数据库中同时处理 OLTP 和 OLAP 两种负载，简化了架构。
• 高可用性保障：得益于多副本和可用区隔离等配置，即使在极端情况下（如机房火灾），TiDB 集群也能保障业务的连续性，无需手动干预。
• 运维成本降低：在 MySQL 中，美柚线上存在大量的分表，修改表结构需要花费十多天的时间进行 DDL 人工操作。而 TiDB 的在线 DDL 功能，使得加列或修改列的操作能够在秒级完成，极大地简化了运维工作，释放了人力。

给 TiDB 使用者的建议

基于多年的实践经验，美柚团队为 TiDB 的使用者提供了以下几点建议：

1. 重视官方学习资源：官方文档和视频课程是获取 TiDB 知识最权威、最有效的途径。
2. 积极参与社区论坛：社区论坛是交流和解决问题的重要平台。在 TiDB 社区中，不仅可以寻求帮助，也可以通过帮助他人来提升自己。
3. 做好应急预案与运维手册：在上线前，务必对各种故障场景进行充分的模拟，并制定详细的运维手册和应急预案。
4. 保持版本统一：尽量保持 TiDB 的大版本统一，避免因版本差异导致后期维护成本增加。
5. 生产环境独立部署：对于在线业务，不要为了节省成本而将各个组件混合部署。资源争抢可能导致业务受损。

结语

美柚在 TiDB 上的实践是一场从技术探索到赋能业务的成功之旅。TiDB 以其卓越的 分布式 能力，为美柚的核心业务，特别是出海业务，提供了稳固的支撑。这场实践也告诉我们，扎实的前期测试、严谨的配置调优和持续的社区学习，是成功驾驭一项新技术并让其创造业务价值的关键。

希望美柚的实践经验能为你带来启发。如果你想了解更多关于数据库选型、架构设计的深度内容，欢迎访问云栈社区，与更多开发者交流讨论。