转转引入 TiDB 首先解决了分库分表的问题。某些场景不便于分库分表，分库分表会使业务层开发逻辑变得越来越复杂，不利于降本增效的方向。其次解决了海量数据存储的问题。单机容量有瓶颈，会影响最终集群的效果。

转转在 2018 年就开始调研 TiDB，从 1.0 到 3.0。目前集群数量 30+/数据量200T+/数据节点/500+/日访问量 1000 亿+，主要承载用户、交易、IM、商业等业务。

随着业务的扩展，集群数量的增加，维护成本也会相应增加。我们首先遇到的第一个问题，也是我们经常会遇到的问题就是性能问题的定位。业务 SQL 响应耗时突然增加了，如何定位是哪些 SQL 导致的？下面这图大家在使用 TiDB 时会经常见到，可以明显看到某一时刻集群的响应延迟变慢了，业务也想要知道为什么变慢了，这时候我们就要定位问题。

通常我们要打开 TiDB 监控平台看一些指标： Query 的指标、事务的指标等，看完之后我们再看 TiDB 日志, 监控过滤关键字后再结合上下文去了解 TiDB 发生了什么情况。最后去看 TiKV 的日志，通过关键字分析后基本上能够定位出来问题了。

如果维护的集群只是一套或两套，没有问题。但是当集群增加到上十套或上百套，节点相应增加时，我们怎么定位问题？

接下来是集群管理。运维单套集群时没有问题，但是管理多套集群时会遇到例如集群部署、集群版本升级、配置不兼容等问题。简单细说一下，比如说在集群部署时，PD 在 Systemd 下会有问题，因为每台机器只支持一个 PD，可以通过 supervise解决，但是在起停时容易失败。版本升级时，早期两星期升一次级，和官方同步，但后来跟不上了，所以我们就会选择一个版本停下来，然后观望。在版本升级的时候，我们遇到的问题是配置不一样，小版本也不一样，由于我们做了一些自定义的配置，可能在这个版本就不生效了，导致升级时出问题、报错。因为都是线上的集群，每次成本都很高。整体来说，集群管理难度增加，每次升级版本的体验都不太友好。

第三个问题：日志规范不统一。这个问题对于刚刚使用 TiDB 的用户来说感受可能不太深，但其实1.0 的日志和 2.0 的日志是不一样的。比如说慢日志这个日志格式，2.1 版本的关键字变化和 2.0 版本不兼容。这个对于我们运维人员来说成本很高。慢日志格式从 2.1.8 之后彻底变成 MySQL 形式，上下版本不太兼容，线上目前是多版本并存，所以极大地增加了日志处理的难度。

第四个问题：慢 SQL 对集群整体稳定性的影响。对于日常来说，线上复杂统计 SQL，大数据的 ETL 需求，以及数据临时抽取需求都很正常，但是直接在线上操作时有可能会导致整个集群响应延时变慢，最终影响整个业务的响应延时。

第五个问题：优化器不能正确命中索引概率较高，这个问题业务经常遇到。我的 SQL 一模一样，一个两秒，一个几十毫秒，怎么解释？比如说，在我们开启了统计信息自动统计、表的统计信息相对良好的情况下，两个一样的 SQL，一个走了索引，一个走了全程扫描，执行计划不一样。为什么在统计信息相对良好的情况下索引正确命中概率不高？大家可以先思考一下。

第六个问题：事务冲突会导致集群性能严重下降。例如图中的这个问题 SQL，执行时有一个并发更新的场景，在 TiDB retry_limite = 3 的情况下会严重影响集群性能。可以看到当 retry 出现时，整体锁的状态比较高，响应延时也相应增加。

刚刚我们整理了比较有代表性的六个问题，相信大家也有过思考。转转通过 TiDB 的标准化来解决：集群部署、信息收集、监控告警和业务上线中遇到的问题。

在集群部署标准化方面，转转至少部署 3 个以上的 TiDB Server，用于 TiDB 高可用，为数据提供稳定的接入，需要万兆网卡和机械磁盘。其次需要 3 个 PD Server, 千兆或万兆网卡都可以，机械磁盘。最后至少 6 个 TiKV Server，单独 TiKV 容量不超过 400GB，但这也因企业的使用而异，最好使用固态硬盘。

对于部署管理的建议：作为 MySQL 应用场景的补充，我们不建议接入 TiDB 的容量特别少，建议至少大于 500GB，避免浪费资源；单独 TiKV 容量不超过 400GB，这可以有效缩短 TiKV 故障之后的恢复时间；TiDB/TiKV 在高并发下千兆网卡会成为容量瓶颈，请使用万兆网卡；TiKV 单机多实例，可以使用多盘挂载，将 IO 进行隔离，目前应用效果较好。

接下来是信息收集的标准化。我们一直和官方吐槽日志能不能固定下来，一路从 1.0 追到 3.0，算是资深老用户。对于新上 TiDB 的用户，建议使用 2.1.8 之后的版本，日志相对稳定，做日志的 ETL 也相对容易。官方会在未来的版本中将格式固定下来，这对社区来说是一件非常好的事情。目前对于转转来说，经过我们的规范，主要问题还是在 TiDB 的慢查询这块，我们针对慢查询开发了对应的实时慢查询视图，方便业务 RD 观察集群慢查询信息。目前主要通过 Flume 进行日志采集，最终通过平台进行统一处理、展示和告警。

下面是告警监控标准化。 TiDB 的原生报警有很多种告警和监控，转转做了梳理，确保每次告警都能起到预警的效果，并且有意义，但不一定每次告警都需要人工干预。如果每天都在收报警，会产生疲劳，大家就不看了，所以我们希望做到告警收敛。

还有就是告警做了简化，做定制，让收到的人更容易理解信息。业务 RD 根本看不懂 TiDB 的原生报警，他们只想知道出了什么问题，所以我们做了处理。

最后就是监控简化，通过扫描关键指标获取集群瞬时状态，这个目前还在和 TiDB 的同学一起做这个事情，希望能够兼容多个版本可以获取到集群的瞬时值，以便快速了解到集群问题、状态，定位大方向故障。

最后是业务上线标准化。第一是 SQL 优化，表结构、索引及列表全部优化。DBA 要全程参与业务上线，包括建表、SQL List，审视表结构和 SQL，也就是我们每次要上线 TiDB 集群时，都要和业务去讨论有些地方可能有问题。SQL 要全部使用 Force Index，用于解决优化器不能正确命中索引概率高的问题。3.0 GA 中包含 SQL Plan Management，目前虽然是实验特性，但是大家可以测一下，这个是美团和 TiDB 一起联合开发的功能。然后响应延时我们要求比较高，99.9% 控制在 100 ms 以下，99% 控制在 10 ms 以下才能上线，能解决一些常规的响应延时。接下来就是 TiDB Explain, DBA 需要熟练掌握，并且将如何解读其中的内容告诉开发后才能上线。

第二是业务逻辑。在已有的业务场景下，并发更新同一条记录的情况下会触发 TiDB retry，在当前的事务模型（乐观锁）下表现并不好，怎么解决？我们使用的是转转自研的分布式锁 ZZLock，即将乐观锁加一个分布式锁来模拟悲观锁，这样对业务响应延时没有问题，可以将冲突时间降到比较平稳的时间。

第三是数据抽取，这是非常普遍的需求，我们使用了 binlog 这个组件，将 tidb-server 变更数据写到 Pump Cluster，然后 Drainer 将数据应用到下游集群，通过访问下游集群，解决在线上进行的复杂查询、抽取等时效要求不高的需求。

对于 TiDB 未来规划和展望，整体来说还是围绕降本增效这个主题，我们正在和 PingCAP 进行容器试点，接下来会将 TiDB 跑在云上面。

Q&A：

美团同学：转转现在最大的集群是什么场景下的，大概有几个节点？访问 QPS 峰值有多少，数据量有多大？

冀浩东：目前最大的集群是 IM 集群，有上百个节点，数据量上百亿。整体来说 TiKV 集群比较多，整体响应不错，SQL 都是基于主键查询，业务方面做得很好。

美团同学：当前线上版本分布情况是什么？为什么不都升级到2.1.8？

冀浩东：目前有 2.0、 2.0.5、2.1.7、2.1.8，主流版本是2.1.8。2.1.8以下版本还比较稳定，有升级规划但是业务还没有什么需求，所以想和业务一起升上去。如果 3.0 测试效果较好，会考虑直接升级到 3.0。

美团同学：一个集群有多个 DB，还是只有一个 DB？隔离怎么考虑？

冀浩东：一个集群只有一个 DB。

作者介绍：

冀浩东，转转数据库负责人，TiDB User Group (TUG) 大使。

原文链接：

https://asktug.com/t/tidb/1023

创作场景

TiDB 在转转的标准化之路