作者介绍：刘春雷，58 集团高级 DBA，负责 MySQL 和 TiDB 的运维工作，TUG Ambassador。
58 集团业务种类繁多，目前包括的业务有 58 同城、赶集网、安居客、58 金融公司、中华英才网、驾校一点通等，数据库种类包括 MySQL、Redis、MongoDB、ES、TiDB。我们自己构建了“58 云 DB 平台”，整合了所有数据库的一体化运维。
本文将重点从运维的角度，介绍 TiDB 在 58 集团应用实践及后续计划。
一、TiDB 在 58 集团的使用概况
我们目前使用 TiDB 的服务器为 50+ 台，服务器的配置为 24 核的 CPU，128G 内存，用的是宝存的闪存卡。部署 TiKV 实例 88 个，集群共 7 套，每个业务一套集群，涉及到 TiDB 多个版本。由于是单集群多个库，目前库的数量大概是 21 个左右。磁盘目前数据量并不算大，在 10T 左右。涵盖的业务线大概目前有 7 条，包括 58 招聘、TEG、安居客、用户增长、信息安全、金融公司还有车业务，后续还会有比较多的业务推进。
二、业务需求及解决方案
业务需求目前有 4 点：
- 有大容量、需要长期保留的数据
目前 MySQL 都是单机存储，物理机容量有限，大约是 3T 的单机容量，由于磁盘空间瓶颈，MySQL 扩容比较麻烦。
- 保证业务高可用
目前我们在 MySQL 上做的是主从复制+ MHA，这个方案有一个问题是，当主库挂掉的时候，需要切换主从，就会影响一定时间的写入，这对于业务来说影响比较大。
- 需要更高的读写性能
MySQL 目前都是单点写入，也就是主库写入，如果要读的话，就需要通过从域名到从库来进行读操作，读延时比较高，同时读流量增加会进一步加大延迟高的问题。
- 分库分表很痛苦
在数据量特别大的情况下，就需要分库分表，分库分表大家都比较痛苦，因为聚合比较困难，业务侧开发同事也要自己维护库表的对应路由信息。
上面这几点在 TiDB 上都被很好的解决了，比如 TiDB 可以水平伸缩，如果计算能力不够的话，直接加节点就可以了，而且 TiDB 有多副本，可以保证数据安全及高可用。另外，TiDB Server 没有状态，支持多点读写。TiDB 无需分库分表，操作比较简单，也不用定期清理数据。
三、TiDB 环境建设
TiDB 的环境建设包括开发工具进行慢 SQL 的分析，完善监控系统，并把 TiDB 接入到“58 云 DB 平台”，收集数据、做可视化报表等等。
1. 架构
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 这张表提取结果，直接进行汇总展示）。
这个针对 TiDB 2.X 版本的慢 SQL 分析工具，主要是判断慢日志的采集区间，把所有的 SQL 格式化、逻辑化，把每类 SQL 的类型、具体信息采集出来，然后再把此类逻辑 SQL 的具体 SQL 放在一个具体的文件上，然后再去展示它的具体情况，如下图所示。
主要信息包括比如排序情况、库名、账号、平均执行时间、执行次数、具体逻辑 SQL 等。
(3) 状态检查工具：tidb_check
我们会临时查看某个集群的状态，比如宕机检查等等。这是跟监控类似的工具，防止集群繁忙时的状态误报情况。因为我们当前的监控是通过 Prometheus 来获取数据的，但 Prometheus 是单点，如果 Prometheus 挂了，或者在 TiDB 集群特别繁忙的时候，可能从 Prometheus 采集数据延迟高，然后大家判断 TiDB 集群可能挂掉了，这时我们就会用 tidb_check 查看 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. 平台化
在平台化方面，我们把 TiDB 接入到了“58 云 DB 平台”，利用开源 inception 来处理 DDL/DML 工单。平台分为管理端和用户端，管理端就是 DBA 用来做元信息维护、工单处理、运营报表、监控概览等。用户端方面，业务会在上面申请 TiDB 集群、DDL/DML 工单，账号管理，查看集群的信息及监控情况，他们还可以自助查询库中的数据。
TiDB 运维管理方面主要是集群的信息展示、查看集群的监控，或者添加 TiDB/TiKV/PD 节点。另外我们也可以批量添加实例，选好机器、配好角色，然后指定开发负责人，就可以直接添加了。
4. 可视化报表
可视化报表方面的工作是将 Prometheus 或者服务器的 Zabbix 的监控数据汇总放在平台上，提供给开发人员和 DBA 查看，主要维度包括服务器负载情况、CPU 内存、磁盘、网络、IO 等。集群方面是通过 Prometheus 的接口获取该集群当前使用量和总容量情况，库、表方面就是通过定期采集观察库的数据增长情况。
四、业务及 TiDB 使用情况
目前，58 集团使用 TiDB 的业务主要有 TEG 业务、安居客（日志类）、用户增长业务（58 咨询、通讯录数据保存）、信息安全（验真中心）、金融公司（金融实时数据仓库底层存储）、车业务（二手车话单分配） 等，其中应用最多的是 TEG 业务。
TEG 的业务主要包含 WList、WTable 管理后台、搜索指数等，这些都是我们自研数据库的管理端，目前写入量比较大，数据量在 6T 左右，数据增长 500G/月 左右，近半年 TEG 业务损坏了 8 块闪存卡，但是都没有影响业务，让我们充分感受到了 TiDB 高可用的优势。
目前 TiDB 在 58 集团内部应用总量增长趋势是很快的，从 2018 年中开始接入 TiDB，到目前 TiKV 实例是达到 88 个，库的增长是达到 22 个左右，尤其是今年第二季度开始发力增长。
五、后续计划
我们后续计划将服务管理平台、PMC 订单流水等 6 个业务，共 18 套 MySQL 集群全部迁移到 TiDB，总计磁盘量 30T，数据量 2000 亿。其中最重要的是 PMC 订单流水这个库，它有 8 套 MySQL 集群都是分库，每套集群磁盘量 2T，迁移 TiDB 的过程应该会有很大的挑战。
在运维方面，我们已经着手准备版本升级，可能会全部迁到 TiDB 3.0 版本，目前已经升级了一套，还是非常平稳的。至于监控完善，刚刚已经提到过，之后监控工具将通过多个组件接口来获取数据，防止单点问题导致误报。在报表功能方面，我们也在持续开发完善，比如包括 3.0 版本下的慢 SQL 查询的优化等。另外，因为有数仓类的业务，所以我们也考虑使用 TiSpark 和 TiFlash 提升系统性能。最后，我们也在做自动化部署、扩缩容、故障处理方面的开发。
本文整理自刘春雷老师在 TiDB TechDay 2019 成都站上的演讲。
原文阅读：https://pingcap.com/cases-cn/user-case-58/
更多案例阅读：https://pingcap.com/cases-cn/
