Redis—配置参数介绍_redis配置

---

前言

  因不同版本的参数可能有差别，本文涉及的主要涉及5、6版本常见参数。

---

一、基础配置

daemonize
  默认配置：daemonize no，redis默认不是以守护进程的方式后台运行，如果想后台运行，开启配置：daemonize yes

supervised
  是否supervised模式运行Redis
  默认配置：supervised no

pidfile
  如果配置指定了 pid 文件，Redis 就用该配置的 pid 文件写入，退出的时候移除对应的 pid 文件。
  如果 Redis 是以非守护进程模式的运行，又没有配置指定的 pid 文件，那么不会创建 pid 文件。如果 Redis 是守护进程的模式，即使没有配置指定的 pid 文件，会默认使用 “/var/run/redis.pid”文件。
  默认值：pidfile /var/run/redis_6379.pid

loglevel
  指定 Server 的日志级别
  有以下四种级别：

• debug（包含许多具体信息，开发/测试环境下很方便）
• verbose（包含许多不常用的信息，但没有 debug 级别那么混乱）
• notice（适中的信息，很适合生产环境）
• warning（只记录重要或者非常的信息）

  默认配置：loglevel notice

logfile
  指定 log 文件名。配置成空串的话可以强制 Redis 在标准输出记录日志。如果使用标准输出进行日志记录且是以守护进程的模式运行，日志会在 /dev/null 中。
  默认值：logfile “”

syslog-enabled
  想让日志记录到系统日志，设置 ‘syslog-enabled’ 成 yes
  默认配置：syslog-enabled no

syslog-ident
  指定 syslog 的身份。
  默认配置：syslog-ident redis

syslog-facility
  指定 syslog 工具（facility）。一定要是 USER 或者在 LOCAL0-LOCAL7 之间。
  默认配置：syslog-facility local0

databases
  设置数据库的数量。默认的数据库号是 DB 0。
  默认配置：databases 16

always-show-logo
  Redis 会在启动的时候，如果标准输出日志是 TTY，则会在开始记录标准输出日志的时候展示一个 ASCII 字符组成的 Redis logo。也就是说，通常只在交互的会话中会展示该 logo。
  默认配置：always-show-logo yes

二、持久化配置配置

1. RDB

save
  rdb保存数据,如果时间秒数seconds 和写的次数都配置了，那么一旦达到了配置条件 Redis 会将 DB 保存到硬盘。
  以默认配置举例，达到了以下条件会触发写磁盘：

	900 秒内（15 分钟）且数据库中至少有一个 key 被改变。
	300 秒内（5 分钟）且数据库中至少有10 个 key 被改变。
	60 秒内且数据库中只有一个 10000 个 key 被改变。
1
2
3

  可以通过添加一个带空串的 save 指令来让配置的 save 选择失效。比如：save “”
  默认配置：
  save 900 1
  save 300 10
  save 60 10000

stop-writes-on-bgsave-error
  在开启了 RDB 快照后，如果最近的一次 RDB 快照在后台生成失败的话，Redis 默认会拒绝所有的写请求。这么做的目的是为了让用户注意到后台持久化可能出现了问题。否则用户可能一直无法注意到问题，进而可能导致灾难级别的事情发生。
  如果bgsave正常，Redis 会自动的继续处理写请求。
  如果已经为 Redis 实例和持久化配置了合适的监控手段，且希望 Redis 在非理想情况下（比如硬盘问题，权限问题等等）仍继续提供服务，可以将此项配置为 no。
  默认配置：stop-writes-on-bgsave-error yes

rdbcompression
  想要在生成 rdb 文件的时候使用 LZF 压缩 String 对象？将该配置保持默认为 ‘yes’ 几乎不会出现意外状况。
  可以将该配置设置为 “no” 来节省 CPU 开销。但是那些原本可以被压缩的 key 和 value 会让数据集更大。
  默认配置：rdbcompression yes

rdbchecksum
  从 5.0 版本开始 RDB 文件的末尾会默认放置一个 CRC64 的校验码。
  这会让文件的格式更加容易检验验证，代价是生成和加载 RDB 文件的性能会损失 10% 左右。你可以把该配置关闭以求更佳的性能。没有开启校验码配置的 RDB 文件会将校验码设置为 0，加载该文件的程序就会跳过校验过程。
  默认配置：rdbchecksum yes

dbfilename
  配置 rdb 文件的名称。
  默认配置：dbfilename dump.rdb

dir
  工作目录，存储 rdb 文件的目录。数据库会使用该配置放置 rdb 文件，文件的名字使用上面的 ‘dbfilename’ 指定的文件名。AOF 文件的存储位置也会使用这个配置项。
  注意：配置一个目录而不是文件名。
  默认配置：dir ./

2. AOF

appendonly
  Redis 默认使用异步方式转储数据到硬盘。但在 Redis 处理出现问题或者设备断电的意外期间可能丢失相应的写操作（取决于 save 配置的时间点）。
  AOF 文件是 Redis 提供的另外一种提供更好的持久性的持久化模式。例如如果使用默认的数据传输策略（根据之后提供的配置）Redis 在发生意外情况下比如设备断电，或者 Redis 本身的进程出现了一些问题的情况下（操作系统正常运行），Redis 可以仅仅丢失 1 秒钟的写操作。
  AOF 和 RDB 的持久化策略可以同时启用。如果打开了 AOF，Redis 启动时会加载 AOF。
常见配置：

	appendonly yes                   #开启AOF
	appendfilename "appendonly.aof" #AOF 的文件名
1
2

appendfsync
  函数 fsync() 会告诉操作系统立即把数据写到磁盘上而不是等输出缓冲区有更多的数据时才进行。有些 OS 会马上把数据刷到硬盘，有些 OS 只保证尽快进行刷盘操作。
Redis 支持三种模式：

• no：不 fsync，让操作系统来决定什么时候进行刷盘。最不会影响 Server 响应。
• always：每写入 aof 文件就进行 fsync。影响 Server 响应，但是数据更安全。
• everysec：每秒进行 fsync。最稳健的形式。

  默认的模式是 everysec，在响应速度和数据安全方面最稳妥的选择。选择 no ，让 OS 选择写入时机，这样有更好的性能表现。又或者使用 always，可以会让响应变慢一些但是数据的安全性会更高。如果不确定选哪种的话，那就用 “everysec” 吧。

no-appendfsync-on-rewrite
  当 AOF fsync 策略是 always 或者 everysec，会启动一个后台进程（后台进行保存或者 AOF 文件的后台重写），该进程会在磁盘上频繁的 I/O，在一些 Linux 配置下 Redis 的 fsync() 调用可能会阻塞太久。需要注意的是目前还没有相应的优化策略，极端情况下在不同线程进行的 fsync 可能阻塞同步的 write(2) 调用。
  为了减缓上面提到的问题，可以在主线程调用 BGSAVE 或者 BGREWRITEAOF 命名避免 fsync() 在主线程上调用。这意味着当其他的子节点在保存的时候，Redis 的持久化就和 “appendfsync no” 策略一样。这意味着在实际中的最糟糕的场景下（在默认的 Linux 配置下）有可能丢失超过 30s 时间粒度的 log。
  如果应用不能忍受延迟问题，将下面的选项配置为 “yes”。否则保持为 “no”，这样在持久化的角度上是最安全的选择。
  no-appendfsync-on-rewrite no

auto-aof-rewtire-percentage和auto-aof-rewrite-min-size
  自动重写 aof 文件。Redis 支持调用 BGREWRITEAOF 命名，并在 AOF 文件达到特定的百分比的时候自动重写 AOF 文件。
  一般是这么工作的：Redis 会记录最近一次重写后的 AOF 文件大小（如果启动后没有重写过，则记录启动时的 AOF 文件大小）。基础的文件大小和当前的文件大小进行比较。如果当前的大小比配置的百分比大，则触发重写操作。同时也应该配置一个触发重写的最小文件大小，这么做可以避免当 AOF 文件达到了配置的百分比，但是 AOF 文件还是很小的情况触发重写操作。配置百分比为 0 意味着关闭自动重写 AOF 的特性。

• auto-aof-rewtire-percentage 100
• auto-aof-rewrite-min-size 64mb

aof-load-truncated
  当 AOF 文件的数据加载到内存的时候，AOF 文件可能在 Redis 启动的时候在末尾被截断。这可能在跑 Redis 进程的系统崩溃的情况下出现，特别是当一个 ext4 文件系统挂载的时候没有使用 data=ordered 选项（但是，在 Redis 进程自己崩溃或者中止，但是操作系统还正常运行时，这种情况就不会发生）。
  当 Redis 发现 AOF 在末尾被截断的时候，Redis 可以主动退出进程或者尽可能的加载更多的数据（目前的默认行为）并正常启动。
如果 aof-load-truncated 设置成 yes，Redis 加载被截断的 AOF 文件，redis启动并将相关的信息写到 log 中通知用户有这一现象发生。如果设置成 no，Redis 错误充电并拒绝启动。当该配置设置为 no 的时候，就要求用户在重启服务前使用 “redis-check-aof” 来修复 AOF 文件。
  注意：如果 AOF 文件的中间位置出现了问题，Redis 仍会错误退出。这个配置选项只在 Redis 想从 AOF 文件中读取更多数据但是实在没有新的可以读取的情况下才有作用。
  默认值：aof-load-truncated yes

aof-use-rdb-preamble
  当重写 AOF 文件的时候，Redis 也可以在 AOF 文件在开头应用 RDB 文件来更快的重写和恢复。当该配置选项开启，AOF 文件的重写组成由这两部分组成：[RDB file][AOF tail]
  Redis 加载 AOF 文件的时候发现 AOF 文件里由 “REDIS” 字符串打头，Redis 就会加载预先的 RDB 文件，接着在尾部加载 AOF 文件。
  默认配置：aof-use-rdb-preamble yes

三、生产常见配置

1. 安全配置

requirepass
  要求客户端先使用命令 AUTH 进行认证，才能处理其他命令。
  配置格式：requirepass password

rename-command
  命令重命名。可以在环境中重命名那些比较危险的命令。比如把 CONFIG 命令重命名成一个不好猜的名字，这样内部的功能还可以使用，且可以避免大部分的客户端使用。
  例如：rename-command CONFIG abcdef

2. 客户端配置

maxclients
  设置可以同时连接客户端的最大数量。默认该项设置为 10000 个客户端。一旦达到该限制数 Redis 会拒绝所有的新连接并返回错误信息 ‘max number of clients reached’。
  配置格式：maxclients 10000

3. 内存管理

maxmemory
  设置限定的最大内存使用。当内存使用达到限制 Redis 会根据配置的淘汰策略（见 maxmemory-policy）移除键值对。
  如果根据淘汰策略，Redis 不能移除键值对，Redis 会拒绝那些申请更大内存的命令，比如 SET，LPUSH 等等，但是仍可以处理读请求，比如 GET 等。
  该选项对那些使用 Redis 进行 LRU，LFU 缓存系统或者硬性限制内存很友好（使用 ‘noeviction’ 策略）。
  如果为实例配置了 maxmemory，且该实例配置了子节点，那么已使用内存的大小就需要加上为副本配置的输出缓冲区的大小。这样因为网络问题/重新同步不会一直触发键的淘汰行为。相反的，副本缓冲区中充满了对键的删除或淘汰的情况可能触发更多 key 被淘汰，以此类推直到库完全被清空。简单说就是，如果为实例配置了副本，那么建议设置一个较低的 maxmemory 值，这样系统中就有更多的内存空间留给副本缓冲区（如果淘汰策略是 ‘noeviction’ 那上面说的就没有必要）。
  配置格式：maxmemory

maxmemory-policy
  在内存使用达到 maxmemory 后，Redis 如何选择键值对进行淘汰。有以下几种：

	volatile-lru，使用 LRU 算法，在设置了过期时间的 key 中选择。
	allkeys-lru，使用 LRU 算法，在所有的 key 中选择。
	volatile-lfu，使用 LFU 算法，在设置了过期时间 key 中选择。
	allkeys-lfu，使用 LFU 算法，在所有的 key 中选择。
	volatile-random，在设置了过期时间的 key 中随机选择。
	allkeys-random，在所有 key 中随机选择。
	volatile-ttl，在设置了过期时间的 key 中，选择过期时间最近的 key。
	noeviction，不淘汰 key ，对任何写操作（使用额外内存）返回错误。
1
2
3
4
5
6
7
8

• LRU 代表最近最少使用。
• LFU 代码最近最不常使用。
• LRU，LFU 和 volatile-ttl 均由近似的随机算法实现。
  不管采用了以上的哪种策略，对于新的写请求，如果没有合适的 key 可以淘汰，Redis 均会响应一个 error。

  默认策略是：#maxmemory-policy noeviction

maxmemory-samples
  LRU，LFU 以及最小 TTL 的实现都不是精确的而是比较粗略的近似算法（为了节省内存），为了速度或者精确度，可以进行相应的配置。默认 Redis 会检查 5 个 key，在其中选择最近最少使用的，也可以直接在下面的配置项中配置 Redis 选择的样本数量。
  默认配置的值是 5，已经可以有一个很完美的结果。10 的话可能会让选择策略更像真正意义上的 LRU 算法，但是需要更多 CPU 资源。3 的话会更快，但是不够精确。
  #maxmemory-samples 5

replica-ignore-maxmemory
  从 Redis 5.0 之后，副本默认会忽略为其配置的 maxmemory 选项（除非因为故障转移（failover）或者选择将其晋升为主节点）。也就是说 key 的淘汰只会由主节点执行，副本对应的是主节点发送对应的删除命令给副本作为 key 的淘汰方式。
  这个行为模式保证了主副节点的一致性，但是如果副本是可写的或者你想要你的副本有不同的内存配置，而且你也很确认到达副本的写操作能保证幂等性（idempotenet），那你可以修改这个默认值（但是最好保证你理解了这么做的原因）。
  提示：因为副本默认没有 maxmemory 和淘汰策略，副本实际的内存占用可能比 maxmemeory 配置的值大（可能因为副本缓冲区，或者某些数据结构占用了额外的内存等等原因）。所以确保对副本有合适的监控手段，保证在主节点达到配置的 maxmemory 设置之前，副本有足够的内存保证不会出现真正的 out-of-memory 条件。
  #replica-ignore-maxmemory yes

4. 其他配置

CLUSTER DOCKER/NAT support
  在某些部署情况中，Redis 集群节点可能会出现地址发现失败，原因是地址是 NAT-ted 或者端口转发（一个典型的场景就是 Docker 或者其他容器）。为了让 Redis 集群在这种环境下正常工作，就需要个静态的配置文件来让集群节点知晓他们的公共地址。下面两个选项就有这个作用：

cluster-announce-ip
cluster-announce-port
cluster-announce-bus-port
1
2
3

SLOW LOG（慢日志）
  Redis 的慢日志用来记录那些执行了超过特定时间的查询行为。这里的执行时间不包括 I/O 操作，比如和客户端的通信，发送回复的时间等等。而应该只是执行了这个命令本身需要的时间（就是说执行这个命令期间，线程会阻塞且不会同时响应其他的请求）。
  慢日志有两个属性可以配置：一个用来告诉 Redis 执行时间的定义，什么样的执行时间才要被记录。另一个用来配置慢日志的长度。记录一个新的命令，队列中的最旧的命令会被移除。

下面配置的时间单位是微秒，所以 1000000 相当于 1 秒。注意如果配置的是负值，慢日志则不起作用。如果是 0 的话，慢日志则会记录每个命令。
  slowlog-log-slower-than 10000
长度的配置没有任何限制。但是主要内存的消耗。可以使用慢日志的 SLOWLOG RESET 来回收内存。
  slowlog-max-len 128

LATENCY MONITOR（延迟监控）
  Redis 的延迟监控系统会在 Redis 运行期间以不同的操作对象为样本，收集和 Redis 实例相关的延迟行为。用户可以通过 LETENCY 命令，打印相关的图形信息和获取相关的报告。延迟监控系统只会收集那些执行时间超过了我们通过 latency-monitor-threshold 配置的值的操作。当latency-monitor-threshold 的值设置为 0 的时候，延迟监控系统就会关闭。
默认情况下延迟监控是关闭的，因为大多数情况下可能没有延迟相关的问题，而且收集数据对性能表现是有影响的，虽然影响很小，但是在系统高负载运行情况下还是不能忽视的。延迟监控系统可以在运行期间使用 “CONFIG SET latency-monitor-threshold milliseconds” 开启。
  #latency-monitor-threshold 0

LAZY FREEING（懒释放）
  Redis 有两个可以删除 key 的原语（primitive）。其中一种是调用 DEL ，阻塞地删除对象。也就是说 Redis Server 需要通过同步的方式确认回收了所有和刚才删除的 key 相关的内存后，才能处理接下来的命令。如果要删除的 key 很小，执行 DEL 命令的时间也很短，和其他时间复杂度为 O(1) 或 O(log_N) 的命令差不多。但是，如果要删除的 key 涉及到一个存储着百万级别元素的集合，Redis server 就可能因此阻塞一段时间（甚至到秒的级别）。
  由于同步的处理方式可能带来的问题，Redis 提供了非阻塞的删除原语比如 UNLINK 以及异步的选项比如 FLUSHALL 和 FLUSHDB 命名，为的就是在后台回收内存。这些命名会在固定时间执行（in constant time）。另外的线程会在后台以尽可能快的速度释放这些对象。
  DEL，UNLINK 和带有 ASYNC 选项的FLUSHALL 和 FLUSHDB 命名都可以由用户控制。这取决于应用层面是否理解且合适的使用相应的命令来达到目的。但是还是有一些情况要注意，Redis 有时会因为其他操作的副作用导致触发 key 的删除或者刷新整个数据库。特别是在用户调用了对象删除的以下场景：
  在淘汰策略下，因为配置了 maxmemory 和 maxmemory policy，为了在不超过配置的内存限制下腾出空间给新来的数据。
  因为过期时间的配置：当一个 key 配置了 expire 时间且时间到了，那它必须从内存中移除。命名在已经存在的 key 上进行数据的存储操作的副作用。比如 RENAME 命名在替换的时候需要删除原本的 key 的内容。类似的带有 STORE 选项的 SUNIONSTORE 或者 SORT 命名可能会删除已存在的 key。SET 命令本身为了用新的值替换，会将要操作的 key 的旧值先删除掉。在 REPLICATION 期间，当副本执行了全量同步复制，副本的整个数据库会被清空，然后加载传输来的 RDB 文件。

上面的场景在默认情况下都是以阻塞的方式删除对象，比如调用 DEL 的时候。你在本配置项中为每个场景进行配置，这样就可以像 UNLINK 被调用时以非阻塞的方式释放内存。

lazyfree-lazy-eviction no
lazyfree-lazy-expire no 
lazyfree-lazy-server-del no 
lazyfree-lazy-flush no
1
2
3
4

总结

  以上为Redis常见配置,其中主从和Cluster相关配置未列出。有不对之处欢迎留言指出。