华为云gaussdb(for redis)揭秘第24期：游戏一致性bug怎么解-4008云顶国际网站

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

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

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

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

1. 读写分离引发的bug

• 背包道具丢失（mysql做主数据库场景）

bug描述：玩家在游戏地图a购买道具，随后立刻切换地图，进入游戏地图b，结果打开背包竟发现道具丢失。

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

• 关注好友后漏发hi~（redis做主数据库场景）

bug描述：在某个游戏地图中遇到美女玩家，关注对方后，本应自动发送预定义招呼语，对方却迟迟没有收到。

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

2. 如何解决？

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

其实，数据库不止mysql一种，缓存也不止redis一种。

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

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

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

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

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

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

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

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

1. 主从切换引发的bug

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

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

2. 如何解决？

开源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既能为游戏业务保驾护航，又省心省力省钱，何乐而不为！

• 本文作者：

     华为云数据库gaussdb(for redis)团队

• 杭州/西安/深圳简历投递：

     yuwenlong4@huawei.com

• 更多产品信息，欢迎访问官方博客：

     bbs.huaweicloud.com/blogs/248875