1.3万亿条数据查询如何做到毫秒级响应？( 二 )

2025-12-19 数据查询

MHA不为从属服务器提供读取负载平衡功能。

MHA只能监视主服务器（而不是从主服务器）是否可用。

在我们发现TiDB并将数据从MySQL迁移到TiDB之前，数据库可伸缩性仍然是整个系统的弱点。
什么是TiDB？
TiDB平台是一组组件，当它们一起使用时，它们将成为具有HTAP功能的NewSQL数据库。

1.3万亿条数据查询如何做到毫秒级响应？

文章插图

图1 TiDB平台架构
在TiDB平台内部，主要组件如下：

TiDB服务器是一个无状态的SQL层，它处理用户的SQL查询，访问存储层中的数据，并将相应的结果返回给应用程序。它与MySQL兼容并且位于TiKV之上。
TiKV服务器是数据持久存在的分布式事务键值存储层。它使用 Raft共识协议进行复制，以确保强大的数据一致性和高可用性。
TiSpark集群也位于TiKV之上。它是一个Apache Spark插件，可与TiDB平台配合使用，支持商业智能（BI）分析师和数据科学家的复杂在线分析处理（OLAP）查询。
放置驱动程序（PD）服务器是由 etcd支持的元数据集群，用于管理和调度TiKV 。

除了这些主要组件之外， TiDB还拥有一个工具生态系统，例如用于快速部署的 Ansible脚本，用于从MySQL 迁移的 Syncer和 TiDB数据迁移，以及用于收集对TiDB群集进行的逻辑更改并提供增量备份的 TiDB Binlog 。复制到下游（TiDB ， Kafka或MySQL）。
TiDB的主要功能
TiDB的主要功能包括：

水平可扩展性。
MySQL兼容之语法。
具有强一致性的分布式事务
云原生架构。
使用HTAP进行最小提取，转换，加载（ ETL）。
容错和Raft恢复。
在线架构更改。

我们是如何使用TiDB的
在本节中，我将向您展示如何在Moneta的架构中运行TiDB以及Moneta应用程序的性能指标。
我们架构中的TiDB
我们在系统中部署了TiDB ， Moneta应用程序的整体架构变为：

顶层：无状态和可伸缩的客户端API和代理。这些组件易于扩展。
中间层：软状态组件和分层redis缓存作为主要部分。当服务中断时，这些组件可以通过恢复保存在TiDB群集中的数据来自我恢复服务。
底层：TiDB集群存储所有有状态数据。它的组件高度可用，如果节点崩溃，它可以自我恢复其服务。

1.3万亿条数据查询如何做到毫秒级响应？

文章插图

知乎的Moneta应用程序中的TiDB架构
在该系统中，所有组件都是可自我恢复的，整个系统具有全局故障监视机制。然后，我们使用 Kubernetes来协调整个系统，以确保整个服务的高可用性。
TiDB的性能指标
由于我们在生产环境中应用了TiDB ，因此我们的系统具有高可用性和易于扩展性，并且系统性能得到显着改善。
例如，在2019年6月为Moneta应用程序采用一组性能指标：
在高峰时间每秒写入40,000行数据。

1.3万亿条数据查询如何做到毫秒级响应？

文章插图

每秒写入的数据行（数千）
在高峰时段每秒检查30,000个查询和1200万个帖子。

1.3万亿条数据查询如何做到毫秒级响应？

文章插图

每秒写入的数据行（数千）
第99百分位响应时间约为25毫秒，第999百分位响应时间约为50毫秒。实际上，平均响应时间远远小于这些数字，即使对于需要稳定响应时间的长尾查询也是如此。

1.3万亿条数据查询如何做到毫秒级响应？

文章插图

第99百分位响应时间

1.3万亿条数据查询如何做到毫秒级响应？

文章插图

第999百分位响应时间
我们学到了什么？
我们迁移到TiDB并非顺利。在这里，我们想分享一些经验教训。
更快地导入数据
我们使用TiDB数据迁移（DM）来收集MySQL增量binlog文件，然后使用 TiDB Lightning将数据快速导入TiDB集群。
令我们惊讶的是，将这1.1万亿条记录导入TiDB只用了四天时间。如果我们逻辑地将数据写入系统，可能需要一个月或更长时间。如果我们有更多的硬件资源，我们可以更快地导入数据。

推荐阅读

上一篇：淘宝直播有了浮现怎么流量还是那么少啊淘宝直播有浮现权但是完全没有流量

下一篇：架构师总结的9种OOM常见原因及解决方案