---
title: TiDB 在游族网络平台部的深度应用
author: ['陶政']
date: 2018-02-08
summary: 经过内部的实际使用后，后续已经有数个符合业务场景在评估或计划使用 TiDB 作为 OLTP 存储层的支撑。
tags: ['游戏']
category: case
url: /case/user-case-youzu/
weight: 2
logo: /images/blog-cn/customers/youzu-logo.png
customer: 游族
customerCategory: 游戏
---
## 公司介绍
游族网络股份有限公司（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 是平凯星辰受 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 业务的稳定运行快一年的时间。 期间平凯星辰团队提供了非常多的技术支持：集群部署策略、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，现负责游族网络数据库整体的运维规划和设计。熟悉各类业务的数据库设计、缓存设计、离线数据分析等解决方案。