TiDB 在游族网络平台部的深度应用

百家 作者:PingCAP 2018-02-08 10:55:42

  公司介绍  

游族网络股份有限公司(SZ.002174)成立于2009年,是全球领先的互动娱乐供应商。公司以“大数据”、“全球化”、“精品化”为战略方向,立足全球化游戏研发与发行,知名 IP 管理,大数据与智能化,泛娱乐产业投资四大业务板块全面发展。


背景


2017 年初的时候,游族的用户中心体系面临迭代和重构,当时数据库有数亿多的核心数据,通过hash key 分为了 1024 张表在 64 个数据库中来存储,使用自研的代码框架来进行对应 hash key 的 seek 操作。这时,非 hash key 的查询、DDL 变更等业务需求,分表分库逻辑代码框架的局限,让研发和运维都面临较高的数据库使用成本,数据库不能灵活高效的支撑业务需求。

图1:分库分表方案架构图

为了解决上述问题,游族的技术团队急需一套同时满足如下的条件的数据库分布式集群:

  • 能够提供实时的 OLTP 的一致性数据存储服务;

  • 弹性的分布式架构;

  • 配套的监控备份方案;

  • 稳定的高可用性;

  • 较低的迁移重构成本。


前期选择


最开始先考察了几个方案,但都有相对来说的不足:

  • 方案一,将整个分表分库逻辑剥离到开源分表分库中间件上:

    • 基于 2PC 的 XA 弱事务的一致性保证不尽如人意;

    • 高可用架构更加复杂,单分片的局部不可用会对全局产生影响;

    • 备份恢复的复杂度高;

    • 这些方案引入了新的 sharding key 和 join key 的设计问题,整体的迁移难度不降反升。

    • 方案二,官方的 MySQL cluster 集群:

      • ndb 引擎不同于 InnoDB,需要修改表引擎,且实际使用效果未知;

      • ndb 的高可用有脑裂风险;

      • 监控备份的方案需要另作整理;

      • 国内生产用例不多,资料缺乏,非企业版运维流程复杂。


      探索


      机缘巧合下,与 TiDB 的技术团队做了一次技术交流,了解到 TiDB 是 PingCAP 受 Google Spanner 的论文启发设计而来的开源分布式 NewSQL 数据库,具备如下 NewSQL 特性:

      • SQL支持 (TiDB 是 MySQL 兼容的);

      • 水平线性弹性扩展;

      • 分布式事务;

      • 跨数据中心数据强一致性保证;

      • 故障自恢复的高可用;

      • 海量数据高并发写入及实时查询(HTAP 混合负载)。

      上述的特点非常契合目前我们在数据库应用设计上碰到的问题,于是在与 TiDB 的技术团队沟通了解后,就开始着手安排部署和测试 TiDB:

      • TiDB 的备份目前采用的是逻辑备份,官方提供了一套基于 mydumper 和 myloader 的工具套件;

      • 监控用的是应用内置上报 Prometheus 的方案,可以写脚本与自有的监控系统对接;

      • 有状态的 KV 层采用的是 Raft 协议来保证,Leader 的选举机制满足了故障自恢复的需求;

      • KV 层的 Region 分裂保证了集群无感知的扩展。

      测试之后发现数据库运维中比较重要的几项都已经闭环的解决了,实测结论是:

      • TiDB 是分布式结构,有网络以及多副本开销,导致 Sysbench OLTP 测试中 TiDB 单 server 的读性能不如 MySQL,但写优于 MySQL,且弹性扩展能力评估后可以满足业务的峰值需求;

      • TiDB 的 OLAP 能力在大数据量下远优于 MySQL,且能看到持续的大幅提升;

      • 由于 TiDB-Server 是无状态的,后续可以添加 Load Balance 来扩展 Server 层的支撑。


      持续引入


      在性能和需求满足前提下,就开始着手业务层的接入和改造: MySQL 协议的兼容这时候极大的降低了迁移到 TiDB 的成本,官方的 TiDB 同步 MySQL 的 Syncer 工具也给了接入和改造有力的支持,部分迁移在业务层就是一次 MySQL 的主从切换。

      于是,用户积分系统的扩展便不再采用分表分库的方案,分表逻辑回归到多个独立的单表,数亿的数据在 OLTP 的业务场景下表现十分出色,没有 sharding key 的约束后,整个使用逻辑在上层看来和 MySQL 单表没有不同,更加灵活的索引也提供了一部分低开销的 OLAP 的查询能力,整体的迁移改造流程比较顺利,业务契合度很高。

      随着上述系统的成功应用后,后面符合场景的 OLTP 项目也逐渐开始使用 TiDB:

      • 登录态系统:原先的在 MySQL 采用 Replace 保留最后一条数据,迁移到 TiDB 的模式后,由于表的伸缩能力获得了很大的提升,故将 Replace 改为了 Insert 保留了所有的登录情况,单表数据量十亿以上,业务上支持了更多维度的记录,没有碰到性能和扩展性问题;

      • 礼包码系统:礼包码的主流程为复杂度 O(1) 的 hash seek OLTP业务,经过 TiDB 的改造后,将原来的 100 个表的分表模式集中成单表管理,单表数据预计会达到 20 亿+;

      • 用户轨迹项目:数据库弹性能力增长后的新需求,一些重要的用户行为数据的记录。

      同时,在 kv 存储层没有瓶颈的时候,采用复用了集群的 kv 层的策略,在无状态的 Server 层做了业务隔离,间接的提升了整个集群的使用率,类似一个 DBaaS 的服务(图2)。

      图2:多套业务系统 TiDB 部署图


      RC2.2 -> GA1.0 -> GA1.1


      从 RC2.2 版本到 GA1.0,游族平台部的生产环境已经有 3 套 TiDB 集群在运行,共计支撑了 6 个 OLTP 业务的稳定运行快一年的时间。 期间 PingCAP 团队提供了非常多的技术支持:集群部署策略、BUG 响应和修复、升级方案协助、迁移工具支持等,厂商和开源社区都非常活跃。

      从 RC2.2 开始,从性能优化到细小的 SQL 兼容性 BUG 修复,每个版本都能看到开发团队对  roadmap 的细致规划和态度。TiDB 也在厂商和社区打磨下,性能和稳定性逐渐提升,兼容性也越来越好。

      现在官方已经发布 GA1.1 的 alpha 版本,重构了 TiDB 的优化器,我们也在第一时间做了详细的测试,目前大部分 OLAP 性能比 GA1.0 要提升 1~2 倍,不得不感慨 TiDB 的演进速度,也期待 1.1 的正式发布。


      计划和期望


      我们与 TiDB 团队的沟通中了解到补充 TiDB-Server 的重 OLAP 需求的 TiSpark 计算层已经比较成熟了,后面计划分析型的需求也会尝试使用 TiSpark 来进行计算。

      同时我们与 TiDB 团队在交流的时候也得知分区表,视图等功能都已经在计划中,后续 TiDB 的数据存储方式将会越来越灵活。

      经过内部的实际使用后,后续已经有数个符合业务场景在评估或计划使用 TiDB 做为 OLTP 存储层的支撑。TiDB 给了大库大表业务的一个全新的选择方向,相信 TiDB 以后能在更多的业务选型和设计方案上给出新的方向和思路。


      ✎  作者:陶政,游族网络平台部 MySQL DBA 负责人。曾任同程旅游系统架构组 DBA,现负责游族网络数据库整体的运维规划和设计。熟悉各类业务的数据库设计、缓存设计、离线数据分析等解决方案。


      延展阅读

      TiDB 助力牛板金互联网金融营销平台

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

      TiDB 在摩拜单车在线数据业务的应用和实践




      长按关注

      新型分布式 NewSQL 数据库

      微信号:pingcap2015



      关注公众号:拾黑(shiheibook)了解更多

      [广告]赞助链接:

      四季很好,只要有你,文娱排行榜:https://www.yaopaiming.com/
      让资讯触达的更精准有趣:https://www.0xu.cn/

      公众号 关注网络尖刀微信公众号
      随时掌握互联网精彩
      赞助链接