共计 2857 个字符，预计需要花费 8 分钟才能阅读完成。
简介：PolarDB 在游戏行业的最佳实际为什么游戏行业喜爱用 PolarDB 游戏行业痛点在我看来, 不同行业对数据库应用有微小的差异. 比方游戏行业没有简单的事务交易场景, 他有一个十分大的 blob 字段用于存储角色的配备信息, 那么大 Blob 字段的更新就会成为数据库的瓶颈, 比方在线教育行业须要有抢课的需要, 因而会有热点行更新的场景, 对热点行如何解决会成为数据库的瓶颈, 比方 SaaS 行业, 每一个客户有一个 Database, 因而会有十分多的 Table, 那么数据库就须要对多表有很好的反对能力. 游戏行业和其余行业对数据库的应用要求是不一样的. 所以在撑持了大量游戏业务之后, 我了解游戏行业在应用自建 MySQL 的时候有 3 个比拟大的痛点对备份复原的需要对写入性能的要求对跨 region 容灾的需要接下来会别离讲述这三个痛点 PolarDB 是如何解决的. 备份复原笔者和大量游戏开发者沟通中, 游戏行业对备份复原的需要是极其强烈的. 比方在电商行业, 是不可能存在将整个数据库实例进行回滚到一天之前的数据, 这样所有的用户的购买交易信息都失落了. 然而, 在游戏行业中, 这种场景的确存在的, 比方在发版的时候, 游戏行业是有可能发版失败, 这个在其余行业呈现概率非常低, 如果发版失败, 那么整个实例就须要回滚到版本之前. 因而每次发版的时候都须要对数据库实例进行备份. 因而当咱们玩游戏的时候, 看到大版本须要停服更新, 那么就有可能是因为后盾须要备份数据等等一系列操作了. 还有一种场景, 当产生因为外挂, 破绽, 参数配置谬误等等场景下, 这种紧急情况游戏就须要回滚到出问题前的版本, 这样就须要对整个实例进行回滚.
官网 MySQL 因为是单机架构, 那么常见的备份办法是通过 Xtrabackup 工具, 将数据备份到本地当前, 如果本地空间不够, 就须要上传到 OSS 等远端存储中. 通常通过 Xtrabackup 备份工具都须要 1h 左右, 如果须要将数据上传到远端那么工夫就更长了.PolarDB 是人造的计存拆散的架构, 那么备份的时候通过底下分布式存储的快照能力, 备份能够不超过 30s, 将备份工夫大大缩短了. 外围思路是采纳 Redirect-on-Write 机制, 每次创立快照并没有真正 Copy 数据, 只有建设快照索引, 当数据块前期有批改 (Write) 时才把历史版本保留给 Snapshot, 而后生成新的数据块, 被原数据援用(Redirect). 另外一种场景是, 在游戏行业中, 有可能某一个玩家的配备被盗号了, 那么玩家就会找游戏的经营人员投诉, 经营人员会找到游戏运维人员, 帮忙查问玩家的历史数据. 笔者之前就遇到某驰名游戏多个玩家被盗号, 而后运维人员常常须要通过 PolarDB 按工夫的还原的能力复原出某多个不同工夫点的实例, 用来查问这个玩家的具体配备信息, 同时因为玩家对盗号的工夫也不精确, 常常有时候须要还原出多个实例才能够. 针对这样的场景, PolarDB 推出了 Flashback Query, 就能够在以后实例查问出任意工夫点的历史数据. 具体原理见文章 Flashback Query
整体而言, PolarDB 建设了一套十分欠缺的备份恢复能力, 从库 => 表 => 行三个维度满足的游戏行业对备份复原的需要.
写入性能游戏行业应用数据库的形式也与其余行业有较大区别, 是一种十分弱 Schema 的应用形式, 其余行业通常对业务常常形象, 建设表构造, 每个字段尽可能小, 不倡议有大字段, 有大字段尽可能进行拆封等等. 然而在游戏行业中, 因为须要满足游戏疾速迭代倒退的需要, 玩家的配备信息结构非常复杂, 因而常见的做法是将玩家配备等级信息保留在一个大的 blob 字段中, 这个 blob 字段通过 proto_buf 或者 json 进行编解码, 每次在取得配备或者降级当前, 就进行整个字段更新, 在游戏开服初期玩家数据长度较短, 而随着游戏版本更新版本, 游戏剧情, 经营流动的增多, 绝对于游戏开服初期的数 KB, blob 字段的长度可能会收缩到数百 KB, 甚至达到 MB 级别, 因而可能只是取得一个配备, 就须要向数据库写入数百 KB 大小的数据, 这样的写放大其实十分不合理. 目前也有像 MongoDB 这样的文档数据库, 让用户写入的时候仅仅更新某个字段, 从而缩小写放大. 然而这样影响了用户的应用习惯, 须要用户在业务逻辑上进行批改, 这是疾速倒退的游戏行业所不能承受的, 所以笔者看到只管有客户因为写入问题转向了 MongoDB, 然而其实不多. PolarDB 针对这样的状况尽可能满足用户的应用习惯, 在数据库内核层面优化数据库的写入能力. 通过 partition redo log, redo log cache, undo log readahead, early lock release, no blob latch 等等能力将写入能力充沛优化. 具体原理能够参考咱们内核月报 和之前的文章 PolarDB-cloudjump 针对游戏场景, 咱们批改了 sysbench 工具, 模拟游戏行业中大 Blob 更新的 workload, 放在 game-sysbench 工具中, 后续咱们还会将更多行业比方 Saas, 电商等等行业的 workload 放在这个工具中. 在 game_blob_update workload 中, 如果玩家的均匀配备信息是 300kb, 咱们比照了 PolarDB VS aurora VS 自建 MySQL 的数据 PolarDB 8.0 绝对有最高的 QPS 1877.44, 峰值 QPS 最高能够到 2000, CPU bound 场景 PolarDB 的性能大略是 Aurora 的 5.7 倍, 是自建 MySQL 本地盘的 3 倍. IO bound 场景 PolarDB 的性能是 Aurora 的 15 倍.CPU bound 场景：DB 并发数据 QPSPolarDB 8.051877.44MySQL 8.0 本地盘 4600.22Aurora 8.0200328.47 IO bound 场景：DB 并发数据 QPSPolarDB 8.02001035.30MySQL 8.0 本地盘 200610Aurora 8.020069.15 跨 region 容灾 目前游戏行业纷纷出海, 蕴含了游戏服和平台服. 用户在自建 MySQL/RDS 的场景中, 用户可能须要在另外一个 region 建设一个新的实例, 而后通过同步工具或者 DTS 进行跨 region 备份. 用户须要解决 region 谬误场景如何进行切换等等. 笔者认为对数据库而言, 稳定性 > 易用性 > 性能. 在这个场景中, 用户如果应用云厂商的话, 应用的是云厂商提供的原子能力, 本人通过组装这些原子能力实现容灾的需要, 而 PolarDB 针对这样场景提出来 PolarDB GlobalDataba 的解决方案, 将跨 region 的容灾放在解决方案中, 提供了一个更加易容的解决方案, 从而用户能够关注本身的业务逻辑, 而不须要解决这些容灾的场景. 在具体跨 region 的同步场景计划中, PolarDB 是通过多通道物理复制能力, 从而保障跨 region 的容灾在 1s 以内. 原文链接：http://click.aliyun.com/m/100… 本文为阿里云原创内容，未经容许不得转载。
