【Redis笔记】第2篇:redis.conf基本配置项说明

Redis的配置项看起来比较复杂，分析之下，其实可以分为几大类（以redis v2.6.14版本的redis.conf为例）： 1) 基本配置项 2) 持久化（Persistence）相关配置 3) Replication配置 4) Security配置 5) Limit配置 6) SlowLog配置 7) Advanced配置 8) INCLUDES配

Redis的配置项看起来比较复杂，分析之下，其实可以分为几大类（以redis v2.6.14版本的redis.conf为例）：

1) 基本配置项

2) 持久化（Persistence）相关配置

3) Replication配置

4) Security配置

5) Limit配置

6) SlowLog配置

7) Advanced配置

8) INCLUDES配置

其中，持久化配置及Replication配置对redis来说非常重要，因此，我准备在后面两篇笔记中单独说明。

本篇笔记主要介绍其它几类配置项。

1. 基本配置项

1) daemonize

是否以守护模式启动，默认为no，配置为yes时以守护模式启动，这时redis instance会将进程号pid写入默认文件/var/run/redis.pid

2) pidfile

配置pid文件路径，默认/var/run/redis.pid，该配置项在以daemonized mode启动redis时有效

3) port

Redis进程监听的TCP端口，默认为6379，如果配成0，则redis不会再listen TCP socket

4) bind

配置bind网卡，若配为具体ip值，则redis只侦听来自该网卡的连接。该配置项默认为commented状态，表示redis会监听来自该机器所有网卡的连接

5) unixsocket和unixsocketperm

配置unix sock file的路径和权限，表明redis要侦听来自指定路径下的unix socket file的数据请求。这些配置项默认是commented的，即redis默认不会侦听unix socket

6) timeout

配置连接超时时间，单位为秒，超时后redis进程主动断开连接；若配置为0，则表示redis服务进程不会主动断开来自client的连接

7) tcp-keepalive

配置redis向client发送保活ACKs的时间间隔，默认为0，表示不发送keep-alive报文。
备注：该配置项是新加的，2.6.7版本中没有，最新的2.6.14有（还没有调研是哪个版本引入的）。

8) loglevel

配置redis进程的日志level，支持4种：debug/verbose/notice/warning，日志信息的详细程度递减，可根据实际情况做配置

9) logfile

redis输出日志路径，默认stdout。若需改为其它目录（如./log/redis-running.log），则日志文件的父路径必须事先mkdir出来，否则会启动失败

10) sys-log-enable/syslog-ident/syslog-facility

这3个配置项与syslog相关，默认都是commented状态。这里不再赘述，感兴趣的话，可以在shell terminal中man syslog查看之。

总结：上述基本配置项中，port为必配项，其余项一般情况下保持默认即可。

2. 持久化（Persistence）相关配置

篇幅较多，下篇笔记做详细说明。update: 参见这里

3. Replication配置

篇幅较多，下下篇笔记做详细说明。update: 参见这里

4. Security配置

若redis实例可能会接收来自不受自己控制的客户端的命令时（如来自第三方的访问），可以考虑启用密码保护（即客户端必须先通过认证（通过AUTH ）才能执行其它命令），也可以通过rename-command来禁用某些会危及Redis正常运行的危险命令。

1) requirepass

指定访问密码

2) rename-command

重命名命令。如rename-command CONFIG randomcommand或rename-command CONFIG ""，其中后者会完全禁用CONFIG命令。

注意：Changing the name of commands that are logged into the AOF file or transmitted to slaves may cause problems. 即若某些会写入aof文件或同步给从库的命令被rename后，可能会引起问题：aof文件回放时，redis实例未必会识别出被rename后的命令；类似地，master实例中被配置了rename的命令，同步到slave实例执行时，后者可能无法识别这些非官方支持的"自定义"命令。

5. Limit配置

1) maxclients

客户端的并发连接数，默认10000。当redis实例无法更改系统fd限制时，会以系统限制数n减去32作为Redis支持的最大连接数（减32是因为Redis保留32个fd供内部逻辑使用）。当达到Redis支持的最大连接数后，新连接会被close，对应的client会收到"max number of clients reached"的出错提示。

2) maxmemory

配置Redis Server可占用的最大内存值，单位byte。如果达到该阈值，根据用户配置的淘汰策略，Redis会尝试删除符合淘汰条件的key。假如用户配置了永不淘汰（noeviction）的策略，则Redis不会删除现有的key，此时，来自客户端的所有写入或排序等需要使用更多内存的命令都会报错，而读取命令可以正常执行。

在Redis被用来作为LRU缓存时，该配置项会很有用。

特别注意：在主从部署下，master在配置了淘汰策略的前提下，配置maxmemory时，需要配置一个比机器可用物理存储器数量小一些的阈值，因为主从同步需要为slave保留output buffer。若master的maxmemory配置成与机器Physical Memory很接近的值，可能会引起master的key全部被淘汰的严重后果！

具体的触发过程：在Redis Server实际使用的内存达到阈值后，开始根据淘汰策略删除master的key，同时会通过DEL命令同步删除slave的key，此时，master需要申请output buffer用于存放发往slave的命令，这会使master尝试使用更多内存，从而加剧内存超限的严重程度。于是，master只能通过删除更多的keys以便尝试降低内存使用，而这些keys的DELs命令同样需要同步至slaves，意味着master需要申请更大的output buffer用于存放同步命令或数据。典型的"雪崩效应"，最坏的结果是master会把所有的key都删干净。

而若maxmemory配置成比机器Physical Memory小一些的值（如配成后者的90%），当Redis实际使用内存达到配置阈值后，开始淘汰key，发给slave的同步命令存到output buffer，此时Redis实际使用的内存可能会继续增长，由于目前系统还有大约10%的存储器资源可供使用，因此output buffer会从这些free的memory中借用资源（从Redis 2.4开始，master会认为这个增长是暂时的，同步完成后即可释放内存），从而避免master通过删除更多的keys为output buffer腾空间。

关于这个问题的更详细讨论以及Redis作者的实现策略，可以参考这里。

总之，要谨记：若系统以主从方式部署且master配置了淘汰策略，那么，master的maxmemory务必要配置一个合理的值（与用户可以为Redis提供的最大物理内存相比），以避免Redis实际使用的内存达到阈值后发生所有的key被完全删除的情况发生！

3) maxmemory-policy

配置Redis的淘汰策略，默认为volatile-lru。目前支持6种策略：

a. volatile-lru => remove the key with an expire set using an LRU algorithm;

b. allkeys-lru -> remove any key accordingly to the LRU algorithm

c. volatile-random -> remove a random key with an expire set

d. allkeys-random -> remove a random key, any key

e. volatile-ttl -> remove the key with the nearest expire time (minor TTL)

f. noeviction -> don't expire at all, just return an error on write operations

4) maxmemory-samples

配置key淘汰算法运行时的采样数，默认为3。之所以存在这个配置项，是由于redis为节省内存，采用了近似的淘汰算法，这个配置项可以用来调节淘汰算法的精度：当需要淘汰key时（如内存达到阈值），Redis会在符合淘汰条件（由maxmemory-policy指定）的key set中，随机采样n个key并将其中符合LRU的那个key删掉。默认情况下n取3，如果要提高淘汰算法的精度，n可以调大（代价是增加CPU运算时间）。

6. SlowLog配置

Redis可以记录处理时间超过某个阈值的慢查询，这里的处理时间不包括I/O操作（如与客户端会话的读/写时间等）。

注意：由于Redis Server是单线程实现，因此若其中某个查询命令导致阻塞，会影响到后续的客户端请求，因此，线上环境最好开启慢查询记录以便追踪问题。

1) slowlog-log-slower-than

指定慢查询的阈值，单位：微秒。处理时间超过该值的查询命令，会被记录到日志中。

2) slowlog-max-len

配置slowlog记录的最大条数，大小无限制，但会消耗更多内存。默认128。

7. Advanced配置

1) 内部数据结构优化的阈值配置

可以配置相应的阈值，Redis据此判断其内部实现时是否优化相关的数据结构。例如：

hash-max-ziplist-entries 512

hash-max-ziplist-value 64

上面的配置指定当ziplist中的key个数不大于512且最大的value不大于64字节时，Redis会用一种特殊的更节省内存的数据结构来存储这些k-v数据。

类似的配置还包括list、set、zset等数据类型。

2) activerehashing

配置Redis是否主动rehashing，默认yes，意味着Redis每秒会有10次自动rehashing的动作（每100ms会触发一次），以便尽可能优化内存使用。

注意：Redis采取的是lazy rehashing策略，即越是被频繁访问的hash table，Redis针对该表的rehashing也会越频繁；相反，若某个hash table处于idle状态，则针对它的rehashing永远不会被真正执行。

3) output buffer

output buffer是Redis为client分配的缓冲区（这里的"client"可能是真正的client，也可能是slave或monitor），若为某个客户端分配的output buffer超过了预留大小，Redis可能会根据配置策略关闭与该端的连接。

例如，若Redis被用作message queue，订购消息的consumer处理速度跟不上发布消息的producer时，就会发生对应的output buffer超限的情况。

该配置项格式如下：

client-output-buffer-limit

：目前支持3种客户端：1) normal => normal clients; 2) slave clients and MONITOR clients; 3) pubsub => clients subcribed to at least one pubsub channel or pattern

：若output buffer大小超过该值，Redis会立即关闭与对应client的连接

：若output buffer大小超过soft limit且这种情况的持续时间超过soft seconds，则Redis会关闭与对应client的连接。

默认的配置如下：

client-output-buffer-limit normal 0 0 0

client-output-buffer-limit slave 256mb 64mb 60

client-output-buffer-limit pubsub 32mb 8mb 60

8. INCLUDES配置

当机器不只存在1个Redis实例时，这里可以实现每个Redis实例的"个性化"配置，此时，可以将这些实例的共有配置写到redis.conf中，而个性化的配置写到由include配置路径指定的文件中。

配置格式：include /path/to/local.conf

【参考资料】

1. redis.conf (redis v2.6.14)

2. redis github issue: maxmemory + evicting policy + slaves = death