游戏一致性BUG怎么解？

GaussDB数据库 2022-08-04

397

关于游戏与一致性

最近在跟一些游戏客户交流，聊到了容易让人“踩坑”的数据一致性问题，常见BUG有“背包道具丢失”、“一个玩家同时加入两个公会”等等。这类问题往往藏得比较深，等到游戏上线后期才发现，会比较难解决。

其实，只要前期做好数据库选型和架构设计，一致性问题是可以避免的。本文将聚焦两大主要场景，对数据一致性问题进行详细剖析。

场景一：读写分离引起的数据不一致问题

在游戏行业，MySQL很多时候都是首选的“主数据库”。然而游戏业务也有很多高并发场景，当上千RPS的MySQL不够用时，为了提升吞吐，就可能会做读写分离、分库分表。

但如果需要更高吞吐能力，MySQL可能会无法满足，这时可以引入Redis，利用NoSQL的强扩展性，承载上万，甚至是数十万RPS。同样的，Redis也可以做读写分离。

读写分离引发的BUG

背包道具丢失（MySQL做主数据库场景）
BUG描述：玩家在游戏地图A购买道具，随后立刻切换地图，进入游戏地图B，结果打开背包竟发现道具丢失。

根因分析：前一个地图的购买行为写入主节点，而新地图中打开背包时查询了从节点。由于主从同步有延时，导致没查到最新数据。

关注好友后漏发Hi~（Redis做主数据库场景）
BUG描述：在某个游戏地图中遇到美女玩家，关注对方后，本应自动发送预定义招呼语，对方却迟迟没有收到。

根因分析：好友链这种业务很适合用Redis做主数据库（提供灵活的hash/set/zset）。但是社区版Redis天然弱一致，原理同上，由于脏读发生，读写分离必踩坑。

如何解决

做读写分离的初衷，其实还是对算力水平扩展有诉求，同时也是不想让那些“Slave”们闲置浪费（毕竟算力成本也是钱呐）。

其实，数据库不止MySQL一种，缓存也不止Redis一种。

华为云GaussDB(for Redis)作为企业级定位的KV数据库，已经在很多业务场景被用作 “主数据库”了，单实例存储TB级数据是家常便饭。

GaussDB(for Redis)可以根除读写分离的一致性问题，原因如下：

1）支持36个节点，全都可读可写（全员Master，算力别浪费）

2）数据强一致（无需主从分离，并发访问任一节点都无脏读）

3）单实例承载数百万QPS（高吞吐需求从来不是事）

很显然，高斯Redis完全可以满足“既要、又要”的业务诉求，让游戏远离读写分离之“坑”。

【有人可能会说，对不起，我是土豪，Slave就只用于高可用，我的业务不读它，这样总不会踩坑了吧？其实，隐患还是存在的！】

场景二：主从切换引起的数据不一致问题

请时刻注意，你使用的数据库，不论是MySQL还是Redis，他们都是高可用的。而高可用意味着，当主节点故障时，它们会发生主从切换。

主从切换引发的BUG

BUG描述：暑假做活动，全服玩家参与抢购100件稀有装备（官方公告：每件都是全服仅有）。后来在公会PK时，持有“屠龙刀”的玩家A遇到了持有“屠龙刀”的玩家B……发生了“撞刀”。

根因分析：活动期间，业务使用了一套Redis主从做抢购，创建一个Redis队列存稀有装备。活动期间请求量高，Redis发生了主从切换。于是BUG就这样发生了：本来队列已经pop掉了“屠龙刀”，但是由于主从同步延迟，从节点顶上来后，其中队列内的“屠龙刀”此时还没有被pop掉！活动继续，于是随后两个玩家同时拥有了“屠龙刀”。

如何解决

开源Redis主从切换导致的此类BUG其实很常见，业务以为访问的数据是稳定的，但其实社区版Redis随时可能“突变”（主从切换）导致业务读到旧数据。

解决办法还是一样——做正确的数据库选型，使用华为云GaussDB(for Redis)。

为什么说GaussDB(for Redis)没有这类问题：

1）数据强一致存储，故障场景业务不会发生脏读

2）故障秒级恢复（社区版Redis启动慢，需加载全量数据，故障恢复慢）

3）存算分离架构，容忍N-1分片故障（社区版Redis只要故障1对分片，业务无法恢复）

使用高斯Redis，完全不用担心脏读发生。

总结

其实在很多业务场景，如果不希望出现脏读导致业务BUG，那么华为云的高斯Redis的确是最佳数据库选型。另外，高斯Redis自带了冷热数据交换能力，本身也是一个兼顾了性能与成本的降本方案，像是游戏公司常用的protobuf序列化数据，高斯Redis能实现500G到160G的数据压缩（案例数据），轻松节省70%存储空间。

高斯Redis既能为游戏业务保驾护航，又省心省力省钱，何乐而不为！

附录