# 因为hash的再散列会导致整个进程的stop，为了避免长时间的stop，以上的策略都是 # 在分散整个rehash的过程(参照《redis设计与实现》的字典部分)
activerehashing yes
# 客户端输出缓冲区显示可以用来解决由于某些原因导致的强制断线，
# 而造成的不能读到需要的数据。
# 一个比较常见的原因是发布订阅模式中，客户端不能足够快速地消费发布者生产的信息。
#
# 这个限制可以设置为如下的三种类型:
#
# normal -> 正常普通的客户端，包含监控客户端
# slave -> 主从结构中的从客户端
# pubsub -> 订阅了最少一个频道的客户端
#
# 每一个 client-output-buffer-limit 格式如下:
#
# client-output-buffer-limit <class> <hard limit> <soft limit> <soft seconds>
#
# 在两种情况下服务器认为客户端不是意外临时掉线
#
# 1.缓冲区的数据达到硬限制
# 2.缓冲区的数据达到软限制，同时时间超过了指定值
#
# 因为一个客户端离线，有可能是临时性的网络故障，或者传输问题
# 也有可能是永久性离线 或者强制性离线，此时服务器将不会保留他的缓存数据
# 以下的设置就是为了判断这一情况的
#
# 硬限制和软限制都可以通过将其设置为0来关闭掉
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
# redis会按照一定的频率来处理诸如关闭超时连接，清理没有被使用的过期key等此类
# 后台任务
#
# 并不是所有的任务都以相同的频率来执行的，redis通过一个hz的值来决定处理这些(如上所述的后台任务)任务的频率
#
# 提高这个值会使用更多的cpu时间来在redis闲置的时候处理以上的，但是同时，
# 超时的连接的处理和过期key的清理也会更精确
#
# hz的取值范围在1到500，不建议设置为超过100的值，默认是10
hz 10
# 当子进程重写AOF文件的时候，以下选项将会允许等到存在32MB数据的时候才调用强制同步，这样可以降低IO上的延迟。
aof-rewrite-incremental-fsync yes
下面关于Redis的文章您也可能喜欢，不妨参考下：