redis.conf基本配置项的示例分析-创新互联

这篇文章主要介绍redis.conf基本配置项的示例分析，文中介绍的非常详细，具有一定的参考价值，感兴趣的小伙伴们一定要看完！

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

以上是“redis.conf基本配置项的示例分析”这篇文章的所有内容，感谢各位的阅读！希望分享的内容对大家有帮助，更多相关知识，欢迎关注创新互联行业资讯频道！

另外有需要云服务器可以了解下创新互联cdcxhl.cn，海内外云服务器15元起步，三天无理由+7*72小时售后在线，公司持有idc许可证，提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案，具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势，专为企业上云打造定制，能够满足用户丰富、多元化的应用场景需求。