TiDB 在凤凰网新闻内容业务的创新实践

作者：卞新栋，凤凰网工程师

背景

凤凰网（纽交所上市公司，代码：FENG）是全球领先的跨平台网络新媒体公司，整合旗下综合门户凤凰网、手机凤凰网和凤凰视频三大平台，秉承"中华情怀，全球视野，兼容开放，进步力量"的媒体理念，为主流华人提供互联网、无线通信、电视网的三网融合无缝衔接的新媒体优质内容与服务。

在媒体行业，新闻内容就是核心的业务数据，我们需要一个稳定的、具有高可用的、易水平扩展的数据存储系统，来存放公司核心数据，在最早，我们采用比较流行的 MySQL 来存储各个业务模块的内容，通过主从切换的方式进行高可用，但随着数据量的增加，MySQL 单机容量成为了瓶颈，传统的基于 MySQL 分片方案在实现及运维都需要比较昂贵的成本，同时 MySQL 主流主从切换方案由于机制问题，在判断“主库真死”，“新主库选举”及“新路由信息广播”上都存在一些不足，整体时间消耗比较大，并不能达到公司核心业务的高可用要求。于是，我们不得不寻找新的解决方案。

选择 TiDB

前期方案选择

在选择评估初期，我们主要有以下几个考虑点：

1. 支持业务弹性的水平扩容与缩容；

2. 满足业务故障自恢复的高可用；

3. 支持 MySQL 便捷稳定的迁移，不影响线上业务；

4. 支持 SQL，尽量少的改动代码；

5. 使用上、运维上要足够优化，最好支持在线 DDL。

在寻找的道路中，我们惊喜的发现了 TiDB — 中国人研发主导的开源分布式数据库。

数据库容量及扩展

记得有这样一句话：“单机 MySQL 能解决的问题，不要使用 TiDB！”，我们原有的数据存储存放于多个 MySQL 数据库中。诚然，对于数据量小的库来说，一些常见的点查、范围查 MySQL 的性能要比 TiDB 的性能好，如果不考虑扩张的问题，短期内使用主从 MySQL 比使用 TiDB 更满足我们的线上需求，但是，即使如此，我们也不得不考虑成本问题。将多套线上的主从 MySQL 迁移到 TiDB，更能充分利用服务器资源，减少资源的浪费。而对于很多业务来说，扩张问题是不可能回避的，对数据日益增长的数据库来说，单表响应时间会越来越长，而分库分表的成本过高，代码需要改动和测试，即使业务上能接受这一次的操作，那下次扩容呢？TiDB 通过底层自动进行分片帮我们解决了这个问题，同时业务量的增加或减少可以通过添加减少节点来处理，代码上基本无改动，这也是我们所期望的。

高可用

对于原有的主从 MySQL，并没有配置高可用，我们也对 MHA 等第三方工具做过调研，在发生主从切换后，在新路由信息分发这块也依赖修改网络配置或者数据库中间件（DBproxy），有一定的时间成本，虽然业界有很多中间件方案，但也很多问题和技术成本，所以这个方向并不是我们首选，之前的方式是一旦 MySQL 主数据库宕机，我们通过内部的监控系统获知，再进行更改 Keepalived + HAproxy 配置，即使人为响应非常及时，其影响的时间也早已超过业务的容忍。而选择天然的多节点 TiDB 自然就避免了这一点，配合网络 HAproxy 完全实现了 DB 层面的高可用。前一段时间，我们内部监控系统升级，其中一台机器没有对 TiKV 添加监控，而该 TiKV 节点由于硬件原因服务宕了几天，我们业务上也未感知，当然这是我们的失误，但是也侧面反应了 TiDB 自身的高可用机制。

OSC 问题

众所周知，一个可编程的内容管理平台，增加字段是再正常不过的业务场景，虽然 MySQL 5.7 已经支持 Online DDL，但实际操作还有很多限制，并且经常性导致从库延迟，TiDB 支持在线 DDL，加字段的过程是非阻塞的，平滑的，业务无感知的，这也是我们选择它的一个重要原因。

迁移 TiDB

MySQL 数据迁移到 TiDB 上，我们使用 mydumper、loader 对数据导入导出。而后续数据的增量同步，PingCAP 公司提供了 Syncer 工具回放 MySQL 传来的 Binlog 日志来模拟 MySQL 的 Slave。让我们感到惊喜的是，它支持多个 MySQL 同时同步到一个 TiDB，刚开始，我们就采用这种方式来搭建环境，这种便捷的方案可以把我们的精力从数据迁移中解放出来，更多关注在业务测试和试用上，经过完善的业务测试后，我们发现 TiDB 高度兼容 MySQL，于是我们逐步将每个库流量切到 TiDB 上，整个数据迁移、流量迁移都非常友好便捷。实际迁移过程中，只遇到了由于部分原有 MySQL 版本过低导致 Binlog 格式不兼容的问题，除此之外其他都很顺利。

节点迁移

TiDB 的线上节点迁移。我们线上的部分 TiDB 是使用 Binary 部署的，且版本过老（2016 年的版本），无法进行及时的自动化升级，因此当我们涉及到机房迁移的时候，会担心是否会影响服务。好在迁移涉及的是无状态的 TiDB 节点和存储元数据的 PD 节点，在对 PD 节点一上一下逐步增加减少验证无误后，启动新机房中的 TiDB 节点，经 Haproxy 层灰度上线几台后，下掉原有的 TiDB 节点，完成迁移。

官方强力支持

当然，虽然官方提供的迁移方案很友好，但在学习了解、实际操作阶段也免不了磕磕绊绊，之前很长一段时间内我们并没有与 PingCAP 公司取得联系，但当我们出现迁移问题的时候，我们选择求助官方，他们非常迅速的响应了我们，解决了线上迁移因 etcd 导致的 PD 节点去除故障，而且还安排了架构师来我们公司进行技术交流，锦上添花不如雪中送炭，当时我们在与官方人员沟通时，深深体会到了这一点。

TiDB 数据库的稳定性还是非常不错的，在我们和官方取得联系的时候，我们使用的 beta4 版本也已稳定运行了近 220 天。

TiDB 目前环境

目前我司有三套 TiDB 在使用，均为 OLTP 业务。其中前两套使用 Binary 安装的远古版本（beta4），第三套才是 TiDB GA 版本，通过官方 Ansible 进行的部署。

在与官方沟通中获知，两套远古版本（beta4）由于距离现有版本太多需要进行迁移升级，官方也十分愿意为我们提供技术支持，在此，就先谢过官方的帮助，显然，对我们来说后续也少不了麻烦。

一点吐槽

TiDB 的出现，帮我们跳过了传统的 Sharding + proxy 的路线，给我们节省了巨大的技术成本，我们对 TiDB 非常的钟爱，但在接触、使用 TiDB 过程中，我们也遇到一些问题。即使官方对于服务器配置有明确的要求（SSD 以上硬盘），但对我们公司内来说，刚开始很难申请到高性能的机器来进行 TiDB 功能性测试，和学习、熟悉 TiDB 的搭建、扩容、迁移等操作，于是在刚开始，我们拿几台低性能的测试机，使用 loader 导入数据进而进行增量测试的时候，出现了报错，TiDB 的报错信息并没有提醒我这是由于机器性能低引起的，而在官方文档中，也没有这方面的引导，这导致我们反复导入测试多次，问题依然存在，后才考虑可能是机器性能导致的（官方已经在最新的 ansible 安装脚本中做了硬件的性能检测），于是申请了几台高性能机器进行复测，验证确实是因为机器性能导致。后在与官方人员沟通时得知，**整个 TiDB 架构是面向未来、面向海量数据高并发场景，底层存储技术（如数据定位 seek）都是针对当前主流的 SSD 进行设计和优化的，不会对传统的 SATA/SAS 机械硬盘再进行优化。**至于官方文档和报错信息，他们也在持续快速的更新中。

展望

在与官方进行详细沟通，听取官方架构师的分享后，我们近期打算再上 2-3 套 TiDB 集群对众多不同业务线主从 MySQL 进行整理归纳，这样不但可以逐步统一、规范数据库的使用，而且还可以大大减少机器资源浪费，运维成本，同时借助 TiDB 实现我司数据库的高可用。而在听取分享的其他部门的小伙伴也已经行动起来，对于我司一个重点 OLTP 新项目，已经确定使用 Cloud TiDB（在 K8S 上部署 TiDB）作为数据库系统。同时我们了解到，TiDB 不仅仅满足 OLTP 业务，它还能满足很多 OLAP 业务场景，听完分享后，大数据组小伙伴也在跃跃欲试中。

未来，我们将加强与 PingCAP 官方的沟通交流，进行更深入的研究和开发，持续提升 TiDB 的性能，将它全面应用到凤凰网业务中。