Redis使用——Redis的redis.conf配置注释详解（三）

背景

日常我们开发时，我们会遇到各种各样的奇奇怪怪的问题（踩坑o(╯□╰)o），这个常见问题系列就是我日常遇到的一些问题的记录文章系列，这里整理汇总后分享给大家，让其还在深坑中的小伙伴有绳索能爬出来。
同时在这里也欢迎大家把自己遇到的问题留言或私信给我，我看看其能否给大家解决。

开发环境

系统：Ubuntu
工具：Docker
镜像：Redis
官方配置：redis.conf

内容

本节对于其Redis的redis.conf配置进行注释翻译，确定各个配置的主要用途，便于日后配置使用，由于redis.conf中的配置较多，因此我们拆分为四节进行，话不多说下面开始。

############################# LAZY FREEING ####################################

# Redis有两个基本的删除键。一个是DEL，它是对象的阻塞删除。这意味着服务器停止处理新命令，以便以同步方式回收与对象关联的所有内存。 
# 如果删除的键与一个小对象相关联，执行DEL命令所需的时间非常小，可以与Redis中的大多数其他O(1)或O(log_N)命令相媲美。
# 但是，如果键与包含数百万个元素的聚合值相关联，服务器可能会阻塞很长时间(甚至几秒)以完成操作。
#
# 基于上述原因，Redis还提供了非阻塞删除原语，如UNLINK(非阻塞DEL)和FLUSHALL和FLUSHDB命令的ASYNC选项，以便在后台回收内存。
# 这些命令在固定时间内执行。另一个线程将在后台以尽可能快的速度逐步释放该对象。
#
# FLUSHALL和FLUSHDB的DEL、UNLINK和ASYNC选项由用户控制。
# 什么时候最好使用其中一种，这取决于应用程序的设计。然而，Redis服务器有时不得不删除键或刷新整个数据库作为其他操作的副作用。
# 具体来说，在以下情况下，Redis会独立于用户调用来删除对象:
#
# 1) 在回收时，由于maxmemory和maxmemory策略配置，为了为新数据腾出空间，而不会超过指定的内存限制。
# 2) 因为expire:当必须从内存中删除一个与生存时间相关的键时(请参阅expire命令)。
# 3) 因为将数据存储在可能已经存在的键上的命令有副作用。例如，RENAME命令在用另一个密钥替换旧密钥时可能会删除旧密钥内容。类似地，带有STORE选项的SUNIONSTORE或SORT可以删除现有的密钥。SET命令本身删除指定键的任何旧内容，以便用指定的字符串替换它。
# 4) 在复制期间，当一个副本与它的主副本执行完全的重新同步时，为了加载刚刚传输的RDB文件，整个数据库的内容将被删除。
#
# 在上述所有情况下，默认情况是以阻塞的方式删除对象，就像调用DEL一样。
# 不过，您可以使用下面的配置指令来配置每种情况，以非阻塞方式释放内存，就像调用UNLINK时那样。

lazyfree-lazy-eviction no
lazyfree-lazy-expire no
lazyfree-lazy-server-del no
replica-lazy-flush no

# 也有可能，当用UNLINK调用替换用户代码DEL调用不容易时，修改DEL命令的默认行为，使其完全像UNLINK一样，使用以下配置指令:

lazyfree-lazy-user-del no

################################ THREADED I/O #################################

# Redis主要是单线程的，但是也有一些线程操作，如UNLINK，缓慢的I/O访问和其他一些在侧线程上执行的事情。
#
# 现在也可以处理Redis客户端套接字读写在不同的I/O线程。
# 由于写的特别慢，通常Redis用户使用流水线来提高每个核心的Redis性能，并产生多个实例，以扩大规模。
# 使用I/O线程可以很容易地加速两倍的Redis，而无需诉诸于管道或分片的实例。
#
# 默认情况下线程是禁用的，我们建议只在至少有4个或更多内核的机器上启用它，留下至少一个空闲内核。
# 使用超过8个线程不会有太大帮助。我们也建议只有当你确实有性能问题时才使用线程I/O，因为Redis实例能够使用相当大比例的CPU时间，否则使用这个特性没有意义。
#
# 例如，如果你有一个4核的盒子，尝试使用2或3个I/O线程，如果你有一个8核，尝试使用6个线程。为了启用I/O线程，请使用以下配置指令:
#
# io-threads 4
#
# 将io-threads设置为1只会像往常一样使用主线程。
# 当I/O线程被启用时，我们只使用线程写，即线程写(2)系统调用和传输客户端缓冲区到套接字。
# 然而，也可以使用下面的配置指令启用线程读取和协议解析，通过设置它为yes:
#
# io-threads-do-reads no
#
# 通常线程读取没有多大帮助。
#
# 注1:此配置指令不能在运行时通过CONFIG SET更改。因此，当启用SSL时，该特性目前无法工作。
#
# 注2:如果你想使用Redis -benchmark测试Redis加速，请确保你也在线程模式下运行基准测试本身，使用——threads选项来匹配Redis线程的数量，否则你将无法注意到改进。

############################ KERNEL OOM CONTROL ##############################

# 在Linux上，当内存不足时，可以提示内核OOM杀手应该首先杀死哪些进程。
#
# 启用该功能使Redis主动控制其所有进程的oom_score_adj值，取决于他们的角色。默认的分数会尝试让后台子进程在所有其他进程之前被终止，副本在主进程之前被终止。
#
# Redis支持三个选项:
#
# no:       不要更改oom-score-adj(默认)。
# yes:     别名“relative”，见下文。
# absolute: oom-score-adj-values中的值按照内核的方式写入。
# relative: 当服务器启动时，相对于oom_score_adj的初始值使用值，然后固定在-1000到1000的范围内。
# 因为初始值通常是0，它们通常会匹配绝对值。
oom-score-adj no

# 当使用oom-score-adj时，这个指令控制主进程、复制进程和后台子进程的特定值。值范围为-2000到2000(越高表示越有可能被杀死)。
#
# 无特权进程(非根进程，且不具有CAP_SYS_RESOURCE功能)可以自由增加它们的值，但不能将其降低到初始设置以下。这意味着将oom-score-adj设置为“相对”，并将oom-score-adj-values设置为正值将始终成功。
oom-score-adj-values 0 200 800

############################## APPEND ONLY MODE ###############################

# 默认情况下，Redis将数据集异步转储到磁盘上。
# 这种模式在许多应用中已经足够好了，但是Redis进程的问题或者断电可能会导致几分钟的写丢失(取决于配置的保存点)。
#
# The Append Only File是一种持久性模式，它提供了更好的持久性。例如使用默认数据fsync策略配置文件中(见后)复述,可以失去只是一秒的写在一个戏剧性的事件像一个服务器断电,或一个写如果复述过程本身出了问题,但正确操作系统仍在运行。
#
# AOF和RDB持久性可以同时启用，没有问题。
# 如果在启动时启用了AOF, Redis将加载AOF，这是具有更好的耐久性保证的文件。
#
# 请登录http://redis.io/topics/persistence了解更多信息。

appendonly no

# apponly文件的名称(默认:"appendonly.aof")

appendfilename "appendonly.aof"

# fsync()调用告诉操作系统实际将数据写入磁盘，而不是等待输出缓冲区中的更多数据。
# 一些操作系统真的会刷新磁盘上的数据，而另一些操作系统会尽快尝试这么做。
#
# Redis支持三种不同的模式:
#
# no:不要fsync，只要让操作系统在需要的时候刷新数据。得更快。
# always: fsync每次写入只追加日志后。缓慢的,安全的。
# everysec:每秒只同步一次。妥协。
#
# 默认值是“everysec”, 因为这通常是速度和数据安全之间的正确妥协。 
# 这取决于您是否能够理解是否可以将其放宽为“no”，从而让操作系统在需要时刷新输出缓冲区，
# 为了获得更好的性能(但如果您可以接受一些数据丢失的想法，请考虑默认的持久模式，即快照)，或者相反，
# 使用“always”，它非常慢，但比everysec更安全。
#
# More details please check the following article:
# http://antirez.com/post/redis-persistence-demystified.html
#
# If unsure, use "everysec".

# appendfsync always
appendfsync everysec
# appendfsync no

# 当AOF fsync策略设置为always或everysec，并且后台保存进程(后台保存或AOF日志后台重写)对磁盘执行大量I/O时，在某些Linux配置中，Redis可能会阻塞太长时间的fsync()调用。
# 注意，目前还没有解决这个问题，因为即使在不同的线程中执行fsync也会阻塞我们的同步写(2)调用。
#
# 为了缓解这个问题，可以使用下面的选项来防止在进行BGSAVE或BGREWRITEAOF时在主进程中调用fsync()。
#
# 这意味着当另一个孩子在保存，Redis的持久性是相同的“appendfsync none”。
# 实际上，这意味着在最糟糕的情况下(使用默认的Linux设置)可能会丢失30秒的日志。
#
# 如果您有延迟问题，将此转换为“yes”。否则，从耐久性的角度来看，“no”是最安全的选择。

no-appendfsync-on-rewrite no

# 自动重写append only文件。
# Redis能够自动重写日志文件隐式调用BGREWRITEAOF时，AOF日志大小增长指定的百分比。
#
# Redis会记住最近一次重写后AOF文件的大小(如果重启后没有重写，则使用启动时的AOF大小)。
#
# 这个基本大小与当前大小比较。如果当前大小大于指定的百分比，则会触发重写。
# 您还需要指定要重写的AOF文件的最小大小，这对于避免重写AOF文件非常有用，即使达到了百分比增长，但它仍然非常小。
#
# 指定0的百分比，以禁用自动AOF重写特性。

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

# 在Redis启动过程中，当AOF数据被加载回内存时，一个AOF文件可能会被截断。
# 当Redis运行的系统崩溃时可能会发生，特别是当ext4文件系统没有data=ordered选项时(然而当Redis本身崩溃或中止，但操作系统仍然正常工作时不会发生)。
#
# Redis可以退出与错误时，这发生，或加载尽可能多的数据(默认现在)，并开始如果AOF文件被发现被截断在最后。以下选项控制此行为。
#
# 如果AOF -load-truncated设置为yes，则加载一个被截断的AOF文件，Redis服务器开始发送日志来通知用户该事件。
# 如果该选项设置为no，服务器将以错误终止并拒绝启动。当该选项被设置为no时，用户需要在重启服务器之前使用“redis-check-aof”实用程序修复AOF文件。
#
# 请注意，如果发现AOF文件在中间被损坏，服务器仍然会以错误退出。
# 这个选项只适用于当Redis将试图从AOF文件读取更多数据，但没有找到足够的字节时。
aof-load-truncated yes

# 当重写AOF文件时，Redis能够在AOF文件中使用RDB序言，以更快地重写和恢复。当打开这个选项时，重写的AOF文件将由两个不同的节组成:
#
#   [RDB file][AOF tail]
#
# 当加载时，Redis识别到AOF文件以“Redis”字符串开始，并加载带前缀的RDB文件，然后继续加载AOF尾部。
aof-use-rdb-preamble yes

################################ LUA SCRIPTING  ###############################

# Lua脚本最大执行时间(以毫秒为单位)
#
# 如果达到最大执行时间，Redis将记录一个脚本在最大允许的时间后仍在执行，并将开始回复一个错误的查询。
#
# 当长时间运行的脚本超过最大执行时间时，只有script KILL和SHUTDOWN NOSAVE命令可用。
# 第一种方法可用于停止尚未调用任何写命令的脚本。
# 第二种方法是在脚本已经发出写命令但用户不想等待脚本自然终止的情况下关闭服务器的唯一方法。
#
# 将它设置为0或负值，表示无限执行而没有警告。
lua-time-limit 5000

################################ REDIS CLUSTER  ###############################

# 普通的Redis实例不能成为Redis集群的一部分;只有作为集群节点启动的节点才能启动。为了启动一个Redis实例作为一个集群节点，集群支持取消注释如下:
#
# cluster-enabled yes

# 每个集群节点都有一个集群配置文件。此文件不打算手工编辑。它由Redis节点创建和更新。
# 每个Redis集群节点需要一个不同的集群配置文件。
# 确保在同一系统中运行的实例没有重叠的集群配置文件名称。
# cluster-config-file nodes-6379.conf

# 集群节点超时是指节点处于故障状态时无法访问的毫秒数。
# 大多数其他内部时间限制是节点超时的倍数。
#
# cluster-node-timeout 15000

# 如果数据看起来太旧，故障主机的副本将避免启动故障转移。
#
# 对于一个副本来说，没有一种简单的方法可以精确地测量它的“数据时代”，因此执行以下两个检查:
#
# 1) 如果有多个副本能够进行故障转移，它们就会交换消息，以尽量使副本具有最好的复制偏移量(处理更多来自主服务器的数据)。
#   副本将尝试通过偏移量获得它们的秩，并在故障转移开始时应用与它们的秩成比例的延迟。
#
# 2) 每个副本都计算与它的主节点最后一次交互的时间。这可以是接收到的最后一次ping或命令(如果主服务器仍处于“连接”状态)，也可以是与主服务器断开连接后所经过的时间(如果复制链路当前处于断开状态)。
#   如果最后一次交互太旧，则副本根本不会尝试故障转移。
#
# 点“2”可由用户调整。具体来说，如果副本与主服务器的最后一次交互时间大于以下情况，则副本不会执行故障转移:
#
#   (node-timeout * cluster-replica-validity-factor) + repl-ping-replica-period
#
# 例如，如果node-timeout是30秒，而cluster-replica-validity-factor是10，并且假设默认的repp -ping-replica-period是10秒，那么如果副本无法与主服务器对话的时间超过310秒，它将不会尝试进行故障转移。
#
# 一个较大的集群副本有效性因子可能允许具有太旧数据的副本对主服务器进行故障转移，而太小的值可能会阻止集群能够选择一个副本。
#
# 为了获得最大可用性，可以将集群副本有效性因子设置为0，这意味着副本将始终尝试对主服务器进行故障转移，而不管它们最后一次与主服务器交互是什么时候。
# (但是他们总是会尝试与他们的偏移等级成比例的延迟)。
#
# 0是唯一能够保证当所有分区恢复时，集群将始终能够继续的值。
#
# cluster-replica-validity-factor 10

# 集群副本能够迁移到孤立的主节点，即没有工作副本的主节点。
# 这提高了集群抵抗故障的能力，否则，如果孤立的主节点没有工作副本，就不能在故障发生时进行故障转移。
#
# 只有当旧主服务器上仍然有至少给定数量的其他工作副本时，副本才会迁移到孤立的主服务器。
# 这个数字就是“migration barrier”。migration barrier为1意味着一个副本只有在它的主副本至少有一个其他工作副本时才会迁移，以此类推。
# 它通常反映您希望集群中每个主机的副本数量。
#
# 默认值是1(副本只有在它们的主副本至少保留一个副本时才迁移)。要禁用迁移，只需将其设置为一个非常大的值。
# 可以设置值0，但仅用于调试，在生产中是危险的。
#
# cluster-migration-barrier 1

# 默认情况下，Redis集群节点停止接受查询，如果他们检测到至少有一个哈希槽未被发现(没有可用的节点正在服务它)。
# 这样，如果集群部分关闭(例如不再覆盖散列槽范围)，所有集群最终将不可用。
# 一旦所有的插槽被再次覆盖，它将自动返回可用。
#
# 然而，有时您希望正在工作的集群子集继续接受对仍然覆盖的键空间部分的查询。为此，只需将cluster- required -full-coverage选项设置为no。
#
# cluster-require-full-coverage yes

# 当设置为yes时，该选项将阻止副本在主服务器故障期间尝试故障转移。但是，如果被迫，主服务器仍然可以执行手动故障转移。
#
# 这在不同的场景中非常有用，特别是在多个数据中心操作的情况下，如果不是在整个DC故障的情况下，我们希望永远不要提升其中的一方。
#
# cluster-replica-no-failover no

# 这个选项，当设置为yes时，允许节点在集群处于down状态时提供读流量，只要它认为它拥有槽。
#
# 这在两种情况下是有用的。第一种情况是应用程序在节点故障或网络分区期间不需要数据一致性。
# 其中一个例子是缓存，只要节点拥有数据，它就应该能够为其提供服务
#
# 第二个用例用于配置不满足推荐的三个分片，但希望稍后启用集群模式和扩展。
# 在没有设置此选项的情况下，1或2分片配置中的主中断会导致整个集群的读/写中断，如果设置了该选项，则只有写中断。
# 没有足够的masters，插槽所有权不会自动改变。
#
# cluster-allow-reads-when-down no

# 为了设置集群，请务必阅读http://redis.io网站提供的文档。

########################## CLUSTER DOCKER/NAT support  ########################

# 在某些部署中，由于地址nat转换或端口转发导致Redis Cluster节点地址发现失败(典型的是Docker和其他容器)。
# 为了让Redis Cluster在这样的环境中工作，需要一个静态配置，每个节点都知道自己的公共地址。以下两个选项用于此范围，它们是:
#
# * cluster-announce-ip
# * cluster-announce-port
# * cluster-announce-bus-port
#
# 每个节点都将其地址、客户端端口和集群消息总线端口指示给节点。
# 然后在总线包的头部发布信息，以便其他节点能够正确地映射发布信息的节点的地址。
#
# 如果不使用上述选项，将使用正常的Redis集群自动检测。
#
# 注意，当重新映射时，总线端口可能不在客户端端口+ 10000的固定偏移量上，所以您可以指定任何端口和总线端口，这取决于它们如何重新映射。
# 如果没有设置总线端口，则固定偏移量10000将被使用。
#
# 例如:
#
# cluster-announce-ip 10.1.1.5
# cluster-announce-port 6379
# cluster-announce-bus-port 6380

################################## SLOW LOG ###################################

# Redis Slow Log是一个记录超过指定执行时间的查询的系统。
# 执行时间不包括I / O操作,比如与客户端,发送应答等等,但就实际执行命令所需的时间(这是唯一阶段命令执行的线程被阻塞,不能同时处理其他请求)。
#
# 你可以用两个参数配置慢日志:一个告诉Redis执行时间，以微秒为单位，为了命令被记录，另一个参数是慢日志的长度。
# 当记录新命令时，最老的命令将从记录的命令队列中删除。

# 下面的时间用微秒表示，因此1000000相当于1秒。请注意，负数禁用慢日志，而0值强制记录每个命令。
slowlog-log-slower-than 10000

# 这个长度没有限制。请注意，它将消耗内存。
# 您可以使用SLOWLOG RESET来回收慢日志所使用的内存。
slowlog-max-len 128

更多内容详见 Redis使用——Redis的redis.conf配置注释详解（四）