redis.conf

Redis配置文件

请注意，为了读取配置文件，必须以文件路径作为第一个参数来启动Redis：./redis-server /path/to/redis.conf

关於单位的注意事项：当需要内存大小时，可以指定＃以通常的1k 5GB 4M格式，依此类推：
1k => 1000 bytes
1kb => 1024 bytes
1m => 1000000 bytes
1mb => 1024*1024 bytes
1g => 1000000000 bytes
1gb => 1024*1024*1024 bytes
单位不区分大小写，因此1GB 1Gb 1gB都相同。

--- INCLUDES

在此处包括一个或多个其他配置文件。如果您具有可用于所有Redis服务器的标准模板，但还需要自定义一些每台服务器设置，则此功能很有用。包含文件可以包含其他文件，因此请明智地使用此文件。

注意，选项“ include”不会被admin或Redis Sentinel中的命令“ CONFIG REWRITE”重写。由于Redis始终使用最后处理的行作为配置指令的值，最好将包含在此文件的开头，以避免在运行时覆盖配置更改。

如果您有兴趣使用include覆盖配置选项，则最好使用include作为最后一行。例如
include /path/to/local.conf
include /path/to/other.conf

--- MODULES

在启动时加载模块。如果服务器无法加载模块，它将中止。可以使用多个loadmodule指令。

loadmodule /path/to/my_module.so
loadmodule /path/to/other_module.so

--- NETWORK

默认情况下，如果未指定“ bind”配置指令，则Redis侦听来自服务器上所有可用网络接口的连接。可以使用“ bind”配置指令仅侦听一个或多个所选接口，然后侦听一个或多个IP地址。

# Examples:
# bind 192.168.1.100 10.0.0.1
# bind 127.0.0.1 ::1

警告~~~如果运行Redis的计算机直接暴露在Internet上，则绑定到所有接口都是危险的，并且会将实例暴露给Internet上的每个人。因此，默认情况下，我们将取消注释以下的bind指令，这将强制Redis仅侦听IPv4环回接口地址（这意味着Redis将只能接受来自正在运行的同一台计算机上运行的客户端的连接）。

如果您确定要立即收听所有界面，请注释一下以下几行。

bind 127.0.0.1

保护模式是安全保护的一层，以避免访问和利用Internet上打开的Redis实例。

启用保护模式时，如果：

服务器没有使用“ bind”指令显式绑定到一组地址。
未配置密码。

服务器仅接受来自IPv4和IPv6回送地址127.0.0.1和::1以及来自Unix域套接字的客户端的连接。

默认情况下启用保护模式。仅当您确定您希望其他主机的客户端连接到Redis时，即使未配置身份验证，也不会使用“ bind”指令显式列出一组特定的接口，才应禁用它。

protected-mode yes

接受指定端口上的连接，默认为6379（IANA #815344）。如果指定了端口0，则Redis将不会在TCP套接字上侦听。

port 6379

TCP listen() backlog(积压).

在每秒请求数很高的环境中，为了避免客户机连接速度慢的问题，您需要大量积压订单。请注意，Linux内核＃将以无提示的方式将其截断为 /proc/sys/net/core/somaxconn 的值，因此确保同时提高 somaxconn 和 tcp_max_syn_backlog 的值，以获得所需的效果。

tcp-backlog 511

Unix socket(套接字).

指定用于侦听传入连接的Unix套接字的路径。没有默认值，因此在未指定Redis时，Redis将不会在Unix套接字上侦听。

 unixsocket /tmp/redis.sock
 unixsocketperm 700

客户端空闲N秒后关闭连接（0禁用）超时0

TCP keepalive.

如果不为零，请在没有通信的情况下使用SO_KEEPALIVE向客户端发送TCP ACK。这很有用，有两个原因：

检测死亡的同伴。
从中间的网络设备的角度来看，使连接活着。

在Linux上，指定的值（以秒为单位）是用于发送ACK的时间段。注意，关闭连接需要两倍的时间。在其他内核上，期限取决于内核配置。

此选项的合理值为300秒，这是从Redis 3.2.1开始的新Redis默认值。

tcp-keepalive 300

TLS/SSL

默认情况下，禁用TLS / SSL。要启用它，可以使用“ tls-port”配置指令来定义TLS侦听端口。要在默认端口上启用TLS，请使用：

port 0
tls-port 6379

配置X.509证书和私钥，以用于对连接的客户端，主服务器或群集对等服务器进行身份验证。这些文件应为PEM格式。

tls-cert-file redis.crt 
 tls-key-file redis.key

配置DH参数文件以启用Diffie-Hellman（DH:）密钥交换：

 tls-dh-params-file redis.dh

配置CA证书捆绑包或目录以对TLS / SSL客户端和对等方进行身份验证。 Redis需要其中至少一项的显式配置，并且不会隐式使用系统范围的配置。

tls-ca-cert-file ca.crt
tls-ca-cert-dir /etc/ssl/certs

默认情况下，TLS端口上的客户端（包括副本服务器）是必需的使用有效的客户端证书进行身份验证。

使用此伪指令可以禁用认证。

tls-auth-clients no

默认情况下，Redis副本不尝试建立TLS连接与它的master。

使用以下指令在复制链接上启用TLS。

tls-replication yes

默认情况下，Redis Cluster总线使用纯TCP连接。要为总线协议启用TLS，请使用以下指令：

 tls-cluster yes

明确指定要支持的TLS版本。允许的值不区分大小写，包括“ TLSv1”，“ TLSv1.1”，“ TLSv1.2”，“ TLSv1.3”（OpenSSL> = 1.1.1）或任意组合。要仅启用TLSv1.2和TLSv1.3，请使用：

 tls-protocols "TLSv1.2 TLSv1.3"

配置允许的密码。有关更多信息，请参见 ciphers(1ssl) 联机帮助页。关于此字符串的语法。

注意：此配置仅适用于<= TLSv1.2。

tls-ciphers DEFAULT:!MEDIUM

配置允许的TLSv1.3密码套件。有关此字符串的语法（尤其是TLSv1.3密码套件）的语法的更多信息，请参见ciphers（1ssl）联机帮助页。

tls-ciphersuites TLS_CHACHA20_POLY1305_SHA256

选择密码时，请使用服务器的首选项而不是客户端的首选项。默认情况下，服务器遵循客户端的首选项。

tls-prefer-server-ciphers yes

默认情况下，TLS会话缓存已启用，以允许支持它的客户端进行更快，更便宜的重新连接。使用以下指令禁用缓存。

tls-session-caching no

更改默认的TLS会话缓存数。零值会将缓存设置为无限大小。默认大小为20480。

 tls-session-cache-size 5000

更改缓存的TLS会话的默认超时。默认超时为300 秒。

tls-session-cache-timeout 60

GENERAL(一般)

默认情况下，Redis不会作为守护程序运行。如果需要，请使用“是”。请注意，Redis守护进程将在/var/run/redis.pid中写入一个pid文件。

daemonize no

如果从upstart或systemd运行Redis，Redis可以与您的supervision(管理者) tree进行交互。选项：

supervised no - no supervision interaction
supervised upstart - 通过将Redis置于SIGSTOP模式发出信号upstart
supervised systemd - 通过将 READY=1 写入 $NOTIFY_SOCKET 来产生信号
supervised auto - 根据UPSTART_JOB或NOTIFY_SOCKET环境变量检测upstart 或systemd方法

注意：这些管理方式仅表示“过程已准备就绪”。它们无法使您的管理者连续不断地进行ping操作。

supervised no

如果指定了pid文件，则Redis会在启动时将其写入指定位置并在退出时将其删除。

当服务器以非守护进程运行时，如果在配置中未指定任何pid文件，则不会创建。守护服务器时，即使未指定，也会使用pid文件，默认为“ /var/run/redis.pid”。

创建pid文件是最大的努力：如果Redis无法创建它，则不会发生任何不好的情况，服务器将正常启动并运行。

pidfile /var/run/redis_6379.pid

指定服务器详细级别。

这可以是以下之一：

debug 很多信息，对于开发/测试很有用
verbose 许多很少有用的信息，但不会像调试级别那样混乱
notice 中等冗长，您可能想在生产中使用
warning 仅记录非常重要/重要的消息

loglevel notice

指定日志文件名。空字符串也可以用于强制Redis登录标准输出。请注意，如果您使用标准输出进行日志记录但进行守护进程，则日志将发送到 /dev/null

logfile ""

要启用到系统记录器的日志记录，只需将“ syslog-enabled”设置为yes，并根据需要更新其他syslog参数

syslog-enabled no

指定系统日志标识。

syslog-ident redis

指定系统日志工具。必须是USER或LOCAL0-LOCAL7之间。

syslog-facility local0

设置数据库数。默认数据库为DB 0，您可以使用SELECT <dbid>在每个连接的基础上选择一个不同的数据库，其中dbid是介于0和'databases'-1之间的数字

databases 16

默认情况下，仅当开始登录到标准输出并且标准输出为TTY时，Redis才会显示ASCII艺术logo 。基本上，这意味着通常仅在交互式会话中显示Logo 。

但是，可以通过将以下选项设置为yes，来强制执行4.0之前的行为并始终在启动日志中显示ASCII艺术Logo。

always-show-logo yes

SNAPSHOTTING (快照)

将数据库保存在磁盘上：

save <seconds> <changes>

如果同时发生了给定的秒数和对数据库的写操作数，则将保存数据库。

在下面的示例中，行为将是保存：

如果至少更改了1个按键，则在900秒（15分钟）后
300秒（5分钟）后，如果至少更改了10个按键
60秒后，如果至少更改了10000个键

注意：您可以通过注释掉所有“保存”行来完全禁用保存。

也可以通过添加带有单个空字符串参数的save指令来删除所有先前配置的保存点，如以下示例所示：

save ""   # 将是删除之前保存的值

# 默认值
save 900 1
save 300 10
save 60 10000

默认情况下，如果启用RDB快照（至少一个保存点）并且最新的后台保存失败，则Redis将停止接受写入。这将使用户（以一种困难的方式）意识到数据无法正确地持久存储在磁盘上，否则，可能没人会注意到并且会发生一些灾难。

如果后台保存过程将再次开始工作，则Redis将自动允许再次写入。

但是，如果您设置了对Redis服务器和持久性的适当监视，则可能要禁用此功能，以便即使磁盘，权限等出现问题，Redis也将继续照常工作。

stop-writes-on-bgsave-error yes

转储.rdb数据库时使用LZF压缩字符串对象？默认情况下将其设置为“yes”，因为它几乎总是胜利。如果要在保存子项中保存一些CPU，请将其设置为“ no”，但是如果您具有可压缩的值或键，则数据集可能会更大。

rdbcompression yes

从RDB版本5开始，CRC64校验和位于文件的末尾。这使该格式更能抵抗损坏，但是在保存和加载RDB文件时会降低性能（约10％），因此可以禁用它以实现最佳性能。

在禁用校验的情况下创建的RDB文件的校验为零，这将指示加载代码跳过该校验。

rdbchecksum yes

转储数据库的文件名

dbfilename dump.rdb

在未启用持久性的实例中删除复制使用的RDB文件。默认情况下，此选项是禁用的，但是在某些环境中，出于法规或其他安全方面的考虑，应将RDB文件由主数据库持久存储在磁盘上以提供副本，或将RDB文件由副本存储在磁盘上以加载它们以进行初始同步。应该尽快删除。请注意，此选项仅在同时禁用AOF和RDB持久性的实例中起作用，否则将被完全忽略。

一种获得相同效果的替代方法（有时更好）是在主实例和副本实例上使用无盘复制。然而对于副本，无盘并非总是一种选择。

rdb-del-sync-files no

工作目录。

数据库将被写入该目录内，文件名使用“ dbfilename”配置指令在上面指定。

也将在此目录中创建仅附加文件。

请注意，您必须在此处指定目录，而不是文件名。

dir ./

REPLICATION(复制)

主副本复制。使用的副本使Redis实例成为另一个Redis服务器的副本。尽快了解有关Redis复制的几件事。

   +------------------+      +---------------+
   |      Master      | ---> |    Replica    |
   | (receive writes) |      | (exact copy)  |
   |   接受     写     |      |   精确   复制   |
   +------------------+      +---------------+

Redis复制是异步的，但是您可以将主服务器配置为在似乎未与至少给定数量的副本连接时停止接受写操作。
如果复制链接在相对较短的时间内丢失，则Redis副本能够与主副本执行部分重新同步。您可能需要根据需要将复制 backlog(积压) 大小（请参阅此文件的下一部分）配置为合理的值。
复制是自动的，不需要用户干预。网络分区副本之后，副本会自动尝试重新连接到母版并与它们重新同步。

replicaof <masterip> <masterport>

如果主服务器受密码保护（使用下面的“ requirepass”配置指令），则可以在开始复制同步过程之前告知副本进行身份验证，否则主服务器将拒绝副本请求。

masterauth <master-password>

但是，如果您使用的是Redis ACL（对于Redis版本6或更高版本），并且默认用户无法运行PSYNC命令和/或其他复制所需的命令，这还不够。在这种情况下，最好配置一个特殊用户以用于复制，并这样指定masteruser配置：

masteruser <username>

指定masteruser时，副本将使用新的AUTH形式针对其主服务器进行身份验证：

AUTH <username> <password>

当副本失去与主数据库的连接时，或者仍在进行复制时，副本可以以两种不同的方式起作用：

如果复制副本服务过时的数据设置为“是”（默认值），则复制副本仍将回复客户端请求，可能包含过期数据，或者如果这是第一次同步，则数据集可能只是空的。
如果复制副本服务过时的数据设置为“否”，则复制副本将对所有类型的命令以错误“与主机进行同步”答复，但是对于 INFO, replicaOF, AUTH, PING, SHUTDOWN, REPLCONF, ROLE, CONFIG, SUBSCRIBE, UNSUBSCRIBE, PSUBSCRIBE, PUNSUBSCRIBE, PUBLISH, PUBSUB, COMMAND, POST, HOST: and LATENCY.

replica-serve-stale-data yes

您可以配置副本实例以接受或不接受写入。针对副本实例进行写操作可能对存储某些临时数据很有用（因为与主实例重新同步后，很容易删除副本上写入的数据），但是如果客户端由于配置错误而向其写入数据，也可能会导致问题。

由于Redis 2.6默认情况下，副本是只读的。

注意：只读副本并非旨在向Internet上不受信任的客户端公开。它只是防止实例滥用的保护层。默认情况下，只读副本仍会导出所有管理命令，例如CONFIG，DEBUG等。在一定程度上，您可以使用'rename-command'隐藏所有管理/危险命令来提高只读副本的安全性。

replica-read-only yes

复制SYNC策略： disk or socket(磁盘或套接字)。

仅接收差异而无法继续复制过程的新副本和重新连接的副本需要执行所谓的“完全同步”。 RDB文件从主数据库传输到副本数据库。

传输可以通过两种不同的方式进行：

Disk-backed：Redis主服务器创建一个新过程，将RDB文件写入磁盘。后来，该文件由父进程逐步传输到副本。
Diskless：Redis主服务器创建一个新进程，该进程将RDB文件直接写入副本套接字，而完全不接触磁盘。

使用磁盘支持的复制，在生成RDB文件的同时，只要生成RDB文件的当前的子级完成工作，就可以将更多副本排入队列并与RDB文件一起使用。如果使用无盘复制，则一旦传输开始，新的副本将排队，并且当当前副本终止时将开始新的传输。

使用无盘复制时，主服务器在开始传输之前会等待一段可配置的时间（以秒为单位），以希望多个副本可以到达并且传输可以并行化。

使用慢速磁盘和快速（大带宽）网络，无盘复制效果更好。

repl-diskless-sync no

启用无盘复制后，可以配置服务器等待的延迟，以便生成通过套接字将RDB传输到副本的子代。

这一点很重要，因为一旦传输开始，就无法为到达的新副本提供服务，新副本将排队等待下一次RDB传输，因此服务器会等待一段时间才能让更多副本到达。

延迟以秒为单位指定，默认情况下为5秒。要完全禁用它，只需将其设置为0秒，传输就会尽快开始。

repl-diskless-sync-delay 5

警告：RDB无盘加载是实验性的。因为在此设置中，副本不会立即在磁盘上存储RDB，所以它可能会导致故障转移期间的数据丢失。在与主机的初始同步阶段，如果 I/O 错误，则RDB无盘加载+ Redis模块不处理 I/O 读取也可能导致Redis中止。仅在执行自己的操作时使用。

副本可以直接从套接字加载它从复制链接读取的RDB，也可以将RDB存储到文件中，并在从主服务器完全获取文件后读取该文件。

在许多情况下，磁盘的速度比网络慢，并且存储和加载RDB文件可能会增加复制时间（甚至会增加主服务器的“写时复制”内存和从属缓冲区）。但是，直接从套接字解析RDB文件可能意味着我们必须在收到完整的rdb之前刷新当前数据库的内容。因此，我们有以下选择：

"disabled" 不要使用无盘负载（首先将rdb文件存储到磁盘）
"on-empty-db" 仅在完全安全时才使用无盘加载。
"swapdb" 直接从套接字解析数据时，将当前数据库内容的副本保留在RAM中。请注意，这需要足够的内存，如果没有足够的内存，则可能会杀死OOM。

repl-diskless-load disabled

副本以预定义的间隔将PING发送到服务器。可以使用repl_ping_replica_period选项更改此间隔。默认值为10秒。

repl-ping-replica-period 10

以下选项为以下项设置复制超时：

从副本的角度来看，在SYNC期间进行批量传输I/O。
从副本（data, pings）的角度来看，主服务器超时。
从主服务器角度来看，副本超时（REPLCONF ACK pings）。

重要的是要确保该值大于为repl-ping-replica-period指定的值，否则，每当主机和副本之间的通信量较低时，就会检测到超时。

repl-timeout 60

在同步后禁用副本套接字上的TCP_NODELAY？

如果选择“yes”，则Redis将使用更少的TCP数据包和更少的带宽将数据发送到副本。但这会增加数据出现在副本端的延迟，对于使用默认配置的Linux内核，此延迟最多可达40毫秒。

如果选择“否”，则将减少数据在副本侧出现的延迟，但是将使用更多带宽进行复制。

默认情况下，我们会针对低延迟进行优化，但是在流量非常高的情况下，或者当主副本和副本之间的距离很远时，将其设置为“yes”可能是个好主意。

repl-disable-tcp-nodelay no

设置复制backlog(积压) 大小。待办事项是一个缓冲区，当副本断开连接一段时间后，该缓冲区会累积副本数据，因此当副本要重新连接时，通常不需要完全重新同步，但是部分重新同步就足够了，仅传递副本断开连接时丢失的数据部分。

复制待办事项越大，副本可以断开连接并稍后能够执行部分重新同步的时间越长。

仅当至少有一个副本连接时，才分配backlog(积压)。

repl-backlog-size 1mb

主服务器在一段时间内不再连接副本后，积压的事务将被释放。以下选项配置了从断开最后一个副本的时间开始到释放待办事项缓冲区所需的秒数。

请注意，副本永远不会释放积压的超时，因为它们可能稍后会升级为主副本，并且应该能够与副本正确“部分重新同步”：因此，它们应始终累积积压。

值为0表示从不释放积压。

repl-backlog-ttl 3600

副本优先级是Redis在INFO输出中发布的整数。如果主服务器不再正常工作，Redis Sentinel会使用它来选择要升级为主服务器的副本。

具有较低优先级编号的副本被认为更适合提升，因此，例如，如果存在三个具有10、100、25优先级的副本，则Sentinel将选择具有最低优先级10的副本。

但是，特殊优先级0会将副本标记为不能执行主角色，因此Redis Sentinel永远不会选择优先级为0的副本进行升级。

缺省情况下，优先级为100。

replica-priority 100

如果连接的副本少于N个，并且延迟小于或等于M秒，则主服务器可能会停止接受写入。

N个副本需要处于“联机”状态。

延迟（以秒为单位）必须小于等于指定值，该延迟是根据从副本接收到的最后ping（通常每秒发送一次）计算得出的。

此选项不能保证N个副本将接受写操作，但是会将可用写副本不足的情况下丢失的写操作的暴露窗口限制为指定的秒数。

例如，要要求至少3个副本的延迟<= 10秒，请使用：

min-replicas-to-write 3
min-replicas-max-lag 10

将一个或另一个设置为0将禁用该功能。

默认情况下，将要写入的最小副本设置为0（禁用功能），并且将min-replicas-max-lag设置为10。

Redis主服务器能够以不同方式列出附加副本的地址和端口。例如，“ INFO replication”部分提供了此信息，Redis Sentinel使用此信息以及其他工具来发现副本实例。该信息可用的另一个位置是主服务器的“ ROLE”命令的输出。

副本通常报告的列出的IP和地址可以通过以下方式获得：

IP：通过检查副本用来与主服务器连接的套接字的对等地址来自动检测该地址。
Port：该端口在复制握手期间由副本进行通信，通常是副本用来侦听连接的端口。

但是，当使用端口转发或网络地址转换（NAT）时，实际上可以通过不同的 IP和Port pairs(一对) 访问该副本。副本可以使用以下两个选项，以便向其主服务器报告特定的IP和端口集，以便INFO和ROLE都将报告这些值。

如果只需要覆盖端口或IP地址，则无需使用这两个选项。

replica-announce-ip 5.5.5.5
replica-announce-port 1234

KEYS TRACKING(跟踪, 追踪)

Redis为客户端的值缓存实现服务器辅助的支持。这是使用invalidation table来实现的，该无效表使用1600万个插槽记住哪些客户端可能具有某些键子集。依次使用它是为了向客户端发送无效消息。请了解有关此功能的更多信息，请检查以下页面：

https://redis.io/topics/client-side-caching

为客户端启用跟踪时，所有只读查询均假定为已缓存：这将强制Redis将信息存储在invalidation table中。修改密钥后，此类信息将被清除，并将无效消息发送到客户端。但是，如果工作量主要由读取决定，Redis可以使用越来越多的内存来跟踪许多客户端获取的keys 。

因此，可以为invalidation table配置最大填充值。默认情况下，它设置为1M keys，一旦达到此限制，即使未修改键，Redis也将开始撤消失效表中的键，只是为了回收内存：这反过来将迫使客户端使缓存无效价值观。基本上，表的最大大小是要在服务器端用来跟踪有关谁缓存内容的信息的内存与客户端将缓存的对象保留在内存中的能力之间进行权衡的。

如果将值设置为0，则表示没有限制，Redis将在失效表中保留所需数量的键。在“stats”信息部分，您可以在invalidation table中找到有关键数的信息。在每个给定的时刻。

注意：在广播模式下使用键跟踪时，服务器端未使用任何内存，因此此设置无用。

tracking-table-max-keys 1000000

SECURITY(安全)

警告：由于Redis的速度非常快，外部用户每秒可以在一个现代化的盒子上尝试高达100万个密码。这意味着您应该使用非常安全的密码，否则密码很容易破解。请注意，由于该密码实际上是客户端和服务器之间的共享机密，并且不应被任何人记住，因此该密码可以很容易地是来自 /dev/urandom 的长字符串或其他任何内容，因此可以使用长且不可猜测的密码没有暴力攻击的可能。

Redis ACL用户的定义如下：

user <username> ... acl rules ...
# 例如：
user worker +@list +@connection ~jobs:* on >ffa9203c493aa99

特殊的用户名“默认”用于新连接。如果该用户具有“ nopass”规则，则新连接将立即被认证为“default”用户，而不需要通过AUTH命令提供的任何密码。否则，如果未将“default”用户标记为“ nopass”，则连接将以未认证状态启动，并且需要AUTH（或HELLO命令的AUTH选项）才能进行认证并开始工作。

描述用户可以执行的操作的ACL规则如下：

on 启用用户：可以验证为该用户。
off 禁用用户：不再可以与此用户进行身份验证，但是已经过身份验证的连接仍然可以使用。
+<command> 允许执行该命令
-<command> 禁止执行该命令
+@<category> 允许执行此类中具有有效类别的所有命令，例如@admin, @set, @sortedset, ...，请参阅server.c文件中的完整列表，其中描述和定义了Redis命令表。特殊类别@all表示所有命令，但是当前在服务器中存在，并且将来会通过模块加载。
+<command>|subcommand 允许使用本来禁用的命令中的特定子命令。注意，这种形式不允许像-DEBUG | SEGFAULT那样为负数，而只能以“ +”开头。
allcommands +@all的别名。请注意，这意味着可以执行将来通过模块系统加载的所有命令。
nocommands -@all的别名。
~<pattern> 添加可以在命令中提及的键模式。例如~*允许所有键。该模式是类似于KEYS之一的 glob-style 的模式。可以指定多个模式。
allkeys 〜*的别名
resetkeys 刷新允许的键模式列表。
><password> 将此密码添加到用户的有效密码列表中。例如，>mypass会将“ mypass”添加到列表中。该指令清除“ no pass”标志（请参阅下文）。
<<password> 从有效密码列表中删除此密码。
nopass 用户的所有设置密码都将被删除，并且该用户被标记为不需要密码：这意味着每个密码都将对该用户起作用。如果此指令用于默认用户，则每个新连接都将立即通过默认用户进行身份验证，而无需任何显式的AUTH命令。请注意，“ resetpass”指令将清除此情况。
resetpass 刷新允许的密码列表。此外，删除“ nopass”状态。在“resetpass”之后，用户将没有关联的密码，并且没有添加一些密码（或稍后将其设置为“ nopass”）就无法进行身份验证的方法。
reset 执行以下操作：resetpass, resetkeys, off, -@all。用户返回到创建后立即具有的相同状态。

可以按任何顺序指定ACL规则：例如，您可以先输入密码，再输入标志或密钥模式。但是请注意，加法和减法规则将根据ordering顺序进行更改。例如，请参见以下示例：

user alice on +@all -DEBUG ~* >somepassword

这将允许“ alice”使用除DEBUG命令之外的所有命令，因为 +@all 将所有命令添加到了alice可以使用的命令集中，并且后来删除了DEBUG。但是，如果我们颠倒两个ACL规则的顺序，结果将是不同的：

user alice on -DEBUG +@all ~* >somepassword

现在，当alice在允许的命令集中还没有命令时，DEBUG被删除，之后又添加了所有命令，因此用户将能够执行所有操作。

基本上，ACL规则是从左到右处理的。

有关ACL配置的更多信息，请参考Redis网站，网址https://redis.io/topics/acl。

ACL LOG

ACL日志跟踪与ACL关联的失败命令和身份验证事件。 ACL日志可用于对被ACL阻止的失败命令进行故障排除。 ACL日志存储在内存中。您可以使用ACL LOG RESET回收内存。在下面定义ACL日志的最大条目长度。

acllog-max-len 128

使用外部ACL文件

除了在此文件中配置用户之外，还可以使用仅列出用户的独立文件。这两种方法不能混合使用：如果您在此处配置用户并同时激活外部ACL文件，则服务器将拒绝启动。

外部ACL用户文件的格式与redis.conf内部用于描述用户的格式完全相同。

aclfile /etc/redis/users.acl

重要说明：从Redis 6开始，“ requirepass”只是新ACL系统之上的兼容性层。选项效果将只是为默认用户设置密码。客户端仍然可以像往常一样使用AUTH 进行身份验证，或者如果它们遵循新协议，则可以使用AUTH default 进行更明确的身份验证：两者都可以使用。

requirepass foobared

Command renaming (DEPRECATED).命令重命名（不建议使用）

警告：尽可能避免使用此选项。而是使用ACL从默认用户中删除命令，并将其仅放置在您出于管理目的而创建的某些admin用户中。

可以在共享环境中更改危险命令的名称。例如，可以将CONFIG命令重命名为一些难以猜测的名称，以便它仍可用于内部使用的工具，但不适用于一般客户。

Example:
 rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52

通过将命令重命名为空字符串也可以完全取消命令：

rename-command CONFIG ""

请注意，更改登录到AOF文件或传输到副本的命令的名称可能会导致问题。

CLIENTS

同时设置最大连接客户端数。默认情况下，此限制设置为10000个客户端，但是，如果Redis服务器无法将进程文件限制配置为允许指定的限制，则允许的最大客户端数将设置为当前文件限制减去32（因为Redis保留了内部使用的文件描述符很少）。

达到限制后，Redis将关闭所有新连接，并发送错误消息“已达到最大客户端数”。

重要说明：使用Redis群集时，最大连接数也与群集总线共享：群集中的每个节点将使用两个连接，一个进入，另一个离开。对于非常大的群集，重要的是相应地调整限制大小。

maxclients 10000

MEMORY MANAGEMENT

将内存使用限制设置为指定的字节数。当达到内存限制时，Redis将尝试根据所选的逐出策略（请参见maxmemory-policy）删除密钥。

如果Redis无法根据策略删除密钥，或者如果策略设置为“ noeviction”，则Redis将开始对将使用更多内存的命令（例如SET，LPUSH等）进行错误回复，并将继续答复诸如GET之类的只读命令。

当将Redis用作LRU或LFU缓存，或为实例设置硬盘限制（使用“ noeviction”策略）时，此选项通常很有用。

警告：如果您将副本连接到实例且maxmemory处于打开状态，则从使用的内存数量中减去提供副本所需的输出缓冲区的大小，这样，网络问题/重新同步将不会触发逐出密钥的循环，并且反过来，副本的输出缓冲区已满，有被驱逐的键的DEL触发了更多键的删除，依此类推，直到数据库完全清空。

简而言之...如果您附加了副本，建议您为maxmemory设置一个下限，以便系统上有一些可用RAM用于副本输出缓冲区（但是如果策略为'noeviction'，则不需要这样做）。

maxmemory <bytes>

MAXMEMORY POLICY：达到maxmemory时，Redis将如何选择要删除的内容。您可以从以下行为中选择一种：

volatile-lru -> 使用近似的LRU驱逐，仅设置过期的密钥。
allkeys-lru -> 使用近似的LRU退出任何密钥。
volatile-lfu -> 使用近似的LFU退出，仅设置了过期密钥。
allkeys-lfu -> 使用近似的LFU退出任何密钥。
volatile-random -> 删除具有过期设置的随机密钥。
allkeys-random -> 删除随机密钥，任何密钥。
volatile-ttl -> 取出最接近到期时间（较小的TTL）的密钥
noeviction -> 不要驱逐任何东西，只需在写操作中返回错误。

LRU(Least Recently Used)表示最近最少使用

LFU(Least Frequently Used)表示最少使用

LRU，LFU和volatile-ttl均使用近似随机算法实现。

注意：使用上述任何策略时，如果没有合适的退出键，Redis将在写入操作中返回错误。在撰写本文时，这些命令是：set setnx setex append incr decr rpush lpush rpushx lpushx linsert lset rpoplpush sadd sinter sinterstore sunion sunionstore sdiff sdiffstore zadd zincrby zunionstore zinterstore hset hsetnx hmset hincrby incrby decrby getset mset msetnx exec sort

默认值为：

maxmemory-policy noeviction

LRU，LFU和最小TTL算法不是精确算法，而是近似算法（以节省内存），因此您可以针对速度或准确性进行调整。对于默认情况，Redis将检查五个键并选择最近使用的键，您可以使用以下配置指令更改样本大小。

默认值为5会产生足够好的结果。 10非常接近真实的LRU，但是会花费更多的CPU。 3更快，但不是很准确。

maxmemory-samples 5

从Redis 5开始，默认情况下，副本将忽略其maxmemory设置（除非在故障转移后或手动提升为主副本）。这意味着密钥的移出将仅由主服务器处理，将DEL命令作为副本在主计算机侧逐出，将DEL命令发送到副本。

此行为可确保主副本和副本始终保持一致，这通常是您想要的，但是，如果副本是可写的，或者您希望副本具有不同的内存设置，并且您确定对副本执行的所有写操作都是幂等的，那么您可以更改此默认设置（但请务必了解您的操作）。

请注意，由于默认情况下该副本不会退出，因此它可能会使用比通过maxmemory设置的内存更多的内存（某些缓冲区在副本上可能会更大，或者数据结构有时会占用更多的内存，依此类推）。因此，请确保您监视副本并确保副本具有足够的内存，以确保在主副本达到配置的最大内存设置之前，永不达到实际的内存不足状态。

replica-ignore-maxmemory yes

Redis通过两种方式回收过期的密钥：访问时发现这些密钥已过期，以及在后台，称为“活动的过期密钥”。缓慢地，交互地扫描密钥空间，以查找要回收的过期密钥，以便可以释放已过期且不久之后将不再访问的密钥的内存。

到期周期的默认工作将尝试避免在内存中保留超过百分之十的过期密钥，并且将尝试避免消耗超过总内存的25％并增加系统延迟。但是，可以将通常设置为“ 1”的过期“effort”增加到更大的值，直到值“ 10”。系统将以其最大值使用更多的CPU，更长的周期（并且从技术上讲可能会引入更多的延迟），并且将减少仍存在于系统中的已过期密钥的数量。在内存，CPU和延迟之间进行权衡。

active-expire-effort 1

LAZY FREEING

Redis有两个删除键的原语。一种称为DEL，它是对象的阻塞删除。这意味着服务器停止处理新命令，以便以同步方式回收与对象关联的所有内存。如果删除的键与一个小对象相关联，则执行DEL命令所需的时间非常短，可与Redis中的其他大多数O（1）或O（log_N）命令相提并论。但是，如果键与包含数百万个元素的聚合值相关联，则服务器可能会阻塞很长时间（甚至几秒钟）以完成操作。

由于上述原因，Redis还提供了非阻塞删除原语，例如UNLINK（非阻塞DEL）以及FLUSHALL和FLUSHDB命令的ASYNC选项，以便在后台回收内存。这些命令在固定时间内执行。另一个线程将尽可能快地在后台逐渐释放对象。

用户可以控制FLUSHALL和FLUSHDB的DEL，UNLINK和ASYNC选项。由应用程序的设计决定何时使用一个或另一个是一个好主意。但是，Redis服务器有时必须删除键或刷新整个数据库，这是其他操作的副作用。特别是在以下情况下，Redis独立于用户调用删除对象：

逐出时，由于maxmemory和maxmemory策略配置，以便在不超过指定的内存限制的情况下为新数据腾出空间。
因为到期：必须从内存中删除具有相关生存时间的密钥（请参阅EXPIRE命令）。
由于将数据存储在可能已经存在的键上的命令的副作用。例如，当RENAME命令替换为旧密钥内容时，RENAME命令可能会删除它。类似地，SUNIONSTORE或SORT 与 STORE选项可能会删除现有密钥。 SET命令本身会删除指定键的所有旧内容，以便将其替换为指定的字符串。
复制期间，当副本与其主副本执行完全重新同步时，将删除整个数据库的内容，以便加载刚传输的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 访问和其他在侧线程上执行的操作。

现在，还可以在不同的 I/O 线程中处理Redis客户端套接字的读写。由于特别慢的写入速度，因此Redis用户通常使用流水线以加快每个内核的Redis性能，并生成多个实例以扩展规模。使用 I/O 线程，可以轻松地将Redis加速两次，而无需求助于实例的流水线处理或分片。

默认情况下，禁用线程处理，我们建议仅在具有至少4个或更多内核的计算机上启用它，并至少保留一个备用内核。使用8个以上的线程不太会有帮助。我们还建议仅在确实存在性能问题时才使用线程 I/O，Redis实例可以使用很大一部分CPU时间，否则就没有必要使用此功能。

因此，例如，如果您有四个核的盒子，请尝试使用2或3个 I/O 线程，如果您有8个核，请尝试使用6个线程。为了启用 I/O 线程，请使用以下配置指令：

io-threads 4

通常，将io-threads设置为1只会使用主线程。启用 I/O 线程后，我们仅使用线程进行写操作，即对 write(2) 系统调用进行线程化，并将客户端缓冲区传输到套接字。但是，也可以通过将以下配置指令设置为yes来启用读取线程和协议解析：

io-threads-do-reads no

通常，线程读取没有太大帮助。

注意1：无法在运行时通过CONFIG SET更改此配置指令。启用SSL后，该功能目前也无法使用。

注意2：如果您想使用redis-benchmark测试Redis加速，请确保您还以--threads选项匹配Redis thead的数量，以线程模式运行基准测试本身，否则您将无法注意到这些改进。

**APPEND ONLY MODE(追加模式)**

默认情况下，Redis异步将数据集转储到磁盘上。此模式在许多应用程序中已经足够好，但是Redis进程问题或停电可能会导致几分钟的写入丢失（取决于配置的保存点）。

仅附加文件(Append Only File;AOF)是一种替代的持久性模式，可提供更好的持久性。例如，使用默认的数据fsync策略（请参阅配置文件中的稍后内容），Redis在严重的事件（例如服务器断电）中仅会丢失一秒钟的写入，如果Redis进程本身发生问题，则可能会丢失一次写入，但是操作系统仍在正常运行。

可以同时启用AOF和RDB持久性，而不会出现问题。如果在启动时启用AOF，则Redis将加载AOF，即具有更好持久性保证的文件。

请检查http://redis.io/topics/persistence了解更多信息。

appendonly no

仅附加文件的名称（默认值：“ appendonly.aof”）
appendfilename "appendonly.aof"

fsync() 调用告诉操作系统将数据实际写在磁盘上，而不是等待输出缓冲区中的更多数据。有些操作系统确实会刷新磁盘上的数据，而另一些操作系统只会尝试尽快进行处理。

Redis支持三种不同的模式：

no：不要fsync，只要让OS在需要时刷新数据即可。 Faster(快点)。
always：每次写入仅附加日志后的fsync。 Slow(慢), Safest(最安全)。
everysec：fsync每秒仅一次。Compromise(妥协)。

默认值为“ everysec”，因为这通常是速度和数据安全性之间的正确折衷。您可以了解是否可以将其放松为“ no”，这将使操作系统在需要时刷新输出缓冲区，以获得更好的性能（但是，如果您可以忍受某些数据丢失的想法，请考虑使用默认的持久性模式（即快照），或者相反，请使用“always”，该速度非常慢，但比秒安全。

更多详细信息，请查看以下文章：http://antirez.com/post/redis-persistence-demystified.html

如果不确定，请使用“ everysec”

appendfsync always
appendfsync everysec
appendfsync no

当AOF fsync策略设置为always或everysec，并且后台保存进程（后台保存或AOF日志后台重写）对磁盘执行大量 I/O 时，在某些Linux配置中，Redis可能会在磁盘上阻塞太长时间。 fsync() 调用。请注意，目前尚无此修复程序，因为即使在其他线程中执行fsync也将阻止我们的同步 write(2) 调用。

为了减轻此问题，可以使用以下选项来防止在BGSAVE或BGREWRITEAOF进行时在主进程中调用fsync() 。

这意味着当另一个孩子正在保存时，Redis的持久性与“ appendfsync none”相同。实际上，这意味着在最坏的情况下（使用默认的Linux设置）可能会丢失多达30秒的日志。

如果您有延迟问题，请将其设置为“yes”。否则，从耐用性的角度出发，将其保留为“no”是最安全的选择。

no-appendfsync-on-rewrite no

自动重写仅附加文件。当AOF日志大小增加指定的百分比时，Redis可以自动重写日志文件，隐式调用BGREWRITEAOF。

它是这样工作的：Redis会在最近一次重写后记住AOF文件的大小（如果自重新启动以来未发生任何重写，则使用启动时AOF的大小）。

将此基本大小与当前大小进行比较。如果当前大小大于指定的百分比，则触发重写。另外，您需要指定要重写的AOF文件的最小大小，这对于避免重写AOF文件非常有用，即使达到百分比增加，但它仍然很小。

指定零百分比以禁用自动AOF重写功能。

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

percentage=百分比

当AOF数据重新加载到内存中时，在Redis启动过程中可能会发现AOF文件在末尾被截断。当运行Redis的系统崩溃时，尤其是在没有 data=ordered 选项的情况下挂载ext4文件系统时，可能会发生这种情况（但是，当Redis本身崩溃或中止，但操作系统仍然可以正常工作时，就不会发生这种情况）。

发生这种情况时，Redis可能会退出并显示错误，也可以加载尽可能多的数据（当前为默认值），如果发现AOF文件最后被截断，则Redis会开始加载。以下选项控制此行为。

如果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脚本

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

如果达到了最大执行时间，Redis将记录在允许的最大时间后脚本仍在执行中，并将开始以错误答复查询。

如果长时间运行的脚本超过了最大执行时间，则只有“ SCRIPT KILL”和“ SHUTDOWN NOSAVE”命令可用。第一个可用于停止尚未调用写命令的脚本。第二种是在脚本已发出写命令但用户不想等待脚本自然终止的情况下关闭服务器的唯一方法。

将其设置为0或负值可无警告地无限执行。

lua-time-limit 5000

REDIS集群

普通Redis实例不能属于Redis群集；只有作为群集节点启动的节点可以。为了将Redis实例作为群集节点启动，请启用群集支持，取消注释以下内容：

cluster-enabled yes

每个群集节点都有一个群集配置文件。该文件不适合手工编辑。它由Redis节点创建和更新。每个Redis群集节点都需要一个不同的群集配置文件。确保在同一系统上运行的实例没有重叠的集群配置文件名。

cluster-config-file nodes-6379.conf

群集节点超时是一个节点必须不可达的毫秒数，才能将其视为故障状态。其他大多数内部时间限制是节点超时的倍数。

cluster-node-timeout 15000

如果发生故障的主副本的数据看起来太旧，它将避免启动故障转移。

没有一种简单的方法可以使副本实际上具有对其“data age”的精确度量，因此执行以下两项检查：

如果存在多个能够进行故障转移的副本，则它们会交换消息，以尝试利用具有最佳复制偏移量的副本（已处理来自主数据库的更多数据）来发挥优势。副本将尝试按偏移量获取其等级，并将与它们的等级成比例的延迟应用于故障转移。
每个单个副本都会计算与其主副本之间最后一次交互的时间。这可以是最后收到的ping或命令（如果主服务器仍处于“connected(已连接)”状态），也可以是自从与主服务器断开连接以来经过的时间（如果复制链接当前已关闭）。如果最后一次交互太旧，则副本将完全不会尝试故障转移。

用户可以调整点 “ 2”。具体而言，如果自从上次与主服务器进行交互以来，经过的时间大于以下时间，则副本将不执行故障转移：

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

因此，例如，如果节点超时为30秒，并且 replica-validity-factor 为10，并且假设默认的repl-ping-replica-period值为10秒，则该副本将无法尝试进行故障转移（如果无法进行通话）与主机的时间超过310秒。

较大的 replica-validity-factor 可能会使数据太旧的副本无法对主副本进行故障转移，而值太小可能会使群集根本无法选择副本。

为了获得最大的可用性，可以将 replica-validity-factor 设置为0，这意味着，无论副本上次与主机交互的时间，副本将始终尝试对主机进行故障转移。（但是，他们将始终尝试应用与其偏移等级成正比的延迟）。

Zero 是唯一能够确保当所有分区恢复正常后群集将始终能够继续运行的值。

cluster-replica-validity-factor 10

群集副本能够迁移到孤立的主数据库，即那些没有工作副本的主数据库。这样可以提高群集抵御故障的能力，因为如果没有工作副本，孤立的主节点在发生故障的情况下将无法进行故障转移。

仅当其旧主副本仍至少存在给定数量的其他工作副本时，副本副本才会迁移到孤立的主副本。这个数字是“移民壁垒”。迁移障碍为1表示仅当副本数据库的主副本上至少有1个其他工作副本时，副本副本才会迁移。它通常反映出集群中每个主数据库所需的副本数。下方是原文：

Replicas migrate to orphaned masters only if there are still at least a given number of other working replicas for their old master. This number is the "migration barrier". A migration barrier of 1 means that a replica will migrate only if there is at least 1 other working replica for its master and so forth. It usually reflects the number of replicas you want for every master in your cluster.

缺省值为1（副本仅在其主数据库保留至少一个副本的情况下迁移）。要禁用迁移，只需将其设置为非常大的值即可。可以将值设置为0，但仅用于调试和生产危险。

cluster-migration-barrier 1

默认情况下，如果Redis Cluster节点检测到至少发现一个哈希槽（没有可用的节点正在为其提供服务），它们将停止接受查询。这样，如果集群部分关闭（例如，不再覆盖哈希槽的范围），则所有集群最终将变得不可用。一旦再次覆盖所有插槽，它将自动返回可用状态。下方是原文

By default Redis Cluster nodes stop accepting queries if they detect there is at least an hash slot uncovered (no available node is serving it). This way if the cluster is partially down (for example a range of hash slots are no longer covered) all the cluster becomes, eventually, unavailable. It automatically returns available as soon as all the slots are covered again.

但是，有时您希望正在运行的集群子集继续接受对仍覆盖的部分键空间的查询。为此，只需将cluster-require-full-coverage选项设置为no。

cluster-require-full-coverage yes

设置为yes时，此选项可防止副本在主服务器发生故障时尝试对其主服务器进行故障转移。但是，主服务器仍然可以执行手动故障转移（如果被迫执行）。

这在不同的情况下很有用，尤其是在多个数据中心操作的情况下，如果在DC完全故障的情况下不希望一侧不升级，则尤其如此。

cluster-replica-no-failover no

如果将此选项设置为yes，则允许节点在群集处于关闭状态时为读取流量提供服务，只要它认为自己拥有slots即可。

这对于两种情况很有用。第一种情况是在节点故障或网络分区期间应用程序不需要数据一致性时。一个示例是高速缓存，只要节点具有数据，它就应该能够为其提供服务。

第二个用例用于不符合建议的三个分片但要启用集群模式并在以后扩展的配置。如果没有设置此选项，则在1或2分片配置中的主服务器中断会导致整个集群的读/写中断，只有在设置了该选项的情况下，才会发生写中断。没有法定人数的主持人，插槽所有权将不会自动更改。下方原文

The second use case is for configurations that don't meet the recommended three shards but want to enable cluster mode and scale later. A master outage in a 1 or 2 shard configuration causes a read/write outage to the entire cluster without this option set, with it set there is only a write outage. Without a quorum of masters, slot ownership will not change automatically.

cluster-allow-reads-when-down no

为了设置群集，请确保阅读http://redis.io网站上的可用文档。

CLUSTER DOCKER/NAT support

在某些部署中，Redis Cluster节点的地址发现失败，这是因为地址经过NAT限制或端口被转发（典型情况是Docker和其他容器(containers)）。

为了使Redis Cluster在这样的环境中工作，需要一个静态配置，其中每个节点都知道其公共地址。以下两个选项用于此范围，分别是：

cluster-announce-ip
cluster-announce-port
cluster-announce-bus-port

每个命令都向节点指示其地址，客户端端口和群集消息总线端口。然后将信息发布在总线数据包的报头中，以便其他节点将能够正确映射发布信息的节点的地址。

如果未使用上述选项，则将使用常规的Redis群集自动检测。

请注意，重新映射时，总线端口(bus port)可能不在客户端端口+ 10000的固定偏移处，因此您可以根据重新映射的方式指定任何port和bus-port。如果未设置bus-port，通常将使用10000的固定偏移量。

Example:
 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等于一秒。请注意，负数将禁用慢速日志记录，而零值将强制记录每个命令。

slowlog-log-slower-than 10000

该长度没有限制。请注意，它将消耗内存。您可以使用SLOWLOG RESET回收慢速日志使用的内存。

slowlog-max-len 128

LATENCY MONITOR

Redis延迟监视子系统会在运行时对不同的操作进行采样，以收集与Redis实例的潜在延迟源相关的数据。

通过LATENCY命令，该信息可供打印图形并获取报告的用户使用。

系统仅记录在等于或大于通过delay-monitor-threshold配置指令指定的毫秒数内执行的操作。当其值设置为零时，等待时间监视器( latency monitor)将关闭。

默认情况下，延迟监视是禁用的，因为如果您没有延迟问题，则通常不需要监视，并且收集数据会对性能产生影响，尽管影响很小，但是可以在大负载下进行测量。如果需要，可以在运行时使用命令“ CONFIG SET delay-monitor-threshold <milliseconds>”轻松启用延迟监视。

latency-monitor-threshold 0

EVENT NOTIFICATION

Redis可以将关键空间中发生的事件通知给发布/订阅客户端。此功能记录在http://redis.io/topics/notifications

例如，如果启用了键空间事件通知，并且客户端对存储在数据库0中的键“ foo”执行了DEL操作，则将通过Pub / Sub发布两条消息：

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

可以在一组类中选择Redis将通知的事件。每个类都由一个字符标识：

K Keyspace事件，以 __keyspace@<db>__ 前缀发布。
E Keyevent事件，以 __keyevent@<db>__ 前缀发布。
g 通用命令（非类型专用），例如DEL，EXPIRE，RENAME，...
$ String commands
l List commands
s Set commands
h Hash commands
z Sorted set commands
x Expired 事件（每次key过期时生成的事件）
e Evicted 事件（将key驱逐到最大内存时生成的事件）
t Stream commands
m Key-miss事件（注意：它不包含在“ A”类中）
A g$lshzxet的别名，因此“ AKE”字符串表示所有事件（由于key-miss事件的独特性质，这些键事件被排除在“A”之外）。

“notify-keyspace-events”将由零个或多个字符组成的字符串作为参数。空字符串表示已禁用通知(notifications)。

示例：要启用列表事件和通用事件，请从事件名称的角度使用：

notify-keyspace-events Elg

Example 2: to get the stream of the expired keys subscribing to channel name 、__keyevent@0__:expired use:

notify-keyspace-events Ex

默认情况下，所有通知都被禁用，因为大多数用户不需要此功能，并且该功能会有一些开销。请注意，如果您未指定K或E中的至少一个，则不会传递任何事件。

notify-keyspace-events ""

GOPHER SERVER

Redis包含Gopher的实现RFC 1436（https://www.ietf.org/rfc/rfc1436.txt）中指定的协议。

Gopher协议在90年代后期非常流行。它是Web的替代方法，服务器和客户端的实现是如此简单，以至于Redis服务器只有100行代码才能实现这种支持。

您现在如何使用Gopher？好吧，Gopher从未真正死过，最近出现了一种运动，目的是使仅由纯文本文档组成的Gopher更高层次的内容得以复活。有些人希望使用更简单的互联网，另一些人则认为主流互联网已变得过于可控，为想要一点新鲜空气的人们创造替代空间很酷。

无论如何，在Redis诞生10周年之际，我们给了它Gopher协议作为礼物。

--- 这个怎么运作？(HOW IT WORKS?) ---

Redis Gopher支持使用Redis的内联协议，特别是两种非法的内联请求：空(empty)请求或任何以“/”开头的请求（没有以这样的斜杠开头的Redis命令）。正常的RESP2/RESP3请求完全超出了Gopher协议实现的范围，并且通常也得到满足。

如果在启用Gopher后打开与Redis的连接，并向其发送“/foo”之类的字符串，则如果存在名为“/foo”的key，则会通过Gopher协议为其提供服务。

为了创建一个真正的Gopher“漏洞”（Gopher对话中Gopher站点的名称），您可能需要类似以下的脚本：https://github.com/antirez/gopher2redis

--- 安全警告 (SECURITY WARNING) ---

如果您打算将Redis放在服务器Gopher页面的公共访问地址上，请确保为实例设置密码。设置密码后：

Gopher服务器（启用后，默认情况下未启用）仍将通过Gopher提供内容。
但是，在客户端进行身份验证之前无法调用其他命令。

因此，请使用“ requirepass”选项来保护您的实例。

要启用Gopher支持，请取消注释以下行，并将选项从no（默认）设置为yes。

gopher-enabled no

ADVANCED CONFIG(高级配置)

当哈希条目只有少量条目且最大条目未超过给定阈值时，将使用内存高效的数据结构对其进行编码。可以使用以下指令配置这些阈值。

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

列表也以特殊的方式编码以节省大量空间。每个内部列表节点允许的条目数可以指定为固定的最大大小或最大元素数。

对于固定的最大大小，请使用-5到-1，表示：

-5: max size: 64 Kb <-- 不建议用于正常工作负载
-4: max size: 32 Kb <-- 不建议
-3: max size: 16 Kb <-- 可能不推荐
-2: max size: 8 Kb <-- Good(好)
-1: max size: 4 Kb <-- good

正数表示每个列表节点最多可以存储该数量的元素。

性能最高的选项通常是-2（8 Kb大小）或-1（4 Kb大小），但是如果您的用例是唯一的，请根据需要调整设置。

list-max-ziplist-size -2

列表也可以被压缩。压缩深度是指从列表的每个一侧到从压缩中排除的快速列表ziplist 节点的数量。为了快速执行push/pop操作，列表的首尾始终未压缩。设置为：

0：禁用所有列表压缩
1：深度1表示“直到1个节点进入列表之后，从头到尾：So: [head]->node->node->...->node->[tail]；[head]，[tail]将始终未压缩；内部节点将压缩。
2：[head]->[next]->node->node->...->node->[prev]->[tail]；这里的2表示：不要压缩head或head-> next或tail-> prev或tail，而是压缩它们之间的所有节点。
3：[head]->[next]->[next]->node->node->...->node->[prev]->[prev]->[tail] 等等

list-compress-depth 0

在仅一种情况下，集合具有特殊的编码：当集合仅由字符串组成，这些字符串恰好是基数为10的整数，其范围为64位有符号整数。以下配置设置设置了大小限制，以便使用此特殊的内存节省编码。

set-max-intset-entries 512

与hashes 和lists类似，对排序集也进行了特殊编码，以节省大量空间。仅当排序集的长度和元素低于以下限制时，才使用此编码：

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

HyperLogLog 稀疏(sparse)表示形式的字节数限制。限制包括16个字节的标头。当使用稀疏表示的HyperLogLog超过此限制时，它将转换为密集表示。

大于16000的值完全没有用，因为在那一点上，密集表示的存储效率更高。

建议值约为3000，以便在不降低过多PFADD的情况下获得节省空间编码的好处，而PFADD的稀疏编码为 O(N) 。当不关心CPU但空间很大时，该值可以提高到10000，并且数据集由基数在0-15000范围内的许多HyperLogLog组成。

hll-sparse-max-bytes 3000

Streams macro节点最大大小/项目(max size / items)。流数据结构是一个大节点的基数树，该树对内部的多个项目进行编码。使用此配置，可以配置单个节点的大小（以字节为单位），以及在添加新的流条目时切换到新节点之前它可能包含的最大项目数。如果以下任何设置被设置为零，则该限制将被忽略，例如，可以通过将max-bytes设置为0并将max-entries设置为所需值来设置maxs整体限制。

stream-node-max-bytes 4096
stream-node-max-entries 100

活动重新哈希处理每100毫秒CPU时间使用1毫秒，以帮助重新哈希主Redis哈希表（将顶级键映射到值的一个哈希表）。 Redis使用的哈希表实现（请参见dict.c）执行一次懒惰的重新哈希处理：您在要进行哈希处理的哈希表中运行的操作越多，执行的哈希处理“步骤”就越多，因此，如果服务器空闲，则哈希处理将永远不会完成散列表使用更多的内存。以下原文:

Active rehashing uses 1 millisecond every 100 milliseconds of CPU time in order to help rehashing the main Redis hash table (the one mapping top-level keys to values). The hash table implementation Redis uses (see dict.c) performs a lazy rehashing: the more operation you run into a hash table that is rehashing, the more rehashing "steps" are performed, so if the server is idle the rehashing is never complete and some more memory is used by the hash table.

默认值是每秒使用10毫秒的毫秒数来主动刷新主要词典，并在可能的情况下释放内存。

如果不确定：

如果您有严格的延迟要求，请使用“ activehashing no”，并且在您的环境中，Redis可以不时地以2毫秒的延迟答复查询不是一件好事。

如果您没有如此严格的要求，但希望在可能的情况下尽快释放内存，请使用“ activerehashing yes”。

activerehashing yes

客户端输出缓冲区限制可用于出于某些原因强制断开没有足够快地从服务器读取数据的客户端的断开连接（常见原因是，Pub / Sub客户端不能像发布者产生消息那样快地消耗消息。）。

可以为三种不同类别的客户端设置不同的限制：

normal -> 普通客户，包括MONITOR客户
replica -> 复制客户端
pubsub -> 客户订阅了至少一个pubsub频道或模式

每个client-output-buffer-limit指令的语法如下：

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

一旦达到硬限制，或者达到软限制并在指定的秒数内（连续）保持达到此限制，客户端将立即断开连接。

因此，例如，如果硬限制为32兆字节，软限制为16兆字节/ 10秒，则如果输出缓冲区的大小达到32兆字节，客户端将立即断开连接，但如果客户端达到16兆字节，则也会断开连接。持续超过限制10秒钟。

默认情况下，普通客户端不受限制，因为它们不会在没有询问的情况下（以推送方式）接收数据，而是在请求之后才接收数据，因此，只有异步客户端才可能创建请求数据比读取数据更快的场景。

相反，由于订阅者和副本以push方式接收数据，因此对pubsub和副本客户端没有默认限制。

硬限制或软限制都可以通过将其设置为零来禁用。

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

客户端查询缓冲区会累积新命令。默认情况下，它们被限制为固定数量，以避免协议不同步（例如由于客户端错误）导致查询缓冲区中的未绑定内存使用。但是，如果您有非常特殊的需求，例如巨大的 multi/exec 请求等，则可以在此处进行配置。

client-query-buffer-limit 1gb

在Redis协议中，批量请求（即表示单个字符串的元素）通常限制为512 mb以上。但是，您可以在此处更改此限制。

proto-max-bulk-len 512mb

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

并非所有任务都以相同的频率执行，但是Redis会根据指定的 "hz" 值检查要执行的任务。

默认情况下， "hz" 设置为10。提高该值将在Redis空闲时使用更多的CPU，但是同时当有多个键同时到期时，它将使Redis的响应速度更快，并且可以更精确地处理超时。

范围在1到500之间，但是通常不建议超过100。大多数用户应使用默认值10，仅在要求非常低延迟的环境中才将其提高到100。

hz 10

通常，具有与连接的客户端数量成比例的HZ值很有用。例如，这有助于避免每次后台任务调用处理过多的客户端，从而避免延迟高峰。

由于默认的默认HZ值保守地设置为10，因此Redis提供并默认启用了使用自适应HZ值的能力，当有许多连接的客户端时，该值会暂时升高。

启用动态HZ后，实际配置的HZ将用作基准，但是一旦连接了更多客户端，实际将使用配置的HZ值的倍数。这样，空闲实例将占用很少的CPU时间，而繁忙的实例将具有更高的响应速度。

dynamic-hz yes

当孩子(child)重写AOF文件时，如果启用了以下选项，则每生成32 MB的数据，文件就会进行同步处理。这对于将文件更多地提交到磁盘并避免大的延迟峰值很有用。

aof-rewrite-incremental-fsync yes

当redis保存RDB文件时，如果启用以下选项，则每生成32 MB数据将对文件进行fsync处理。这对于将文件更多地提交到磁盘并避免大的延迟峰值很有用。

rdb-save-incremental-fsync yes

可以调整Redis LFU 逐出(eviction)（请参阅maxmemory设置）。但是，最好从默认设置开始，仅在研究了如何提高性能以及LFU keys 随时间变化后再进行更改，这可以通过OBJECT FREQ命令进行检查。

Redis LFU实现中有两个可调参数：计数器对数因子和计数器衰减时间。在更改两个参数之前，请务必先了解这两个参数的含义。

LFU计数器每个密钥只有8位，最大值是255，因此Redis使用具有对数行为的概率增量。给定旧计数器的值，当访问一个键时，该计数器以这种方式递增：

提取介于0和1之间的随机数R。
概率P被计算为 1/(old_value*lfu_log_factor+1) 。
仅当R <P时，计数器才会递增。

默认的 lfu-log-factor 是10。这是一个表格，该表格显示了频率计数器如何随着具有不同对数因子的不同访问次数而变化：

 +--------+------------+------------+------------+------------+------------+
 | factor | 100 hits   | 1000 hits  | 100K hits  | 1M hits    | 10M hits   |
 +--------+------------+------------+------------+------------+------------+
 | 0      | 104        | 255        | 255        | 255        | 255        |
 +--------+------------+------------+------------+------------+------------+
 | 1      | 18         | 49         | 255        | 255        | 255        |
 +--------+------------+------------+------------+------------+------------+
 | 10     | 10         | 18         | 142        | 255        | 255        |
 +--------+------------+------------+------------+------------+------------+
 | 100    | 8          | 11         | 49         | 143        | 255        |
 +--------+------------+------------+------------+------------+------------+

注意：上表是通过运行以下命令获得的：
redis-benchmark -n 1000000 incr foo
redis-cli object freq foo

注意2：计数器的初始值为5，以便使新对象有机会累积命中数。

计数器衰减时间是必须经过的时间（以分钟为单位），以便将key 计数器除以2（如果值小于等于10，则递减）。

lfu-decay-time的默认值为1。特殊值0表示每次扫描计数器都会使其衰减。

lfu-log-factor 10
lfu-decay-time 1

ACTIVE DEFRAGMENTATION(主动碎片整理)

什么是主动碎片整理？

主动（online）碎片整理使Redis服务器可以压缩内存中数据的小分配和释放之间的剩余空间，从而可以回收内存。

碎片是每个分配器（幸运的是，使用Jemalloc的情况要少得多）和某些工作负载发生的自然过程。通常，需要重新启动服务器以减少碎片，或者至少清除所有数据并重新创建。但是，由于Oran Agra为Redis 4.0实现了此功能，因此在服务器运行时，此过程可以在运行时以“hot”方式进行。

基本上，当碎片超过一定级别时（请参阅下面的配置选项），Redis将开始通过利用某些特定的Jemalloc功能在连续的内存区域中创建值的新副本（为了了解分配是否引起碎片，并将其分配到更好的位置），同时将释放数据的旧副本。对于所有键，以增量方式重复此过程将导致碎片恢复到正常值。

重要事项：

默认情况下，此功能是禁用的，并且仅当您编译Redis以使用我们随Redis的源代码提供的Jemalloc副本时才起作用。这是Linux构建的默认设置。
如果没有碎片问题，则无需启用此功能。
遇到碎片之后，可以在需要时使用命令“ CONFIG SET activedefrag yes”启用此功能。

配置参数能够微调碎片整理过程的行为。如果您不确定它们的含义，则最好不要更改默认值。

启用主动碎片整理
- activedefrag no
启动主动碎片整理的最小碎片废物量
- active-defrag-ignore-bytes 100mb
启动主动碎片整理的最小碎片百分比
- active-defrag-threshold-lower 10
我们在最大程度地使用碎片的最大百分比
- active-defrag-threshold-upper 100
达到下限阈值时使用的最小的CPU碎片整理工作
- active-defrag-cycle-min 1
达到上限时使用的最大的CPU碎片整理工作
- active-defrag-cycle-max 25
主字典扫描将处理的 set/hash/zset/list 字段的最大数量
- active-defrag-max-scan-fields 1000
默认情况下，将启用用于清除的Jemalloc后台线程
- jemalloc-bg-thread yes

可以将不同的Redis线程和进程固定到系统中的特定CPU，以最大化服务器的性能。这对于将不同的Redis线程固定在不同的CPU中很有用，而且还可以确保在同一主机上运行的多个Redis实例将被固定到不同的CPU。

通常，您可以使用“ taskset”命令执行此操作，但是在Linux和FreeBSD中，也可以直接通过Redis配置进行此操作。

您可以固定 server/IO 线程，bio线程，aof重写子进程和bgsave子进程。指定cpu列表的语法与taskset命令相同：

将Redis服务器/ IO线程设置为CPU关联0、2、4、6：

server_cpulist 0-7:2

将bio线程设置为cpu近似1,3：

bio_cpulist 1,3

将aof重写子进程设置为cpu近似8,9,10,11：

aof_rewrite_cpulist 8-11

将bgsave子进程设置为cpu 近似1,10,11

bgsave_cpulist 1,10-11

Redis6.0配置文件翻译(Google手动翻译)