redis.conf配置详解(二)
# 命令重命名.
#
# 在一个共享环境下可以重命名相对危险的命令。比如把CONFIG重名为一个不容易猜测的字符。
#
# 举例:
#
# rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52
#
# 如果想删除一个命令,直接把它重命名为一个空字符""即可,如下:
#
# rename-command CONFIG ""
################################### 约束 #################################### # 设置同一时间最大客户端连接数,默认无限制,Redis可以同时打开的客户端连接数为Redis进程可以打开的最大文件描述符数, # 如果设置 maxclients 0,表示不作限制。 # 当客户端连接数到达限制时,Redis会关闭新的连接并向客户端返回max number of clients reached错误信息 # # maxclients 128 # 指定Redis最大内存限制,Redis在启动时会把数据加载到内存中,达到最大内存后,Redis会先尝试清除已到期或即将到期的Key # Redis同时也会移除空的list对象 # # 当此方法处理后,仍然到达最大内存设置,将无法再进行写入操作,但仍然可以进行读取操作 # # 注意:Redis新的vm机制,会把Key存放内存,Value会存放在swap区 # # maxmemory的设置比较适合于把redis当作于类似memcached的缓存来使用,而不适合当做一个真实的DB。 # 当把Redis当做一个真实的数据库使用的时候,内存使用将是一个很大的开销 # maxmemory# 当内存达到最大值的时候Redis会选择删除哪些数据?有五种方式可供选择 # # volatile-lru -> 利用LRU算法移除设置过过期时间的key (LRU:最近使用 Least Recently Used ) # allkeys-lru -> 利用LRU算法移除任何key # volatile-random -> 移除设置过过期时间的随机key # allkeys->random -> remove a random key, any key # volatile-ttl -> 移除即将过期的key(minor TTL) # noeviction -> 不移除任何可以,只是返回一个写错误 # # 注意:对于上面的策略,如果没有合适的key可以移除,当写的时候Redis会返回一个错误 # # 写命令包括: set setnx setex append # incr decr rpush lpush rpushx lpushx linsert lset rpoplpush sadd # sinter sinterstore sunion sunionstore sdiff sdiffstore zadd zincrby # zunionstore zinterstore hset hsetnx hmset hincrby incrby decrby # getset mset msetnx exec sort # # 默认是: # # maxmemory-policy volatile-lru # LRU 和 minimal TTL 算法都不是精准的算法,但是相对精确的算法(为了节省内存),随意你可以选择样本大小进行检测。 # Redis默认的灰选择3个样本进行检测,你可以通过maxmemory-samples进行设置 # # maxmemory-samples 3
############################## AOF ############################### # 默认情况下,redis会在后台异步的把数据库镜像备份到磁盘,但是该备份是非常耗时的,而且备份也不能很频繁,如果发生诸如拉闸限电、拔插头等状况,那么将造成比较大范围的数据丢失。 # 所以redis提供了另外一种更加高效的数据库备份及灾难恢复方式。 # 开启append only模式之后,redis会把所接收到的每一次写操作请求都追加到appendonly.aof文件中,当redis重新启动时,会从该文件恢复出之前的状态。 # 但是这样会造成appendonly.aof文件过大,所以redis还支持了BGREWRITEAOF指令,对appendonly.aof 进行重新整理。 # 你可以同时开启asynchronous dumps 和 AOF appendonly no # AOF文件名称 (默认: "appendonly.aof") # appendfilename appendonly.aof # Redis支持三种同步AOF文件的策略: # # no: 不进行同步,系统去操作 . Faster. # always: always表示每次有写操作都进行同步. Slow, Safest. # everysec: 表示对写操作进行累积,每秒同步一次. Compromise. # # 默认是"everysec",按照速度和安全折中这是最好的。 # 如果想让Redis能更高效的运行,你也可以设置为"no",让操作系统决定什么时候去执行 # 或者相反想让数据更安全你也可以设置为"always" # # 如果不确定就用 "everysec". # appendfsync always appendfsync everysec # appendfsync no # AOF策略设置为always或者everysec时,后台处理进程(后台保存或者AOF日志重写)会执行大量的I/O操作 # 在某些Linux配置中会阻止过长的fsync()请求。注意现在没有任何修复,即使fsync在另外一个线程进行处理 # # 为了减缓这个问题,可以设置下面这个参数no-appendfsync-on-rewrite # # This means that while another child is saving the durability of Redis is # the same as "appendfsync none", that in pratical terms means that it is # possible to lost up to 30 seconds of log in the worst scenario (with the # default Linux settings). # # If you have latency problems turn this to "yes". Otherwise leave it as # "no" that is the safest pick from the point of view of durability. no-appendfsync-on-rewrite no # Automatic rewrite of the append only file. # AOF 自动重写 # 当AOF文件增长到一定大小的时候Redis能够调用 BGREWRITEAOF 对日志文件进行重写 # # 它是这样工作的:Redis会记住上次进行些日志后文件的大小(如果从开机以来还没