腾讯游戏DBA团队的发展自白

BA这个岗位跟仓管员很像，就是天天给别人发点货，别人在你这儿放点货，DBA工做就是把货尽快给送出去或者让人家尽快放进来。固然，还有一份重要的工做，就是让仓库里摆放的货物尽量整齐，这也是仓管员的本职工做，你不能拿到货往仓库里一通乱扔，别人来取货，又让别人等上半个小时。

 

图：腾讯游戏DBA Team Leader Robin

 

内容提纲：

1. 前辈的积累

2. Game Cloud Storage架构

3. Game Cloud Storage组成

4. Game Cloud Storage去哪

5. 驱动力及方向探讨

前辈的积累：三类游戏DB架构解析

图：前辈的积累

 

图： 腾讯互娱的三类游戏

腾讯互娱有三类PC端游戏：1. 平台休闲游戏，好比QQGame斗地主、QQ宠物；2. 高级休闲游戏，由于游戏实时性要求增高，对用户须要就近接入，这类游戏会进行分区处理；3. 大型多人在线游戏MMOG，这类游戏玩法比较复杂，可能包含上万个任务，道具信息，逻辑很复杂，实时性要求更高，对应单用户数据量也会变得更大，新的MMOG游戏或者运营时间长的MMOG单用户数据量会达到几百K。手游这几年自己游戏内容不断的丰富，演进中的游戏分类基本也能够参考原先端游。

图：PLAT／QQGame DB分布

对于平台休闲／QQ游戏的DB，数据集中一个城市存放。由于游戏玩法相对最简单，因此，玩家自身的属性较少，可能就是积分、荣誉、装扮，少许道具的变化，对应数据量也比较小，比较适合集中存放，不一样地域的gamesvr到专线也不会有太大压力。

此类DB特色：

• DB数据集中，基本分布在同城IDC；

• 单用户数据结构简单，数据量少(<1K)；

• 用户量巨大，一般注册用户过亿，后台经过qq号hash或者uin末尾2-3位数字作分布式数据切片处理；

• 单DBServer支持访问人数大于10万。

图：ACG/飞车 DB分布

相对MMOG，ACG／飞车的游戏内容比较简单，以玩家对局为主，但单用户的数量会比PLAT / QQGame要大一点，须要大区方式运营，产品策划对于用户聚合有更多诉求，大区增长相对少，反而单个大区承载人数的上限，会由于时间推移，逐步经过技术升级不断提高。

DB特色：

• 介于PLAT，MMOG之间，单大区支持人数有10万。

图：MMOG/ 三国DB分布

MMOG/ 三国游戏逻辑复杂，用户属性多，玩家升级、打怪、作任务、多人组队做战PK为主。自己一个大区，由于内容过多，复杂的经济系统平衡等，同时承载人数有几万的上限，须要经过不断增长大区，扩张在线人数。实时性要求更高，适合把整个游戏的后台物理设施跟用户做就近接入，这样用户体验会更好一些。

DB特色：

• DB数据分布广，分布在多个IDC；

• 单用户数据结构简单，数据量少(50K-几百K)；

• DBServer物理及逻辑扩展频繁，单个区支持同时游戏人数在2-3万。

图：DB架构简化

通过总结，发现其实架构是蛮简单的，咱们的MySQL就很简单，一个Master，一个Slave，一个LogDB，把三种游戏精练一下，其实就是一个很简单的架构，如上图。

咱们总结了一个经验，由于单用户数据量比较小的话，DB部署的适合集中存在一个城市；若是像一个用户的玩家数据达到几百K的时候，仍是适合总体单区架构包括数据库作就近接入、Set化。

图：DB架构精粹

• 数据部署策略：集中与Set分布，数据集中适合逻辑简单，用户属性较少的游戏；IDC Set分布，适合逻辑复杂，用户属性多游戏.

• 数据切割策略：平行(QQ号或其它用户ID)及垂直（不一样模块属性数据，例如QQGame的道具与装扮信息的切分）

• 成本与质量策略：分级投入，核心状态与日志流水硬件分离，让读写最频繁的状态类信息保持一个较小的规模，为核心状态类数据增长热备投入。流水日志如今由于近几年大数据很时髦，也有传输到hadoop作分析，也至关于有备份了。

• 回写策略：前端cache定时合并回写，自己Mysql设置innodb_flush_log_at_trx_commit=0，提高2-3倍性能。

• 简化策略：对于MMOG将用户属性中数据量较大的任务，道具，仓库信息以二进制方式封装到Blob中。尽量将DB问题简化为或IO或内存或CPU资源不足的问题。

• SNS游戏没有列出来，是由于如今全部游戏几乎都包含了SNS元素，但当社交变为游戏的重点时，由于热点不在集中，首要策略是All In Memory，好比前些年特别流行的QQ农场业务。

Game Cloud Storage 架构

图：Game Cloud Storage架构

Game Cloud Storage主要解决硬件故障处理时间长，版本停机时间长，以及空闲率高这三个问题。mysql前增长了proxy一层作高可用；推出定制的tmysql，秒级在线加字段；以及将多实例管理变得更加方便，便于缩扩容。

自动切换

图：Auto-Switch

Auto-Switch首要的考虑是避免误切换。不切换影响最多回到从前，但误切换可能致使更加复杂的问题，好比切换到一个落后了几天数据的Slave，意味着要总体停机，数据乱了，耗费N个小时来作用户数据回档工做，新的用户数据彻底丢失。

MySQL Proxy定制扩展

• refresh_backends，在proxy管理端口扩展了一个核心的指令refresh backend，经过外围控制，外围检测到master故障，一个指令将proxy指向slave，引导后续gamesvr来的正常访问，经过增长proxy总体访问切割，也避免一致性问题；

• Refresh_user，作user@ip白名单的控制，Proxy自己当它做为MySQL代理的时候，MySQL看到的ip已经都是proxy，加强这一点来延续对于MySQL对来源IP的控制。

• Show_processlist，查看来源链接，在MySQL里看到的都是来自于proxy的链接，这个时候也不方便去定位一些来源连接的问题，因此proxy须要看到能更直接地来自于gameserver等等前端详细信息。

• Refresh_connlog，打开记录链接log，保证整个全部DB的请求，能够追溯来源。

监控逻辑

多点监控

高可用切换主要依赖外围的集中监控，咱们分了几个大的IDC，好比成都、深圳和上海等，咱们会在大的区域本地进行监控，好比成都会有本地的点去对成都全部DB定时监测，深圳也会监测，并会对比这二者，若是二者有一者存活的话，那就不作处理，若是二者都有问题的话，就会考虑开始把它进行切换，这是多点监控。

SQL探测，SSH登录

先经过replace sql探测DB端口，成功则认为ok，不然经过ssh登录，及touch文件探测。为何要以SHH做为条件？由于MySQL负载高的时候，SQL探测遇到Hang住异常，但愿ssh进一步去探测物理机器存活，若是ssh登录不了或ssh后touch遇到只读，咱们基本判定一台机器故障了，这个时候，会推送到下一步第二轮探测队列，以便整机切换。

DoubleCheck

前述第一轮探测，检验完成后，进行Double Check探测，确认问题后，同时检查一下Slave这些跟进的状态是否是对的，最近的数据Check Sum校验是否是一致的，是否有主备Time delay。

最后，知足切换的前置条件包括如下几方面：

1. show slave status, 获取binlog获取及本地relay执行对比；

2. Checksum(7天内)不一致块数量，小于5个块可进行切换；

3. Slave落后Master时间, 小于10秒为可进行切换；

4. Master已故障时间，小于10分钟可进行切换；

压缩

图：压缩

关于Blob咱们遇到的一个问题是，当时比较火的《地下城与勇士》，上线刚半年单机数据量达到200多G。当时跑的硬件只是只有8G内存，6块SAS磁盘一台机器，一个周末由于夜间备份时间过长，到了白天还没结束，业务连续出了2个突发。后来，咱们跟韩国的开发商商定了压缩这个投入最小的方案，经过一次停机，总体数据作一次压缩，整个数据库数据从200多G变成了4G。

同时，后续数据修改，从数据库拿到数据后进行gameserver进行解压，在gameserver写入数据库前就进行压缩。根据在Slave上对OSS金钱统计相关数据进行的经营统计分析，发现原来要执行400分钟的，基本上下降到5分钟。很简单的压缩仍是蛮有用的，控制核心数据量，对后续这个游戏长续运营产生了极大的帮助，这个游戏早期被外界叫作掉线城与虚弱勇士，我想咱们作的很简单的事情，对于帮助游戏丢掉这个恶名仍是有一点帮助的。

图：压缩演进历程

压缩演进历程：

2008年，遇到一款MMOG游戏，单一用户量很大，当时想到最简单的办法就是压缩。开发方，在select时候，用mysql自身的uncompress作解压，update直接sql里边用mysql函数compress写回，用MySQL的技术就搞定了。

2011年，逐步会有一些内部的ORM DB公共组件能够作一些透明开关，经过中间件层去压缩数据。

2013年，前面几种办法都不是DBA能彻底cover的，总须要开发更新中间件，或者改写sql，或者更新gameserver逻辑，咱们想了一招，就是把Mysql内彻底解决这个问题，彻底对开发透明，只要给字段经过alter增长Compress的属性，在MySQL底层直接就把大字段压缩给作了。这个效率，咱们测试中发现远好于自己innodb page压缩。

监控

• 2007年前，监控是比较零散的。

• 2007年刚入职，接到的第一个稍大的任务就是给DB写监控，咱们都把监控放在数据库机器本地，还有一些Hang判断，ErrorLog检测，还有status咱们收集了232个。

• 2009年，由于有时候某个指标异常的时候，难以获得问题相关因素现场，因此咱们针对slowquery量及io利用率超过必定阀值去作了一些现场保留工做，好比show processlist，ps aux，top等，并保存在监控日志里边。同时，也作了checksum的办法，OS层指标增长一些咱们急需的但公司网管系统并未涉及的，好比每一个分区的ioutil等。

• 2012年，为了配合作GCS高可用，作一些时间同步的检测；为了能更方便地去对比一些DB的性能，聚合性能指标在一块儿，作了特别方便的性能对比工具。

Game Cloud Storage去哪

图：Game Cloud Storage去哪

思考GCS去哪，自己也是在想源码定制这条路该往哪里走？若是你们对开源软件比较有兴趣的话，能够参考咱们走过的路，能够先尝试简单功能的优化，而后考虑扩展至性，再考虑性能，由于性能优化的挑战，涉及到mysql底层更复杂的锁调优等机制优化，我一直以为仍是蛮大的。最近一两年，在线加字段这个痛点解决折后，咱们一直但愿能MySQL在保持mysql协议基本不变的前提下，能像nosql相似MongoDB扩展性那么好，在这方面作了一些探索。

咱们选用了Spider，一个分布式的MySQL底层存储引擎来解决这个问题，前一两年开始研究这个Spider，到如今已有超过10个业务上用了起来。Spider官方，在最近一两年也不断完善，合并到MariaDB 10的正式版本里面。你们若是对数据库分布式有需求，同时不但愿开发太多修改，能够考虑MariaDB 10的版本。

图：运维的驱动力

最近业界有不少运维发展方向的讨论，我自身也在思考运维的核心驱动力究竟是什么。若是我去回顾过去的一些历程，我本身考虑运维核心的驱动力仍是最简单两个字——问题。可能来自业务发展的快速增大数据量，请求并发增大，或者开发使用整个存储的容易程度，或者平时运维的一些问题，咱们不但愿本身那么多通宵处理故障，那么多步骤那么辛苦缩扩容。无论在哪家公司，只要我还可以不断解决问题，可能这个公司我还能呆得下去；若是没有问题须要解决，或者是每天时间都花在其余地方了，可能也就没什么意思了。

图：内部平台产品方向

咱们作这些内部平台，按目前的人力投入，最重要的仍是聚焦支撑内部精品大业务的发展。但站在内外部技术平台竞争加重的角度，天天都能看到各类各样渠道吹牛的信息(就像我今天这样)，都说本身很厉害，很强，咱们的下一步该怎么走，怎么证实本身的价值，得到应有的承认，这是个很关键的问题。

听了不少业界大拿的建议，好比叶金荣同窗，平静的思考以后，咱们后续计划或者是策略大概是：首要的，仍然会站在“巨人的肩膀上”，更好的使用及支持整个社区开放协议存储方案，经过更为深刻研究积累，能提供基本闭环的服务支撑能力；第二步，关于怎么证实团队价值，从前几年的“定制”方向转变到“回到社区”方向，在那个更加广袤的空间去追求些许的承认。

更新这个ppt以前，翻出来多年前内部分享的一页ppt，“关于DB的美好想象”，其中第一点由于牵扯业务过于多样化逻辑数据设计，仍是没作到，第二点作到一点点。