酷应用

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）。