Redis【有与无】【C1】配置 redis.conf

请注意，选项“include”不会被 admin 或 Redis Sentinel 的命令“CONFIG REWRITE”重写。因为 Redis 总是使用最后处理的行作为配置指令的值，所以你最好在该文件的开头放置 includes，以避免在运行时覆盖配置更改。

如果你对使用 include 覆盖配置选项感兴趣，那么最好使用 include 作为最后一行。

include /path/to/local.conf
include /path/to/other.conf

3.模块（MODULES）

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

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

4.网络（NETWORK）

默认情况下，如果没有指定“bind”配置指令，Redis 将侦听来自主节点上所有可用网络接口的连接。

可以使用“bind”配置指令监听一个或多个选定的接口，后跟一个或多个 IP 地址。

例子:

bind 192.168.1.100 10.0.0.1
bind 127.0.0.1 ::1

~ ~ ~ 警告 ~ ~ ~

如果运行 Redis 的计算机直接暴露在互联网上，绑定到所有的接口是危险的，并将实例暴露给互联网上的每个人。因此，默认情况下，我们取消注释下面的 bind 指令，这将迫使 Redis 只监听 IPv4 loopback 接口地址(这意味着 Redis 将只能接受来自运行它的同一台主节点的客户端连接)。

如果确定要实例监听所有接口，请注释掉以下行。

bind 127.0.0.1

保护模式是一个安全保护层，目的是避免因特网上保持开放状态的 Redis 实例被访问和利用。

当保护模式打开时，如果以下情况:

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

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

默认情况下，启用了保护模式。即使没有配置身份验证，也没有使用“bind”指令显式列出特定的一组接口，只有在确定希望其他主节点的客户端连接到 Redis 时，才应该禁用该接口。

protected-mode yes

接受指定端口上的连接，默认值为6379(IANA # 815344)。如果指定端口0，Redis 将不会侦听 TCP 套接字。

port 6379

4.1.TCP listen() 积压

在每秒请求数很高的环境中，你需要大量积压，以避免客户端连接速度慢的问题。请注意，Linux 内核将静默地将其截断为 /proc/sys/net/core/somaxconn 的值，因此请确保同时提高 somaxconn 和 tcp_max_syn_backlog 的值，以达到预期的效果。

tcp-backlog 511

4.2.Unix socket

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

unixsocket /tmp/redis.sock
unixsocketperm 700

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

timeout 0

4.3.TCP keepalive

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

检测死亡的同伴。
强制中间的网络设备考虑连接是否有效。

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

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

tcp-keepalive 300

5.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端口上的客户端（包括复制节点）使用有效的客户端证书进行身份验证。

如果指定“no”，则不需要也不接受客户端证书。
如果指定了“optional”，则接受客户端证书，并且如果提供的话，客户端证书必须有效，但不是必需的。

tls-auth-clients no
tls-auth-clients optional

缺省情况下，Redis 复制节点不尝试与其主节点建立TLS连接。

使用以下指令在复制链接上启用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"

配置允许的密码。

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

tls-ciphers DEFAULT:!MEDIUM

配置允许的TLSv1.3密码套件。

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

6.通用(GENERAL)

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

daemonize no

如果从systemd运行Redis，Redis可以与你的监督树进行交互。

选项说明：

supervised no 没有监督互动
supervised upstart 通过将Redis置于SIGSTOP模式来发出信号以指示upstart，这需要在upstart的作业中配置“expect stop”
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艺术徽标。基本上，这意味着通常仅在交互式会话中显示徽标。

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

always-show-logo yes

7.快照（SNAPSHOTTING）

将数据库保存在磁盘上：

save <seconds> <changes>

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

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

900秒后(15分钟) ，如果至少1个键更改
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压缩字符串对象吗？默认情况下启用了默认压缩，因为它几乎总是胜利。如果要在保存子项中保存一些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 ./

8.复制(REPLICATION)

主节点与复制节点复制。使用copyof来使Redis实例成为另一个Redis服务器的复制节点。尽快了解有关Redis复制的几件事。

+------------------+ +---------------+
| Master | ---> | Replica |
| (receive writes) | | (exact copy) |
+------------------+ +---------------+

Redis 复制是异步的，但是如果主节点看起来至少没有连接到给定数量的复制节点，你可以配置它停止接受写操作。
如果在相对较短的时间内丢失了复制链接，Redis 复制节点可以与主节点执行部分重新同步。你可能希望根据需要使用合理的值配置复制计划安排的大小。
复制是自动的，不需要用户干预。在网络分区之后，复制自动尝试重新连接主节点并与它们重新同步。

replicaof <masterip> <masterport>

如果主节点受到密码保护(使用下面的"requirepass"配置指令) ，可以在启动复制同步进程之前告诉复制节点进行身份验证，否则主节点将拒绝复制节点请求。

masterauth <master-password>

但是，如果你正在使用 Redis acl (对于 Redis version 6或更高版本) ，并且默认用户不能运行复制所需的 PSYNC 命令和/或其他命令，那么这是不够的。在这种情况下，最好配置一个特殊的用户用于复制，并指定主节点用户配置如下:

masteruser <username>

指定masteruser时，复制节点将使用新的AUTH形式针对其主节点进行身份验证：AUTH <username> <password>.

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

如果将 replica-serve-stale-data 设置为“yes”(默认值) ，那么该复制节点仍然会回复客户端请求，可能带有过期的数据，或者如果这是第一次同步，那么该数据集可能是空的。
如果将 replica-serve-stale-data 设置为“no” ，则该复制节点将以错误“SYNC with master in progress”回复所有命令，除非: 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默认的复制节点是只读的。

注意: 只读复制节点不设计为在互联网上向不可信客户机公开。它只是一个防止实例被滥用的保护层。

如果复制复制节点服务过时数据设置为“yes”（默认值），则复制复制节点仍将回复客户端请求，可能包含过期数据，或者如果这是第一次同步，则数据集可能只是空的。

replica-read-only yes

复制SYNC策略：disk or socket。

仅仅接受差异就无法继续复制过程的新复制节点和重新连接的复制节点需要进行所谓的“完全同步”。 RDB文件从主节点传输到复制节点。

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

Disk-backed: Redis主节点创建一个新过程，将RDB文件写入磁盘。后来，该文件由父进程逐步传输到复制节点。
Diskless: Redis主节点创建一个新进程，该进程将RDB文件直接写入复制节点套接字 (socket)，而完全不接触磁盘。

使用磁盘支持的复制，当生成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指定的值，否则，每当主节点和复制节点之间的通信量较低时，就会检测到超时。默认值为60秒。

repl-timeout 60

在同步后禁用复制节点套接字上的TCP_NODELAY？

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

如果选择“no”，则将减少数据在复制节点端出现的延迟，但将使用更多带宽进行复制。

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

repl-disable-tcp-nodelay no

设置复制积压（replication backlog）大小。待办事项是一个缓冲区，当复制节点断开连接一段时间后，该缓冲区将累积复制节点数据，因此，当复制节点要重新连接时，通常不需要完全重新同步，但是部分重新同步就足够了，只需传递复制节点中的部分数据断开连接时错过。

复制积压越大，复制节点可以承受断开连接并随后能够执行部分重新同步的时间就越长。

仅当至少有一个复制节点连接时才分配积压。

repl-backlog-size 1mb

主节点在一段时间内没有连接的复制节点后，积压的订单将被释放。以下选项配置了从断开最后一个复制节点的时间开始到释放待办事项缓冲区所需的秒数。

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

值为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个复制节点必须处于“online”状态。

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

此选项不能保证N个复制节点将接受写操作，但是如果没有足够的复制节点可用，则会将丢失写操作的暴露窗口限制为指定的秒数。

例如，需要至少3个滞后<= 10秒的复制节点，请使用：

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

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

默认情况下，将要写入的最小复制节点设置为0（禁用功能），并且将最小复制节点最大延迟设置为10。

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

复制节点通常报告的列出的IP地址和端口可以通过以下方式获得：

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

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

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

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

9.KEYS 追踪(KEYS TRACKING)

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

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

由于这个原因，可以为失效表配置最大填充值。默认情况下，它被设置为1M的键，一旦达到这个限制，Redis 将开始驱逐失效表中的键，即使它们没有被修改，只是为了回收内存: 这反过来将迫使客户端使缓存的值失效。基本上，表的最大大小是一种权衡，一方面是你希望使用服务器端的内存来跟踪关于谁缓存了什么的信息，另一方面是客户机在内存中保留缓存对象的能力。

如果将该值设置为 0，则意味着没有限制，并且 Redis 将保留失效表中所需的所有键。

在“stats” INFO 部分，你可以找到关于无效化表中每个给定时刻键的数量的信息。

注意: 当在广播模式下使用键跟踪时，服务器端不使用内存，所以这个设置是无用的。

tracking-table-max-keys 1000000

10.安全（SECURITY）

警告

由于 Redis 非常快，外部用户可以针对一个现代的方框尝试每秒100万个密码。这意味着你应该使用非常强大的密码，否则他们将非常容易破解。

请注意，由于密码实际上是客户机和服务器之间共享的秘密，不应该被任何人记住，密码可以很容易地从 /dev/urandom 或任何东西长字符串，所以使用一个长的和不可猜测的密码不可能有穷举法。

Redis ACL 用户的定义格式如下:

user <username> ... acl rules ...

例如:

user worker +@list +@connection ~jobs:* on >ffa9203c493aa99

特殊的用户名“default”用于新的连接。如果这个用户有“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 注意，它意味着能够执行通过模块系统加载的所有未来命令。
nocommands 别名 -@all。
~<pattern> 添加可以作为命令的一部分提及的键模式。例如 ~ * 允许所有的键。该模式是一种类似于 KEYS 的全球风格模式。指定多个模式是可能的。
allkeys 别名 ~ *
resetkeys 刷新允许的键模式列表。
><password> 将此密码添加到用户的有效密码列表中。例如 >mypass 将添加“mypass”到列表中。此指令清除“nopass”标志(请参阅后面的内容)。
<<password> 从有效密码列表中删除此密码。
nopass 用户的所有设置密码都被删除，用户被标记为不需要密码: 这意味着每个密码都将对该用户起作用。如果此指令用于默认用户，则每个新连接都将立即通过默认用户的身份验证，而不需要任何明确的 AUTH 命令。请注意，“resetpass”指令将清除此条件。
resetpass 刷新允许的密码列表。此外，还删除了“nopass”状态。在“resetpass”之后，用户没有相关的密码，如果不添加一些密码(或者稍后将其设置为“nopass”) ，就无法进行身份验证。
reset 执行以下操作: resetpass、 resetkeys、 off、 -@all。用户在创建后立即返回到相同的状态。

ACL 规则可以按任意顺序指定: 例如，你可以从密码、标志或键模式开始。然而，请注意，加法和减法规则将改变意义取决于顺序。

例如，看下面的例子:

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

10.1.ACL LOG

ACL 日志跟踪与 ACL 关联的失败命令和身份验证事件。ACL 日志对于排除 ACL 阻塞的失败命令非常有用。ACL 日志存储在内存中。你可以使用 ACL LOG RESET 回收内存。定义下面 ACL 日志的最大输入长度。

acllog-max-len 128

10.2.使用外部 ACL 文件

与在此文件中配置用户不同，可以使用一个只列出用户的独立文件。这两种方法不能混合使用:

如果你在这里配置用户，同时激活外部 ACL 文件，服务器将拒绝启动。

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

aclfile /etc/redis/users.acl

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

requirepass foobared

10.3.命令重命名（不建议使用）

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

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

例：

rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52

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

rename-command CONFIG ""

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

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

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

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

maxclients 10000

11.内存管理(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表示最近最少使用
LFU表示最少使用

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通过两种方式回收过期的键：访问时发现这些键已过期，以及在后台，称为“活动的过期键(active expire key)”。缓慢地，交互地扫描键空间，以查找要回收的过期键，以便可以释放已过期且不久之后将不再访问的键。

到期周期的默认工作将尝试避免在内存中保留超过百分之十的过期键，并且将尝试避免消耗超过总内存的25％并增加系统延迟。但是，可以将通常设置为“1”的过期“努力”增加到更大的值，直到值“10”。在其最大值时，系统将使用更多的CPU，更长的周期（并且从技术上讲可能会引入更多的延迟），并且将容忍系统中仍然存在的较少的已过期键。这是内存，CPU和延迟之间的折衷方案。

active-expire-effort 1

12.懒惰释放（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命令被另一旧键内容替换时，它可能会删除它。同样，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

13.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线程数，在线程模式下运行基准测试本身，否则将无法注意改进。

14.内核OOM控制（KERNEL OOM CONTROL）

启用此功能可使Redis根据其进程主动控制其所有进程的oom_score_adj值。默认分数将尝试使后台子进程在所有其他进程之前被杀死，而复制节点在主节点之前被杀死。

oom-score-adj no

使用oom-score-adj时，此伪指令控制用于主节点，复制节点和后台子进程的特定值。值的范围是-1000到1000（值越高，表示被杀死的可能性越高）。

非特权进程（不是root进程，并且没有CAP_SYS_RESOURCE功能）可以自由地增加其值，但不能将其减小到其初始设置以下。

服务器启动时，使用相对于oom_score_adj初始值的值。因为通常初始值为0，所以它们通常会与绝对值匹配。

oom-score-adj-values 0 200 800

15.追加模式（APPEND ONLY MODE）

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

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

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

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

appendonly no

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

appendfilename "appendonly.aof"

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

Redis支持三种不同的模式：

no: 不要fsync，只要让OS在需要时刷新数据即可。快点。
always: 每次写入仅追加日志后，fsync。慢，最安全。
everysec: fsync每秒仅一次。妥协。

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

更多详细信息，请查看以下文章：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

在 Redis 启动过程的末尾，当 AOF 数据被加载回内存时，可能会发现一个 AOF 文件被截断。当 Redis 运行的系统崩溃时可能会发生这种情况，特别是当没有 data = ordered 选项安装 ext4文件系统时(但是当 Redis 本身崩溃或中止但操作系统仍然正常工作时就不会发生这种情况)。

当发生这种情况时，Redis 可以退出并带有错误，或者加载尽可能多的数据(现在是默认值) ，如果发现 AOF 文件在结尾被截断，Redis 可以启动。下面的选项控制此行为。

如果 AOF-load-torted 设置为 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 tail。

aof-use-rdb-preamble yes

16.LUA SCRIPTING

Lua 脚本的最大执行时间(毫秒)。

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

当长时间运行的脚本超过最大执行时间时，只有 scriptkill 和 shutdownnosave 命令可用。第一种方法可用于停止尚未调用任何写命令的脚本。第二种方法是关闭服务器的唯一方法，如果脚本已经发出了 write 命令，但用户不想等待脚本的自然终止。

将其设置为0或负值，用于无限制执行，不带警告。

lua-time-limit 5000

17.REDIS CLUSTER

普通 Redis 实例不能成为 Redis 群集的一部分; 只有作为群集节点启动的节点才能成为 Redis 群集的一部分。为了将 Redis 实例作为集群节点启用集群支持取消注释如下:

cluster-enabled yes

每个集群节点都有一个集群配置文件。此文件不打算用手工编辑。它由 Redis 节点创建和更新。

每个 Redis 群集节点都需要不同的群集配置文件。

确保在同一系统中运行的实例没有重叠的群集配置文件名。

cluster-config-file nodes-6379.conf

集群节点超时是指一个节点处于故障状态时必须无法到达的毫秒数。大多数其他内部时间限制是节点超时的倍数。

cluster-node-timeout 15000

如果失败主节点的数据看起来太旧，则它的复制节点将避免启动故障转移。

对于一个复制品来说，没有一个简单的方法可以精确地测量它的“data age” ，因此需要进行以下两项检查:

如果有多个复制节点可以进行故障转移，那么它们将交换消息，以便使用最佳的复制偏移量(来自主处理的更多数据)为复制节点提供优势。复制节点将尝试通过偏移来获得他们的排名，并在故障转移开始时申请与他们的排名成正比的延迟。

每个复制节点都计算最后一次与主节点交互的时间。这可以是接收到的最后一个 ping 或命令(如果主节点仍处于“连接”状态) ，也可以是与主节点断开连接后经过的时间(如果复制链接当前关闭)。如果最后一个交互过于陈旧，那么复制节点根本不会尝试故障转移。

点“2”可以由用户调整。具体来说，如果由于上次与主节点的交互，经过的时间大于:

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

例如，如果节点超时为30秒，cluster-replica-validity-factor为10，并且假设默认的 repl-ping-replica-period 为10秒，那么如果复制节点无法与主节点通话超过310秒，它就不会尝试故障转移。

较大的集群节点有效性因子可能允许具有过老数据的复制节点故障转移到主节点，而太小的值可能根本阻止集群选择复制节点。

为了获得最大的可用性，可以将集群-复制节点-有效性-因子设置为0，这意味着无论复制节点最后一次与主节点交互是什么时候，复制节点总是尝试对主节点进行故障转移。(然而，他们总是试图申请延迟成比例的抵消排名)。

零是唯一能够保证当所有分区都恢复时集群总是能够继续的值。

cluster-replica-validity-factor 10

集群节点可以迁移到孤立的主节点，这些主节点没有可用的复制节点。这提高了集群抵抗失败的能力，否则孤立主节点不能在失败的情况下失败，如果没有可用的复制节点。

仅当旧的主节点仍存在至少给定数量的其他工作复制节点时，复制节点才会迁移到孤立的主节点。这个数字是“migration barrier”。迁移屏障为1意味着，仅当复制节点数据库的主节点中至少有1个其他工作复制节点时，复制节点才会迁移。它通常反映出集群中每个主节点所需的复制节点数。

缺省值为1（仅当其主节点保留至少一个复制节点时，复制节点才会迁移）。要禁用迁移，只需将其设置为一个非常大的值即可设置为0，但仅用于调试和生产危险。

cluster-migration-barrier 1

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

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

cluster-require-full-coverage yes

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

这在不同的情况下很有用，特别是在多个数据中心操作的情况下，如果我们希望在完全DC故障的情况下不对一侧进行升级，那么这是不可行的。

cluster-replica-no-failover no

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

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

第二个用例是针对不符合建议的三个分片但希望启用集群模式并在以后扩展的配置。如果未设置此选项，则在1或2分片配置中的主节点中断会导致整个集群的读/写中断，如果设置了该选项，则只会发生写中断。如果没有主节点的quorum，则插槽所有权不会自动更改。

cluster-allow-reads-when-down no

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

18.集群DOCKER / NAT支持(CLUSTER DOCKER/NAT support)

在某些部署中，Redis Cluster节点的地址发现失败，这是因为地址经过NAT限制或端口被转发（典型情况是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

19.SLOW LOG

Redis Slow Log是一个用于记录超过指定执行时间的查询的系统。执行时间不包括与客户端交谈，发送答复等I/O操作，而仅包括实际执行命令所需的时间（这是命令执行的唯一阶段，在该阶段线程被阻塞并且可以在此期间不满足其他要求）。

你可以使用以下两个参数配置慢速日志：一个告诉Redis，为了使命令被记录下来，执行时间要超过多少微秒，而另一个参数是慢速日志的长度。记录新命令后，最旧的命令将从记录的命令队列中删除。

接下来的时间以微秒为单位，因此1000000等于一秒。请注意，负数将禁用慢速日志记录，而零值将强制记录每个命令。

slowlog-log-slower-than 10000

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

slowlog-max-len 128

20.延迟监视器

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

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

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

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

latency-monitor-threshold 0

21.活动通知(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@<db>__前缀发布。
E 键盘事件，以 __keyevent@<db>__前缀发布。
g 通用命令（非类型专用）像 DEL, EXPIRE, RENAME, ...
$ String 命令
l List 命令
s Set 命令
h Hash 命令
z Sorted set 命令
x 过期事件（每次键过期时生成的事件）
e 驱逐事件（驱逐键以获取最大内存时生成的事件）
t Stream 命令
m 按键丢失事件（注意：它不包括在“ A”类中）
A g$lshzxet的别名，因此“AKE”字符串表示所有事件（由于键丢失事件的独特性，这些键事件被排除在“A”之外）

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

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

notify-keyspace-events Elg

示例2：要获取订阅频道名称__keyevent@0__:expired的过期键流，请使用：

notify-keyspace-events Ex

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

22.GOPHER SERVER

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

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

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

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

22.1.HOW IT WORKS?

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

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

为了创建一个真正的Gopher“漏洞”（Gopher对话中Gopher站点的名称），你可能需要类似以下的脚本：

https://github.com/antirez/gopher2redis

22.2.安全警告(SECURITY WARNING)

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

设置密码后：

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

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

请注意，启用“ io-threads-do-reads”时，当前不支持Gopher。

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

gopher-enabled no

23.高级配置

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

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 <-- 推荐
-1: max size: 4 Kb <-- 推荐

正数表示每个列表节点最多可以存储该元素数量。性能最高的选项通常是-2（8 Kb大小）或-1（4 Kb大小），但是如果你的用例是唯一的，请根据需要调整设置。

list-max-ziplist-size -2

列表也可以被压缩。

压缩深度是指从列表的*each*一侧到*exclude*的快速列表ziplist节点的数量。为了快速执行push/pop出操作，列表的首尾始终未压缩。设置为：

为了快速执行push/pop出操作，列表的首尾始终未压缩。设置为：

禁用所有列表压缩
深度1表示“直到头上有1个节点之后，才开始压缩”，So: [head]->node->node->...->node->[tail]，[head], [tail] 永远不会被压缩；内部节点将压缩。[head]->[next]->node->node->...->node->[prev]->[tail]
这里的2表示：不要压缩head or head->next or tail->prev or tail，而是压缩它们之间的所有节点。
[head]->[next]->[next]->node->node->...->node->[prev]->[prev]->[tail]

等等

list-compress-depth 0

在仅一种情况下，集合具有一种特殊的编码：当集合仅由字符串组成，这些字符串恰好是基数10中的整数（在64位有符号整数范围内）。

以下配置设置设置了大小限制，以便使用此特殊的内存节省编码。

set-max-intset-entries 512

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

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

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

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

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

hll-sparse-max-bytes 3000

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

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

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

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

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

如果你没有如此严格的要求，但希望在可能的情况下尽快释放内存，请使用“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秒钟。

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

相反，由于订阅者和复制节点以推送方式接收数据，因此对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。但是，你可以在此处更改此限制，但必须为1mb或更大

proto-max-bulk-len 512mb

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

并非所有任务都以相同的频率执行，但是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

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

aof-rewrite-incremental-fsync yes

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

rdb-save-incremental-fsync yes

可以调整Redis LFU逐出（请参阅maxmemory设置）。但是，最好从默认设置开始，仅在研究了如何提高性能以及LFU键随时间变化后，才对它们进行更改，可以通过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 |
+--------+------------+------------+------------+------------+------------+

注意1：上表是通过运行以下命令获得的：

  redis-benchmark -n 1000000 incr foo
  redis-cli object freq foo

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

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

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

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

24.主动碎片整理（Active Defragmentation）

什么是主动碎片整理？

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

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

基本上，当碎片超过一定级别时（请参阅下面的配置选项），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，以最大化服务器的性能。

这不仅可以在不同的CPU中固定不同的Redis线程，而且还可以确保将在同一主节点上运行的多个Redis实例固定到不同的CPU。

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

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

将Redis server/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：

bgsave_cpulist 1,10-11

琴韵

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
打赏
0
评论
Redis【有与无】【C1】配置 redis.conf

本文章基于Redis 6.0.9版本，对Redis配置进行说明1.说明Redis 配置文件示例注意，为了读取配置文件，Redis 必须以文件路径作为第一个参数开始:./redis-server /path/to/redis.conf注意: 当需要内存大小时，可以指定通常的形式是1k 5GB 4M 等等：1k => 1000 bytes1kb => 1024 bytes1m => 1000000 bytes1mb => 1024*1024 byte
复制链接

扫一扫