编者按
美柚作为一家专注于女性健康管理的互联网公司，自 2013 年成立以来，已发展成为拥有美柚、柚宝宝、柚子街等多款应用，日活跃用户超千万的平台。随着业务的快速发展，尤其是在海外市场的拓展，其底层数据库架构面临着严峻的挑战。本文内容源自美柚 DBA 赵丹在 TiDB 社区活动（厦门站）的实践分享，探讨美柚如何在技术选型的十字路口，坚定地选择了 TiDB，并将其成功应用于核心业务系统，最终实现了运维成本的降低和业务性能的显著提升。
作者：赵丹｜美柚 DBA
从探索性应用到沉淀 TiDB 知识库
（一）初识 TiDB（2020 年）
美柚与 TiDB 的故事始于 2020 年。2020 年，我第一次接触到 TiDB，当时使用的是 4.0 版本。由于对 TiDB 了解不深，我们抱着尝试的心态，将其用于离线业务查询。通过 TiDB 自带的 DM （Data Migration）工具，我们把 MySQL 的全量数据加增量同步到 TiDB 集群，为业务提供支持。令人惊喜的是，这些后台离线业务的性能得到了极大提升，原本在 MySQL 上需要分钟级别执行时间的操作，在 TiDB 上秒级就能完成，性能提升数十倍之多，这让我们看到了 TiDB 的巨大潜力。
（二）深入接触 TiDB（2022-2023 年）
此后，对 TiDB 的探索从未停止。随着对 TiDB 兴趣的加深，2022 年到 2023 年，我投入更多精力学习 TiDB。通过研读官方文档、观看视频课程，深入了解其架构原理、功能特性等，并考取了相关证书，对 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 官方文档中的系统变量和各个组件的配置文件，总结出适合自身业务的配置。
- PD（Placement Driver）组件配置
我们为 PD 设置了云厂商、可用区和主机名的标签，并将隔离级别设为可用区级，以保证副本分布在不同可用区，提升系统的稳定性。在经历过阿里云新加坡可用区 C 的火灾故障后，更能体现出这种配置的优势，TiDB 在故障中表现稳定，而 MySQL 则需要手动进行主备倒换等操作，相对麻烦。
副本数采用默认的 3，日志保留时间设为 7 天，根据自身情况进行调整即可。对于磁盘充足和不足的阈值，默认不足阈值为 80%，考虑到使用 TiDB 通常数据量大、磁盘大，80% 的剩余空间仍很充足，我们将其调整为 90%，当达到该阈值时，PD 节点不再往该 tikv 节点调度数据，这样的设置完全能满足需求。
- TiDB Server 配置
TiDB Server 的临时目录设置在数据目录下，因为默认的 temp 目录所在的根目录通常空间不大，担心会被撑爆。其中，第一个临时目录是创建索引时回填的目录，第二个是 SQL 执行时内存不足产生的落盘位置。
日志保留时间统一设为 7 天，单个节点的最大连接数设置为 5000，在满足业务需求的同时，防止突增流量导致数据库挂掉，起到保护 TiDB 的作用。
- TiKV（TiDB Key-Value）配置
TiKV 的日志同样保留 7 天。考虑到海外业务跨可用区，为降低延迟，我们对 GRPC 的消息采用 gzip 压缩方式，默认是没有压缩的。
对于分裂后的 region 大小，默认配置是 64 MB，在数据量较大的情况下，会导致 region 数量过多，给 PD 的压力管理带来很大负担。因此，我们将其调整为 128 MB，以防止 region 数量过多。需要注意的是，TiDB v8.4 以后这个值已变为 256 MB，无需再手动调整。
- 系统变量调整
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 中，美柚线上存在大量的分表，有些业务甚至分了1024张分表。当需要修改表结构时，需要花费十多天的时间进行 DDL 人工操作，变更过程非常痛苦。而 TiDB 的在线 DDL 功能，使得加列或修改列的操作能够在秒级完成，极大地简化了运维工作，释放了人力。
给 TiDB 使用者的建议
基于多年的实践经验，美柚团队为 TiDB 的使用者提供了以下几点建议：
- 重视官方学习资源： 官方文档和视频课程是获取 TiDB 知识最权威、最有效的途径，其中蕴含着丰富的干货和案例。
- 积极参与社区论坛： 社区论坛是交流和解决问题的重要平台。在 TiDB 社区中，不仅可以寻求帮助，也可以通过帮助他人来提升自己。
- 做好应急预案与运维手册： 在上线前，务必对各种故障场景进行充分的模拟，并制定详细的运维手册和应急预案，确保在任何突发状况下都能迅速应对。
- 保持版本统一： 尽量保持 TiDB 的大版本统一，避免因版本差异导致后期维护成本增加。对于老版本，建议尽快进行升级。
- 生产环境独立部署： 对于在线业务，不要为了节省成本而将各个组件混合部署。资源争抢可能导致业务受损，得不偿失。
结语
美柚在 TiDB 上的实践是一场从技术探索到赋能业务的成功之旅。TiDB 以其卓越的分布式能力，为美柚的核心业务，特别是出海业务，提供了稳固的支撑。以严谨的态度和扎实的实践，美柚为我们展示了如何将一个强大的数据底座，真正融入到业务核心，并创造出显著价值。
