【Redis】千呼万唤始出来，Redis4最详细配置文件讲解，全网首发
以下内容基于Redis4配置文件整理，基于一千多行配置文件，翻译、理解而作，也参考了一些网上的资料，包含了全部配置大概100项。希望对大家有帮助，并多多支持～
| 分类 | 配置项 | 默认值 | 是否默认启用 | 取值说明 | 备注 |
| INCLUDES 引入/包含 |
include | N | 1、假如说你有一个可用于所有的 redis server 的标准配置模板，但针对某些 server 又需要一些个性化的设置，你可以使用include 来引入一些其他的配置文件； 2、include 是不能被 config rewrite 命令改写的； 3、因为Redis总是使用最后处理的行作为配置指令的值，最好将includes在该文件的开头，以避免在运行时覆盖配置更改。 |
||
| MODULES 模块 |
loadmodule | N | 在启动时加载模块。 如果服务器无法加载模块它会中止。 可以使用多个loadmodule指令。 | ||
| NETWORK 网络 |
bind | 127.0.0.1 | Y | 1、如果未指定“ bind”配置指令，则Redis侦听来自服务器上所有可用网络接口的连接； 2、bind后可配置一个或多个IP，用以监听一个或多个选定的网络接口(多个用空格分隔)； 3、由于redis采用的安全策略，默认会只准许本地访问。需要通过简单配置，完成允许外网访问； 4、警告：如果运行Redis的计算机直接暴露于互联网，绑定到所有接口都是危险的，并且会暴露实例给互联网上的所有人。 |
|
| protected-mode | yes | Y | yes,no | 1、redis3.2版本后新增protected-mode配置，默认是yes，即开启； 2、关闭protected-mode模式，此时外部网络可以直接访问； 3、开启protected-mode保护模式，需配置bind ip或者设置访问密码。 |
|
| port | 6379 | Y | 接受指定端口上的连接，默认为6379，如果指定了端口0，则Redis将不会在TCP套接字上侦听。 | ||
| tcp-backlog | 511 | Y | 1、表示TCP 监听的最大容纳/积压数量； 2、当系统并发量大并且客户端速度缓慢的时候，你需要把这个值调高以避免客户端连接缓慢的问题； 3、Linux的默认参数值是128，Linux内核不会把默认的511改成128。 |
||
| unixsocket | /tmp/redis.sock | N | 指定用于监听传入连接的Unix套接字的路径。 没有默认值，因此在未指定的情况下，Redis不会在Unix套接字上侦听。 | ||
| unixsocketperm | 700 | N | 用于设置unixsocket指定file的权限 | ||
| timeout | 0 | Y | 1、单位：秒； 2、当客户端闲置多少秒后关闭连接，如果设置为0表示关闭该功能。 |
||
| tcp-keepalive | 300 | Y | 1、单位：秒； 2、TCP连接保活策略。假如设置为60，则server端会每60秒向连接空闲的客户端发起一次ACK请求，以检查客户端是否已经挂掉，对于无响应的客户端则会关闭其连接，所以关闭一个连接最长需要120秒的时间，如果设置为0，则不会进行保活检测； 3、使用SO_KEEPALIVE向客户端发送TCP ACK。 |
||
| GENERAL 通用 |
daemonize | no | Y | yes,no | 1、默认情况下，Redis不会作为守护程序运行（即后台运行）， 如果需要，设置为yes； 2、注意，Redis守护进程将在pidfile配置的文件中写入pid。 |
| supervised | no | Y | no,upstart,systemd,auto | 1、可以通过upstart和systemd管理Redis守护进程。如果从upstart或systemd运行Redis，Redis可以与监督树进行交互； 选项： supervised no - 没有监督互动 supervised upstart - 通过将Redis置于SIGSTOP模式来通知upstart supervised systemd - 通过将READY = 1写入$ NOTIFY_SOCKET来通知systemd supervised auto - 基于UPSTART_JOB或NOTIFY_SOCKET环境变量，检测upstart或systemd方法 2、注意：这些监视方法仅表示“过程已准备就绪“，他们无法使监督器连续不断地进行ping操作。 |
|
| pidfile | /var/run/redis_6379.pid | Y | 1、如果指定了pid文件，则Redis会在启动时将进程号写入指定位置，并在退出时将其删除； 2、当服务器非后台运行时，如果在配置中未指定任何pid文件，则不会创建该文件。 后台启动时，即使未指定，也会使用pid文件，默认为“ /var/run/redis.pid“； 3、最好创建pid文件：如果Redis无法创建它，不会发生任何不良情况，服务器将启动并正常运行。 |
||
| loglevel | notice | Y | debug,verbose,notice,warning | 指定服务器的日志详细级别： debug - 调试（很多信息，对于开发/测试很有用） verbose - 详细（无用的信息比较多，但不会像调试级别那样混乱） notice - 通知（适度冗长，可能在生产中需要什么） warning - 警告（仅记录非常重要/重要的消息） |
|
| logfile | "" | Y | 1、指定日志文件名。 也可以使用空字符串强制Redis记录到标准输出； 2、如果使用标准输出来记录日志，并且redis是后台启动，日志将发送到/ dev / null。 |
||
| syslog-enabled | no | N | yes,no | 要启用记录日志到系统记录器的功能，只需将'syslog-enabled'设置为yes，然后根据需要更新其他syslog参数。 | |
| syslog-ident | redis | N | 指定记录系统日志的身份标识 | ||
| syslog-facility | local0 | N | user,local0,local1,local2,local3, local4,local5,local6,local7 |
指定syslog设备，值可以是USER或LOCAL0-LOCAL7 | |
| databases | 16 | Y | 1～16 | 设置数据库数量。 默认数据库为DB 0，您可以使用SELECT |
|
| always-show-logo | yes | Y | yes,no | 1、设置redis启动时是否显示Logo； 2、默认情况下，仅当开始记录到标准输出并且标准输出为TTY时，Redis才会显示ASCII艺术Logo。 基本上，这意味着徽标通常仅在交互式会话中显示。但是，可以通过将以下选项设置为yes，来强制执行4.0之前的行为并始终在启动日志中显示ASCII艺术Logo。 |
|
| SNAPSHOTTING RDB快照 |
save | save 900 1 save 300 10 save 60 10000 |
Y | 1、设置将数据持久化到磁盘的频率和规则； 2、格式：save 3、如果你想禁用RDB持久化的策略，只要不设置任何save指令就可以，或者给save传入一个空字符串参数也可以达到相同效果； 4、如果给save传入一个空字符串参数，会删除所有先前配置的save命令。 |
|
| stop-writes-on-bgsave-error | yes | Y | yes,no | 1、默认情况下，如果 redis 最后一次的后台保存失败，redis 将停止接受写操作； 2、这样以一种强硬的方式让用户知道数据不能正确的持久化到磁盘，否则就会没人注意到灾难的发生。如果后台保存进程重新启动工作了，redis 也将自动的允许写操作； 3、然而你要是安装了靠谱的监控，你可能不希望redis这样做，那你就改成no。 |
|
| rdbcompression | yes | Y | yes,no | 1、在进行备份时,是否进行压缩； 2、是否在dump .rdb数据库的时候使用LZF压缩字符串，默认都设为yes； 3、如果你希望保存子进程节省点cpu，你就设置它为no，不过这个数据集可能就会比较大。 |
|
| rdbchecksum | yes | Y | yes,no | 1、从RDB版本5开始，在文件末尾放置了CRC64校验和（注：RDB文件版本不是redis版本）。 2、这使该格式更能抵抗损坏，但是在保存和加载RDB文件时会降低性能（约10％），因此可以禁用该格式以获得最佳性能。 3、在禁用校验和的情况下创建的RDB文件的校验和为零，这将指示加载代码跳过该校验。 |
|
| dbfilename | dump.rdb | Y | 设置RDB备份文件的文件名 | ||
| dir | ./ | Y | 1、配置redis的工作目录； 2、RDB文件将写入该目录内，文件名使用“ dbfilename”配置指令在上面指定； 3、AOF文件也会使用该目录； 4、请注意，您必须在此处指定目录，而不是文件名。 |
||
| REPLICATION 复制 |
slaveof | N | 1、使用slaveof使Redis实例成为另一个Redis服务器的副本； 2、格式：slaveof |
||
| masterauth | N | 1、如果主服务器受密码保护，指定与主数据库连接时需要的密码验证； 2、格式：masterauth |
|||
| slave-serve-stale-data | yes | Y | yes,no | 当slave服务器和master服务器失去连接后，或者当数据正在复制传输的时候： 1、如果此参数值设置“yes”，slave服务器可以继续接受客户端的请求； 2、否则，会返回给请求的客户端如下信息“SYNC with master in progress”,除了INFO，SLAVEOF这两个命令。 |
|
| slave-read-only | yes | Y | yes,no | 设置slave节点是否为只读模式，从redis2.6版本开始，slave默认为只读 | |
| repl-diskless-sync | no | Y | yes,no | 新的slave和重连后不能继续备份的slave，需要做所谓的“完全备份”，即将一个RDB文件从主站传送到slave。这个传送有以下两种方式： -硬盘备份：Master创建一个新的进程，用于把RDB文件写到硬盘上。过一会儿，其父进程递增地将文件传送给slave； -无硬盘备份：Master创建一个新的进程，直接把RDB文件写到slave的套接字，不需要用到硬盘； 1、在硬盘备份的情况下，Master的子进程生成RDB文件。一旦生成，多个slave可以立即排成队列使用主站的RDB文件； 2、在无硬盘备份的情况下，一次RDB传送开始，新的slave到达后，需要等待现在的传送结束，才能开启新的传送； 3、如果使用无硬盘备份，Master会在开始传送之间等待一段时间（可配置，以秒为单位），希望等待多个slave到达后并行传送； 4、在硬盘低速而网络高速（高带宽）情况下，无硬盘备份更好； |
|
| repl-diskless-sync-delay | 5 | Y | 1、单位：秒； 2、当启用无盘复制时，可以配置服务器等待的延迟，以便于等待更多的slave到达后并行传送； 3、这一点很重要，因为一旦传输开始，就不可能为到达的新从属服务器提供服务，而新从属服务器将排队等待下一个RDB传输，因此服务器将等待一个延迟，以便让更多从属服务器到达； 4、延迟以秒为单位指定，默认情况下为5秒。要完全禁用它，只需将其设置为0秒，传输将尽快开始。 |
||
| repl-ping-slave-period | 10 | N | 1、单位：秒； 2、slave向master发送ping信号的时间间隔 |
||
| repl-timeout | 60 | N | 1、单位秒，主从复制的超时时间； 2、通过以下内容设置备份的超时时间： - 从slave的角度，同步期间的批量传输的I/O - 从slave（数据、ping）的角度来看主超时 - master角度认为的slave超时（REPLCONF ACK pings) 3、确认这些值比定义的repl-ping-slave-period要大，否则每次master和slave之间通信低速时都会被检测为超时。 |
||
| repl-disable-tcp-nodelay | no | N | yes,no | 1、设置同步之后是否禁用slave上的TCP_NODELAY - 如果选择yes，Redis将使用较少的TCP数据包和较少的带宽向从机发送数据。但这会增加slave的数据延迟，对于使用默认配置的Linux内核，延迟可达40毫秒； - 如果选择no，slave的数据延时不会那么多，但备份需要的带宽相对较多。 |
|
| repl-backlog-size | 1mb | N | 1、设置备份的积压储备大小。积压储备是一个缓冲区，当slave断开一段时间的情况时，它替slave接收存储数据，因此当slave重连时，通常不需要完全备份，只需要一个部分同步就可以，即把slave断开时错过的一部分数据接收。 2、工作储备越大，允许slave断开并稍后执行部分同步的断开时间就越长。 3、只要有一个slave连接，就会立刻分配一个工作储备。 |
||
| repl-backlog-ttl | 3600 | N | 1、单位：秒；用于配置积压储备释放所等待的时间； 2、Master过了指定的时间没有与从站连接，对应的积压储备就会自动释放，秒数从断开的那一刻开始计算； 3、值为0表示不释放。 |
||
| slave-priority | 100 | Y | 1、设置slave的优先级；优先级可以用reids的info命令查到； 2、主要用于master宕机时，Sentinel选举新的master； 3、Sentinel会选举优先级低的slave作为新的master； 4、如果设置为0，则不会被选举为新的master。 |
||
| min-slaves-to-write | 0 | N | 1、一般和下面一个配置结合使用，表示如果连接的slave少于N个，且延迟大于M秒，则主服务器可以停止接受写入； 2、N个从站必须是在线状态； 3、设置两个中的某一个为0表示禁用这一功能。 |
||
| min-slaves-max-lag | 10 | N | 1、单位：秒； 2、延迟（必须<=指定值）是从从机接收的最后一个ping（通常每秒发送一次）计算得出的。 3、例如，需要至少3个延迟<=10秒的slave min-slaves-to-write 3 min-slaves-max-lag 10 |
||
| slave-announce-ip | N | 1、Redis主机能够以不同的方式列出所连接的从机的地址和端口：例如命令"INFO replication"、"role"； 2、当使用端口转发或网络地址转换（NAT）时，从机实际上可以通过不同的IP和端口对访问。从机可以使用这两个选项向其主机报告一组特定的IP和端口，以便INFO和ROLE都将报告这些值； 3、如果只需要覆盖端口或IP地址，则不需要同时使用这两个选项。 |
|||
| slave-announce-port | N | ||||
| SECURITY 安全 |
requirepass | N | 1、设置redis连接密码； 2、警告：由于Redis非常快，外部用户可以尝试每秒15万个密码，这意味着你应该使用一个非常强的密码，否则很容易破解。 |
||
| rename-command | N | 1、将命令重命名，为了安全考虑，可以将某些重要的、危险的命令重命名； 2、当你把某个命令重命名成空字符串的时候就等于取消了这个命令。 如： rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52 rename-command CONFIG "" |
|||
| CLIENTS 客户端 |
maxclients | 10000 | N | 1、设置同时连接的客户端数。 一旦达到限制，Redis将关闭所有新连接，并发送错误消息“已达到最大客户端数"； 2、设置为0表示不做限制，最大可设置为无限大，但是受系统配置等其他因素影响。 |
|
| MEMORY MANAGEMENT 内存管理 |
maxmemory | N | maxmemory |
1、将内存使用限制设置为指定的字节数，当内存满了，需要配合maxmemory-policy策略进行处理； 2、注意slave的输出缓冲区是不计算在maxmemory内的，所以为了防止主机内存使用完，建议设置的maxmemory需要更小一些。 |
|
| maxmemory-policy | noeviction | N | volatile-lru,allkeys-lru, volatile-lfu,allkeys-lfu, volatile-random, allkeys-random, volatile-ttl,noeviction |
内存淘汰策略：当达到配置的MAXMEMORY时，Redis将如何选择要删除的内容。您可以在五种行为中进行选择： - volatile-lru：从设置了过期时间的key中驱逐最近最少使用的key； - allkeys-lru：从对所有key中驱逐最近最少使用的key； - volatile-lfu：从所有配置了过期时间的key中驱逐使用频率最少的key； - allkeys-lfu：从所有键中驱逐使用频率最少的key； - volatile-random：从设置了过期时间的key中随机删除； - allkeys-random：从所有key中随机删除； - volatile-ttl：从配置了过期时间的key中驱逐马上就要过期的key； - noeviction：不驱逐key，在写操作中返回错误 ----------------------------------------------- LRU：Least Recently Used 最近最少使用 LFU：Least Frequently Used 最不常用（redis4.0之后新增） |
|
| maxmemory-samples | 5 | N | 1、LRU、LFU和最小TTL算法不是精确算法，而是近似算法（为了节省内存），因此可以调整它的速度或精度。默认情况下，Redis将检查5个键并选择最近使用较少的键，您可以使用以下配置指令更改样本大小； 2、默认值5产生足够好的结果。10非常接近真实的LRU，但需要更多的CPU。3更快，但不太准确。 |
||
| LAZY FREEING 惰性回收/延迟删除 |
lazyfree-lazy-eviction | no | Y | yes,no | 1、redis4之后，新增lazy free特性，使得主动或被动的删除big key时，和一个O(1)指令的耗时一样，亚毫秒级返回； 把真正释放redis元素耗时动作交由bio后台任务非阻塞执行，而传统的DEL、FLUSHDB等命令都是阻塞的； 2、lazy free的使用分为2类：第一类是与DEL命令对应的主动删除，第二类是过期key删除、驱逐淘汰删除； 3、主动删除时使用lazy free，使用命令： - UNLINK：是与DEL一样删除key功能的lazy free实现 - FLUSHALL ASYNC/FLUSHDB ASYNC：redis在清理整个实例或DB时，操作是异步的 4、如果被动删除需要使用lazy free，则结合需求配置接下来几项即可： - lazyfree-lazy-eviction 针对redis内存使用达到maxmeory，并设置有淘汰策略时；在被动淘汰key时，是否采用lazy free机制； 因为此场景开启lazy free, 可能使用淘汰键的内存释放不及时，导致redis内存超用，超过maxmemory的限制。此场景使用时，请结合业务测试。 |
| lazyfree-lazy-expire | no | Y | yes,no | 针对设置有TTL的键，达到过期时间后，被redis清理删除时是否采用lazy free机制。 | |
| lazyfree-lazy-server-del | no | Y | yes,no | 有些指令在处理已存在的键时，会带有一个隐式的 del 键的操作，比如 rename 命令，当目标键已存在，Redis 会先删除目标键，如果这些目标键是一个 big key，就会造成阻塞删除的问题，此配置表示在这种场景中是否开启 lazy free 机制删除。 | |
| slave-lazy-flush | no | Y | yes,no | 针对slave进行全量数据同步，slave 在加载 master 的 RDB 文件前，会运行 flushall 来清理自己的数据，该项设置是否开启 lazy free 机制删除数据。 | |
| APPEND ONLY MODE AOF持久化 |
appendonly | no | Y | yes,no | 1、redis 默认每次更新操作后会在后台异步的把数据库镜像备份到磁盘，但该备份非常耗时，且备份不宜太频繁； 2、redis 同步数据文件是按上面save条件来同步的； 3、如果发生诸如拉闸限电、拔插头等状况,那么将造成比较大范围的数据丢失，所以redis提供了另外一种更加高效的数据库备份及灾难恢复方式； 4、开启append only 模式后,redis 将每一次写操作请求都追加到appendonly.aof 文件中，redis重新启动时,会从该文件恢复出之前的状态； 5、但可能会造成 appendonly.aof 文件过大，所以redis支持BGREWRITEAOF 指令，对appendonly.aof重新整理,默认是不开启的。 |
| appendfilename | appendonly.aof | Y | 指定aof文件名 | ||
| appendfsync | everysec | Y | always,no,everysec | 1、通过调用sync()方法告诉操作系统将数据实际写在磁盘上，不再等待输出缓冲区中的更多数据。 2、有些操作系统确实会刷新磁盘上的数据，而另一些操作系统只会尝试尽快完成该操作。 3、设置对appendonly.aof文件进行同步的频率,有三种选择always、everysec、no，默认是everysec表示每秒同步一次： - always 表示每次有写操作都进行同步，慢，但是最安全 - everysec 表示对写操作进行累积,每秒同步一次，两者之间的妥协 - no 不进行同步，等操作系统进行数据缓存同步到磁盘时再做同步，最快 |
|
| no-appendfsync-on-rewrite | no | Y | yes,no | 1、当AOF的fsync策略设置为always或everysec，并且后台保存进程（后台保存或AOF日志后台重写）对磁盘执行大量I/O时，在某些Linux配置中，Redis可能会在fsyn()调用时在磁盘上阻塞太长时间，目前无法修复这个问题； 2、为了缓解此问题，可以使用以下选项来防止在BGSAVE或BGREWRITEAOF进行时在主进程中调用fsync(); 3、如果该参数设置为no，是最安全的方式，不会丢失数据，但是要忍受阻塞的问题； 4、如果设置为yes，这就相当于将appendfsync设置为no，这说明并没有执行磁盘操作，只是写入了缓冲区，因此这样并不会造成阻塞（因为没有竞争磁盘），但是如果这个时候redis挂掉，就会丢失数据。在linux的操作系统的默认设置下，最多会丢失30s的数据； 5、因此，如果应用系统无法忍受延迟，而可以容忍少量的数据丢失，则设置为yes。如果应用系统无法忍受数据丢失，则设置为no。 |
|
| auto-aof-rewrite-percentage | 100 | Y | 1、当AOF日志大小增加指定的百分比时，Redis可以自动重写日志文件，隐式调用BGREWRITEAOF； 2、它是这样工作的：Redis会在最近一次重写后记住AOF文件的大小（如果自重新启动以来未发生任何重写，则使用启动时AOF的大小）。将此基本大小与当前大小进行比较。 如果当前大小大于指定的百分比，则触发重写； 3、另外，需要指定要重写的AOF文件的最小大小，这对于避免重写AOF文件非常有用，即使达到百分比增加，但它仍然很小； 4、指定零百分比以禁用自动AOF重写功能。 |
||
| auto-aof-rewrite-min-size | 64mb | Y | 1、该项用于设置AOF文件达到指定大小后，后台AOF重写才会执行； 2、AOF重写： - AOF持久化是通过保存被执行的写命令来记录数据库状态的，所以AOF文件的大小随着时间的流逝一定会越来越大；影响包括但不限于：对于Redis服务器，计算机的存储压力；AOF还原出数据库状态的时间增加； 为了解决AOF文件体积膨胀的问题，Redis提供了AOF重写功能：Redis服务器可以创建一个新的AOF文件来替代现有的AOF文件，新旧两个文件所保存的数据库状态是相同的，但是新的AOF文件不会包含任何浪费空间的冗余命令，通常体积会较旧AOF文件小很多。 |
||
| aof-load-truncated | yes | Y | yes,no | 1、当redis启动的时候，AOF文件的数据被载入内存； 2、AOF文件可能在尾部是不完整的：可能发生在redis所在的主机操作系统宕机后，尤其在ext4文件系统没有加上data=ordered选项； 3、如果该选项设置为yes，当截断的aof文件被导入的时候，Redis服务器将开始发出日志来通知用户； 4、如果该选项设置为no，则服务器将中止并显示错误，并拒绝启动，用户必须用redis-check-aof修复AOF文件才可以；默认值为 yes。 |
|
| aof-use-rdb-preamble | no | Y | yes,no | 1、redis4之后新增混合持久化的功能； 2、yes则表示开启，no表示禁用，默认是禁用的； 3、混合持久化同样也是通过BGREWRITEAOF完成的，不同的是当开启混合持久化时，fork出的子进程先将共享的内存副本全量的以RDB方式写入AOF文件，然后再将缓冲区的增量命令以AOF方式写入到文件，写入完成后通知主进程更新统计信息，并将新的含有RDB格式和AOF格式的AOF文件替换旧的的AOF文件。简单的说：新的AOF文件前半段是RDB格式的全量数据后半段是AOF格式的增量数据。 |
|
| LUA SCRIPTING LUA脚本 |
lua-time-limit | 5000 | Y | 1、单位：毫秒；Lua脚本的最大执行时间； 2、如果达到了最大执行时间，Redis将把超过最大限制时间仍在执行的脚本记录在日志中，并以错误答复查询； 3、如果长时间运行的脚本超过了最大执行时间，则只有“ SCRIPT KILL”和“ SHUTDOWN NOSAVE”命令可用； 4、将其设置为0或负值可无警告地无限执行。 |
|
| REDIS CLUSTER 集群 |
cluster-enabled | yes | N | yes,no | 1、普通的Redis实例不能是Redis集群的一部分；只有作为集群节点启动的节点才可以； 2、为了将Redis实例作为群集节点启动，即开启集群模式，将此项设置为"yes"。 |
| cluster-config-file | nodes-6379.conf | N | 1、每个群集节点都有一个群集配置文件，此文件不需要手动编辑，它由Redis节点创建和更新； 2、每个Redis集群节点都需要不同的集群配置文件，请确保在同一系统中运行的实例没有重叠的群集配置文件名。 |
||
| cluster-node-timeout | 15000 | N | 1、单位：毫秒；节点互连超时时间； 2、超过配置的时间，集群节点还连不上，则被判定为节点故障； 3、大多数其他内部时间限制是节点超时的倍数。 |
||
| cluster-slave-validity-factor | 10 | N | 1、设置集群从节点有效因子； 2、在进行故障转移的时候全部slave都会请求申请为master，但是有些slave可能与master断开连接一段时间了导致数据过于陈旧，不应该被提升为master； 3、该参数就是用来判断slave节点与master断线的时间是否过长。判断方法是：比较slave断开连接的时间和(node-timeout * slave-validity-factor)+ repl-ping-slave-period；如果节点超时时间node-timeout为三十秒, 并且slave-validity-factor为10，假设默认的repl-ping-slave-period是10秒，即如果超过310秒，slave将不会尝试进行故障转移，即不会参加master选举。 |
||
| cluster-migration-barrier | 1 | N | 1、设置集群从节点的转移屏障；master的slave数量大于该值，slave才能迁移到其他孤立的master上；（这么做是为了保证集群中没有孤立的主节点，保证容错性） 2、转移屏障为1意味着只有当master至少有一个slave时，slave才会转移，以此类推。它通常反映集群中每个主节点所需的从节点数量； 3、要禁用转移，只需将其设置为一个非常大的值； 4、设置为0，表示没有屏障，但该值仅用于调试和生产中的危险；小于0则启动失败。 |
||
| cluster-require-full-coverage | yes | N | yes,no | 1、设置集群是否需要槽位完全覆盖才能正常使用； 2、建议设置为no，可以在slot没有全部分配的时候提供服务。 |
|
| cluster-slave-no-failover | no | N | yes,no | 1、是否关闭自动故障转移，设置为yes，将不会主动进行故障转移（但是可以手动执行命令进行） 2、故障转移： 与哨兵模式的故障转移类似，都是针对故障主节点的转移，大致流程如下： (1) Redis Cluster通过定时任务进行节点间的通信，当主节点A发现与主节点B的上一次通信时间超过cluster_node_timeout时，会在本地将该B设为主观下线(即将该节点的flags属性修改为CLUSTER_NODE_PFAIL)； (2)当A做出了主观下线的判断后，会通过ping消息将该判断进行扩散； (3) 某个主节点C收到该消息后，会将该判断保存在fail_reports列表中，如果经过cluster_node_timeout*2时间，该列表没有更新，则取消客观下线； (4) 如果收到了quorum个节点的主观下线判断，此时触发客观下线流程。客观下线触发后，会将该节点的flags修改为 CLUSTER_NODE_FAIL ，然后以广播的形式传递FAIL判断，收到判断的节点会在本地标记节点客观下线。需要注意的是，FAIL标记只有在下线节点恢复上线后才能清除，不会像PFAIL那样，超时后自动清除。 (5) 接下来就需要进行从节点的晋升，首先要检查从节点是否足够新，即从节点最后一次和主节点正常数据同步时间是否超过cluster_node_time*cluster_slave_validity_factor，如果超过了，则不允许晋升； (6) 接下来的过程就是从节点的选举流程了，此处省略。 |
|
| CLUSTER DOCKER/NAT support NAT 支持 |
cluster-announce-ip | N | 1、在某些部署中，Redis集群节点地址发现失败，因为地址是NAT-ted或端口是转发的（典型的情况是Docker和其他容器）；为了使Redis集群在这样的环境中工作，需要一个静态配置，使其中每个节点都知道其公共地址； 2、每个节点都指示其地址、客户端端口和群集消息总线端口。然后，信息被发布在总线数据包的报头中，以便其他节点能够正确地映射发布信息的节点的地址； 3、如果不使用上述选项，将使用普通的Redis集群自动检测； 4、请注意，重新映射时，总线端口可能不在客户端端口+10000的固定偏移量处，因此可以根据重新映射的方式指定任何端口和总线端口。如果未设置总线端口，则通常使用10000的固定偏移量。 |
||
| cluster-announce-port | N | ||||
| cluster-announce-bus-port | N | ||||
| SLOW LOG 慢日志 |
slowlog-log-slower-than | 10000 | Y | 1、单位：微秒；设置判定为慢查询的时间阈值； 2、Redis Slow Log记录了超过指定的执行时间的日志记录。包含命令ID、当前时间戳、执行命令、耗时；执行时间不包括与客户机交谈、发送应答等I/O操作，而只是实际执行命令所需的时间； 3、负数将禁用慢日志，而值为零会强制记录每个命令。 |
|
| slowlog-max-len | 128 | Y | 1、设置慢查询日志保存的记录条数； 2、当达到最大长度，记录新命令时，最旧的命令将从记录的命令队列中删除； 3、这个长度没有限制，只是要注意它会消耗内存，可以使用slow log RESET回收慢日志使用的内存。 |
||
| LATENCY MONITOR 延迟监听 |
latency-monitor-threshold | 0 | Y | 1、单位：微秒； 2、Redis延迟监控子系统在运行时对不同的操作进行采样，以便收集与Redis实例的可能延迟源相关的数据； 3、系统只记录在等于或大于配置指令指定的毫秒数的时间内执行的操作，当其值设置为零时，延迟监视器将关闭。 |
|
| EVENT NOTIFICATION 事件通知 |
notify-keyspace-events | "" | Y | 1、Redis可以通过Pub/Sub模式通知客户端key空间中发生的事件； 例如，如果启用了键空间事件通知，并且客户端对存储在数据库0中的键“foo”执行DEL操作， 将通过Pub/Sub发布两条消息： PUBLISH __keyspace@0__:foo del PUBLISH __keyevent@0__:del foo 2、可以在一组类中选择Redis通知的事件。每个类都由一个字符标识： K：键空间通知，所有通知以 __keyspace@ E：键事件通知，所有通知以 __keyevent@ g：DEL 、 EXPIRE 、 RENAME 等类型无关的通用命令的通知 $：字符串命令的通知 l：列表命令的通知 s：集合命令的通知 h：哈希命令的通知 z：有序集合命令的通知 x：过期事件：每当有过期键被删除时发送 e：驱逐(evict)事件：每当有键因为 maxmemory 政策而被删除时发送 A：参数 g$lshzxe 的别名，即包含了以上所有的类型，可以理解为ALL，因此如果设置“AKE”表示所有事件 3、由零个或多个字符组成，根据实际需求组合，注意需要双引号！ 4、空字符串表示通知已禁用，如果未指定K或E中的至少一个，则不会传递任何事件。 |
|
| ADVANCED CONFIG 高级配置 |
hash-max-ziplist-entries | 512 | Y | 1、当哈希有少量的条目，并且最大的条目不超过给定的阈值时，使用内存高效的数据结构对其进行编码。可以使用这两个指令配置这些阈值： 当哈希表的项不超过 hash-max-ziplist-entries，并且每一项的长度不超过 hash-max-ziplist-value 使用 ziplist 保存数据。 |
|
| hash-max-ziplist-value | 64 | Y | |||
| list-max-ziplist-size | -2 | Y | -1,-2,-3,-4,-5,正整数 | 1、Redis 的 List 内部是通过 quicklist 实现的（Redis 3.2 开始使用），quicklist 是一个双向链表。 quicklist 的每个节点都是一个 ziplist。list-max-ziplist-size 就是用于配置 quicklist 中的每个节点的 ziplist 的大小。 2、取负值表示按照占用字节来限定quicklist节点ziplist的长度： -5:最大大小：64 Kb<--不建议用于正常工作负载 -4:最大大小：32 Kb<--不推荐 -3:最大大小：16 Kb<--可能不推荐 -2:最大大小：8 Kb<--良好 -1:最大大小：4 Kb<--良好 3、、取正数意味着每一个列表节点存储的元素数量要精确到这个数量。 |
|
| list-compress-depth | 0 | Y | 非负整数 | quicklist 中的 ziplist 节点会被压缩。为了 push/pop 操作的高效性，quicklist 的头和尾节点永远都不会被压缩。 list-compress-depth 选项用于控制 quicklist 中压缩的节点的深度，下面的示例中加了中括号的节点表示未压缩： - 0 表示不对节点进行压缩，这是默认的值 - 1 表示对头和尾节点外的其他节点进行压缩， [head]->node->node->...->node->[tail] - 2 [head]->[next]->node->node->...->node->[prev]->[tail] - 3 [head]->[next]->[next]->node->node->...->node->[prev]->[prev]->[tail] - 依次类推 |
|
| set-max-intset-entries | 512 | Y | 当 Redis 的集合类型保存的数据均为数字，并且元素个数不超过 set-max-intset-entries 的时候。 Redis 将使用特殊的 intset 结构来保存这个集合。 | ||
| zset-max-ziplist-entries | 128 | Y | 类似哈希表和列表，当排序集合的元素个数不超过 zset-max-ziplist-entries 并且每个元素的长度不超过 zset-max-ziplist-value 时，Redis 将使用 ziplist 保存这个排序集合。 | ||
| zset-max-ziplist-value | 64 | Y | |||
| hll-sparse-max-bytes | 3000 | Y | 1、HyperLogLog稀疏模式的字节限制，包括了 16 字节的头，默认值为 3000。当超出这个限制后HyperLogLog将有稀疏模式转为稠密模式； 2、将这个值设置为超过16000是没必要的，因为这时使用稠密模式更省空间。 |
||
| activerehashing | yes | Y | yes,no | 1、当启用这个功能后，Redis对哈希表的rehash操作会在每100毫秒CPU时间中的1毫秒进行。 Redis的哈希表实现的rehash策略是一个惰性策略：就是说你对这个哈希表进行越多操作，你将有更多的rehash机会， 若你的服务器处于空闲状态则不会有机会完成rehash操作，这时哈希表会占用更多内存； 2、默认情况下会在每一秒中用 10 毫秒来对主哈希表进行 rehash； 3、如果在你的环境中需要有严格的延迟要求，则需要使用将activerehashing配置为no，比如说需要在2毫秒内相应查询操作。 否则你应该将这个选项设置为yes，这样可以更及时地释放空闲的内存。 |
|
| client-output-buffer-limit | normal 0 0 0 | Y | 1、客户端输出缓冲区限制，可用于强制断开从服务器读取数据的速度不够快的客户端 (一个常见的原因是 Pub/Sub 客户端处理发布者的消息不够快) 2、可以为每种客户端设置不同的限制： - normal -> 普通客户端，包括 MONITOR 客户端 - replica -> 复制客户端 - pubsub -> 订阅了至少一个频道的客户端 3、client-output-buffer-limit 选项的语法为： client-output-buffer-limit 4、当一个客户端到达 hard limit 后会马上被断开，或者在到达 soft limit 并持续 soft seconds 秒后会被断开； 5、默认情况下，普通客户端不会有限制，因为除非主动请求否则他们不会收到信息， 只有异步的客户端才可能发生发送请求的速度比读取响应的速度快的情况；pubsub 和 replica 客户端会有默认的限制，因为这些客户端是以 Redis 服务端 push 的方式接收数据的； 6、soft limit 或者 hard limit 都可以设置为 0，这表示不启用此限制。 |
||
| client-output-buffer-limit | slave 256mb 64mb 60 | Y | |||
| client-output-buffer-limit | pubsub 32mb 8mb 60 | Y | |||
| client-query-buffer-limit | 1gb | N | 1、客户端查询缓冲区会累加新的命令。 默认情况下，他们会限制在一个固定的数量避免协议同步失效（比如客户端的 bug）导致查询缓冲区出现未绑定的内存。 2、但是，如果有类似于巨大的 multi/exec 请求的时候可以修改这个值以满足你的特殊需求。 |
||
| proto-max-bulk-len | 512mb | N | 在 Redis 协议中，批量请求通常限制在 512 mb 内，可以通过修改 proto-max-bulk-len 选项改变这个限制。 | ||
| hz | 10 | Y | 1～500 | 1、Redis 会通过调用内部函数来完成很多后台任务，比如关闭超时的客户端的连接，清除过期的 key，等等； 2、Redis 通过 hz 设置的值来决定执行这些任务的频繁程度； 3、可以通过提高这个值来使得 CPU 在空闲的时候使用更多的 CPU 时间来处理后台任务。 但同时这会使得当有很多 key 在同一时间过期时，过期处理会更精确； 4、超过 100 一般都不是一个好主意，很多客户只有在一些需要很低延迟的环境中才会将这个值从 10 提升到 100。 |
|
| aof-rewrite-incremental-fsync | yes | Y | yes,no | 当子进程进行 AOF 的重写时，如果启用了 aof-rewrite-incremental-fsync， 子进程会每生成 32 MB 数据就进行一次 fsync 操作。 通过这种方式将数据分批提交到硬盘可以避免高延迟峰值。 | |
| lfu-log-factor | 10 | N | 1、Redis LFU 回收策略（忘了的话可以回顾下 maxmemory 选项）是可以调整的； 2、Redis 的 LFU 实现目前有两个可调整的参数：计数器对数因子（couter logarithm factor） 和 计数器衰退时间（counter decay time）； 3、每个 key 的 LFU 计数器只有 8 bits，也就是说最大值为 255,因此 Redis 通过对数行为来对计数进行概率性的增加。 当一个 key 被访问后，计数器通过如下方式进行增加（假设计数器的旧值为 old_value）： 1）取出一个 0 到 1 之间的随机数 R 2）通过如下方式算出概率 P: 1 / (old_value * lfu_log_factor + 1) 3）只有当 R < P 时，才增加计数器 4、lfu-log-factor 的默认值为 10； 5、计数器衰减时间是 key 计数器除以 2 (如果值小于 <= 10，则递减)所必须经过的时间； 6、 lfu-decay-time 的默认值为 1， 0 表示每次都对计数器进行衰减，单位为分钟。 -------------------------------- 简单来说通过key的计数器判断是否需要被驱逐，而key的计数器由这两个参数计算得到 |
||
| lfu-decay-time | 1 | N | |||
| ACTIVE DEFRAGMENTATION 活动碎片整理 |
activedefrag | yes | N | yes,no | 设置是否开启活动碎片整理功能 警告：这个功能是实验性的。当然此功能已经在包括生产环境在内的环境中通过压力测试。 并且被多名工程师手工测过一段时间 1、活动碎片整理允许 Redis 服务器压缩内存中由于申请和释放数据块导致的碎片，从而回收内存； 2、碎片是每次申请内存的时候会自然发生的。 通常来说，为了降低碎片化程度需要重启服务，或者至少需要清除所有的数据然后重新创建； 3、得益于 Oran Agra 在 Redis 4.0 实现的这个特性，进程可以在服务运行时以“热”方式完成这些目的； 4、通常来说当碎片化达到一定程度（查看下面的配置）Redis 会使用 Jemalloc 的特性创建连续的内存空间， 并在此内存空间对现有的值进行拷贝，拷贝完成后会释放掉旧的数据。 这个过程会对所有的导致碎片化的 key 以增量的形式进行。 5、需要重点理解的是： - 这个特性默认是关闭的，并且只有在编译 Redis 时使用我们代码中的 Jemalloc 版本才生效。（这是 Linux 下的默认行为） - 如果没有碎片问题，你永远不需要启用这项特性 - 如果你需要试验这项特性，可以通过命令 CONFIG SET activefrag yes 来启用 - 相关的配置参数可以很好的调整碎片整理过程。如果你不知道这些选项的作用最好使用默认值。 |
| active-defrag-ignore-bytes | 100mb | N | 有至少多少碎片时才开始碎片整理。 | ||
| active-defrag-threshold-lower | 10 | N | 启动活动碎片整理的最小碎片百分比 | ||
| active-defrag-threshold-upper | 100 | N | 使用最大努力进行碎片整理的百分比（占用更多的cpu时间） | ||
| active-defrag-cycle-min | 25 | N | 进行碎片整理时至少使用多少比例的 CPU 时间 | ||
| active-defrag-cycle-max | 75 | N | 进行碎片整理时至少使用多少比例的 CPU 时间 |
如果内容对您有所帮助，欢迎打赏哦～
