Include Part

Include

include 可以允许用户在 Redis 的 Conf 文件中引用一份「已经准备好」的配置。一般来说,我们都会把一些通用的且很少变化的配置放在一个「配置模板」中,然后在真正的 Redis-Server 启动的配置文件中使用include 命令包含它。这样一来,Redis-Server 在启动的时候就会使用配置模板内的配置项。

你也可以在include 命令后按照正常的方法写入其他配置。若新添加的配置项不在「配置模板」内容之中,那么这就相当于做了一个「追加」操作,否则,那将是一个「覆盖」操作。更为重要的是,include 的内容不会被CONFIG REWRITE命令的执行结果覆盖。

1
2
3
# Example
# include /path/to/local.conf
# include /path/to/other.conf

Load Part

loadmodule

loadmodule 可以允许用户在 Redis 的 Conf 文件中指定在 Redis-Server 启动时要加载的「外部模块」。因为 Redis 本身也是通过 C 语言进行实现的,所以它在redismodule.h文件中提供了一些 C API, 可供用户在使用 C 语言实现「外部模块」的时候使用。

1
2
3
# Example
# loadmodule /path/to/my_module.so
# loadmodule /path/to/other_module.so

Network Part

bind

bind配置项,允许用户指定一个或多个特定网卡的地址,并且将 Redis-Server 绑定在这个地址上。设置好了之后,若想通过 Redis-Cli 等工具访问 Redis-Server 的时候,host 参数必须指定bind 所绑定的地址。否则无法访问 Redis-Server。

默认情况下,Redis 将此配置项的缺省值指定为:127.0.0.1。这代表仅有和 Redis-Server 处于同一机器上的客户端可以访问。如果不指定bind配置项,那么 Redis-Server 将接受来自机器上所有网卡的链接。

这里一定需要注意的是,bind 参数是给 Redis-Server 绑定一个本地机器网卡的地址,而不是一个外部访问的 IP 地址。

1
2
3
# Example
# bind 192.168.1.100 10.0.0.1
# bind 127.0.0.1 ::1

protected-mode

protected-mode是 Redis 除了访问密码之外为增加其安全性所给出的一个配置参数。该配置项默认开启,仅接受和 Redis-Server 处于同一机器上的客户端的链接。并且可以支持无密码访问。否则,会禁用掉这项保护措施。

1
2
# Example
protected-mode yes

port

port 配置允许用户指定 Redis-Server 运行所监听的端口,默认情况下为 6379。

1
2
# Example
port 6379

tcp-backlog

tcp-backlog配置项是和 TCP 建立链接的过程有关的。对于使用者来说,可以简单的理解为,在完成了 TCP 的三次握手之后,客户端和 Redis—Server 建立链接的请求被放入了一个 Accept Queue 中,相当于进程的就绪队列,等待被 Redis-Server 处理。这个队列容量的大小就是受tcp-backlog配置项控制的。

理论上来说,如果使用 Redis 的服务有「高吞吐量」的特性,那么就需要在配置项中调大这个值。但是,这个值同时受到操作系统的相关参数的限制。最终 backlog 的值将取 tcp-backlog 和 /proc/sys/net/core/somaxconn 两个值中较小的那一个。默认情况下,这个值的参数为 511。

1
2
# Example
tcp-backlog 511

tcp-keepalive

tcp-keepalive 是和 TCP 链接保活机制有关的一个参数。若该配置项的值大于0,则 Redis-Server 将每隔 tcp-keepalive秒向客户端发送一个保活探测报文,根据回应判断客户端当前是否正常。如果超过一定次数,发现对方仍然没有回应,则 Redis-Server 会主动断开他们之间的链接。若该配置项被设置为0,则 Redis—Server 不会再进行这个检测。否则将每隔 tcp-keepalive秒发送一次保活探测报文。

1
2
# Example
tcp-keepalive 500

unixsocket && unixsocketperm

unixsocketunixsocketperm 是 Unix socket 的配置项。如果用户想通过 Unix socket 的方式来链接 Redis-Server 的话,需要开启这两个配置,使得 Redis-Server 可以监听从 Unix socket 进来的链接。默认情况下这两个配置是不开启的。

1
2
3
# Example
# unixsocket /tmp/redis.sock
# unixsocketperm 700

timeout

timeout 配置项可以让用户自由指定一个客户端到 Redis-Server 的链接在空闲多久之后断开,单位是秒。当配置为 0 的时候,意味着链接永远不会断开,直到通信双方有一方进程停掉。

1
2
# Example
timeout 0

General Part

daemonize

daemonize配置项可以由用户来决定,是否以「守护进程」的方式来运行 Redis-Server。默认情况下这个配置项是禁用的。

1
2
# Example
daemonize no

pidfile

pidfile 配置项允许用户指定一个文件的绝对路径。该文件的内容为 Redis-Server 进程的 PID。若已经开启了 daemonize配置且pidfile指定了一个路径,那么默认情况下会将 Redis-Server 的 PID 写入到pidfile指定的文件中。否则,写入到/var/run/redis.pid中。

1
2
# Example
pidfile /var/run/redis_6379.pid

loglevel && logfile

loglevel 配置项允许用户指定 Redis-Server 日志输出的等级。等级越高,输出的信息也就越丰富。该配置项的候选值有如下几个:

  • warning: 仅一些必要的错误信息和重要的信息
  • notice: 除一些必要的错误信息和重要的信息之外,有一部分的冗余信息。推荐在生产环境中开启
  • verbose:信息更加丰富,揭示 Redis-Server 的运行过程
  • debug:Redis-Server 能够输出的所有的信息

logfile允许用户指定 Redis-Server 服务日志的存放路径。默认情况下如果不指定这个参数,Redis—Server 会将日志输出到标准输入。而且,如果是以守护进程的模式运行的话,日志会被打入「黑洞」:/dev/null

1
2
3
# Example
loglevel notice
logfile "/var/redis/log"

syslog-enabled && syslog-ident

syslog-enabled 配置项开启之后,会将 Redis-Server 的服务日志输出到操作系统日志所在的文件中。也就是/var/log/syslog。默认情况下这个配置是关闭的。

syslog-ident 配置项主要是用来给输出到系统日志的 Redis-Server 的服务日志内容添加一些特殊的标记,方便通过一些工具进行筛选。

1
2
3
# Example
syslog-enabled yes
syslog-ident native-redis

databases

在一个 Redis 的实例中,通常会将它申请的内存按照 databases配置项的值切分成不同的部分 (即「分组」操作)。每一个子 database 通过整数进行索引,编号从 0~ databases。在对 Redis 操作之前,可以先通过 select 命令选取其中一个子数据库进行读取和写入。若你在两个不同的子数据库中写入相同的 key 但是不同的值之后就会发现,两者是不发生冲突的。默认情况下 databases配置项为16。

1
2
# Example
databases 16

Redis 之所以提供了这样的功能,最主要的原因是,很多重要的功能无法在多个 Redis 实例上一起配合来实现。如涉及到多个实例上的 Key 的事务功能是不可以用的。Redis 提供的分区功能,是在同一个进程的内存空间中实现了内存使用的隔离。至于每一个 db 被分配多少内存,一个 db 写满了之后会发生什么,是和 Redis 的内存分配策略有关的,这里暂时不详细介绍了。

RDB Backup

save

RDB 是 Redis 提供的一种「快照」形式的备份策略。它不能够保证高实时性,但是可以对 Redis 数据的「容灾性」提供一个比较好的帮助。

用户可以通过 save配置来设定 RDB 备份的策略,如 save 900 1,意味着当900秒的时间内,如果有1个 key 的内容发生了改变,那么在900秒的时间结束后,就会进行一次 RDB 的备份操作。当然,如果你想禁用掉这个 RDB 的备份功能,可以在配置文件中不指定 save配置项。

1
2
3
# Example
save 900 1  # 900s 内至少有一个 Key 的内容发生修改就备份
save 1000 2 # 1000s 内至少有两个 Key 的内容发生修改就备份

stop-writes-on-bgsave-error

默认开启 RDB 备份功能的情况下,备份操作可能会出现失败的情况。此时,如果用户和运维都没有察觉的话,最终的结果可能是灾难性的。stop-writes-on-bgsave-error配置项允许用户借助 Redis 自身提供的一个功能:RDB 备份失败后,写入操作会报错。直到下一次 RDB 备份开始,才允许客户端进行写入。

不过,Redis 自身提供的这个「防范机制」有点太暴力的。如果想自己去感知这个问题并且做出一些处理,可以对 Redis 的一些指标进行监控,然后将这个配置关掉。因为它默认是开启的。

1
stop-writes-on-bgsave-error yes

rdbcompression

rdbcompression 配置项开启之后,Redis 在进行 RDB 备份的时候,会对 String 类型的内容按照一定的压缩算法进行压缩,以节省空间。此配置项默认开启。

1
2
# Exapmle 
rdbcompression yes

rdbchecksum

默认情况下,RDB 备份操作之后,会在备份文件的末尾插入一些校验位,以保证数据的完整性。若rdbchecksum 配置项开启,则在 Redis 导入备份数据的时候,会消耗一定的性能对备份数据进行校验,防止导入脏数据甚至是导入数据失败。此配置项默认开启。

1
2
# Exapmle 
rdbchecksum yes

dbfilename

dbfilename可以指定 Redis 创建的 RDB 备份文件的名称。

1
2
# Example
dbfilename dump.rdb

Dir

dir 配置项可以由用户指定 RDB 备份文件的存放路径。

1
2
# Example 
dir ./

AOF Backup

appendonly

AOF 是 Redis 为了保证数据可靠性提供的第二种数据持久化方案。它记录的是 Redis 的写入操作而非数据。AOF 的实时性更强,因为 RDB 快照的属性,总是有相当大的风险丢失两次 RDB 备份之间的数据的。appendonly配置项可以开启和关闭 AOF 的功能。该配置项默认开启。

1
2
# Example 
appendonly yes

appendfilename

appendfilename可以指定 Redis 创建的 aof 备份文件的名称。

1
2
# Example 
appendfilename a.aof

appendfsync

Redis 在开启了 AOF 之后会将操作记录写在内存当中。但是这仍然是不安全的,因为进程 down 掉或者机器掉电,这些数据都没了。而操作系统自动将内存数据 flush 到硬盘的频率是比较长的,不一定能够满足用户对于 AOF 实时性的需求。所以提供了一个名为 appendfsync 的配置来调整 flush 写入记录到硬盘的频率。默认情况下是每秒保存一次。

  • appendfsync always: 每一个操作都会 flush 到硬盘
  • appendfsync everysec:每秒做一次 flush 操作
  • appendfsync no:不主动做 flush,依靠操作系统的机制
1
2
# Example 
appendfsync everysec

no-appendfsync-on-rewrite

AOF 文件重写,RDB 快照备份,都是需要进行磁盘I/O 的操作。如果再加上 AOF 以每秒或者每个操作的写入,势必会发生一些 I/O 阻塞的问题。Redis 在这个问题上,采取了「规避」的方式来处理。当 no-appendfsync-on-rewrite配置项开启之后,如果统一时间段里有其他的磁盘操作在进行,AOF 的 flush 操作可能会延迟一会执行。当然,提升性能的同时带来的问题就是用户需要忍受 AOF 的实时性会有降低。该配置默认关闭。

1
2
# Example 
no-appendfsync-on-rewrite no

auto-aof-rewrite-percentage && auto-aof-rewrite-min-size

AOF 文件随着对 Redis 操作的增多,其文件大小也会上升。但是 Redis 中有很多写操作是可以进行合并的,比如你对一个 Key,先 set 一个 A,又 set 了一个 B。最终 B 是有效的,此时就可以把两个 Set 操作合二为一。Redis 使用 auto-aof-rewrite-percentageauto-aof-rewrite-min-size 两个配置为重写操作提供了一些定制化的功能:

  • auto-aof-rewrite-percentage: 在第一次 AOF 文件重写之后,会记录一个 base size,Redis 会定义将目前 AOF 文件的大小和这个 base size 比较。如果current size 已经达到了base size 的某个比例的大小,就会进行重写操作。base size 在每一次 Rewrite 操作之后都会更新。该配置项取值 0~100.
  • auto-aof-rewrite-min-size:为了防止 AOF 文件在重写的过程中变的越来越小,可以指定一个该文件最小的大小。如果 current size 还没有达到它所设置的阈值,则不会发生AOF 文件重写。
1
2
3
# Example 
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

aof-load-truncated

Redis 在重新启动的时候,会通过加载 AOF 和 RDB 文件两种方式来恢复内存中的数据。其中 AOF 文件会优先使用。如果在 Load AOF 文件中所写入的数据时候,发现在 AOF 文件的尾部有内容上的损坏,则用户可以通过指定 aof-load-truncated配置项来指示 Redis 到底是应该继续恢复并且尽可能多的恢复数据,还是立刻报错。默认情况下,Redis 会尽可能多的读入数据,aof-load-truncated的值为 Yes。

但是,这里要注意的是,被损坏的部分仅限于 AOF 文件的尾端。若中间部分有损坏,Redis 会无视这个配置项,直接报错。

1
2
# Example 
aof-load-truncated yes

Replica

masterauth

如果 Master 已经配置了访问密码,那么需要在从节点的配置中加入masterauth配置项,并将访问密码作为该配置项的值。因为在从节点要和主节点建立数据同步链接的时候,需要通过访问密码来鉴权。

1
masterauth rootroot

replica-serve-stale-data

replica-serve-stale-data配置项允许用户设定,当主从链接断开的时候,从节点如何响应客户端的请求。默认情况下,该配置项的值为 yes, 即允许从节点正常响应用户的请求,但是可能会发生数据是过期的,甚至是根本没有数据的情况。若将其赋值为 no,则从节点将会对客户端的请求返回一个错误,拒绝提供服务。

1
2
# Example 
replica-serve-stale-data yes

replica-read-only

replica-read-only 配置项允许用户将从节点设置为只读模式。这是一种保护措施。因为当主从关系建立之后,主节点会一直向从节点同步数据。如果用户向从节点写数据的话,最终会被覆盖。该配置项默认为yes。

1
2
# Example 
replica-read-only yes

repl-ping-replica-period

该配置项默认值为10,表示从节点每隔 10s 将向主节点执行 PING 命令,以确认两者之间的关系正常。

1
2
# Example 
repl-ping-replica-period yes

repl-timeout

repl-timeout配置项为主从节点之间设置了一个通信的超时时间。若该配置项指定的时间内发现两者没有通信,则认为主从节点间的链接异常。这个配置项的值在设置的时候需要大于 replica-read-only配置项的值,否则在主从节点之间数据量较低的情况下,可能会一直检测到「超时」。

1
2
# Example 
repl-timeout yes

repl-disable-tcp-nodelay

repl-disable-tcp-nodelay配置项主要用于控制主从节点同步数据的速率。若该配置项的值为 yes,则 Redis 将使用更小尺寸的 TCP 报文和更小的带宽来进行数据同步操作。好处比较明显,能够控制 Redis 数据同步的流量,坏处就是增加了数据同步的时延。反之,如果设置为 no,则会去掉这个限制。提升数据同步的效率。

1
2
# Example 
repl-disable-tcp-nodelay yes

repl-backlog-size && repl-backlog-ttl

Master 节点会为 Slave 节点配置一个复制缓冲区,用来保存最新的需要同步的数据。当 Slave 节点和 Master 节点断开连接之后又重新建立链接的时候,很可能只需要一次「局部」的同步操作即可实现主从数据的一致性。这就是复制缓冲区的作用。而 repl-backlog-size 配置项,指定了这个缓冲区的大小。缓冲区越大,那么保存的数据也就越多,对 Slave 节点离线时间的长度容忍度也就越高。

但是,如果主从链接是我们有意断开的,这个复制缓冲区总不能一直保存在那里。所以 Redis 提供了repl-backlog-ttl配置项,当主从链接断开的时间超过该配置项的值的时候,Master 节点将会清空这个复制缓冲区的内容。

repl-backlog-size 默认值为 16mb,repl-backlog-ttl 为3600。

replica-priority

replica-priority 配置项主要用于 Redis Slave 节点,标识了这个节点的优先级,取值范围从0~100。数字越低,优先级越高。在进行主从切换的时候越有可能被 Sentinel 节点提升为 Master 节点。

1
2
# Example 
replica-priority 100

min-replicas-to-write && min-replicas-max-lag

min-replicas-to-writemin-replicas-max-lag 两个配置项分别指定了最小链接到主节点的活跃的从节点的个数以及最大主从节点通信的延迟。如果在主从节点通信的过程中,这个两个选项的条件有哪一个没有满足,主节点将拒绝客户端的写入操作。前者默认值为3,或者为10,都是秒为单位。

1
2
3
4
# Example
#
# min-replicas-to-write 3
# min-replicas-max-lag 10

slave-announce-ip && slave-announce-port

一般来说,通过对 Master 节点执行 Info Replication 命令,即可通过 Master 节点列出所有的 Slave 节点的相关信息(IP,port 等)。Master 节点本来是可以通过两者之间的链接来发现 Slave 节点的 IP 和端口的。但是,如果在环境中启动了 NAT 或者端口转发机制(尤其是在 Docker 和 k8s 中),或者说,两者通信链路之间还通过了一些「代理」,在 Master 上显示的 Slave 节点的信息可能就不准确。所以,用户可以通过 slave-announce-ipslave-announce-port 配置项,强制指定 Slave 节点的 IP 和 Port,并将此信息通知给 Master 节点。

1
2
3
# Example
# replica-announce-ip 5.5.5.5
# replica-announce-port 1234

Security

requirepass

用户可以通过requirepass配置项为 Redis Server 设置密码。客户端在连接了服务端之后,需要使用密码鉴权才能够执行命令。

rename-command

rename-command 是 Redis 为提升其安全性加入的配置项。它允许用户将一些高危命令进行重命名,以防止用户不小心或者恶意对数据库做出一些危险的操作。

这个配置项虽然有用,可以提升安全性。但是最好用在 Redis 实例只有一个用户使用的场景下。因为不同的用户需求不同,强行禁用掉一些命令也并不是一个好事。

1
2
3
# Example
# rename-command CONFIG ""
# rename-command flushall ""

Memory

内存对于 Redis 是一个非常重要的资源,它是 Redis 高性能的支撑点,同时也是最容易出问题的地方。所以,Redis 也开放了一些配置项,使得用户可以根据自己不同的使用姿势来对 Redis 使用内存的行为作出一些限制,以此来提高效率和防止一些问题的发生。

maxmemory && maxmemory-policy

该配置项允许用户为 Redis 配置一个「最大内存使用值」。如果用户在设置了maxmemory的同时还通过 maxmemory-policy设置了一定的缓存淘汰策略。那么当Redis 实例的内存使用量达到阈值之后,会通过「淘汰规则」清理掉一部分的数据,以留出足够的空间来正常响应后续的写入操作。否则,若没有设置淘汰策略(默认为noeviction),当 Redis 实例的内存达到阈值之后,会拒绝写入操作,但是正常响应读取操作。

1
2
3
# Example
# maxmemory <bytes>
# maxmemory-policy noeviction

maxmemory-samples

Redis 在执行内存淘汰策略的时候,会按照一定的规则选取「候选样本」。比如,当用户将maxmemory-policy设置为volatile-lru的时候,如果 Redis 实例的内存用量达到了maxmemory指定的阈值,Redis 就会每次取maxmemory-samples个 key 为样本,删掉一个最近未使用时间最长的 key。maxmemory-samples设置的值越大,淘汰策略越接近真实的 LRU 算法,但是同时给 CPU 造成的压力也会增加。否则,虽然会运行的比较快,但是淘汰的效果不会很好。

1
2
# Example
# maxmemory-samples 5