最近刚好学习用ansible脚本来多实例部署redis集群，也顺便学习了一下redis的部署。
学习过程中发现，redis部署挺容易，但是配置还真是不少，这里我就花点儿时间把redis.conf中所有的配置和应用方式详细记录一下，作为学习笔记，同时如果刚好哪只小猿觉得有用的话，望不吝点赞。
redis.conf
配置名称 | 描述 | 默认值 |
port | 服访问端口 |
|
requirepass | 登录密码 |
|
loglevel | 日志级别,合法值: debug/verbose/notice/warning， 默认为notice | debug/verbose/notice/warning |
logfile | 服务日志输出文件 | "" |
pidfile | 进程文件 | /var/run/redis_6379.pid |
dir | 数据文件保存目录：rdb文件和nodes文件都会保存在该目录下 |
|
dbfilename | 数据持久化文件（rdb文件），只要指定文件名，会保存到dir目录中 |
|
daemonize | 当前redis服务进程是否在后台运行：后台运行：yes，无需后台运行：no； 当redis作为后台进程运行的时候，它会写一个 *.pid文件 |
|
protected-mode | 开启保护模式：yes/no，开启该参数后，redis只会本地进行访问， 拒绝外部访问。要是开启了密码和bind，可以开启。否则最好关闭，设置为no |
|
bind | bind <ip>：指定 redis 只接收来自于该IP地址的请求，如果不进行设置，那么将处理所有请求 |
|
slaveof | slaveof <master ip> <master port>: 将当前server做为slave,并为其指定master信息 |
|
masterauth | 隶属主节点的密码：当配置了slaveof后，如果隶属的master有密码，则要填写该值。 |
|
slave-serve-stale-data | 如果当前server是slave,那么当slave与master失去通讯时,是否继续为客户端提供服务,”yes”表示继续,”no”表示终止 |
|
timeout | 客户端空闲时间：超过配置值，服务端会断开连接，为0则服务端不会主动断开连接，不能小于0 |
|
tcp-backlog | TCP监听的最大容纳数量，在高并发的环境下，你需要把这个值调高以避免客户端连接缓慢的问题。Linux 内核会把这个值缩小成 /proc/sys/net/core /somaxconn对应的值，要提升并发量需要修改这两个值才能达到目的 |
|
tcp-keepalive | 指定TCP连接是否为长连接,”侦探”信号由server端维护,长连接将会额外的增加server端的开支 |
|
supervised | 可以通过upstart和systemd管理Redis守护进程 选项： supervised no - 没有监督互动； supervised upstart - 通过将Redis置于SIGSTOP模式来启动信号； supervised systemd - signal systemd将READY = 1写入$ NOTIFY_SOCKET； supervised auto - 检测upstart或systemd方法基于 UPSTART_JOB或NOTIFY_SOCKET环境变量。 |
|
databases | 设定redis所允许的最大”db簇”的个数,默认为16个簇 |
|
always-show-logo | 是否显示logo |
|
save | 在多少秒期间至少多少个变更操作”触发snapshot，snapshot最终将生成新的dump.rdb文件 |
|
rdbcompression | 是否在 dump*.rdb 数据库的时候使用 LZF 压缩字符串，默认都设为yes，如果想节省性能，可以设为no |
|
rdbchecksum | 是否校验rdb文件：yes/no |
|
appendonly | 是否在每次更新操作后进行日志记录，如果不开启，可能会在断电时导致一段时间内的数据丢失。因为redis本身同步数据文件是按上面save条件来同步的，所以有的数据会在一段时间内只存在于内存中，默认值为no |
|
appendfilename | 更新的日志文件名：默认设为 appendfilename "appendonly.aof" |
|
appendfsync | 指定更新日志条件：always/everysec/no，该值是对redis性能有重要影响的参数之一 |
|
no-appendfsync-on-rewrite | 不进行更新日志重写：yes/no，如果应用系统无法忍受延迟，而可以容忍少量的数据丢失，则设置为yes。如果应用系统无法忍受数据丢失，则设置为no |
|
stop-writes-on-bgsave-error | 持久化存储发生错误后是否停止接受写请求：默认情况下如果上面配置的rdb模式开启且最后一次的保存失败，redis 将停止接受写操作，让用户知道问题的发生。如果后台保存进程重新启动工作了，redis 也将自动的允许写操作，如果有其它监控方式也可关闭。 |
|
replica-serve-stale-data | 默认yes，当从节点和主节点的连接断开或者复制正在进行中，设置yes,那么继续提供服务，设置no,那么返回sync with master in progress。 |
|
replica-read-only | 从节点是否只读标识，配置值：yes/no |
|
repl-diskless-sync | 主从数据复制是否使用无硬盘复制功能，新的丛从节点和重连后不能继续备份的丛从节点，需要做所谓的“完全备份”，即将一个rdb文件从主节点传送到丛从节点。这种传送方式有两种：硬盘备份和无硬盘备份。 |
|
repl-diskless-sync-delay | 当启用无硬盘备份时，服务器等待一段时间后才会通过套接字向丛从节点传送rdb文件，这个等待时间是可配置的。延迟时间以秒为单位，默认为5秒。要关掉这一功能，只需将它设置为0秒，传送会立即启动。 |
|
repl-ping-replica-period | 从redis会周期性的向主redis发出PING包，你可以通过repl_ping_slave _period指令来控制其周期，默认是10秒。 |
|
repl-timeout | 接下来的选项为以下内容设置备份的超时时间： 1）从丛从节点的角度，同步期间的批量传输的I/O 2）丛从节点角度认为的主节点超时（数据，ping） 3）主节点角度认为的丛从节点超时（REPLCONF ACK pings) 确认这些值比定义的repl-ping-slave-period要大，否则每次主节点和丛从节点之间通信低速时都会被检测为超时。 |
|
repl-disable-tcp-nodelay | 同步之后是否禁用丛从节点上的TCP_NODELAY 如果你选择yes，redis会使用较少量的TCP包和带宽向丛从节点发送数据。但这会导致在丛从节点增加一点数据的延时。 如果选择no，丛从节点的数据延时不会那么多，但备份需要的带宽相对较多。 |
|
repl-backlog-size | 设置备份的工作储备大小。工作储备是一个缓冲区，当丛从节点断开一段时间的情况时，它替丛从节点接收存储数据，因此当丛从节点重连时，通常不需要完全备份，只需要一个部分同步就可以，即把丛从节点断开时错过的一部分数据接收。 工作储备越大，丛从节点可以断开并稍后执行部分同步的断开时间就越长。只要有一个丛从节点连接，就会立刻分配一个工作储备。 |
|
repl-backlog-ttl | 主节点有一段时间没有与丛从节点连接，对应的工作储备就会自动释放。 这个选项用于配置释放前等待的秒数，秒数从断开的那一刻开始计算，值为0表示不释放。 |
|
replica-priority | 丛从节点优先级是可以从redis的INFO命令输出中查到的一个整数。当主节点不能正常工作时，redis sentinel使用它来选择一个丛从节点并将它提升为主节点。 低优先级的丛从节点被认为更适合于提升，因此如果有三个丛从节点优先级分别是10/100/25，sentinel会选择优先级为10的丛从节点，因为它的优先级最低。 然而优先级值为0的丛从节点不能执行主节点的角色，因此优先级为0的丛从节点永远不会被redis sentinel提升。默认优先级是100。 |
|
min-replicas-to-write | redis提供了可以让master停止写入的方式，如果配置了min-replicas-to-write，健康的slave的个数小于N，mater就禁止写入。master最少得有多少个健康的slave存活才能执行写命令。这个配置虽然不能保证N个slave都一定能接收到master的写操作，但是能避免没有足够健康的slave的时候，master不能写入来避免数据丢失。设置为0是关闭该功能。 |
|
min-replicas-max-lag | 从节点健康延迟时间：延迟小于该值的从节点判断为是健康的。 |
|
replica-announce-ip | 从节点上报给master的自己ip,防止nat问题。 |
|
replica-announce-port | 从节点上报给master的自己port,防止nat问题。 |
|
lazyfree-lazy-eviction | 默认no,那么redis是同步释放内存,也就是停止完成其他请求来做释放内存操作,如果遇到key复杂度很大时(0(n))的会增加请求延时，如果yes,那么则先删除dict中的key,然后把释放内存的任务提交给后台线程做。 |
|
lazyfree-lazy-expire | 默认no,那么redis是同步删除过期key,也就是停止完成其他请求来做删除过期key,如果遇到key复杂度很大时(0(n))的会增加请求延时，如果yes,把删除key的任务提交给后台线程做。 |
|
lazyfree-lazy-server-del | 默认no,那么redis是同步删除key,也就是停止完成其他请求来做删除key,如果遇到key复杂度很大时(0(n))的会增加请求延时，如果yes,那么则先删除dict中的key,然后把删除key的任务提交给后台线程做(如果key很小则暂时不删除,只是减少了引用)。 |
|
replica-lazy-flush | 默认no,那么redis是同步清空数据库,也就是停止完成其他请求来做清空数据库,如果遇到数据库很大会增加请求延时，如果yes,那么则新建dict等数据结构,然后把清空数据库提交给后台线程做。 |
|
auto-aof-rewrite-percentage | 自动重写AOF文件。如果AOF日志文件增大到指定百分比，Redis能够通过 BGREWRITEAOF 自动重写AOF日志文件。工作原理：Redis记住上次重写时AOF文件的大小（如果重启后还没有写操作，就直接用启动时的AOF大小）这个基准大小和当前大小做比较。如果当前大小超过指定比例，就会触发重写操作。你还需要指定被重写日志的最小尺寸，这样避免了达到指定百分比但尺寸仍然很小的情况还要重写，指定百分比为0会禁用AOF自动重写特性。 |
|
auto-aof-rewrite-min-size | （同上） |
|
aof-load-truncated | 如果设置为yes，如果一个因异常被截断的AOF文件被redis启动时加载进内存，redis将会发送日志通知用户。如果设置为no，erdis将会拒绝启动。此时需要用"redis-check-aof"工具修复文件。 |
|
aof-use-rdb-preamble | aof前部分用rdb,后面保存时缓存的命令还是用aof格式，优点:保存和恢复更快，设置yes开启，配置值：yes/no。 |
|
lua-time-limit | Lua 脚本的最大执行时间，毫秒为单位 |
|
slowlog-log-slower-than | slog log是用来记录redis运行中执行比较慢的命令耗时。当命令的执行超过了指定时间，就记录在slow log中，slog log保存在内存中，所以没有IO操作。执行时间比slowlog-log-slower-than大的请求记录到slowlog里面，单位是微秒，所以1000000就是1秒。 注意，负数时间会禁用慢查询日志，而0则会强制记录所有命令。 |
|
slowlog-max-len | 慢查询日志长度。当一个新的命令被写进日志的时候，最老的那个记录会被删掉，这个长度没有限制。 只要有足够的内存就行，你可以通过 SLOWLOG RESET 来释放内存。 |
|
latency-monitor-threshold | 延迟监控功能是用来监控redis中执行比较缓慢的一些操作，用LATENCY打印redis实例在跑命令时的耗时图表。 只记录大于等于下边设置的值的操作，0的话，就是关闭监视。 默认延迟监控功能是关闭的，如果你需要打开，也可以通过CONFIG SET命令动态设置。 |
|
notify-keyspace-events | 默认值为""（空字符串），键空间通知使得客户端可以通过订阅频道或模式，来接收那些以某种方式改动了 Redis 数据集的事件。因为开启键空间通知功能需要消耗一些 CPU ，所以在默认配置下，该功能处于关闭状态。 |
|
hash-max-ziplist-entries | hash类型的数据结构在编码上可以使用ziplist和hashtable。 ziplist的特点就是文件存储(以及内存存储)所需的空间较小,在内容较小时,性能和hashtable几乎一样。 因此redis对hash类型默认采取ziplist。如果hash中条目的条目个数或者value长度达到阀值,将会被重构为hashtable。 这个参数指的是ziplist中允许存储的最大条目个数，，默认为512，建议为128。 |
|
hash-max-ziplist-value | ziplist中允许条目value值最大字节数，默认为64，建议为1024。 |
|
list-max-ziplist-size | 当取正值的时候，表示按照数据项个数来限定每个quicklist节点上的ziplist长度。比如，当这个参数配置成5的时候，表示每个quicklist节点的ziplist最多包含5个数据项。 当取负值的时候，表示按照占用字节数来限定每个quicklist节点上的ziplist长度。这时，它只能取-1到-5这五个值，每个值含义如下： -5:每个quicklist节点上的ziplist大小不能超过64 Kb。（注：1kb => 1024 bytes） -4:每个quicklist节点上的ziplist大小不能超过32 Kb。 -3:每个quicklist节点上的ziplist大小不能超过16 Kb。 -2:每个quicklist节点上的ziplist大小不能超过8 Kb。（-2是Redis给出的默认值） -1:每个quicklist节点上的ziplist大小不能超过4 Kb。 |
|
list-compress-depth | 这个参数表示一个quicklist两端不被压缩的节点个数。 参数list-compress-depth的取值含义如下： 0:是个特殊值，表示都不压缩。这是Redis的默认值。 1:表示quicklist两端各有1个节点不压缩，中间的节点压缩。 2:表示quicklist两端各有2个节点不压缩，中间的节点压缩。 3:表示quicklist两端各有3个节点不压缩，中间的节点压缩。 依此类推… 由于0是个特殊值，很容易看出quicklist的头节点和尾节点是不被压缩的，便于在表的两端进行快速存取。 |
|
set-max-intset-entries | 数据量小于等于set-max-intset-entries用intset，大于set-max-intset-entries用set。 |
|
zset-max-ziplist-entries | 数据量小于等于zset-max-ziplist-entries用ziplist，大于zset-max-ziplist-entries用zset。 |
|
zset-max-ziplist-value | 每个entry值的长度不大于N个字节。 |
|
hll-sparse-max-bytes | value大小小于等于hll-sparse-max-bytes使用稀疏数据结构（sparse） 大于hll-sparse-max-bytes使用稠密的数据结构（dense），一个比16000大的value是几乎没用的， 建议的value大概为3000。如果对CPU要求不高，对空间要求较高的，建议设置到10000左右。 |
|
stream-node-max-bytes | stream 的最大内存开销字节数。 |
|
stream-node-max-entries | stream 的最大项数量。 |
|
activerehashing | 是否重置Hash表，设置成yes后redis将每100毫秒使用1毫秒CPU时间来对redis的hash表重新hash，可降低内存的使用。 当你的使用场景中，有非常严格的实时性需要，不能够接受Redis时不时的对请求有2毫秒的延迟的话，把这项配置为no。 如果没有这么严格的实时性要求，可以设置为yes，以便能够尽可能快的释放内存。 |
|
hz | redis执行任务的频率为1s除以hz。 |
|
dynamic-hz | 是否开启动态hz，配置值：yes/no。 |
|
aof-rewrite-incremental-fsync | 在aof重写的时候，如果打开了aof-rewrite-incremental-fsync开关，系统会每32MB执行一次fsync，这对于把文件写入磁盘是有帮助的，可以避免过大的延迟峰值。 |
|
rdb-save-incremental-fsync | 设置yes,则每32mb 执行fsync一次(增量式,避免一次性大写入导致的延时)，设置no,则一次性fsync。 |
|
client-output-buffer-limit | 客户端输出缓存限制强迫断开读取速度比较慢的客户端的条件，client-output-buffer-limit <类别> <强制限制> <软性限制> <软性时间>：达到强制限制缓存大小，立刻断开链接， 达到软性限制，仍然会有软性时间大小的链接时间， 默认正常客户端无限制，只有请求后，异步客户端数据请求速度快于它能读取数据的速度， 订阅模式和主从客户端又默认限制，因为它们都接受推送。 强制限制和软性限制都可以设置为0来禁用这个特性。 |
|
maxclients | 客户端链接的最大数量 |
|
maxmemory | 最大内存容量 |
|
maxmemory-policy | 内存超出后的处理策略 volatile-lru：利用LRU算法移除设置过过期时间的key; volatile-random：随机移除设置过过期时间的key; volatile-ttl：移除即将过期的key，根据最近过期时间来删除（辅以TTL）; allkeys-lru：利用LRU算法移除任何key; allkeys-random：随机移除任何key; noeviction（默认）：不移除任何key，只是返回一个写错误。 |
|
maxmemory-samples | lru检测的样本数。使用lru或者ttl淘汰算法，从需要淘汰的列表中随机选择sample个key，选出闲置时间最长的key移除。 |
|
syslog-enabled | 输入值：yes/no，默认为no，如果设置成yes，会将日志输出到系统日志 |
|
syslog-ident | 指定syslog的标识符 |
|
syslog-facility | 指定syslog 设备（facility), 必须是user或者local0到locatl7。 |
|
# 集群配置 |
|
|
cluster-enabled | 集群模式开关：yes/no |
|
cluster-config-file | 集群配置文件名：每个节点都有一个集群相关的配置文件，持久化保存集群的信息。这个文件并不需要手动配置，这个配置文件有Redis生成并更新，每个Redis集群节点需要一个单独的配置文件，请确保与实例运行的系统中配置文件名称不冲突。 |
|
cluster-node-timeout | 节点互连超时阈值，集群节点超时毫秒数 |
|
cluster-replica-validity-factor | 在进行故障转移的时候，全部slave都会请求申请为master，但是有些slave可能与master断开连接一段时间了，导致数据过于陈旧，这样的slave不应该被提升为master。该参数就是用来判断slave节点与master断线的时间是否过长。 |
|
cluster-migration-barrier | master的slave数量大于该值，slave才能迁移到其他孤立master上，如这个参数若被设为2，那么只有当一个主节点拥有2个可工作的从节点时，它的一个从节点会尝试迁移。 |
|
cluster-require-full-coverage | 默认情况下，集群全部的slot有节点负责，集群状态才为ok，才能提供服务。设置为no，可以在slot没有全部分配的时候提供服务。不建议打开该配置，这样会造成分区的时候，小分区的master一直在接受写请求，而造成很长时间数据不一致。 |
|
cluster-replica-no-failover | 在主节点失效期间,从节点不允许对master失效转移，配置值：yes/no |
|
cluster-announce-ip | 集群的节点的汇报ip，防止nat问题。 |
|
cluster-announce-port | 集群的节点的汇报port，防止nat问题。 |
|
cluster-announce-bus-port | 集群的节点的汇报bus-port，防止nat。 |
|
| | |
