先说说我们公司这边的redis应用场景。目前线上的游戏是采用redis作为MongoDB的前端缓存，存储一些玩家需要经常访问的数据，同时游戏的运营公告信息以及BI相关采集数据也存放在redis中。在上周五，运营同事反映在某个合作方的游戏后台添加了游戏运营公告，但是进入游戏后却无法看到公告更新。同时，也有玩家反映游戏相关的活动奖励，游戏排行榜等信息没有更新。通过和开发同事沟通，初步判断是redis无法写入的问题。由于合作方之前一直没有提供redis服务器的访问权限，只有redis实例的权限。通过查看之前让合作方运维同事提供的redis配置参数，发现他们设置了maxmemory 2G 限定了单个redis实例最大使用内存为2G。我勒个去，这个坑可大了，由于之前对redis运维方面没有作深入研究，也没有仔细核对对方运维的redis配置参数。结果这次就坑大了。我们有接近10个区的数据都写入了这个实例中。再进入redis实例中，使用info 命令查看used_memory_human:1.98G 差不多达到了最大值，难怪更新了后台公告，游戏内却无法显示。然后联系对方运维调整maxmemory参数，一切恢复正常，运营那边又得制定玩家赔偿方案了。

redis的相关配置参考信息直接可以通过redis.conf文件查看，在这个文件中关于redis的常规配置已经解释得比较清楚了。这里主要讲解一下maxmemory相关的说明。

如果设定了maxmemory，使用redis的时候，redis的内存使用量不能超过设定的值，一旦redis的内存使用量达到了最大值，redis将会尝试按照选择的eviction policy(回收策略)移除相应的keys

如果redis不能根据回收策略移除keys,或者回收策略设置成noeviction，那么redis将对需要写操作的命令返回错误信息，如SET,LPUSH操作，对GET这样的只读操作会继续响应。

在redis.conf中给出了一个警告信息，如果一个设置了maxmemory的实例连接了从redis，那么预留给redis使用的内存除了redis实例本身占用的内存外还要加上用于主从复制的输出缓冲区大小(the output buffers need to feed the slaves），这样，才不会触发移除keys的死循环，因为当内存达到最大内存限制后，会根据eviction policy移除相应的keys，这时，从redis也会同步移除keys操作，最终所有数据都被清空。

总之，一句话，对一个连接了从redis的redis实例设置maxmemory时，建议设置一个较高的值，使系统有多余的内存用于主从同步，当然，如果eviction policy设置成noevcition,则不需要这么设置。