案例合集丨TiDB 助力出海企业架构升级：多点DMALL、携程、LiveMe 的数字化实战

多点 DMALL 在全球业务中采用 TiDB，运营 46 个集群、300 多个节点，管理超过 400TB 数据，支撑业财融合等关键业务。尽管运行多个 TiDB版本，多点通常谨慎升级以避免风险，但业务需求和新功能促使他们不断评估升级。TiDB 社区的活跃氛围为多点在选择新版本时提供了宝贵经验。自 2018 年起，多点逐步从 MySQL 迁移至 TiDB，经过多次升级，现已使用最新 6.5.8 版本，以应对业务挑战和提升性能。

● 持续增长数据管理：TiDB 以其写入优化和无限扩展能力，有效处理数据持续增长的场景，并通过压缩技术大幅降低存储成本，相比 MySQL 单副本存储效率提升近10倍；

● 数据冷热分离与归档：通过自研的 DRC-TiDB 工具，多点实现了 MySQL 到 TiDB 的数据同步，优化了冷数据和历史数据归档，同时保持了 MySQL 的高性能读写；

● OLAP 聚合查询优化：TiDB 支持合库合表，简化了原本在 MySQL 中复杂的跨库表查询和聚合操作，TiFlash 的列存特性进一步加速了统计操作；

● ES 成本效益替换：多点内部广泛使用的 ES 因成本高昂而逐步被 TiDB 替代，经过测试，约 60% 的 ES 查询可以在 TiDB 中以更低的成本实现

多点 DMALL 原先仅在微软云部署出海业务，但遭遇稳定性和成本问题，包括基础设施不稳定、IO 性能不达标和高成本。为提升业务可用性，多点转而采用微软云和华为云的双机房部署模式，在新加坡实现同城双活架构，确保任一机房故障时业务能迅速恢复，从而增强 RTA OS 的稳定性和数据安全性。

在使用 TiDB 过程中，多点Dmall曾遇到 4.0.9 版本的几个问题：TiDB Server 的 OOM 问题，由于 expensive SQL 操作内存消耗过高；CDC 功能在重启后 checkpoint 不推进，导致服务无法恢复；以及 dashboard 查询 slowlog 时因 plan decode 导致 OOM 。此外，还有执行计划偏差和 TiFlash 重启问题。不过，这些问题在 TiDB 后续版本中已得到解决。建议优先使用新版本，因为社区反馈的问题和解决方案已集成在更新中。

携程自 1999 年成立起主要使用 SQL Server 数据库，但自 2012 年起开始引入开源 MySQL，尽管最初占比仅 10% 。2014 至 2019 年间，随着业务需求变化，携程深化了 MySQL 应用，并进行了深入研究与优化。尽管应用跨多个 IDC 部署，数据库的单主节点架构仍导致切换时业务中断。携程采用客户端分片规则扩展数据库，避免了中间件使用，但这也给运维带来了挑战，尤其是在业务代码复杂性增加和 DBA 团队扩大的情况下。

携程主要从以下几个维度考量分布式数据库：

● 性能：平衡性能和成本，选择通用机型，不使用高端存储或机器，并要求响应稳定；

● 运维与社区：学习成本适中，运维复杂度低，产品需开源且社区活跃；

● 成本：一方面，业务研发需要学习使用 SQL，特别是 MySQL 协议；另一方面，运维团队希望产品不要过于复杂，易于维护；

● 扩展性：分布式数据库需要具有快速的扩展能力，扩缩容对业务影响小。

2018 年，携程引入 TiDB，针对其 IDC 环境，将 TiDB 组件跨三个 IDC 机房部署，实现故障时的自动切换和流量本地感知，增强了系统的高可用性和弹性。

携程面临酒店和度假结算场景中的大量交易数据处理挑战，原 MySQL 分片架构在扩展性和性能上受限，且分片键选择困难，对业务代码侵入大。TiDB 的分布式架构解决了这些问题，支持数据水平扩展，提高承载力。携程成功将 8TB 数据从 SQL Server 迁移至 TiDB，提升了性能，简化了运维，并支持了业务发展。

携程处理海量数据时，原单机存储限制导致必须通过分片扩展，但这种方法复杂且限制多。引入 TiDB 后，其行列混存架构显著提升了查询性能，部分查询速度提升达 20 倍，单表支持超过 300 亿行数据，实现毫秒级读写和秒级聚合查询，有效优化了数据存储和处理效率。

除了使用 TiDB ，携程还在使用其存储层 TiKV。TiKV 的部署与 TiDB 类似，也是在三个机房分布部署，应用可以感知到每个机房的 PD，并且 PD 也在三个机房分别部署。该架构可以确保如果出现机房级故障，或是单 PD 故障，运维团队都可以做到平滑切换。

携程在海外业务的快速增长中，采用了国内成熟的数据库技术，特别是 TiDB 的独立部署。TiDB 的引入简化了内部生态整合，包括发布系统和数据管理，得益于其与 MySQL 相同的协议。携程利用 Prometheus 和 Grafana 进行监控，通过 remote write 将性能数据转发至统一平台，实现告警和监控。TiDB 的 HTAP 能力提升了查询性能，优化了海量数据存储，现稳定支持携程国内外业务场景。

近年来，互联网发展迅速，线上需求激增，使直播成为国内外成熟商业模式。国内竞争激烈，直播企业如 LiveMe 积极出海，在全球市场取得成功。LiveMe 自 2016 年推出，提供多样化直播功能，已积累超 1 亿用户和 300 万主播，成为美国热门社交应用，在 200 多国推广。

经过了多年的沉淀，LiveMe 在业务上已经形成了线上微服务主导，线下计算中心主导的技术架构。这套业务架构中线上业务主要面临着以下痛点：

● 数据库分表问题：虽然实现了微服务分库，但业务中的大表存在MySQL分表需求，难以进行聚合查询，且需要频繁根据时间进行垂直分表，导致线上需求难以满足。

● 实时数据分析需求：对于分析型业务数据，需要保证数据的实时性并保留细节，以支持快速业务决策和风控判断。目前的离线或实时计算方式无法保证数据实时性，且难以查看数据细节。

● 精细化运营需求上升：随着推荐、个性化运营等场景的增加，对数据的实时性要求越来越高。

如果 LiveMe 继续使用大数据技术栈，将面临架构复杂、中间件众多、学习成本高的问题，且需简化架构至仅 CRUD 操作的易用性。

基于以上业务挑战，LiveMe 经过一系列技术选型后最终选择了 TiDB 数据库。TiDB 的以下特性可以帮助 LiveMe 很好的应对挑战：

● 性能需求：TiDB 提供与 MySQL 相当的性能；

● 实时分析：TiDB 的 HTAP 特性支持实时大表处理和 OLAP 分析，确保数据报表的实时性；

●查询速度：TiDB 的 MPP 架构大幅提升了 OLAP 查询速度；

● 技术支持：TiDB 团队提供专业支持，确保大规模线上使用无忧。

对于业务数据， LiveMe 使用 AWS SQS 消息队列，相比 Kafka 的优势在于每条数据都是原子性的，每条数据都可以用来做幂等重试，来保证数据的最终一致性。目前，这套技术方案已经支撑了 LiveMe 的活动运营和金融风控等多个业务场景，满足了 LiveMe 对于线上大量数据实时聚合查询的要求。

LiveMe 有一个类似朋友圈功能的场景，这个业务中存在两个技术难点：第一是对于数据的无限量增长存储如何实现扩容；第二是数据的冷热分离，这又涉及到数据成本的问题。

基于 TiDB 解决方案，LiveMe 技术团队在上述写扩散场景中，把扩散写入的部分替换成了 TiDB，使用一张数据库表来存储所有 feed 的写入关系，比如用户有 100 万粉丝，就在数据库里插入 100 万条数据。基于 TiDB 的分布式数据库特性，帮助 LiveMe 简单高效地解决了数据增长扩容问题。