redis初体验

看了云风的skynet时候, 看到他说了一个redis的事故。今儿引发的一系列博客回复。看的心里很虚。这边先做个备忘。

博客回复从下网上看。

谈谈陌陌争霸在数据库方面踩过的坑(Redis篇)

你好,想问几个问题:
1、公会的用户详细信息数据是如何获取,涉及的用户肯定分布在不同redis数据库里,是每次都到各库查询,还是有缓存机制?
2、redis的落地周期一般为多少,如果发生灾难丢失重要数据如何补救?

https://github.com/shenzhe/redis-storage--把leveldb嵌入到redis.实现真正的数据持久存储,感觉这个东西很适合博主的游戏存储需求,我之前做游戏也用过这个^-^

如果监护进程挂了,还是会存在数据丢失的情况,这部分云风大神如何考虑的,容忍短时间的数据丢失吗?

Posted by: Runforever | (44) June 30, 2015 11:35 AM

1.可以考虑对v进行字符串压缩,可以大幅节省内存和机器。
2.一般是单台slave或master出问题,重启的话也是单台,最好不要重启所有的slave。
3.每个slave机器预留30-40%的内存。
4.对冷热业务的优先级和重要性进行切割,不要将所有业务用一个redis集群。

我的看法是:
1) 个人感觉Redis做主存是存疑的。除了物理内存本身的大小限制外,还有要考虑运维系统的实现。单纯地KV系统,基本很难支持比较复杂的业务查询,比如查询充值超过100并且登录次数的玩家。

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++实现的意义不大

整个游戏没有用db做落地? 现在只有unqlite? 那运营上的数据分析这些都是怎么获得数据呢?写一个解析接口从数据文件获得?

@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这个似乎并不适合用来做落地。

>Redis 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 一键式管理


你可能感兴趣的:(skynet)