--- title: TiDB 在凤凰网新闻内容业务的创新实践 author: ['卞新栋'] date: 2018-01-04 summary: TiDB 的出现，帮我们跳过了传统的 Sharding + proxy 的路线，给我们节省了巨大的技术成本，我们对 TiDB 非常的钟爱。 tags: ['互联网'] category: case url: /case/user-case-ifeng/ weight: 23 logo: /images/blog-cn/customers/ifeng-logo.png customer: 凤凰网 customerCategory: 资讯 --- > 作者：卞新栋，凤凰网工程师 ## 背景 凤凰网（纽交所上市公司，代码：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 自身的高可用机制。 ![图：TiDB 天然高可用架构图](media/user-case-ifeng/1.png) ### OSC 问题 众所周知，一个可编程的内容管理平台，增加字段是再正常不过的业务场景，虽然 MySQL 5.7 已经支持 Online DDL，但实际操作还有很多限制，并且经常性导致从库延迟，TiDB 支持在线 DDL，加字段的过程是非阻塞的，平滑的，业务无感知的，这也是我们选择它的一个重要原因。 ### 迁移 TiDB MySQL 数据迁移到 TiDB 上，我们使用 mydumper、loader 对数据导入导出。而后续数据的增量同步，平凯星辰公司提供了 Syncer 工具回放 MySQL 传来的 Binlog 日志来模拟 MySQL 的 Slave。让我们感到惊喜的是，它支持多个 MySQL 同时同步到一个 TiDB，刚开始，我们就采用这种方式来搭建环境，这种便捷的方案可以把我们的精力从数据迁移中解放出来，更多关注在业务测试和试用上，经过完善的业务测试后，我们发现 TiDB 高度兼容 MySQL，于是我们逐步将每个库流量切到 TiDB 上，整个数据迁移、流量迁移都非常友好便捷。实际迁移过程中，只遇到了由于部分原有 MySQL 版本过低导致 Binlog 格式不兼容的问题，除此之外其他都很顺利。 ![图：多源实时同步汇总架构](media/user-case-ifeng/2.png) ### 节点迁移 TiDB 的线上节点迁移。我们线上的部分 TiDB 是使用 Binary 部署的，且版本过老（2016 年的版本），无法进行及时的自动化升级，因此当我们涉及到机房迁移的时候，会担心是否会影响服务。好在迁移涉及的是无状态的 TiDB 节点和存储元数据的 PD 节点，在对 PD 节点一上一下逐步增加减少验证无误后，启动新机房中的 TiDB 节点，经 Haproxy 层灰度上线几台后，下掉原有的 TiDB 节点，完成迁移。 ![](media/user-case-ifeng/3.png) ![](media/user-case-ifeng/4.png) ![](media/user-case-ifeng/5.png) ### 官方强力支持 当然，虽然官方提供的迁移方案很友好，但在学习了解、实际操作阶段也免不了磕磕绊绊，之前很长一段时间内我们并没有与 平凯星辰公司取得联系，但当我们出现迁移问题的时候，我们选择求助官方，他们非常迅速的响应了我们，解决了线上迁移因 etcd 导致的 PD 节点去除故障，而且还安排了架构师来我们公司进行技术交流，锦上添花不如雪中送炭，当时我们在与官方人员沟通时，深深体会到了这一点。 TiDB 数据库的稳定性还是非常不错的，在我们和官方取得联系的时候，我们使用的 beta4 版本也已稳定运行了近 220 天。 ![](media/user-case-ifeng/6.png) ### TiDB 目前环境 目前我司有三套 TiDB 在使用，均为 OLTP 业务。其中前两套使用 Binary 安装的远古版本（beta4），第三套才是 TiDB GA 版本，通过官方 Ansible 进行的部署。 ![](media/user-case-ifeng/7.png) 在与官方沟通中获知，两套远古版本（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 业务场景，听完分享后，大数据组小伙伴也在跃跃欲试中。 未来，我们将加强与平凯星辰官方的沟通交流，进行更深入的研究和开发，持续提升 TiDB 的性能，将它全面应用到凤凰网业务中。