TiDB 在爱奇艺的应用及实践

爱奇艺，中国高品质视频娱乐服务提供者，2010 年 4 月 22 日正式上线，推崇品质、青春、时尚的品牌内涵现在已深刻人心，网罗了全球广大的年轻用户群体，积极推进产品、技术、内容、营销等全方位创新。企业愿景为作一家以科技创新为驱动的伟大娱乐公司。咱们在前沿技术领域也保持必定的关注度。

随着公司业务的快速发展，原来广泛使用的 MySQL 集群遇到了不少瓶颈，好比单机 MySQL 实例支撑的数据量有限，只能经过不停删除较旧的数据来维持数据库的运转。同时单表的数据行数不断增大致使查询速度变慢。急需一种可扩展、高可用同时又兼容 MySQL 访问方式的数据库来支撑业务的高速发展。

我司从 2017 年年中开始调研 TiDB，而且在数据库云部门内部系统中使用了 TiDB 集群。从今年 TiDB 推出 2.0 以后，TiDB 愈发成熟，稳定性与查询效率都有很大提高。今年陆续接入了边控中心、视频转码、用户登陆信息等几个业务，这几个业务背景和接入方式以下详述。

项目介绍

1. 边控中心

边控中心存储的是机器的安全统计信息，包括根据 DC、IP、PORT 等不一样维度统计的流量信息。上层业务会不按期作统计查询，其业务页面以下：

<center>图 1 边控中心上层业务页面（一）</center>

<center>图 2 边控中心上层业务页面（二）</center>

在选型过程当中，也考虑过期序型数据库 Apache Druid（http://druid.io），可是 Druid 聚合查询不够灵活，最终放弃 Druid 选择了 TiDB 数据库。TiDB 几乎彻底兼容 MySQL 的访问协议，可使用现有的 MySQL 链接池组件访问 TiDB，业务迁移成本低，开发效率高。

边控中心是爱奇艺第一个在线业务使用 TiDB 的项目，因此咱们制定了详细的上线计划。

• 第一，部署单独的 TiDB 集群。而后，为了数据安全，部署了 TokuDB 集群，用做 TiDB 集群的备份数据库。
• 第二，咱们经过 TiDB-Binlog 将 TiDB 集群的数据变动实时同步到 TokuDB 集群中，做为 TiDB 的灾备方案。
• 第三，前端部署了自研的负载均衡中间件，以最大化利用多个 TiDB 节点的计算能力，同时保证 TiDB 节点的高可用。
• 第四，部署 Prometheus 和 Grafana 监控 TiDB 集群健康情况，同时 Grafana 接入了公司的告警平台，会及时将告警信息经过短信、邮件等方式通知到运维值班同事。

边控中心上线过程当中，也遇到了一些问题，都比较顺利的解决了：

• 最多见的问题是链接超时。通过仔细排查发现是统计信息严重过期致使执行计划没法选择最优解形成的，这个问题实际上是关系型数据库广泛存在的问题，广泛的解决思路是手工进行统计信息收集，或者经过 hint 的方式来固定执行计划，这两种方式对使用者都有必定的要求，而最新版本的 TiDB 完善了统计信息收集策略，好比增长了自动分析功能，目前这个问题已经解决。
• 还遇到了加索引时间较长的问题。这一方面是因为 DDL 执行信息更新不及时，形成查询 DDL 进度时看到的是滞后的信息。另外一方面是因为有时会存在 size 过大的 Region，致使加索引时间变长。这个问题反馈给 PingCAP 官方后获得比较积极的响应，大 Region 已经经过增长 Batch split 等功能在新版的 TiDB 中修复了。

边控中心上线之后，在不中断业务的状况下成功作过版本升级，修改 TiKV 节点内部参数等操做，基本对业务没有影响。在升级 TiKV 节点过程当中会有少许报错，如“region is unvailable[try again later]、tikv server timeout”等。这是因为缓存信息滞后性形成的，在分布式系统中是不可避免的，只要业务端有重试机制就不会形成影响。

边控中心上线之后，数据量一直在稳定增加，但查询性能保持稳定，响应时间基本保持不变，能作到这点殊为不易，我我的的理解，这个主要依赖 TiDB 底层自动分片的策略，TiDB 会根据表数据量，按照等长大小的策略（默认 96M）自动分裂出一个分片，而后经过一系列复杂的调度算法打散到各个分布式存储节点上，对一个特定的查询，无论原表数据量多大，都能经过很快定位到某一个具体分片进行数据查询，保证了查询响应时间的稳定。

边控中心数据量增加状况以下：

<center>图 3 边控中心数据量增加状况</center>

TiDB 底层自动分片策略：

<center>图 4 TiDB 底层自动分片策略</center>

2. 视频转码

视频转码业务是很早就接入 TiDB 集群的一个业务。视频转码数据库中主要存储的是转码生产过程当中的历史数据，这些数据在生产完成后还须要进一步分析处理，使用 MySQL 集群时由于容量问题只好保留最近几个月的数据，较早的数据都会删掉，失去了作分析处理的机会。

针对业务痛点，在 2017 年年末部署了 TiDB 独立集群，并全量+增量导入数据，保证原有 MySQL 集群和新建 TiDB 集群的数据一致性。在全量同步数据过程当中，起初采用 Mydumper+Loader 方式。Loader 是 PingCAP 开发的全量导入工具，可是导入过程总遇到导入过慢的问题，为解决这个问题，PingCAP 研发了 TiDB-Lightning 做为全量同步工具。TiDB-Lightning 会直接将导出的数据直接转化为 sst 格式的文件导入到 TiKV 节点中，极大的提升了效率，1T 数据量在 5-6 个小时内就能完成，在稳定运行一段时间后将流量迁移到了 TiDB 集群，而且扩充了业务功能，迄今稳定运行。

TiDB-Lightning 实现架构图：

<center>图 5 TiDB-Lightning 实现架构图</center>

3. 用户登陆信息

用户登陆信息项目的数据量一直在稳定增加，MySQL 主备集群在不久的未来不能知足存储容量的需求。另外，因为单表数据量巨大，不得不在业务上进行分表处理，业务数据访问层代码变得复杂和缺少扩展性。在迁移到 TiDB 后，直接去掉了分库分表，简化了业务的使用方式。另外，在 MySQL 中存在双散表并进行双写。在 TiDB 中进一步合并成了一种表，利用 TiDB 的索引支持多种快速查询，进一步简化了业务代码。

在部署增量同步的过程当中使用了官方的 Syncer 工具。Syncer 支持经过通配符的方式将多源多表数据汇聚到一个表当中，是个实用的功能，大大简化了咱们的增量同步工做。目前的 Syncer 工具还不支持在 Grafana 中展现实时延迟信息，这对同步延迟敏感的业务是个缺点，据官方的消息称已经在改进中，同时 PingCAP 他们重构了整个 Syncer，能自动处理分表主键冲突，多源同时 DDL 自动过滤等功能，总之经过这套工具，能够快速部署 TiDB “实时”同步多个 MySQL，数据迁移体验超赞。

<center>图 6 Syncer 架构</center>

在咱们公司业务对数据库高可用有两个需求：一个是机房宕机了，服务仍然可用。另外一个是，多机房的业务，提供本机房的只读从库，提高响应速度。针对这些不一样的需求，TiDB 集群采用了多机房部署的方式，保证其中任一个机房不可用时仍然正常对外提供服务（以下图）。对每一个 TiKV 节点设置 label 后，TiDB 集群在每一个机房都有一份数据的副本，PD 集群会自动调度到合适的副本进行读操做，也能够知足第二个要求。为了知足迁移过程当中的高可用性，会在流量迁移完成后部署 TiDB 到 MySQL 的实时同步。Drainer 支持指定同步开始的时间戳，有力支持了反向同步功能。

<center>图 7 TiDB 集群多机房部署形式</center>

在整个运维过程当中，PingCAP 的小伙伴们提供了及时的帮助，帮助咱们定位问题并提出建议，保证了业务的有序运行。在此表示由衷的感谢！

适用范围

在实践过程当中感觉到 TiDB 解决的痛点主要是横向扩展和高可用。单机数据库支撑的数据量有限，若是采用分库分表 + proxy 的方式，不管 proxy 是在客户端仍是服务端都增长了运维的成本。同时 proxy 的查询效率在不少场景下不能知足要求。另外，proxy 对事务的支持都比较弱，不能知足数据强一致性的要求。TiDB 能够直接替代 proxy+MySQL 的架构，服务高可用性、数据高可用性、横向扩展性都由 TiDB 集群完成，完美解决了数据量增量状况下出现的不少问题。并且，TiDB 在数据量越大的状况下性能表现得比 MySQL 越惊艳。

一些改进建议

• 统计信息的收集指望更加的智能化，选择更好的时机自动完成并且不影响线上业务。
• OLTP 和 OLAP 混合场景下相互间的隔离和尽可能互不影响还有许多工做值得推动。
• 一些外围工具还须要提供高可用特性。

将来计划

我司仍有其它业务在接入 TiDB 服务，目前正在评估测试中。一些业务场景是 OLTP+OLAP 混合的场景，TiSpark 正好能够大展身手。目前在测试集群发现 TiSpark 查询时对 OLTP 业务的影响仍是比较大的，必须限制 TiSpark 对 TiDB 集群形成的压力。还部署了单独 TiDB 集群作 OLAP 场景的测试，对内部参数作了针对性的优化。将来计划会继续加大对 TiDB 的投入，贡献一些 PR 到社区，其中很大的一部分工做是加强 TiDB-Binlog 的功能，和现有的一些数据同步组件整合起来，支持 TiDB 到 Kudu、HBase 等的同步。

做者：朱博帅，爱奇艺资深数据库架构师