网站地图    收藏   

主页 > canvas引擎 > 服务端游戏 >

Redis在游戏开发中的应用[转]

来源:未知    时间:2021-05-29 16:53 作者:xxadmin 阅读:

[导读] Redis是一个新兴的NoSql数据缓存组件,与memcache类似,但是功能却比memcache多一些。首先,redis和memcache都是基于内存的,所以读取和写入速度都非常快。但是memcache只支持简单的key-value数...

Redis是一个新兴的NoSql数据缓存组件,与memcache类似,但是功能却比memcache多一些。首先,redis和memcache都是基于内存的,所以读取和写入速度都非常快。但是memcache只支持简单的key-value数据的存储方式,而Redis对key-value ,hash,list,set,SortSet等数据结构有很好的支持。下面就Redis在游戏的开发应用中做一些简单的介绍。

一,数据的缓存
    在这一点上,redis和memcache是一样的。都是把数据提前放入到内存中。当逻辑处理中需要用到数据时,先从内存中读取,相同的,写的时候也先向内存中写入,然后再操作数据库,以增加数据处理的速度。不同的是,redis带有把数据写入到硬盘的功能,具体的写入策略可以在redis的配置文件中配置。这样当主机突然出现故障时,比如断电,重启机器不会造成数据的丢失。这个在游戏的应用中特别重要。一般在游戏开发中,数据的处理会采用:缓存 + 持久化队列 + 数据库(MySQL)的架构。执行的流程是先把数据写入到缓存,然后把需要持久化的数据放入到持久化队列中,启动一个守护线程,从持久化队列中不断的取出数据,并存入或更新到数据库。如果使用memcache这样没有写入到硬盘功能的缓存组件,出现故障时,持久人队列中如果还有没有处理完的数据,那么就会造成数据的丢失,引用玩家的数据出现短暂的回档。当然这些也可以自己开发一些功能去防止,但是增加了开发成本。
二,不丢失数据的持久化队列的实现
    上面说过Redis具有把数据写入到硬盘的功能,而且支持多种数据结构。那么就可以利用Redis的list实现持久化队列,而且当机器出现故障时,不会出现队列中数据丢失的情况,重启之后,数据会自动加载到redis的list之中。
具体实现方法:

    (1)在Redis中构造一个list存储
    (2)一个线程使用Redis的lpush方法,向list的左边加入数据
    (3)另外一个线程使用Redis的rpop方法,从list取出数据进行处理,并且从list中删除了取出的数据。这样就实现了一个简单的生产者--消费者模式的队列。
三,对并发操作的控制

        一般来说,我们操作一个数据的流程是这样的,取出--处理---存储,这样在单线程中操作是没有任务问题的,但是在多线程环境中就不适用了,我们必须考虑数据同步的问题,保证数据操作的原子性。如果在游戏中,对玩家战队的属性进行更新,一般在数据库中都会保存一个TeamInfo表,里面有玩家相应的属性,比如名字,等级,金币,钻石等等。在memcache中保存一个TeamInfo对象,这时玩家获得金币,我们就需要取出玩家所有的属性,然后set金币,完成后再存储整个对象。这个时候就得考虑数据的同步了,如果在操作的时候,另外一个线程B修改了钻石,并完成了存储,而这个时候我把金币修改完成之后,再存储,这时,就出现了数据混乱的结果。考虑数据同步无非也是加锁或乐观同步。不但增加了代码量,还增加了维护的难度。而在Redis中,它支持对hash数据结构的操作。我们可以把玩家的对象按每个字段存储到redis的hash中。结构如下图:
当我需要更新金币时,比如增加或减少,我可以使用Redis自带的原子操作方法:hincrby(String key,String field,int value)进行操作,value是正为加,是负为减,这样就简化和避免了一些并发操作,而且这个操做还减少了对数据的操作步骤,因为没有取出,再操作的过程了,只有一次写入。而且在游戏中很少一次更新非常多的字段,如果有这样的情况,下面的方法可以解决

三,对事务的支持
        redis提供了一个事务操作的机制,MULTI 命令用于开启一个事务,它总是返回 OK 。
MULTI 执行之后, 客户端可以继续向服务器发送任意多条命令, 这些命令不会立即被执行, 而是被放到一个队列中, 当 EXEC 命令被调用时, 所有队列中的命令才会被执行。
另一方面, 通过调用 DISCARD , 客户端可以清空事务队列, 并放弃执行事务。
以下是一个事务例子, 它原子地增加了 foo 和 bar 两个键的值:

1
2
3
4
5
6
7
8
9
> MULTI
OK
> INCR foo
QUEUED
> INCR bar
QUEUED
> EXEC
1) (integer) 1
2) (integer) 1


EXEC 命令的回复是一个数组, 数组中的每个元素都是执行事务中的命令所产生的回复。 其中, 回复元素的先后顺序和命令发送的先后顺序一致。当客户端处于事务状态时, 所有传入的命令都会返回一个内容为 QUEUED 的状态回复(status reply), 这些被入队的命令将在 EXEC命令被调用时执行。从 Redis 2.6.5 开始,服务器会对命令入队失败的情况进行记录,并在客户端调用 EXEC 命令时,拒绝执行并自动放弃这个事务。
四,提供外部的CAS行为,实现乐观锁机制
在游戏开发中,有时候需要我们自己在外部实现乐观锁机制,WATCH 命令可以为 Redis 事务提供 check-and-set (CAS)行为,被 WATCH 的键会被监视,并会发觉这些键是否被改动过了。 如果有至少一个被监视的键在 EXEC 执行之前被修改了, 那么整个事务都会被取消, EXEC 返回空多条批量回复(null multi-bulk reply)来表示事务已经失败。
举个例子, 假设我们需要原子性地为某个值进行增 1 操作(假设 INCR 不存在)。
首先我们可能会这样做:

1
2
3
val = GET mykey
val = val + 1
SET mykey $val


上面的这个实现在只有一个客户端的时候可以执行得很好。 但是, 当多个客户端同时对同一个键进行这样的操作时, 就会产生竞争条件。
举个例子, 如果客户端 A 和 B 都读取了键原来的值, 比如 10 , 那么两个客户端都会将键的值设为 11 , 但正确的结果应该是 12 才对。
有了 WATCH , 我们就可以轻松地解决这类问题了:

1
2
3
4
5
6
WATCH mykey
val = GET mykey
val = val + 1
MULTI
SET mykey $val
EXEC


使用上面的代码, 如果在 WATCH 执行之后, EXEC 执行之前, 有其他客户端修改了 mykey 的值, 那么当前客户端的事务就会失败。 程序需要做的, 就是不断重试这个操作, 直到没有发生碰撞为止。这种形式的锁被称作乐观锁, 它是一种非常强大的锁机制。 并且因为大多数情况下, 不同的客户端会访问不同的键, 碰撞的情况一般都很少, 所以通常并不需要进行重试。

四,缓存生命周期的控制

在游戏服务器中,为了节省性能,我们没有必要把所有玩家的信息都缓存到内存中。比如有一些不常登陆的玩家,那么他的信息就没必要一直呆在缓存中了,需要清除。Redis为这个功能提供了一个方法:expire,它可以为key设置以秒为单位的生命周期,比如设置为300s,那么五分钟之后,这条记录就会在内存中删除。这样不仅可以节省内存,而且增加了服务器的性能


自学PHP网专注网站建设学习,PHP程序学习,平面设计学习,以及操作系统学习

京ICP备14009008号-1@版权所有www.zixuephp.com

网站声明:本站所有视频,教程都由网友上传,站长收集和分享给大家学习使用,如由牵扯版权问题请联系站长邮箱904561283@qq.com

添加评论