Redis 配置文件详解

Redis 的配置文件主要有 2 个，一个是 redis.conf 文件，另一个是 redis 哨兵模式下的 redis-sentinel.conf 文件。redis.conf 配置文件内容主要分为通用配置、网络配置、快照配置、主从同步配置、安全配置、限制配置、AOF 配置、集群配置等等。

包含（INCLUDES）配置

include

include <file_path>

# 示例
# include /path/to/local.conf
# include /path/to/other.conf

可以使用 include 来包含一些其他的配置文件。假如你有一个可用于所有的 redis server 的标准配置模板，但针对某些 server 又需要一些个性化的设置，这时候可以通过 include 将配置区分开来。

由于 redis 配置是最后的配置指令值生效，所以最好是把 include 放在这个文件的最前面，以避免在运行时覆盖配置的改变，如果情况相反，就把它放在后面。

需要注意的是，include 是不能被 config rewrite 命令改写的。

网络（NETWORK）配置

bind

bind <ip1> <ip2>

# 示例
# bind 192.168.1.100 10.0.0.1   # 多个 ip 用空格隔开
# bind 127.0.0.1 ::1            # 绑定 ipv6 本地地址

配置绑定监听的 ip 地址。如果不配置“bind”参数，redis 默认可以接收来自所有网络的请求。

protected-mode

protected-mode <yes/no>

# 示例
# protected-mode yes

protected-mode 是一层安全防护，主要是为了提供可限制公网访问 redis 的选项。

启用 protected-mode 有 2 个条件：

1. 没有通过 bind 直接绑定 ip。
2. 没有这是密码。

3.2 版本加入的新特性，如果启用了，只能够通过 lookback ip（127.0.0.1）访问 Redis。

port 

port <port>

# 示例
# port 6379

监听端口号，默认为 6379，如果设为 0，redis 将不再监听 TCP socket。

tcp-backlog

tcp-backlog {value}

# 示例
# tcp-backlog 511

TCP 监听的连接最大容纳数量。

在高并发的环境下，需要把这个值调高以避免客户端连接缓慢的问题。Linux 内核会一声不响的把这个值缩小成 /proc/sys/net/core/somaxconn 对应的值，所以需要修改这两个值才能达到实际的预期。

unixsocket 和 unixsocketperm

unixsocket {socket_file_path}
unixsocketperm {value}

# 示例
# unixsocket /tmp/redis.sock
# unixsocketperm 700

unixsocket 配置项指定 unix socket 文件的路径。

unixsocketperm 配置项指定文件的权限。

对于 linux 系统，如果 redis 客户端和服务端都在同一台服务器，可以使用 unix socket，不需要走 TCP 监听网络端口，使用后效果非常明显。

UNIX Domain Socket 是在 socket 架构上发展起来的用于同一台主机的进程间通讯（IPC），它不需要经过网络协议栈，不需要打包拆包、计算校验和、维护序号和应答等，只是将应用层数据从一个进程拷贝到另一个进程，当用户连接到 Redis 通过 TCP/IP 连接或 Unix 域连接，千兆网络的典型延迟大概 200us，而 Unix Domain Socket 可能低到 30us。

timeout 

timeout <seconds>

# 示例
# timeout 0

当一个客户端连接一直没有内容请求发向服务端，那么服务端有权主动关闭这个连接，可以通过 timeout 来设置“空闲超时时限”，0 表示永不关闭。

tcp-keepalive

tcp-keepalive <seconds>

# 示例
# tcp-keepalive 300

tcp 的保活策略。可以通过 tcp-keepalive 配置项来进行设置，单位为秒。

假如设置为 60 秒，表示将周期性地使用 SO_KEEPALIVE 来给客户端发送 ack 请求，以此来检测客户端是否还处于健康状态，对于无响应的客户端则会关闭其连接。所以关闭一个连接最长需要 120 秒的时间。如果设置为 0，则不会进行保活检测。

从 3.2.1 版本开始，推荐的设置是 300 秒，此前是 60 秒。

通用（GENERAL）配置

daemonize

daemonize <yes/no>

# 示例
# daemonize no

选择是否以守护进程运行 redis。

默认情况下 redis 不会作为守护进程运行的，如果你想让它在后台运行，你需把它改成 yes。

当 redis 作为守护进程运行的时候，它会写一个 pid（进程 ID）到 /usr/local/var/run/redis.pid 文件里面。

supervised

supervised <no/upstart/systemd/auto>

# 示例
# supervised no

Redis 与当前运行系统之间的交互选项。

• no：没有监督交互。
• upstart：通过将 Redis 置于 SIGSTOP 模式来启动信号。
• systemd：signal systemd 将 READY=1 写入 $NOTIFY_SOCKET。
• auto：检测 upstart 或 systemd 方法基于 UPSTART_JOB 或 NOTIFY_SOCKET 环境变量。

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

pidfile 

pidfile {pid_file_path}

# 示例
# pidfile /var/run/redis_6379.pid

pid 文件的路径配置。

如果指定了 pid 文件，Redis 启动的时候会把 pid 写入指定文件，并且退出的时候会删除相应文件。

当 Redis 不是以后台守护进程运行且也没有指定 pid 文件时 pid 文件不会被创建；如果服务是以守护进程启动，且没有指定 pid 文件时，默认会在 /usr/local/var/run/redis.pid 路径上创建 pid 文件。

loglevel

loglevel <debug/verbose/notice/warning>

# 示例
# loglevel notice

指定服务器日志级别。默认是 notice。

• debug：debug 级别，含有大量信息，适合开发和测试时设定。
• verbose：记录一些有用的信息，但不会像 debug 级别那么多。
• notice：普通的 verbose 级别，可用于生产环境。
• warning：warning 级别，仅记录非常重要或严重的日志信息。

logfile 

logfile <log_file_name>

# 示例
# logfile ""

指定日志文件的位置。默认是空字符串。

也可以使用空字符串强制 Redis 将日志输出到标准控制台上。值得注意的是，如果在守护进程启动的状态下，日志使用标准输出时，日志信息将会发送到 /dev/null 上。

syslog-enabled、syslog-ident 和 syslog-facility

syslog-enabled <yes/no>
syslog-ident <ident_name>
syslog-facility <USER|LOCAL0~LOCAL7>

# 示例
# syslog-enabled no
# syslog-ident redis
# syslog-facility local0

syslog-enabled 提供是否启用将记录记载到系统日志功能。

syslog-ident 表示若启用日志记录，则需要设置日志记录的身份。

syslog-facility 表示若启用日志记录，则需要设置日志 facility，可取值范围为 local0~local7 或 user，表示不同的日志级别。

databases

databases <number>

# 示例
# databases 16

设置数据库的数目。默认数目是 16。

默认的数据库是 db 0，可以在每个连接上使用“select {dbid}”命令选择一个不同的数据库，dbid 是一个介于 0 到 databases-1 之间的数值。

快照（SNAPSHOTTING）配置

save

save <seconds> <changes>

# 示例
# save 900 1      # 900 秒（15 分钟）内至少有 1 个更改操作才会触发
# save 300 10     # 300 秒（5 分钟）内至少有 10 个更改操作才会触发
# save 60 10000   # 60 秒（1 分钟）内至少有 10000 个更改操作才会触发
# save ""         # 去除之前所有 save 指令配置

指定在多长时间内，有多少次更新操作，就将数据同步到数据文件，可以多个条件配合使用。

如果不想写磁盘的话，就把所有 save 设置注释掉就行了。

通过添加一条带空字符串参数的 save 指令也能移除之前所有配置的 save 指令。

stop-writes-on-bgsave-error

stop-writes-on-bgsave-error <yes/no>

# 示例
# stop-writes-on-bgsave-error yes

当后台快照持久化出现错误时，是否停止写操作。

默认如果开启 RDB 快照（至少设置一条 save 指令），并且最近的后台持久化失败时，Redis 将会停止接受写操作，这将使用户知道数据没有正确地持久化到硬盘。

如果后台持久化进程能重新恢复，Redis 将自动恢复允许写操作。

然而如果你已经部署了健壮的 Redis 服务器和完善的持久化监控，你可能想关掉这个功能以便于即使是硬盘，权限等出问题时，Redis 也能够像平时一样正常提供服务。

rdbcompression

rdbcompression <yes/no>

# 示例
# rdbcompression yes

当导出到 .rdb 数据库时，是否用LZF压缩字符串对象。

默认设置为 yes，因为几乎在任何情况下它都是不错的。

如果你想节省 CPU 的话，可以把它设置为 no；但是如果有可压缩的 key 或 value 的话，数据文件就会比压缩后的文件大。

rdbchecksum

rdbchecksum <yes/no>

# 示例
# rdbchecksum yes

是否开启 rdb 文件的校验。

版本 5 的 RDB 有一个 CRC 64 算法的校验和放在了文件的末尾。这将使文件格式更加可靠，但在创建和加载 RDB 文件时，这有一个性能消耗（大约 10%），所以你可以关掉它来获取最好的性能表现。

当关闭 rdb 文件的校验和时，文件末尾用 0 来表示加载文件代码要跳过 rdb 文件的校验和检查。

dbfilename

dbfilename <db_file_name>

# 示例
# dbfilename dump.rdb

rdb 持久化数据库的文件名。

dir

dir <directory_path>

# 示例
# dir ./

持久化数据库的文件目录（包括 rdb 持久化的文件和 aof 持久化的 aof 文件）。

必须指定文件目录，而非文件名。

同步（REPLICATION）配置

slaveof

slaveof <masterip> <masterport>

主从同步设置。Redis 通过 slaveof 指令来实现 Redis 实例的备份。

masterauth

masterauth <master-password>

如果 master 设置了密码保护（通过 requirepass 选项来配置），那么 slave 在开始同步之前必须进行身份验证，否则它的同步请求会被拒绝。

slave-serve-stale-data

slave-serve-stale-data <yes/no>

# 示例
# slave-serve-stale-data yes

当一个 slave 失去和 master 的连接，或者同步正在进行中，slave 的行为有两种可能：

1. 如果 slave-serve-stale-data 设置为 yes（默认值），slave 会继续响应客户端请求，可能是正常数据，也可能是还没获得值的空数据。
2. 如果 slave-serve-stale-data 设置为 no，slave 会回复“正在从 master 同步 （SYNC with master in progress）"来处理各种请求，除了 INFO 和 SLAVEOF 命令。

slave-read-only

slave-read-only <yes/no>

# 示例
# slave-read-only yes

slave 实例是否是只读设置。

你可以配置 slave 实例是否接受写操作。可写的 slave 实例可能对存储临时数据比较有用（因为写入 slave 的数据在同 master 同步之后将很容易被删除），但是如果客户端由于配置错误在写入时也可能产生一些问题。

从 Redis 2.6 开始默认所有的 slave 为只读。

只读的 slave 不是为了暴露给不可信的客户端而设计的。它只是一个防止实例误用的保护层。一个只读的 slave 支持所有的管理命令，比如 config、debug 等。为了限制，可以用 rename-command 来隐藏所有的管理和危险命令，以便增强只读 slave 的安全性。

repl-diskless-sync

repl-diskless-sync <yes/no>

# 示例
# repl-diskless-sync no

是否开启无硬盘同步复制。

新的 slave 和重连后不能继续备份的 slave，需要做所谓的“完全备份”，即将一个 RDB 文件从 master 传送到 slave。这个传送有以下两种方式：

1. 硬盘备份（Disk-backed）：redis 的 master 创建一个新的进程，用于把 RDB 文件写到硬盘上。过一会儿，其父进程递增地将文件传送给 slave。
2. 无硬盘备份（Diskless）：redis 的 master 创建一个新的进程，子进程直接把 RDB 文件写到 slave 的套接字，不需要用到硬盘。

在硬盘备份的情况下，master 的子进程生成 RDB 文件。一旦生成，多个 slave 可以立即排成队列使用 master 的 RDB 文件。

在无硬盘备份的情况下，一次 RDB 传送开始，新的 slave 到达后，需要等待现在的传送结束，才能开启新的传送。

如果使用无硬盘备份，master 会在开始传送之间等待一段时间（可配置，以秒为单位），希望等待多个 slave 到达后并行传送。

在硬盘低速而网络高速（高带宽）情况下，无硬盘备份更好。

注意：无硬盘的备份目前仍处理试验阶段

repl-diskless-sync-delay

repl-diskless-sync-delay <seconds>

# 示例
# repl-diskless-sync-delay 5

当开启无硬盘复制备份时的延迟时长，单位为秒。

当启用无硬盘备份，服务器等待一段时间后才会通过套接字向 slave 传送 RDB 文件，这个等待时间是可配置的。

这一点很重要，因为一旦传送开始，就不可能再为一个新到达的 slave 服务。新的 slave 则要排队等待下一次 RDB 传送。因此服务器等待一段时间以期待更多的 slave 到达。

延迟时间以秒为单位，默认为 5 秒。要关掉这一功能，只需将它设置为 0 秒，传送会立即启动。 

repl-ping-slave-period

repl-ping-slave-period <seconds>

# 示例
# repl-ping-slave-period 10

slave 以一个预先设置好的时间间隔向服务器发送 PING。这个时间间隔可以通过 repl_ping_slave_period 选项改变。默认值是 10 秒。

repl-timeout

repl-timeout <seconds>

# 示例
# repl-timeout 60

备份复制的超时时间，单位为秒。

备份复制的超时有如下三种情况：

1. 从 slave 的角度，同步期间的批量传输的 I/O。
2. 从 slave 的角度，认为 master 超时（数据、ping）。
3. 从 master 的角度，认为 slave 超时（REPLCONF ACK pings）。

 要确保该参数值比定义的 repl-ping-slave-period 要大，否则每次 master 和 slave 之间通信低速时都会被检测为超时。

repl-disable-tcp-nodelay

repl-disable-tcp-nodelay <yes/no>

# 示例
# repl-disable-tcp-nodelay no

同步之后是否禁用 slave 上的 TCP_NODELAY。

如果你选择 yes，redis 会使用较少量的 TCP 包和带宽向 slave 发送数据。但这会导致在 slave 增加一点数据的延时。linux 内核默认配置情况下最多 40 毫秒的延时。

如果选择 no，slave 的数据延时不会那么多，但备份需要的带宽相对较多。

默认情况下我们追求低延迟，但在高负载情况下或者在主从站都跳的情况下，把它切换为 yes 是个好主意。

repl-backlog-size

repl-backlog-size <size>

# 示例
# repl-backlog-size 1mb

设置 backlog 的大小。

backlog 是一个缓冲区，在 slave 端失连时存放要同步到 slave 的数据，因此当一个 slave 要重连时，经常是不需要完全同步的，执行局部同步就足够了。backlog 设置的越大，slave 可以失连的时间就越长。

只要有一个 slave 连接，就会立刻分配一个 backlog。

repl-backlog-ttl

repl-backlog-ttl <seconds>

# 示例
# repl-backlog-ttl 3600

如果一段时间后没有 slave 连接到 master，则 backlog size 的内存将会被释放。如果值为 0，则表示永远不释放这部份内存。单位为秒。

slave-priority

slave-priority <number>

# 示例
# slave-priority 100

slave 端的优先级设置，值是一个整数，数字越小表示优先级越高。

slave 优先级是可以从 redis 的 INFO 命令输出中查到的一个整数。当 master 不能正常工作时，redis sentinel 基于它来选择一个 slave 并将它提升为 master。

低优先级的 slave 被认为更适合于提升为 master，因此假设有三个 slave 优先级分别是 10、100、25，sentinel 会选择优先级为 10 的 slave，因为它的优先级最高。

然而优先级值为 0 的 slave 不能切换为 master 的角色，因此优先级为 0 的 slave 永远不会被 redis sentinel 提拔为 master。

默认优先级值是 100。

min-slaves-to-write 和 min-slaves-max-lag

min-slaves-to-write <value>
min-slaves-max-lag <seconds>

# 示例
# min-slaves-to-write 3
# min-slaves-max-lag 10

设置当一个 master 端的可用 slave 少于 N 个，延迟时间大于 M 秒时，不接收写操作。

N 个 slave 必须是在线状态。

延迟的秒数必须<=所定义的值，延迟秒数是从最后一次收到的来自 slave 的 ping 开始计算。ping 通常是每秒一次。

这一选项并不保证 N 个备份都会接受写请求，但是会限制在指定秒数内由于 slave 数量不够导致的写操作丢失的情况。

设置某一个为 0，表示禁用这一功能。

默认情况下 min-slaves-to-write 设置为 0（禁用），而 min-slaves-max-lag 设置为 10。

slave-announce-ip 和 slave-announce-port

slave-announce-ip <ip>
slave-announce-port <port>

# 示例
# slave-announce-ip 5.5.5.5
# slave-announce-port 1234

Redis Master 能够以不同的方式列出所连接 slave 的地址和端口。例如，“INFO replication”部分提供此信息，除了其他工具之外，Redis Sentinel 还使用该信息来发现 slave 实例。此信息可用的另一个地方在“ROLE”命令的输出中。

通常由 slave 报告列出的 IP 和地址，通过以下方式获得：

• IP：通过检查 slave 与 master 连接使用的套接字的对等体地址自动检测地址。
• PORT：端口在复制握手期间由 slave 通信，并且通常是 slave 正在使用列出连接的端口。

然而，当使用端口转发或网络地址转换（NAT）时，slave 实际上可以通过（不同的 IP 和端口对）来到达。slave 可以使用如上两个选项，以便向 master 报告一组特定的 IP 和端口，同时 INFO 和 ROLE 将报告这些值。

如果你需要仅覆盖端口或 IP 地址，则没必要使用这两个选项。

安全（SECURITY）配置

requirepass

requirepass <password>

# 示例
# requirepass foobared

Redis 服务密码设置。

这个配置选项要求客户端在处理任何命令时都要验证身份和密码。

这个功能在有不信任的其它客户端能够访问 redis 服务器的环境里非常有用。

为了向后兼容的话，这段应该注释掉。因为大多数情况下不需要身份验证（如它们运行在自己的服务器上）。

由于 Redis 高效的性能，所以攻击者可以尝试每秒 150k 个的密码来试图暴力破解。这意味着你需要一个高强度的密码，否则破解太容易了。

rename-command

rename-command CONFIG <new_command>

# 示例
# rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52
# rename-command CONFIG ""                                         # 空字符串来禁用

命令重命名。

在共享环境下，可以为危险命令改变名字。比如，你可以为 CONFIG 命令改个其他不太容易猜到的名字（如，rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52），这样内部的工具仍然可以使用，而普通的客户端将不行。

此外，也可以通过改名为空字符串来完全禁用一个命令（rename-command CONFIG ""）。

改变命令名字会被记录到 AOF 文件或被传送到 slave 服务器，这样可能会产生问题。

限制（LIMITS）配置 

maxclients

maxclients <max_number>

# 示例
# maxclients 10000

设置最多同时连接的客户端数量。

默认这个限制是 10000 个客户端连接，然而如果 Redis 服务器不能配置处理文件的限制数来满足指定的值，那么最大的客户端连接数就被设置成当前文件限制数减 32（因为 Redis 服务器保留了一些文件描述符作为内部使用）。

一旦达到这个限制，Redis 会关闭所有新连接并发送错误"max number of clients reached"。

maxmemory

maxmemory <bytes>

设置 Redis 服务内存上限。

不要用比设置的上限更多的内存。一旦内存使用达到上限，Redis 会根据选定的回收策略（参见 maxmemmory-policy 配置）删除 key。

如果因为删除策略 Redis 无法删除 key，或者回收策略设置为 noeviction 时，Redis 会返回需要更多内存的错误信息给客户端，如 SET、LPUSH 等写命令，但是会继续响应像 Get 这样的只读命令。

当 Redis 作为 LRU 缓存，或者为实例设置了硬性内存限制的时候（如 noeviction 策略）的时候，这个选项通常是很有用的。

当有多个 slave 达到内存上限时，master 为同步 slave 的输出缓冲区所需内存不计算在使用内存中。这样当淘汰 key 时，就不会因网络问题或者重新同步事件触发淘汰 key 的循环，反之，slave 的输出缓冲区充满了 key 被淘汰的 DEL 命令，这将触发删除更多的 key，直到这个数据库完全被清空为止。

总之，如果需要多个 slave，建议设置一个稍小 maxmemory 限制，这样系统就会有空闲的内存作为 slave 的输出缓存区（但是如果最大内存策略设置为"noeviction"的话就没必要了）。

maxmemory-policy

maxmemory-policy <volatile-lru/allkeys-lru/volatile-random/allkeys-random/volatile-ttl/noeviction>

# 示例
# maxmemory-policy noeviction

内存数据淘汰策略。

内存数据淘汰策略：如果内存达到了最大限制，Redis 如何选择 key 来进行删除。可以有如下几个选项：

• volatile-lru：针对那些设置过期时间的 key，基于 LRU 算法进行删除。
• allkeys-lru：针对任何 key，基于 LRU 算法进行删除。
• volatile-random：针对那些设置过期时间的 key，随机地进行删除。
• allkeys-random：针对任何 key，随机地进行删除。
• volatile-ttl：针对那些设置过期时间的 key，根据最快过期最优先淘汰的原则（最小 TTL）对 key 进行删除。
• noeviction：不做任何删除，直接在进行写操作时，返回错误。

对于如上所有策略来说，如果 Redis 找不到合适的、可以删除的 key 时，都会在写操作时返回一个错误。

默认的配置是"maxmemory-policy noeviction"。

maxmemory-samples

maxmemory-samples <sample_size>

# 示例
# maxmemory-samples 5

LRU 和最小 TTL 算法的实现都不是很精确，但是很接近（主要是因为为了节省内存），其实是通过抽取样本实现。

例如，默认 Redis 会检查 5 个 key，然后选取其中最旧的那个，你可以通过上面的配置指令来设置取样的个数。

默认设置是 5，它其实有不错的效果（兼顾时间复杂度和空间复杂度）；如果设置为 10，结果更接近于真实的 LRU 算法，但是多耗一些 cpu；如果设置为 3，实现效率会很快，但是不够精确。

AOF（Append Only Mode）配置

appendonly

appendonly <yes/no>

# 示例
# appendonly no

是否设置 AOF 持久化模式。

默认情况下，Redis 异步地把数据导出到磁盘上。这种模式在很多应用里已经足够好，但 Redis 进程出问题或断电时，可能造成一段时间的写操作丢失（这取决于配置的 save 指令）。

AOF 是一种可靠的持久化模式，例如使用默认的数据写入文件策略（参见后面的配置），在遇到像服务器断电或单写情况下，Redis 自身进程出问题，但操作系统仍正常运行等突发事件时，Redis 能只丢失1秒的写操作。

AOF 和 RDB 持久化能同时启动，并且不会有问题。如果 AOF 开启，那么在启动时，Redis 将加载 AOF 文件，它更能保证数据的可靠性。

appendfilename

appendfilename <appendonlyfile_name>

# 示例
# appendfilename "appendonly.aof"

AOF（Append Only File）文件的名称，默认为"appendonly.aof"。

appendfsync

appendfsync <always/everysec/no>

# 示例
# appendfsync everysec

AOF 刷盘的频率。

fsync() 的系统调用告诉操作系统把数据写到磁盘上，而不是等更多的数据进入输出缓冲区。有些操作系统会真的把数据马上刷到磁盘上，有些则会尽快去尝试这么做。

Redis 支持 3 种的 AOF 持久化模式：

1. no：不进行磁盘持久化，操作系统在适当时 flush 数据。比较快。
2. always：每次写操作都立刻写入到 aof 文件。慢，但是最安全。
3. everysec：每秒刷一次盘。折中方案。

默认的"everysec"通常来说，能在速度和数据安全性之间取得比较好的平衡。如果你能放宽该配置为"no"，可以获取更好的性能（但如果你能忍受一些数据丢失，也可以考虑使用默认的快照持久化模式）；或者相反，用"always"会比较慢，但比"everysec"更安全。如果不能确定，就用"everysec"。

no-appendfsync-on-rewrite

no-appendfsync-on-rewrite <yes/no>

# 示例
# no-appendfsync-on-rewrite no

在AOF日志重写时，是否追加命令操作。

该配置的默认值是no。

• yes：在日志重写时，不进行命令追加操作，而只是将其放在缓冲区里，避免与命令的追加造成DISK IO上的冲突。
• no：在日志重写时，命令追加操作照常进行。

如果AOF的同步策略设置成"always"或者"everysec"，后台的存储进程（后台存储或重写AOF日志）会产生很多磁盘I/O开销。某些Linux的配置下会使Redis因为fsync()系统调用而阻塞很久。目前对这个情况还没有完美修正，甚至不同线程的fsync()会阻塞我们同步的write(2)调用。

为了缓解这个问题，可以用下面这个选项。它可以在BGSAVE或BGREWRITEAOF处理时阻止fsync()。

这就意味着，如果有子进程在进行保存操作，那么Redis就处于“不可同步”的状态。这实际上是说，在最差的情况下可能会丢掉30秒钟的日志数据（默认Linux设定）。

如果把这个设置成"yes"带来了延迟问题，就保持"no"，这是保存持久数据的最安全的方式。

auto-aof-rewrite-percentage和auto-aof-rewrite-min-size

auto-aof-rewrite-percentage <percentage>
auto-aof-rewrite-min-size <size>

# 示例
# auto-aof-rewrite-percentage 100
# auto-aof-rewrite-min-size 64mb

触发aof文件重写的百分比（与之前记录的比较）和min-size。

如果AOF日志文件增大到指定百分比，Redis能够通过BGREWRITEAOF自动重写AOF日志文件。

工作原理：Redis记住上次重写时，AOF文件的大小（如果重启后还没有写操作，就直接用启动时的AOF大小）。

这个基准大小和当前大小做比较。如果当前大小超过指定比例，就会触发重写操作。你还需要指定被重写日志的最小尺寸，这样避免了达到指定百分比但尺寸仍然很小的情况还要重写。

指定百分比为0会禁用AOF自动重写特性。

aof-load-truncated

aof-load-truncated <yes/no>

# 示例
# aof-load-truncated yes

是否加载不完整的aof文件来进行启动。

Redis启动加载aof文件，如果发现末尾命令不完整则自动截掉，成功加载前面正确的数据。如果设置为no，遇到此类情况，Redis启动失败，用redis-check-aof工具手工修复。默认设置为yes。

Lua脚本（LUA SCRIPTING）配置

lua-time-limit

lua-time-limit <milliseconds>

# 示例
# lua-time-limit 5000

Lua脚本的最大执行时间，单位为毫秒。

如果达到了最大的执行时间，Redis将要记录在达到最大允许时间之后一个脚本仍然在执行，并且对查询进行错误响应。

当一个长时间运行的脚本超过了最大执行时间，只有"SCRIPT KILL"和"SHUTDOWN NOSAVE"两个命令可用。第一个可以用于停止一个还没有调用写命名的脚本；第二个是关闭服务器，使用场景是当写命令已经通过脚本开始执行，并且用户不想等到脚本的自然终止。

设置成0或者负值表示不限制执行时间并且没有任何警告。

集群（Redis Cluster）配置

cluster-enabled

cluster-enabled <yes/no>

# 示例
# cluster-enabled yes

是否开启集群模式。

如果配置yes，则开启集群功能，此时redis实例作为集群的一个节点，否则，它是一个普通的单一的redis实例。

cluster-config-file

cluster-config-file <filename>

# 示例
# cluster-config-file nodes-6379.conf

集群配置文件名称。

此配置文件不能人工编辑，它是集群节点自动维护的文件，主要用于记录集群中有哪些节点、它们的状态以及一些持久化参数等等，方便在重启时恢复这些状态。通常是在收到请求之后这个文件就会被更新。

cluster-node-timeout

cluster-node-timeout <milliseconds>

# 示例
# cluster-node-timeout 15000

集群节点失联的超时时间。

如果master节点超过这个时间还是不可达，则用它的slave节点启动故障迁移，并将其升级成master节点。注意，任何一个节点在这个时间之内如果还是没有连上大部分的master节点，则此节点将停止接收任何请求。一般设置为15秒即可。

cluster-slave-validity-factor

cluster-slave-validity-factor <factor>

# 示例
# cluster-slave-validity-factor 10

在进行故障转移的时候，全部的slave都会请求申请为master，但是有些slave可能与master断开连接一段时间了导致数据过于陈旧，不应该被提升为master。该参数就是用来判断slave节点与master断线的时间是否过长。

slave进行故障转移的触发条件是，slave和master的最后一次交互时间大于如下计算公式：

• (node-timeout * slave-validity-factor) + repl-ping-slave-period

例如，node-timeout设置为30秒， slave-validity-factor设置为10，并且假设repl-ping-slave-period为10秒，那么在slave节点与master最后一次交互超过310秒后，slave节点才会尝试去进行故障转移。

一个较大的slave-validity-factor参数能够允许slave节点使用比较旧的数据去故障转移它的master节点，而一个比较小的该参数值可能会阻止集群去选择slave节点。

为保证系统最大的可用性，可以设置slave-validity-factor的值为0，这表示slave节点将会一直去尝试failover它的master节点，而不管它与master节点的最后交互时间。

cluster-migration-barrier

cluster-migration-barrier <count>

# 示例
# cluster-migration-barrier 1

master节点需要的最小slave节点数，只有达到这个数，master节点失败时，它的slave节点才会进行故障转移。默认值为1，表示master节点应该至少1个可用的slave才允许其进行故障转移。

要禁用这个功能只需要将此参数设置为一个非常大的值即可。

cluster-require-full-coverage

cluster-require-full-coverage <yes/no>

# 示例
# cluster-require-full-coverage yes

默认情况下，当redis集群节点中发现有至少一个hash slot未被covered时，节点将会停止接收服务。这种情况下，如果有一部分的集群节点宕掉了，那整个集群将变得不可用。集群将会在所有的slot重新covered之后自动恢复可用。

若想要设置集群在部分key space没有cover完成时，继续去接收查询，就将参数设置为no。默认是yes。

慢日志（SLOW LOG）设置

slowlog-log-slower-than

slowlog-log-slower-than <microseconds>

# 示例
# slowlog-log-slower-than 10000

设置慢日志的划定界限，只有命令执行时间大于该参数值，会被定义成慢查询，才会被slow log进行日志记录。单位为微秒，1000000微秒等于1秒。设置一个负值表示禁用慢日志，设置值为0表示记录每条执行的命令。

执行时间不包括类似与client进行交互或发送回复等I/O操作，它只是实际执行指令的时间。

slowlog-max-len

slowlog-max-len <length>

# 示例
# slowlog-max-len 128

慢查询的最大的条数。

当slow log超过设定的最大值后，会将最早的slow log删除，它是一个FIFO队列。

监控（LATENCY MONITOR）配置

latency-monitor-threshold

latency-monitor-threshold <threshold>

# 示例
# latency-monitor-threshold 0

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

通过LATENCY命令可以打印一些图样和获取一些报告，方便监控。

事件通知（EVENT NOTIFICATION）配置

notify-keyspace-events

notify-keyspace-events <events_characters>

# 示例
# notify-keyspace-events ""   # 空字符串表示通知被禁用

键空间事件通知设置，Redis2.8版本及以上新增的配置。

Redis能通知Pub/Sub客户端关于键空间发生的事件。

例如：如果键空间事件通知被开启，并且客户端对0号数据库的键foo执行DEL命令时，将通过Pub/Sub发布两条消息：

• PUBLISH __keyspace@0__:foo del
• PUBLISH __keyevent@0__:del foo

可以在下列表中选择Redis要通知的事件类型。事件类型由单个字符来标识：

• K：键空间通知，以__keyspace@<db>__为前缀。
• E：键事件通知，以__keysevent@<db>__为前缀。
• g：DEL，EXPIRE，RENAME等等与类型无关的通用命令的通知。
• $：String命令。
• l：List命令。
• s：Set命令。
• h：Hash命令。
• z：有序集合命令。
• x：过期事件（每次key过期时生成）。
• e：驱逐事件（当key在内存满了被清除时生成）。
• A："g$lshzxe"的别名，因此"AKE"意味着所有的事件。

notify-keyspace-events带一个由0到多个字符组成的字符串参数。空字符串表示通知被禁用。 

例子1，启用List和通用事件通知：

• notify-keyspace-events Elg

例子2，为了获取过期key的通知订阅名字为__keyevent@__:expired的频道，用以下配置：

• notify-keyspace-events Ex

默认所有的通知被禁用，因为用户通常不需要该特性，并且该特性会有性能损耗。

 如果不指定至少K或E，不会发送任何事件。

高级（ADVANCED CONFIG）配置

hash-max-ziplist-entries和hash-max-ziplist-value

hash-max-ziplist-entries <threshold>
hash-max-ziplist-value <threshold>

# 示例
# hash-max-ziplist-entries 512
# hash-max-ziplist-value 64

当hash只有少量的entry时，并且最大的entry所占空间没有超过指定的限制时，会用一种节省内存的数据结构来编码。可以通过上面的指令来设定限制。

list-max-ziplist-size

list-max-ziplist-size <size>

# 示例
# list-max-ziplist-size -2

参数的含义解释，取正值时表示quicklist节点ziplist包含的数据项。取负值表示按照占用字节来限定quicklist节点ziplist的长度。redis3.2版本及之后新增配置。

• -5：每个quicklist节点上的ziplist大小不能超过64Kb。
• -4：每个quicklist节点上的ziplist大小不能超过32Kb。
• -3：每个quicklist节点上的ziplist大小不能超过16Kb。
• -2：每个quicklist节点上的ziplist大小不能超过8Kb（默认值）。
• -1：每个quicklist节点上的ziplist大小不能超过4Kb。

ziplist太短，内存碎片越多。

ziplist太长，分配大块连续内存空间的难度就越大。

list-compress-depth

list-compress-depth <depth>

# 示例
# list-compress-depth 0

list设计最容易被访问的是列表两端的数据，中间的访问频率很低，如果符合这个场景，list-compress-depth配置可以起到优化内存作用，可以对中间节点进行压缩（采用的LZF，一种无损压缩算法），进一步节省内存。配置如下：

• 0：是个特殊值，表示都不压缩。这是Redis的默认值。
• 1：表示quicklist两端各有1个节点不压缩，中间的节点压缩。
• 2：表示quicklist两端各有2个节点不压缩，中间的节点压缩。
• 以此类推。

set-max-intset-entries

set-max-intset-entries <threshold>

# 示例
# set-max-intset-entries 512

set有一种特殊编码的情况，当set数据全是十进制64位有符号整型数字构成的字符串时，上面这个配置项就是用来设置set使用这种编码来节省内存的最大长度。

zset-max-ziplist-entries和zset-max-ziplist-value

zset-max-ziplist-entries <threshold>
zset-max-ziplist-value <threshold>

# 示例
# zset-max-ziplist-entries 128
# zset-max-ziplist-value 64

与hash和list相似，有序集合也可以用一种特别的编码方式来节省大量空间。这种编码只适合长度和元素都小于如上配置限制的有序集合。

hll-sparse-max-bytes

hll-sparse-max-bytes <bytes>

# 示例
# hll-sparse-max-bytes 3000

HyperLogLog稀疏结构表示字节的限制。

该限制包括16个字节的头。当HyperLogLog使用稀疏结构表示这些限制，它会被转换成密度表示。

值大于16000是完全没用的，因为在该点密集的表示是更多的内存效率。建议值是3000左右，减少内存的消耗。

activerehashing

activerehashing <yes/no>

# 示例
# activerehashing yes

是否启用哈希刷新。

占用CPU的每100个毫秒中会拿出1个毫秒来刷新Redis的主哈希表。redis所用的哈希表实现采用延迟哈希刷新机制，你对一个哈希表操作越多，哈希刷新操作就越频繁；反之，如果服务器是空闲的，那么哈希刷新就不会完成，哈希表就会占用更多的一些内存而已。

默认是每秒钟进行10次哈希表刷新，用来刷新字典，然后尽快释放内存。

如果你对延迟比较在意，不能够接受Redis时不时的对请求有2毫秒的延迟的话，就用"activerehashing no"，如果不太在意延迟而希望尽快释放内存就设置"activerehashing yes"。

client-output-buffer-limit

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

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

客户端的输出缓冲区的限制，可用于强制断开那些因为某种原因从服务器读取数据的速度不够快的客户端（一个常见的原因是一个发布/订阅客户端消费消息的速度无法赶上生产它们的速度）。

可以对三种不同的客户端设置不同的限制：

• normal：正常客户端。
• slave：slave和monitor客户端。
• pubsub：至少订阅了一个pubsub channel或pattern的客户端。

一旦达到硬限制客户端会立即被断开，或者达到软限制并持续达到指定的秒数（连续的）。 

例如，如果硬限制为32兆字节和软限制为16兆字节/10秒，客户端将会立即断开；如果输出缓冲区的大小达到32兆字节，或客户端达到16兆字节并连续超过了限制10秒，就将断开连接。

默认normal客户端不做限制，因为他们在不主动请求时不接收数据（以推的方式），只有异步客户端可能会出现请求数据的速度比它可以读取的速度快的场景。

pubsub和slave客户端会有一个默认值，因为订阅者和slaves以推的方式来接收数据。

把硬限制和软限制都设置为0来禁用该功能。

hz

hz <value>

# 示例
# hz 10

Redis调用内部函数来执行许多后台任务，如关闭客户端超时的连接，清除未被请求过的过期Key等等。

不是所有的任务都以相同的频率执行，但Redis依照指定的"hz"值来执行检查任务。

默认情况下，hz的值设定为10。提高该值将在Redis空闲时，使用更多的CPU，但同时当有多个key同时到期会使Redis的响应以及超时更精确地处理。

范围是1到500之间，但是不建议值超过100。大多数用户应该使用10这个默认值，只有在非常低的延迟要求时，有必要将值提高到100。

aof-rewrite-incremental-fsync

aof-rewrite-incremental-fsync <yes/no>

# 示例
# aof-rewrite-incremental-fsync yes

当一个子进程重写 AOF 文件时，如果启用上面的选项，则文件每生成 32M 数据会被同步。为了增量式的写入硬盘并且避免大的延迟高峰这个指令是非常有用的。