TiDB 在 58 集团的应用与实践

做者介绍：刘春雷，58 集团高级 DBA，负责 MySQL 和 TiDB 的运维工做，TUG Ambassador。

58 集团业务种类繁多，目前包括的业务有 58 同城、赶集网、安居客、58 金融公司、中华英才网、驾校一点通等，数据库种类包括 MySQL、Redis、MongoDB、ES、TiDB。咱们本身构建了“58 云 DB 平台”，整合了全部数据库的一体化运维。

本文将重点从运维的角度，介绍 TiDB 在 58 集团应用实践及后续计划。

1、TiDB 在 58 集团的使用概况

咱们目前使用 TiDB 的服务器为 50+ 台，服务器的配置为 24 核的 CPU，128G 内存，用的是宝存的闪存卡。部署 TiKV 实例 88 个，集群共 7 套，每一个业务一套集群，涉及到 TiDB 多个版本。因为是单集群多个库，目前库的数量大概是 21 个左右。磁盘目前数据量并不算大，在 10T 左右。涵盖的业务线大概目前有 7 条，包括 58 招聘、TEG、安居客、用户增加、信息安全、金融公司还有车业务，后续还会有比较多的业务推动。

2、业务需求及解决方案

图 1 业务及需求

业务需求目前有 4 点：

• 有大容量、须要长期保留的数据

  目前 MySQL 都是单机存储，物理机容量有限，大约是 3T 的单机容量，因为磁盘空间瓶颈，MySQL 扩容比较麻烦。

• 保证业务高可用

  目前咱们在 MySQL 上作的是主从复制+ MHA，这个方案有一个问题是，当主库挂掉的时候，须要切换主从，就会影响必定时间的写入，这对于业务来讲影响比较大。

• 须要更高的读写性能

  MySQL 目前都是单点写入，也就是主库写入，若是要读的话，就须要经过从域名到从库来进行读操做，读延时比较高，同时读流量增长会进一步加大延迟高的问题。

• 分库分表很痛苦

  在数据量特别大的状况下，就须要分库分表，分库分表你们都比较痛苦，由于聚合比较困难，业务侧开发同事也要本身维护库表的对应路由信息。

上面这几点在 TiDB 上都被很好的解决了，好比 TiDB 能够水平伸缩，若是计算能力不够的话，直接加节点就能够了，并且 TiDB 有多副本，能够保证数据安全及高可用。另外，TiDB Server 没有状态，支持多点读写。TiDB 无需分库分表，操做比较简单，也不用按期清理数据。

3、TiDB 环境建设

TiDB 的环境建设包括开发工具进行慢 SQL 的分析，完善监控系统，并把 TiDB 接入到“58 云 DB 平台”，收集数据、作可视化报表等等。

1. 架构

图 2 TiDB 部署架构

TiDB 在 58 集团应用的架构如上图，主要分为管理机、云平台、监控、TiDB 集群等四个模块：

• 管理机

  主要是负责环境部署、监控程序、拓扑查询后、 SQL 的分析、报表程序、TiDB 集群的状态检查工具。

• 58 云 DB 平台

  平台主要功能有元信息维护、工单处理、集群信息的具体展现、监控概览，还有一些自助查询的接入，好比开发利用自助查询查看各自业务的 TiDB 集群状况。此外还有运营报表、TiDB 集群申请等功能。

• 监控

  包括实例监控、服务器监控和报警。

• 具体的 TiDB 集群

  主要分为读写 DNS 和只读 DNS，分别下接读写 TGW 和只读 TGW（TGW 是腾讯的 Tencent GateWay），经过读写帐号或者只读帐号，路由到具体的 TiDB 集群上。

2. TiDB 生态工具

咱们最近开发了如下几个运维工具。

(1) 拓扑查询工具：qtidb

用于查看一个集群的具体拓扑状况。

(2) SQL 分析工具：tidb_slow_query

TiDB 2.X 版本的慢 SQL 收集分析相比起来复杂一些，还不支持 pt-query-degist 这个工具（在最新的 2.1 及 3.0 版本中已支持），因此咱们就着手写了一个 SQL 分析工具，直接分析慢 SQL 的一个日志文件，将结果汇总展现（这个问题在 TiDB 3.0 中已经已经很好的解决了，直接从 SLOW_QUERY 这张表提取结果，直接进行汇总展现）。

图 3 慢 SQL 分析工具

这个针对 TiDB 2.X 版本的慢 SQL 分析工具，主要是判断慢日志的采集区间，把全部的 SQL 格式化、逻辑化，把每类 SQL 的类型、具体信息采集出来，而后再把此类逻辑 SQL 的具体 SQL 放在一个具体的文件上，而后再去展现它的具体状况，以下图所示。

图 4 慢SQL 分析结果举例

主要信息包括好比排序状况、库名、帐号、平均执行时间、执行次数、具体逻辑 SQL 等。

(3) 状态检查工具：tidb_check

咱们会临时查看某个集群的状态，好比宕机检查等等。这是跟监控相似的工具，防止集群繁忙时的状态误报状况。由于咱们当前的监控是经过 Prometheus 来获取数据的，但 Prometheus 是单点，若是 Prometheus 挂了，或者在 TiDB 集群特别繁忙的时候，可能从 Prometheus 采集数据延迟高，而后你们判断 TiDB 集群可能挂掉了，这时咱们就会用 tidb_check 查看 TiDB 集群的真实状态。

图 5 TiDB 状态检查工具

主要实现方式是根据元信息来生成一个实例的拓扑的文件，咱们查看集群的全部的拓扑以后再去从 Prometheus 获取数据而后汇总，最后把结果推送到 Zabbix 进行报警服务（目前咱们用 Zabbix 作统一监控、报警平台，后面暂时没有用官方推荐的 Altermanager），而后再入库进行展现。其实集群状态误报的问题也能够从另一个角度来解决，从各个组件的一个接口去获取集群的一个状态，防止 Prometheus 单点或其余的问题致使误报，这个功能目前也在开发中。

(4) 报表信息收集工具：tidb_report

报表信息收集工具也是经过 Prometheus 的一个接口来获取数据，获取当前的数据库和表的状况，到具体的集群上面去查，在 TiDB 3.0 版本下也会查一些 Slow Query 的表，汇总慢 SQL 的状况。

(5) 监控自动化工具：tidb_monitor

监控咱们是经过 tidb_monitor 这个工具，从 Prometheus 来获取各个节点的监控数据，逻辑化以后推到 Zabbix，咱们的监控平台，而后利用 Zabbix 进行趋势图展现和报警。

3. 平台化

图 6 运维管理平台架构

在平台化方面，咱们把 TiDB 接入到了“58 云 DB 平台”，利用开源 inception 来处理 DDL/DML 工单。平台分为管理端和用户端，管理端就是 DBA 用来作元信息维护、工单处理、运营报表、监控概览等。用户端方面，业务会在上面申请 TiDB 集群、DDL/DML 工单，帐号管理，查看集群的信息及监控状况，他们还能够自助查询库中的数据。

图 7 运维管理平台展现（1/2）

图 8 运维管理平台展现（2/2）

TiDB 运维管理方面主要是集群的信息展现、查看集群的监控，或者添加 TiDB/TiKV/PD 节点。另外咱们也能够批量添加实例，选好机器、配好角色，而后指定开发负责人，就能够直接添加了。

4. 可视化报表

图 9 可视化报表分类

可视化报表方面的工做是将 Prometheus 或者服务器的 Zabbix 的监控数据汇总放在平台上，提供给开发人员和 DBA 查看，主要维度包括服务器负载状况、CPU 内存、磁盘、网络、IO 等。集群方面是经过 Prometheus 的接口获取该集群当前使用量和总容量状况，库、表方面就是经过按期采集观察库的数据增加状况。

4、业务及 TiDB 使用状况

图 10 目前使用 TiDB 的业务

目前，58 集团使用 TiDB 的业务主要有 TEG 业务、安居客（日志类）、用户增加业务（58 咨询、通信录数据保存）、信息安全（验真中心）、金融公司（金融实时数据仓库底层存储）、车业务（二手车话单分配） 等，其中应用最多的是 TEG 业务。

TEG 的业务主要包含 WList、WTable 管理后台、搜索指数等，这些都是咱们自研数据库的管理端，目前写入量比较大，数据量在 6T 左右，数据增加 500G/月 左右，近半年 TEG 业务损坏了 8 块闪存卡，可是都没有影响业务，让咱们充分感觉到了 TiDB 高可用的优点。

图 11 TiDB 数据库总量增加趋势

目前 TiDB 在 58 集团内部应用总量增加趋势是很快的，从 2018 年中开始接入 TiDB，到目前 TiKV 实例是达到 88 个，库的增加是达到 22 个左右，尤为是今年第二季度开始发力增加。

5、后续计划

咱们后续计划将服务管理平台、PMC 订单流水等 6 个业务，共 18 套 MySQL 集群所有迁移到 TiDB，总计磁盘量 30T，数据量 2000 亿。其中最重要的是 PMC 订单流水这个库，它有 8 套 MySQL 集群都是分库，每套集群磁盘量 2T，迁移 TiDB 的过程应该会有很大的挑战。

图 12 后续计划使用 TiDB 的业务

在运维方面，咱们已经着手准备版本升级，可能会所有迁到 TiDB 3.0 版本，目前已经升级了一套，仍是很是平稳的。至于监控完善，刚刚已经提到过，以后监控工具将经过多个组件接口来获取数据，防止单点问题致使误报。在报表功能方面，咱们也在持续开发完善，好比包括 3.0 版本下的慢 SQL 查询的优化等。另外，由于有数仓类的业务，因此咱们也考虑使用 TiSpark 和 TiFlash 提高系统性能。最后，咱们也在作自动化部署、扩缩容、故障处理方面的开发。

本文整理自刘春雷老师在 TiDB TechDay 2019 成都站上的演讲。

原文阅读：pingcap.com/cases-cn/us…

更多案例阅读：pingcap.com/cases-cn/