redis初体验

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

博客回复从下网上看。

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

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

Posted by: ffxiangyu | (49) September 23, 2016 07:31 PM

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

Posted by: 关力宁 | (46) April 26, 2016 08:05 PM

@Runforever如果你硬盘坏了, 也会造成数据短暂丢失的.

Posted by: Cloud | (45) July 1, 2015 10:37 AM

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

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

1.可以考虑对v进行字符串压缩，可以大幅节省内存和机器。

2.一般是单台slave或master出问题，重启的话也是单台，最好不要重启所有的slave。

3.每个slave机器预留30-40%的内存。

4.对冷热业务的优先级和重要性进行切割，不要将所有业务用一个redis集群。

Posted by: bestshare | (42) November 26, 2014 12:22 PM

我的看法是:

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

2) 如果考虑用Redis做memcache, 实际上Redis是独立进程，读取数据仍然是cs的模式，在不实用Redis做持久化的前提先，没想出它的具体使用案例。简单实现与游戏直接关联的实体对象，直接作为缓存的载体是我的倾向。当然也可能是因为我们做的游戏数据量级不同的缘故。

Posted by: BearOcean | (41) September 9, 2014 12:37 PM

感觉redis数据落地策略过于粗糙。针对数据更新的数量采用不同策略。1，如果更新数据量小，redis直接是缓存，leveldb或mysql做持久，更新数据先持久再缓存。2，更新数据量大，定期dump是个不错选择。但是不要让redis自己dump，因为redis不知道和其他实例错开时间，用脚本控制很简单，保证同一个时间只有一个做dump

Posted by: Anonymous | (31) March 25, 2014 04:55 PM

我们也做了个类似的游戏,所有模块都使用的go语言,数据落地是定时存回mysql,策略很简单,玩家的每一部分数据都有版本号,回存时只将更改过的数据拼装成事务交给mysql,目前运行了4个月,用户量也还不小,基本没有出现过问题,也基本不需要维护. 除了mysql drive,我们没有用任何形式的库.个人感觉服务器的话还是少用各种不了解的库,会更轻松.

Posted by: nd | (29) March 19, 2014 12:25 PM

我们的做法和云风差不多，落地策略有些差异。redis只做cache，redis里的key根据具体情况设置过期时间而已，防止过度膨胀，冷数据自动过期。玩家下线时，kv数据保存成功后，把id往redis list里插，另外用个脚本定期从list里取，每次取若干个，再用这些id把kv读出持久化回mysql，这样io的曲线也很平滑，呵呵。

Posted by: nana | (28) March 12, 2014 02:41 PM

我是这么想的，另外启动监听的端口，导致整体的数据库设计太过于复杂。
有一个方案，在redis本身上去修改一些东西，每个key都设置一个时间戳，到达一定的时间，把这些key落地。查询的时候，先在redis本上去查找下，如果没有再从硬盘上获取。当然这个会查询2次的情况，但是热数据，是非常快的。
为了解决查询2次的事情，我们只落地value
目前我们的游戏是采用的这套机制，k,v全部落地

Posted by: 郭建炯 | (19) March 5, 2014 05:07 PM

LevelDB不错, 性能更高, 尤其是写性能非常出众, 其实它也自带了C的访问接口, 在乎是C还是C++实现的意义不大

Posted by: dwing | (7) March 4, 2014 06:56 PM

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

Posted by: bear | (5) March 4, 2014 06:51 PM

@zengzizhao

如果本地连接 redis 还会发生连接断开的话，除了系统过载，就只能是系统的 bug 了。

如果依赖这个机制，那就算清楚，保证不过载,或在过载时启用其它机制就可以了。

Posted by: Cloud | (17) March 5, 2014 01:37 PM

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

Posted by: zengzizhao | (16) March 5, 2014 11:46 AM

>Redis Keyspace Notifications
这个是2.8才有的功能.

reids是有建议不要使用超过50%的物理内存就是担心fork的时候的问题.

另外在没有keyspace notifications时,有打算过用一个"笨办法"来处理冷数据,dump 到非生产机器(内存>=生产机器),然后使用OBJECT来确认key的REFCOUNT,并进行对部分冷数据进行移除.

Posted by: zwei | (13) March 5, 2014 12:15 AM

谢谢， 这样就更简单了。不用改原来的游戏服务器逻辑。

Posted by: Cloud | (2) March 4, 2014 05:34 PM

Redis 有一个功能 “Redis Keyspace Notifications”

http://redis.io/topics/notifications

可以监测 key 的变更事件，如果不复杂倒是可以尝试用于数据落地。

Posted by: 路人甲 | (1) March 4, 2014 05:23 PM

我们在redis 方面的最佳实践，都集成到redis-mgr里面了:

https://github.com/idning/redis-mgr

redis+twemproxy+sentinel deploy/auto-failover/monitor/migrate/rolling-upgrade 一键式管理