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 自身的高可用机制。

图: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 的性能,将它全面应用到凤凰网业务中。

分享到微信

打开微信,使用 “扫一扫” 即可将网页分享至朋友圈。