资讯

精准传达 • 有效沟通

从品牌网站建设到网络营销策划,从策略到执行的一站式服务

redis.conf基本配置项的示例分析

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

10年积累的成都网站建设、成都做网站经验,可以快速应对客户对网站的新想法和需求。提供各种问题对应的解决方案。让选择我们的客户得到更好、更有力的网络服务。我虽然不认识你,你也不认识我。但先网站设计后付款的网站建设流程,更有方山免费网站建设让你可以放心的选择与我们合作。

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基本配置项的示例分析”这篇文章的所有内容,感谢各位的阅读!希望分享的内容对大家有帮助,更多相关知识,欢迎关注创新互联行业资讯频道!


本文名称:redis.conf基本配置项的示例分析
网站地址:http://cdkjz.cn/article/ggiisg.html
多年建站经验

多一份参考,总有益处

联系快上网,免费获得专属《策划方案》及报价

咨询相关问题或预约面谈,可以通过以下方式与我们联系

大客户专线   成都:13518219792   座机:028-86922220