《《真有趣的游戏内存数据库实践》》由会员分享，可在线阅读，更多相关《《真有趣的游戏内存数据库实践》（26页珍藏版）》请在金锄头文库上搜索。
1、真有趣的游戏内存数据库实践报告 面向游戏业务的内存数据库开发 Copyright 2016 SoFunnyCopyright 2016 SoFunny 正式开始之前 Copyright 2016 SoFunny 自我介绍 Copyright 2016 SoFunny 陈明达，花名：达达 来自厦门真有趣信息科技有限公司 C#、PHP、Erlang、Go、AS3 杂而不精，现学现卖，土法造炮 Copyright 2016 SoFunny 今天主要的内容 Copyright 2016 SoFunny 游戏内存数据库方面的实践经验 游戏内存数据库的一些实现细节 供大家参考，希望大家可以少走弯路 Cop
2、yright 2016 SoFunny 为什么讲内存数据库 Copyright 2016 SoFunny 因为它影响产品的方方面面 产品品质：游戏过程要流畅，游戏数据要安全 开发效率：开发要简单高效，不要很容易出BUG 运维效率：运维方案要成熟可靠并且高效 运营效率：要方便数据挖掘 它的演进过程也是架构演进的缩影 Copyright 2016 SoFunnyCopyright 2016 SoFunny 内存数据库的诞生过程 Copyright 2016 SoFunny 第一次实践 Copyright 2016 SoFunny 魔法之城，SLG，2008年 PHP + Memcached + M
3、ySQL 手工编写数据库到缓存的加载代码 手工编写缓存到数据库的落地代码 PHP MySQL Memcached Copyright 2016 SoFunny 第一次实践遇到的问题 Copyright 2016 SoFunny 手工做的事情太多，每一个业务都 是特例，缺乏强约束力的规范，导 致BUG频发 没有事务保护，业务上的BUG直接 导致数据损坏，手工修数据和排查 问题耗费大量精力 Copyright 2016 SoFunny 迷茫阶段 Copyright 2016 SoFunny 怎样才能减少手工和特例化产生的BUG？ 怎么实现事务机制？ 怎么容灾？ 传统数据库还是KV数据库？ 是否有现
4、成方案？ Copyright 2016 SoFunny 理清思路 Copyright 2016 SoFunny 时间和能力有限，做最有把握做到的事 使用MySQL，运维方案成熟可靠，便于数据挖掘 自动映射MySQL表结构，规则简单，容易自动化 在游戏进程内组织数据，运行效率最高，容易实现 Copyright 2016 SoFunny 第二次实践 Copyright 2016 SoFunny 神仙道，RPG，2010年 Erlang + ETS + MySQL 自动映射MySQL数据库结构 有事务机制 有SQL日志 有平滑升级机制 业务逻辑 ETS SQL日志MySQL Erlang Copyr
5、ight 2016 SoFunny 第二次实践遇到的问题 Copyright 2016 SoFunny 按表来组织缓存，数据集太大，游 戏越跑越慢（ID取模分表缓解） SQL文本日志文件不利于数据挖据 Copyright 2016 SoFunny 第三次实践 Copyright 2016 SoFunny 仙侠道，RPG Go + MySQL 按玩家切分数据集 按业务切分数据集 结构化的事务日志 脚本化的审计工具 业务逻辑 Player DB 事务日志MySQL Go Copyright 2016 SoFunny 第三次实践遇到的问题 Copyright 2016 SoFunny 优化太早，引入
6、不必要的复杂度 常驻内存，运营到后期硬件利用率降低 自定义二进制格式的事务日志不利于周边工具开发 Copyright 2016 SoFunny 近期我们在做的 Copyright 2016 SoFunny 支持大服制游戏 冷数据剔除，提升硬件利用率 JSON替代二进制，进一步发挥日志的价值 加入索引机制，允许后期优化，避免过早优化 Copyright 2016 SoFunnyCopyright 2016 SoFunny 内存数据库的实现细节 Copyright 2016 SoFunny 几个关键点 Copyright 2016 SoFunny 部署结构 平滑升级 数据切分 事务机制 Copyr
7、ight 2016 SoFunny 部署结构 Copyright 2016 SoFunny 游戏服和MySQL是多对一关系 游戏启动时全量缓存数据 游戏数据变更异步回写MySQL MySQL做主从同步 在从库上做完整备份+增量备份 运营后台到从库查询数据 1服2服3服 主库 从库 运营 后台 完整 备份 增量 备份 Copyright 2016 SoFunny 平滑升级 Copyright 2016 SoFunny 每次结版前都要手工收集数据库变更是很辛苦的，而 且容易犯错 从开发过程中就严格执行平滑升级过程，跨版本升级 只是重现开发过程 以日期+序号作为命名规则，每次数据库变更都提交一 份P
8、HP脚本到一个固定目录下 用一个PHP脚本去顺序执行目录下的变更脚本，并记 录下当前版本 Copyright 2016 SoFunny 按玩家切分数据 Copyright 2016 SoFunny 游戏业务的特性： 玩家大部分时间都在操作自己数据 每个玩家的数据集并不大 按玩家切分数据会产生两种表： 一对一，每个玩家只有一条数据，比如玩家信息 一对多，每个玩家有多条数据，比如物品 命名规则很重要： 玩家表“player_”开头 一对一的表，用“pid”做主键 一对多的表，用“id”做主键，必须有“pid”字段 Copyright 2016 SoFunny 按业务切分数据 Copyright 2
9、016 SoFunny 全局数据，比如帮派： 帮派成员，帮派公告，所有周边系统都是以帮派为单 位访问数据的，所以按帮派切分数据很合理 玩家数据进一步切分： 装备强化，装备洗练，装备镶嵌，所有装备养成系统 都是以装备为单位访问数据的，所以可以在装备对象 上加上子表数据引用 如果可以建立完善的索引机制，没必要根据业务切分数据 Copyright 2016 SoFunny 事务回滚 Copyright 2016 SoFunny 首先需要顺序记录下事务过程中的非查询操作 事务回滚的时候从最后一笔纪录往前回滚 如果是插入数据，就把新数据删除 如果是修改或删除，就把旧数据替换回去 Copyright 20
10、16 SoFunny 事务回滚示例 Copyright 2016 SoFunny Insert 1 Update 3 Update 2 Delete 1 2 3 Copyright 2016 SoFunny 事务提交 Copyright 2016 SoFunny 我们已经有一份非查询操作记录 按这份记录顺序生成SQL同步到数据库即可 但是必须强调，要以事务为单位： SET autocommit=0; START TRANSACTION; COMMIT; Copyright 2016 SoFunny 事务日志 Copyright 2016 SoFunny 我们已经有一份非查询操作记录 按这份记录顺序写入日志文件即可 前面说到结构化的事务日志： Copyright 2016 SoFunny 事务隔离 Copyright 2016 SoFunny 并发操作数据的时候，如何做好事务隔离？ 最土的办法是不要并发，等价于MySQL的串行级别 串行为什么可行？ 人可感受的延迟大约在100ms左右 平均每次请求处理耗时40us 100ms足够执行2500个请求 利用多核？那就按玩家做事务隔离，但是互动要单独隔离
