Redis3.2.2–配置文件参数解释

共计 9288 个字符，预计需要花费 24 分钟才能阅读完成。

Redis 的配置文件

redis 的默认配置文件在 redis 目录下，有个叫 redis.conf 的文件。

用配置文件启动 redis 命令为：

src/redis-server redis.conf

Redis 支持的参数：

 1k => 1000 bytes
 1kb => 1024 bytes
 1m => 1000000 bytes
 1mb => 1024*1024 bytes
 1g => 1000000000 bytes
 1gb => 1024*1024*1024 bytes

这里可以指定内存的大小

bind 127.0.0.1

这里可以绑定监听一个或多个 IP 地址。如果注释掉，将处理所有的请求，生产环境就注释掉。

protected-mode yes

这个参数是 3.2 才新有的，保护模式，默认开启，如果你确定你想要从其它的主机获取 redis 的监听，那么你就设为 NO. 需要你将配置 bind。

port 6379

这里是监听端口，默认 6379.

tcp-backlog 511

TCP 监听的最大数，这里需要注意，如果链接过多，需要调整的话，同时需要调整 /proc/sys/net/core/somaxconn 下的配置，否则 linux 下会默认使用此配置调正到最低。

timeout 0

设置客户端的超时时间，单位为秒，如果客户端在此时间内没有发出新的请求，就关闭连接。默认为 0 就是不管它。

tcp-keepalive 300

TCP 检测，也就是说每过 300 秒检测一次客户端是否还有效，避免服务器长时间阻塞。

daemonize no

默认情况，redis 服务不在后台开启，设为 yes，则在后台以守护进程形式运行。

supervised no

可以通过 upstart 和 systemd 管理 Redis 守护进程，这个参数是和具体的操作系统相关的。

pidfile /var/run/redis_6379.pid

当 Redis 在后台运行的时候，Redis 默认会把 pid（redis 进程号）文件放在 /var/run/redis.pid，你可以配置到其他地址。当运行多个 redis 服务时，需要指定不同的 pid 文件和端口。

loglevel notice

日志：Redis 总共支持四个级别：debug、verbose、notice、warning。
Debug：记录很多信息，用于开发和测试；
Varbose：有用的信息，不像 debug 会记录那么多；
Notice：普通的 verbose，常用于生产环境；
Warning：只有非常重要或者严重的信息会记录到日志；
默认是 notice 级别。

logfile ""

log 的存放地址，默认为“”就是输出到控制台。

databases 16

可用的数据库数量，默认为 16 个。可以使用 SELECT 命令来切换数据库。默认使用的数据库是 0。

save 900 1
save 300 10
save 60 10000

设置 Redis 进行数据库镜像的频率：
900 秒后如果至少有 1 个 key 的值变化，则保存
300 秒后如果至少有 10 个 key 的值变化，则保存
60 秒后如果至少有 10000 个 key 的值变化，则保存

stop-writes-on-bgsave-error yes

当持久化出现错误之后，是否继续提供写服务.

rdbcompression yes

数据持久化的时候，是否压缩。

rdbchecksum yes

读取和写入的时候是否支持 CRC64 校验，默认是开启的.

dbfilename dump.rdb

镜像备份文件的文件名。

dir ./

数据库镜像备份的文件放置的路径。这里的路径跟文件名要分开配置是因为 Redis 在进行备份时，先会将当前数据库的状态写入到一个临时文件中，等备份完成时，再把该该临时文件替换为上面所指定的文件，而这里的临时文件和上面所配置的备份文件都会放在这个指定的路径当中。

slaveof <masterip> <masterport>
masterauth <master-password>
slave-serve-stale-data yes

设置该数据库为其他数据库的从数据库。
如果需要密码验证则设置密码。
当 slave 服务器和 master 服务器失去连接后，或者当数据正在复制传输的时候，如果此参数值设置“yes”，slave 服务器可以继续接受客户端的请求，否则，会返回给请求的客户端如下信息“SYNC with master in progress”。

slave-read-only yes

是否允许 slave 服务器节点只提供读服务。

repl-diskless-sync no
repl-diskless-sync-delay 5
repl-ping-slave-period 10
repl-timeout 60

主从同步支持两种策略，即 disk 和 socket 方式（socket 方式尚不完善，还处于实验阶段）。
新的 slave 端和重连的 salve 端不允许去继续同步进程，这被称之为“完全同步”。
一个 RDB 文件从 master 端传到 slave 端，分为两种情况：
1、支持 disk：master 端将 RDB file 写到 disk，稍后再传送到 slave 端；
2、无磁盘 diskless：master 端直接将 RDB file 传到 slave socket，不需要与 disk 进行交互。
无磁盘 diskless 方式适合磁盘读写速度慢但网络带宽非常高的环境。

默认不使用 diskless 同步方式 .
无磁盘 diskless 方式在进行数据传递之前会有一个时间的延迟，以便 slave 端能够进行到待传送的目标队列中，这个时间默认是 5 秒.
slave 端向 server 端发送 pings 的时间区间设置，默认为 10 秒。
设置超时时间。

repl-disable-tcp-nodelay no

指定向 slave 同步数据时，是否禁用 socket 的 NO_DELAY 选项。若配置为“yes”，则禁用 NO_DELAY，则 TCP 协议栈会合并小包统一发送，这样可以减少主从节点间的包数量并节省带宽，但会增加数据同步到 slave 的时间。若配置为“no”，表明启用 NO_DELAY，则 TCP 协议栈不会延迟小包的发送时机，这样数据同步的延时会减少，但需要更大的带宽。通常情况下，应该配置为 no 以降低同步延时，但在主从节点间网络负载已经很高的情况下，可以配置为 yes。

repl-backlog-size 1mb
repl-backlog-ttl 3600

设置 backlog 的大小，backlog 是一个缓冲区，在 slave 端失连时存放要同步到 slave 的数据，因此当一个 slave 要重连时，经常是不需要完全同步的，执行局部同步就足够了。backlog 设置的越大，slave 可以失连的时间就越长。
如果一段时间后没有 slave 连接到 master，则 backlog size 的内存将会被释放。如果值为 0 则表示永远不释放这部份内存。

slave-priority 100
min-slaves-to-write 3
min-slaves-max-lag 10

当 master 不能正常工作的时候，Redis Sentinel 会从 slaves 中选出一个新的 master，这个值越小，就越会被优先选中，但是如果是 0，那是意味着这个 slave 不可能被选中。
设置当一个 master 端的可用 slave 少于 N 个，延迟时间大于 M 秒时，不接收写操作。

maxclients 10000
maxmemory <bytes>
maxmemory-policy volatile-lru

限制同时连接的客户数量。当连接数超过这个值时，redis 将不再接收其他连接请求，客户端尝试连接时将收到 error 信息。默认为 10000，要考虑系统文件描述符限制，不宜过大，浪费文件描述符，具体多少根据具体情况而定。

redis-cache 所能使用的最大内存 (bytes), 默认为 0, 表示”无限制”, 最终由 OS 物理内存大小决定(如果物理内存不足, 有可能会使用 swap)。此值尽量不要超过机器的物理内存尺寸, 从性能和实施的角度考虑, 可以为物理内存 3 /4。此配置需要和”maxmemory-policy”配合使用, 当 redis 中内存数据达到 maxmemory 时, 触发”清除策略”。在”内存不足”时, 任何 write 操作(比如 set,lpush 等) 都会触发”清除策略”的执行。在实际环境中, 建议 redis 的所有物理机器的硬件配置保持一致 (内存一致), 同时确保 master/slave 中”maxmemory”“policy”配置一致。
当内存满了的时候，如果还接收到 set 命令，redis 将先尝试剔除设置过 expire 信息的 key，而不管该 key 的过期时间还没有到达。在删除时，
将按照过期时间进行删除，最早将要被过期的 key 将最先被删除。如果带有 expire 信息的 key 都删光了，内存还不够用，那么将返回错误。这样，redis 将不再接收写请求，只接收 get 请求。maxmemory 的设置比较适合于把 redis 当作于类似 memcached 的缓存来使用。

最大内存策略，你有 5 个选择：

volatile-lru -> 使用 LRU 算法移除包含过期设置的 key。
noeviction -> 不让任何 key 过期，只是给写入操作返回一个错误。
allkeys-lru -> 根据 LRU 算法移除所有的 key。
volatile-random -> 对”过期集合”中的数据采取”随即选取”算法, 并移除选中的 K -V, 直到”内存足够”为止. 如果如果”过期集合”中全部移除全部移除仍不能满足, 将 OOM
allkeys-random -> 对所有的数据, 采取”随机选取”算法, 并移除选中的 K -V, 直到”内存足够”为止
volatile-ttl -> 对”过期集合”中的数据采取 TTL 算法(最小存活时间), 移除即将过期的数据.

maxmemory-samples 5

默认值 5，上面 LRU 和最小 TTL 策略并非严谨的策略，而是大约估算的方式，因此可以选择取样值以便检查。

appendonly no

默认情况下，redis 会在后台异步的把数据库镜像备份到磁盘，但是该备份是非常耗时的，而且备份也不能很频繁。所以 redis 提供了另外一种更加高效的数据库备份及灾难恢复方式。开启 append only 模式之后，redis 会把所接收到的每一次写操作请求都追加到 appendonly.aof 文件中，当 redis 重新启动时，会从该文件恢复出之前的状态。但是这样会造成 appendonly.aof 文件过大，所以 redis 还支持了 BGREWRITEAOF 指令，对 appendonly.aof 进行重新整理。如果不经常进行数据迁移操作，推荐生产环境下的做法为关闭镜像，开启 appendonly.aof，同时可以选择在访问较少的时间每天对 appendonly.aof 进行重写一次。
另外，对 master 机器, 主要负责写，建议使用 AOF, 对于 slave, 主要负责读，挑选出 1 - 2 台开启 AOF，其余的建议关闭。

appendfilename "appendonly.aof"

aof 文件名字，默认为 appendonly.aof。

# appendfsync always
appendfsync everysec
# appendfsync no

设置对 appendonly.aof 文件进行同步的频率。always 表示每次有写操作都进行同步，everysec 表示对写操作进行累积，每秒同步一次。no 不主动 fsync，由 OS 自己来完成。这个需要根据实际业务场景进行配置。

no-appendfsync-on-rewrite no

在 aof rewrite 期间, 是否对 aof 新记录的 append 暂缓使用文件同步策略, 主要考虑磁盘 IO 开支和请求阻塞时间。默认为 no, 表示”不暂缓”, 新的 aof 记录仍然会被立即同步。

auto-aof-rewrite-percentage 100

当 Aof log 增长超过指定比例时，重写 log file，设置为 0 表示不自动重写 Aof 日志，重写是为了使 aof 体积保持最小，而确保保存最完整的数据。

auto-aof-rewrite-min-size 64mb

触发 aof rewrite 的最小文件尺寸。

aof-load-truncated yes

: redis 在启动的时候可以加载被截断的 AOF 文件，默认启用。

lua-time-limit 5000

lua 脚本运行的最大时间。

cluster-enabled yes

配置 redis 做为一个集群节点来启动。

cluster-config-file node-6379.conf

每个集群节点都有一个集群配置文件，这个文件不需要编辑，它由 redis 节点来创建和更新。每个 redis 节点的集群配置文件不可以相同。

cluster-node-timeout 15000

设置集群节点超时时间，如果超过了指定的超时时间后仍不可达，则节点被认为是失败状态，单位为毫秒。
一个属于失效的 master 端的 slave，如果它的数据较旧，将不会启动 failover。
现在来讲并没有一个简单的方法去解决如何判定一个 slave 端的数据的时效性问题，所以可以执行以下两个选择：
1、如果有多个 slave 可用于 failover，它们会交换信息以便选出一个最优的进行主从复制的 offset，slave 端会尝试依据 offset 去获取每个 slave 的 rank，这样在启动 failover 时对每个 slave 的利用就与 slave 端的 rank 成正比。
2、每个 slave 端和它的 master 端进行最后交互的时间，这可能是最近的 ping 或指令接收时间，或自与 master 端失连的过时时间。如果最近的交互时间太久，slave 就不会尝试去进行 failover。
第 2 点可以由用户来进行调整，明确一个 slave 不会进行 failover。自最近一次与 master 端进行交互，过时时间有一个计算公式：

（node-timeout * slave-validity-factor）+repl-ping-slave-period

一个比较大的 slave-validity-factor 参数能够允许 slave 端使用比较旧的数据去 failover 它的 master 端，而一个比较小的值可能会阻止集群去选择 slave 端。
为获得最大的可用性，可以设置 slave-validity-factor 的值为 0，这表示 slave 端将会一直去尝试 failover 它的 master 端而不管它与 master 端的最后交互时间。

cluster-slave-validity-factor 10

集群中的 slave 可以迁移到那些没有可用 slave 的 master 端，这提升了集群处理故障的能力。毕竟一个没有 slave 的 master 端如果发生了故障是没有办法去进行 failover 的。
要将一个 slave 迁移到别的 master，必须这个 slave 的原 master 端有至少给定数目的可用 slave 才可以进行迁移，这个给定的数目由 migration barrier 参数来进行设置，默认值为 1，表示这个要进行迁移的 slave 的原 master 端应该至少还有 1 个可用的 slave 才允许其进行迁移，要禁用这个功能只需要将此参数设置为一个非常大的值。

cluster-migration-barrier 1

默认情况下当 redis 集群节点发现有至少一个 hashslot 未被 covered 时将会停止接收查询。
这种情况下如果有一部份的集群 down 掉了，那整个集群将变得不可用。
集群将会在所有的 slot 重新 covered 之后自动恢复可用。
若想要设置集群在部份 key space 没有 cover 完成时继续去接收查询，就将参数设置为 no。

cluster-require-full-coverage yes

slowlog-log-slower-than 10000

“慢操作日志”记录, 单位: 微秒(百万分之一秒,1000 * 1000), 如果操作时间超过此值, 将会把 command 信息”记录”起来.(内存, 非文件)。其中”操作时间”不包括网络 IO 开支, 只包括请求达到 server 后进行”内存实施”的时间.”0”表示记录全部操作。

 slowlog-max-len 128

“慢操作日志”保留的最大条数,”记录”将会被队列化, 如果超过了此长度, 旧记录将会被移除。可以通过”SLOWLOG args”查看慢记录的信息(SLOWLOG get 10,SLOWLOG reset)。

 latency-monitor-threshold 0

延迟监控，用于记录等于或超过了指定时间的操作，默认是关闭状态，即值为 0。

 hash-max-ziplist-entries 512
hash-max-ziplist-value 64

hash 类型的数据结构在编码上可以使用 ziplist 和 hashtable。ziplist 的特点就是文件存储 (以及内存存储) 所需的空间较小, 在内容较小时, 性能和 hashtable 几乎一样. 因此 redis 对 hash 类型默认采取 ziplist。如果 hash 中条目的条目个数或者 value 长度达到阀值, 将会被重构为 hashtable。
这个参数指的是 ziplist 中允许存储的最大条目个数，，默认为 512，建议为 128。

ziplist 中允许条目 value 值最大字节数，默认为 64，建议为 1024。

list-max-ziplist-size -2
list-compress-depth 0

redis 在 3.2 中废弃了之前的两个 list 底层结构设置：list-max-ziplist-entries 512 list-max-ziplist-value 64。改为新的 quicklist 结构。

set-max-intset-entries 512

与哈希和列表类似，有序集合也会使用一种特殊的编码方式来节省空间，这种特殊的编码方式只用于这个有序集合的长度和元素均低于以下参数设置的值时。intset 中允许保存的最大条目个数, 如果达到阀值,intset 将会被重构为 hashtable。

zset-max-ziplist-entries 128
zset-max-ziplist-value 64

zset 为有序集合, 有 2 中编码类型:ziplist,skiplist。因为”排序”将会消耗额外的性能, 当 zset 中数据较多时, 将会被重构为 skiplist。

hll-sparse-max-bytes 3000

设置 HyeperLogLog 的字节数限制，这个值通常在 0~15000 之间，默认为 3000，基本不超过 16000。

activerehashing yes

是否开启顶层数据结构的 rehash 功能, 如果内存允许, 请开启。rehash 能够很大程度上提高 K - V 存取的效率。redis 将会在每秒中抽出 10 毫秒来对主字典进行重新散列化处理，这有助于尽可能的释放内存。

client-output-buffer-limit <class><hard limit><soft limit><soft seconds>

因为某些原因，client 不能足够快的从 server 读取数据，那 client 的输出缓存限制可能会使 client 失连，这个限制可用于 3 种不同的 client 种类，分别是：normal、slave 和 pubsub。

client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60

客户端 buffer 控制。在客户端与 server 进行的交互中, 每个连接都会与一个 buffer 关联, 此 buffer 用来队列化等待被 client 接受的响应信息。如果 client 不能及时的消费响应信息, 那么 buffer 将会被不断积压而给 server 带来内存压力. 如果 buffer 中积压的数据达到阀值, 将会导致连接被关闭,buffer 被移除。
buffer 控制类型包括:normal -> 普通连接；slave -> 与 slave 之间的连接；pubsub ->pub/sub 类型连接，此类型的连接，往往会产生此种问题; 因为 pub 端会密集的发布消息, 但是 sub 端可能消费不足.
指令格式:client-output-buffer-limit”, 其中 hard 表示 buffer 最大值, 一旦达到阀值将立即关闭连接;
soft 表示”容忍值”, 它和 seconds 配合, 如果 buffer 值超过 soft 且持续时间达到了 seconds, 也将立即关闭连接, 如果超过了 soft 但是在 seconds 之后，buffer 数据小于了 soft, 连接将会被保留.
其中 hard 和 soft 都设置为 0, 则表示禁用 buffer 控制. 通常 hard 值大于 soft.

hz 10

redis 使用一个内部程序来处理后台任务，例如关闭超时的 client 连接，清除过期的 key 等等。它并不会同时处理所有的任务，redis 通过指定的 hz 参数去检查和执行任务。
hz 默认设为 10，提高它的值将会占用更多的 cpu，当然相应的 redis 将会更快的处理同时到期的许多 key，以及更精确的去处理超时。
hz 的取值范围是 1~500，通常不建议超过 100，只有在请求延时非常低的情况下可以将值提升到 100。