【IT168评论】游戏云存储GCS是互娱运营部沉淀多年的贴合游戏生命周期的数据存储及“一站式”管理平台, 它提供了数据缓存层及持久化层的技术解决方案,帮助业务快速接入的同时降低存储成本,减少硬件故障及常规DB维护导致的停机时间,助力公司游戏业务长期发展。
在PC端游戏时代,GCS主要解决DB管理效率和成本问题,我们从mysql源码层面做了很多定制化的功能特性,以适应游戏快速迭代的需要:譬如TMySQL快速加字段特性实现100GB级甚至TB级表的秒级增加新字段;innodb表大字段透明压缩特性实现减少innodb内存和磁盘空间 的占用,以CPU换MEM及IO,进而提升mysql整体吞吐能力。
在移动游戏时代,特别是腾讯手游精品2.0战略的推进,对DB运维管理提出了更高的挑战:如 何实现在不停机情况下,进行用户体验无感知的存储层扩容、缩容,用户数据在线搬迁?互娱DBA团队在2013年底开始探索分布式存储领域,目前GCS包含了TRedis高性能缓存及持久化和TSpider分布式数据库两个产品线。研发也不再需要关注用户数据的切片路由逻辑,至今我们在线上做过了20 次不停机的扩容缩容的调度,存储层的扩容、缩容过程实现了对研发、运维、玩家的基本透明。
GCS-TRedis高性能缓存及持久化
随着手游市场这两年爆发,腾讯游戏尤其是代理业务较多的使用Redis作为数据Cache层。移动时代,游戏上线,贵在神速。Redis本身性能已经足够好,但是在海量用户场景下,其单线程的性能还是难以支持,在容量快速增长的情况下,管理和扩容也面临极大的挑战。因此,我们决定基于Redis定制TRedis,以满足快速上线和快速扩缩容的需要,并兼顾成本和效率。
单个Redis管理内存数量有限,为了提供给业务大量数据存储及访问的支持,我们定制了基于Twemproxy的TRedis集群方案,让业务可以不用关心Redis的存储及容量上的扩展能力,专注 于业务逻辑。TRedis集群方案的源码定制改造涉及Redis及Twemproxy,改造后的集群方案实现了Redis故障切换(基于GCS的DBHA)、在线迁移及在线扩缩容,业务访问基本无感知, 连接不中断。
此外,手游生命周期相对较短,上线后头几个月快速爆发,稳定期后活跃玩家比例逐步下降, 对应到Cache层就是缓存的内容没变少,但访问量会减少很多。此时,如果数据还全在内存里边,在成本上来讲并不划算。因此我们设计了TRedis集群的冷热分离方案,使用rocksdb作为落盘存储,让内存只保留少量热点的数据,提升了数据安全性的同时可以让Redis管理的数据远超过内存的容量。目前现网单集群存储数据超过10T,访问性能稳定。
GCS-TSpider分布式关系型数据库
腾讯互娱运营着数百款游戏,包括端游、页游和手游,其中大部分使用MySQL作为存储。随着游戏玩法的轻量化,尤其是手游的爆发,传统的MySQL Master-Slave(简称MySQL M-S架 构)存储方式逐步暴露出了如下问题:
1 分区分服的游戏,不同区服玩家活跃度不一致,单服对应后端MySQL M-S架构的部署 策略在资源调度上不够灵活,容易造成资源压力不够均摊,形成浪费;
2 全区全服的游戏,研发须根据DB的存储能力和业务特性进行分库分表,存储层分表和 业务逻辑耦合太强;
3 无有效的在线扩缩容机制,存储层扩容、缩容需协调业务停机后再进行操作;
而TSpider是突破了MySQL的单机性能及容量瓶颈的MySQL分布式解决方案,弹性可扩展。TSpider是基于开源的Spider3.1版本进行源码定制的,并建设了完整的配套管理系统,其主要特点包括:
1 透明分库分表和在线扩缩容能力。
这是TSpider首先需要支持的功能,也是解决以上痛点的关键。得益于此,开发者可以 仅专注于业务逻辑的开发及运营,无需编写数据分片逻辑,在海量用户并发情况下,也 无须关心DB存储层的负载压力,TSpider的管理系统会根据负载压力从而进行在线扩缩 容调度。
举个例子来说,某手游上线前,其iOS-QQ渠道的用户数据,我们上架的TSpider集群一般仅包含2组PCIe-SSD作为后端存储机器,随着该游戏快速增长,我们可以在该游戏不停机的情况下,将TSpider集群后端存储机器增加到4组或8组PCIe-SSD,而随着游戏的衰退,我们又可以随时将集群机器减少到2组,这些扩与缩的操作,均不需要研发或运 维的参与,并对玩家的游戏体验无影响。
2 兼容MySQL协议,支持MySQL 99%以上用法。
腾讯游戏对接的开发商众多,在接入腾讯平台前很多已经有现成的开发框架和代码。因 此,在分布式技术方案选型前,协议兼容性是非常关键的一个指标。因为让开发商大量修改代码是一件比较困难的事情,也不符合手游生命周期中快速上线的特点。事实上, 接入TSpider的游戏业务确实使用了比较多“奇怪”的用法,包括表连接、子查询、多表更新等,就是基本上将TSpider当成了一个普通的单机MySQL来使用了。
在兼容协议的同时,我们也做了大量的性能优化,如执行智能下推及并行化查询,在某 些复杂查询场景下没有命中shard-key,则效率比较低,需要遍历所有的后端存储节点,在打开并行化功能情况下,经过游戏的实践验证,在此场景可提升6-8倍的查询效率。
3 高可用
TSpider后端存储节点采用一主一备架构,我们会监控Slave跟进情况及数据一致性。当Master发生机器故障时,可在分钟级完成故障切换,切换过程对应用透明,并且应用无 需重连。
4 老业务数据支持在线接入
除了新业务,老业务也可以享受TSpider带来的收益,MySQL M-S架构迁移到TSpider环境中支持数据在线迁移,但需要短暂的停机时间进行业务访问的切换。
以上GCS-TRedis、GCS-TSpider的实现原理和技术细节将在DTCC 2016大会的<专场2: NoSQL技术实践>和<专场23:数据库技术前瞻>两个专场中,由腾讯互娱高级DBA康中良和 陈福荣两位同学给大家一一进行阐述,敬请关注。
