技术分享:游戏公司该如何使用好Redis?

来自 知乎 2019-09-17
专栏

[ 转载自 知乎 ]

技术分享:游戏公司该如何使用好Redis?

本文首发于知乎,作者水风。原文链接:https://zhuanlan.zhihu.com/p/81639208

本文介绍一下我在多个游戏项目中,对Redis使用的经验。Redis是个好东西,可以用在不同的业务场景。

0 Redis是什么

Redis最大的特点是所有的数据都存放在内存里,它常用于数据库、cache和消息队列等场景。

1 Redis特性

读写性能高

首先,redis数据都在内存里,其次,整体来看可以把redis看成一个大hashmap,所以基于key索引数据都可以在O(1)时间复杂度内完成,所以一个Redis节点(Redis进程)的QPS可以达到10w,特别适合作为传统数据库(mongo/mysql)的补充提升读写效率。

单线程

所有的读写请求都是单线程按照顺序执行的,每个请求都是原子的,不会被打断。

分布式

Redis支持分布式集群,比如阿里云会在集群的多个节点前面放一个负载均衡,就可以像访问单节点一样访问redis集群。

如下图所示,是我们在阿里云的一个16节点redis集群。

技术1.jpg

阿里云的redis集群

由于阿里云提供的redis集群节点数量总是有上限的(其实可以做到无上限),因此为了获得更好和更灵活的水平扩展能力,我们游戏在业务层又增加了一层分布式功能。在操作redis的同时,可以传入一个参数作为index通过hash映射到某一个redis集群上。

持久化

因为支持持久化,若同时开启RDB和AOF持久化选项,可以作为持久化数据库保存数据,重启redis数据不会丢失。

阿里云同时开启了RDB和AOF(存疑)。

少量数据的持久化存储可以使用redis,但是大量数据不可以。因为redis会把数据全部放到内存里,所以对于大量数量,内存成本太高。

比如好友关系这类关系信息属于多个玩家之间的信息,保存在玩家身上也不合适。而且这类信息使用比较频繁并且数据量不大,就可以持久化存储在redis中。

其他高级特性

Redis还有一些高级特性:

  • 事务:watch关键词。

  • 多命令:可以将多个命令同时发给某个redis节点,降低网络通信时间。

  • lua脚本:通过lua脚本,可以将一些redis操作包装成原子操作。

  • 发布/订阅:可以用于消息分发。

  • stream:redis抄kafka做的消息队列,4.0的功能...

2 Redis数据结构

redis整体来看存储的是一个很大的hashmap,其中key是一个字符串,value可以有多种数据结构。

value支持String、Hash、List、Set、SortedSet五种数据存储结构,可以实现不同的业务需求:·

  • String:存储简单的int\string

  • List:列表/队列,也可以作为消息队列使用。

  • Hash:一个key/value的键值对,这里的value只支持简单的类型(int\string)

  • Set:元素不会重复的集合。

  • SortedSet:有序集合,元素不会重复,同时元素会有一个score值,这个集合会根据score进行实时排序。常用的需求是排行榜。

大家使用redis时,使用方式的就是通过接口操作这些数据结构,所以建议大家看一下redis的基本操作 http://doc.redisfans.com/

3 Redis在游戏业务中的常见应用

一般来说,游戏会使用mongo或者mysql存储各类游戏信息,但这种数据库将数据存在硬盘里,读些速度比较慢。而redis将数据放在内存里,读写速度可以提高一个数量级。因此,可以配合mongo/mysql使用。

Cache

redis最常见的功能就是作为cache使用,游戏中很多逻辑如果去读mongodb,会有性能问题,所以使用redis作为缓存,降低对mongodb的读写。

此外,还有些需求可以使用Reids作为缓存,比如玩家个人简要信息。当我们查看其他玩家信息时,往往不需要全量信息,只需要部分信息(在线状态、等级、部分信息等),而这些信息要是去读取mongo会产生非常大的压力。因此,可以将指定的玩家信息放在Redis里,提高访问效率。

业务状态/数据存储

因为redis本身就支持持久化存储,所以redis在一定程度上可以替代mongo。

那么,什么数据适合存在mongo,什么数据适合存在redis呢?

对于一个数据应该放在redis还是mongo中存储,主要考虑两个方面:1.数据量。2.数据访问频率。

若数据量较小,比如记录哪些区域聊天频道需要关闭,这种信息一般使用redis记录即可。

若数据量较大但不是特别大,但数据访问频率比较高,比如玩家好友关系信息,那么一般也可以使用redis存储。

若数据量特别大,比如玩家/家族全量信息,一般使用mongo进行存储。

无状态服务开发支持

一般游戏服务器都是有状态的,也就是说内存里是有数据的。而无状态的服务的意思是内存里不保存数据(有可能在执行逻辑过程中有些临时变量)。

关于有状态无状态的描述,可以参考https://blog.csdn.net/yinxiangbing/article/details/53353940

内存里不保存状态,那么状态存在哪里呢?redis就可以保存状态的地方。

举个例子,我们要开发一个组队服务,那么就需要一个组队匹配池,我们可以将匹配池保存在服务内存中(有状态),当然也可以将这个匹配池信息保存在redis中(无状态)。

无状态(信息保存在redis)的好处如下:

  • 若我们将匹配池保存在内存中,那么这个业务性能的瓶颈最大是一个进程,哪怕使用多线程,那么天花板就是一台服务器。而若使用redis存储数据,我们就可以写多个进程来执行业务逻辑,性能瓶颈就不再存在,理论上就不会出现性能瓶颈。

  • 若数据放在内存里,机器和进程是有概率crash,数据也就丢失了。而redis可以使用主从切换,数据不会丢失,容错能力强。

坏处:成本高、编程麻烦。

我在网易曾经写过一套微服务框架,其实就是用的无状态的原理写游戏逻辑。为服务框架非常适合写非战斗逻辑,对大DAU游戏可以提供非常强力的支持。后面有机会可以写文章介绍下思想。

多进程/线程/线程之间的共享数据存储

有些不同的进程需要共享数据,可以使用redis存储这些共享数据。

比如有个游戏需求是全服玩家给最喜爱的角色投票,所有玩家在不同的进程都需要操作这些信息,就可以将这些信息保存在redis中进行共享。

临时数据管理

redis的数据支持生命周期,所以若一些数据是临时的(比如活动数据,活动结束后就不需要了),就可以将数据存在redis中,并且给一个生存时间(通过EXPIRE命令),当时间超过生存时间就会自动删除。

排行榜

Redis的SortedSet非常适合做排行榜功能,在几年前Redis不火时,如何写一个好用的游戏排行榜还是一个课题,近两年就再也没有人提这个事情了,没啥好说的,用redis就好了。

分布式锁

不同进程中的逻辑若希望使用锁写同步逻辑,可以基于redis的SETNX命令实现。 

参考: https://juejin.im/post/5b737b9b518825613d3894f4

消息队列

游戏中不同的进程之间的通信,也可以使用redis作为消息队列来通信。

比如给游戏服务器发一个控制命令,就可以将命令存在redis的list中,游戏服务器实时检查redis是否有命令,有则pop出来执行。

Redis能否作为消息队列使用是一个常常被争论的话题,因为有更专业的消息队列,比如Kfaka。我曾经服务的一个百万级DAU项目曾经使用Redis作为简单功能的消息队列(只有消息传输功能),由此可见Redis作为消息队列在生产环境使用问题并不大。

4 Redis使用注意事项

避免出现大key,通过小key进行分散

大key表示一个key对应的value非常大。比如,我们希望记录每个玩家的当前在线状态,若我们创建了一个key为online_status的hashmap,这个hashmap的格式为uid:status。那么,所有的玩家的在线信息都保存在这个key中。这种情况,就会导致online_status这个key对应的value极大。

redis虽然没有限制一个key对应的value的大小(应该没有),但是不建议使用大key。正常的使用方式是将每个玩家的信息作为一个字符串直接保存在redis中,比如key为online_status_{uid},value为是否在线。

原因是redis基于key来做的分布式,若创建了一个大key,就会导致分布式功能失效,所有的请求都会到达同一个redis节点,导致这个节点卡顿,其他节点空闲。

Bigkey没办法检测

避免hotkey

hotkey的含义是某个key读写频率很高,特别繁忙。

需要避免这种情况的原因和大key类似,会导致分布式失效,某些节点卡顿。

hotkey在Redis4.0版本有检测方式

给key增加前缀

大家需要创建一个新的key前,需要保证key在所有业务中是独一无二的,因此key最好有namespace的概念。

我们可以通过给key前面加一个前缀,来避免key重复的情况。比如我们需要记录玩家在线信息,key设计为player:online_status,而当我们又需要记录家族的活跃状态,key设计为family:online_status

(举个栗子,家族活跃状态应该叫active_status更合适...)

5 redis冷热数据分离

上文说过,Redis不适合做大数据的持久化存储,因为Redis会将所有数据都放在内存里,相比硬盘存储,成本极高(作为一个成功游戏项目都觉得贵)。

其实有一种折中方案,就是将数据分为冷数据(表示长时间不活跃的数据,比如流失玩家数据)和热数据(活跃数据,比如经常登录玩家信息),将冷数据放在硬盘里,将热数据放在内存里。然后当长期不活跃玩家回流后,就将这个玩家的数据从冷数据转为热数据,从硬盘中转到内存中,玩家长期不在线则把他的数据从热数据转为冷数据,从内存中转到硬盘中。这样的话,内存成本就会降低很多。

之前项目同事曾经尝试实现过这个功能。就是写一个proxy,后面挂一个redis和mongo,proxy实现一套redis协议解析,并且实现冷热数据切换和管理。冷数据存在mongo,当访问冷数据时将数据加载到redis中转为热数据,热数据超过一个ttl后,又变为冷数据存到mongo中。

这个有一些问题,比如redis数据和mongo数据格式如何对应等,如何保证数据一致性和高可用性等。此外,对redis的使用API各种限制也比较多。

腾讯云有一个类似的产品TcaplusDB, 但是不支持Redis命令,据说腾讯游戏内部用的都是这个东西(腾讯的同学可以说说)。腾讯还有一个类似的开源项目DCache,估计就是TcaplusDB的开源产品。

阿里云已经有Redis冷热数据分离的beta版本,等成熟了,甚至可以一定程度上取代mongodb。我认为这个项目用在游戏行业非常合适,关注已久。

https://promotion.aliyun.com/ntms/act/hybridstore.html

附:《忍者必须死3》团队招人

我们忍3团队目前还是一个中小团队,但是游戏玩家数量大,游戏质量高。项目里需要做的事情非常多,公司在紧锣密鼓的招人。

所以,招人,客户端、服务端都招,高级或资深都有需求。

我们内部是全栈开发模式,但只要求你有一定的客户端或服务端经验。只要人靠谱,技术栈啥的都问题不大。

公司在杭州滨江,团队氛围很好,具有竞争力(不输大厂)的薪资待遇。

另外,策划、QA、美术、海外发行等岗位都在招,有需要我可以帮忙转简历。

其他信息,私信我或加我微信详聊:shinepengwei

文章评论
游戏葡萄订阅号