华为云GaussDB(for Redis)揭秘:游戏一致性BUG怎么解?

华为云GaussDB(for Redis)揭秘:游戏一致性BUG怎么解?

2022年08月30日 16:27 ·  阅读 1 编辑

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

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

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

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

BUG描述:玩家在游戏地图A购买道具,随后立刻切换地图,进入游戏地图B,结果打开背包竟然发现道具丢失。

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

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

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

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

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

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

华为云GaussDB(for Redis)揭秘:游戏一致性BUG怎么解?_第1张图片

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

1)支持36个节点,全都可读可写(全员Master,算力别浪费)

2)数据强一致(无需主从分离,并发访问任一节点都无脏读)

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

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

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

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

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

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

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

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

华为云GaussDB(for Redis)揭秘:游戏一致性BUG怎么解?_第2张图片

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

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

2)故障秒级恢复(社区版Redis启动慢,需加载全量数据,故障恢复慢)

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

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

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

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

828-B2B企业节火热进行中!轻松应对高并发访问,为企业创造更多价值。

你可能感兴趣的:(数据库,java,redis)