看了云风的skynet时候, 看到他说了一个redis的事故。今儿引发的一系列博客回复。看的心里很虚。这边先做个备忘。
博客回复从下网上看。
https://github.com/shenzhe/redis-storage--把leveldb嵌入到redis.实现真正的数据持久存储,感觉这个东西很适合博主的游戏存储需求,我之前做游戏也用过这个^-^
如果监护进程挂了,还是会存在数据丢失的情况,这部分云风大神如何考虑的,容忍短时间的数据丢失吗?
Posted by: Runforever | (44) June 30, 2015 11:35 AM
2) 如果考虑用Redis做memcache, 实际上Redis是独立进程,读取数据仍然是cs的模式,在不实用Redis做持久化的前提先,没想出它的具体使用案例。简单实现与游戏直接关联的实体对象,直接作为缓存的载体是我的倾向。当然也可能是因为我们做的游戏数据量级不同的缘故。
感觉redis数据落地策略过于粗糙。针对数据更新的数量采用不同策略。1,如果更新数据量小,redis直接是缓存,leveldb或mysql做持久,更新数据先持久再缓存。2,更新数据量大,定期dump是个不错选择。但是不要让redis自己dump,因为redis不知道和其他实例错开时间,用脚本控制很简单,保证同一个时间只有一个做dump
我们也做了个类似的游戏,所有模块都使用的go语言,数据落地是定时存回mysql,策略很简单,玩家的每一部分数据都有版本号,回存时只将更改过的数据拼装成事务交给mysql,目前运行了4个月,用户量也还不小,基本没有出现过问题,也基本不需要维护. 除了mysql drive,我们没有用任何形式的库.个人感觉服务器的话还是少用各种不了解的库,会更轻松.
我们的做法和云风差不多,落地策略有些差异。redis只做cache,redis里的key根据具体情况设置过期时间而已,防止过度膨胀,冷数据自动过期。玩家下线时,kv数据保存成功后,把id往redis list里插,另外用个脚本定期从list里取,每次取若干个,再用这些id把kv读出持久化回mysql,这样io的曲线也很平滑,呵呵。
我是这么想的,另外启动监听的端口,导致整体的数据库设计太过于复杂。
有一个方案,在redis本身上去修改一些东西,每个key都设置一个时间戳,到达一定的时间,把这些key落地。查询的时候,先在redis本上去查找下,如果没有再从硬盘上获取。当然这个会查询2次的情况,但是热数据,是非常快的。
为了解决查询2次的事情,我们只落地value
目前我们的游戏是采用的这套机制,k,v全部落地
LevelDB不错, 性能更高, 尤其是写性能非常出众, 其实它也自带了C的访问接口, 在乎是C还是C++实现的意义不大
@zengzizhao
如果本地连接 redis 还会发生连接断开的话,除了系统过载,就只能是系统的 bug 了。
如果依赖这个机制,那就算清楚,保证不过载,或在过载时启用其它机制就可以了。
“Redis 有一个功能 “Redis Keyspace Notifications”
http://redis.io/topics/notifications
可以监测 key 的变更事件,如果不复杂倒是可以尝试用于数据落地。”
"Because Redis Pub/Sub is fire and forget currently there is no way to use this feature if you application demands reliable notification of events, that is, if your Pub/Sub client disconnects, and reconnects later, all the events delivered during the time the client was disconnected are lost."
基于fire and forget,Keyspace Notifications这个似乎并不适合用来做落地。
这个是2.8才有的功能.
reids是有建议不要使用超过50%的物理内存就是担心fork的时候的问题.
另外在没有keyspace notifications时,有打算过用一个"笨办法"来处理冷数据,dump 到非生产机器(内存>=生产机器),然后使用OBJECT来确认key的REFCOUNT,并进行对部分冷数据进行移除.
Redis 有一个功能 “Redis Keyspace Notifications”
http://redis.io/topics/notifications
可以监测 key 的变更事件,如果不复杂倒是可以尝试用于数据落地。
我们在redis 方面的最佳实践,都集成到redis-mgr里面了:
https://github.com/idning/redis-mgr
redis+twemproxy+sentinel deploy/auto-failover/monitor/migrate/rolling-upgrade 一键式管理
你好,想问几个问题:
1、公会的用户详细信息数据是如何获取,涉及的用户肯定分布在不同redis数据库里,是每次都到各库查询,还是有缓存机制?
2、redis的落地周期一般为多少,如果发生灾难丢失重要数据如何补救?