redis.conf中指令含义及翻译-CSDN博客

本文链接：https://blog.csdn.net/qq_43675092/article/details/139412829

注释关于单位：当需要指定内存大小时，可以使用以下方式指定

以常见的形式表示，如1k（千字节）、5GB（千兆字节）、4M（兆字节）等：

单位不区分大小写，所以1GB、1Gb、1gB都是相同的意思

# 1k => 1000 bytes

# 1kb => 1024 bytes

# 1m => 1000000 bytes

# 1mb => 1024*1024 bytes

# 1g => 1000000000 bytes

# 1gb => 1024*1024*1024 bytes

INCLUDES

在此处包含一个或多个其他配置文件。这在您有一个适用于所有Redis服务器的标准模板，但同时也需要为每个服务器定制一些特定设置时非常有用。被包含的文件也可以再包含其他文件，因此请明智地使用此功能。请注意，“include” 选项不会被管理员或Redis Sentinel通过"CONFIG REWRITE"命令重写。因为Redis总是使用处理的最后一行作为配置指令的值，你最好将包含的文件放在本文件的开头，以避免在运行时覆盖配置更改。然而，如果你有兴趣使用包含文件来覆盖配置选项，最好将include语句放在文件的最后一行。

include .\path\to\local.conf
include c:\path\to\other.conf

NETWORK

默认情况下，如果不指定"bind"配置指令，Redis会监听服务器上所有可用的网络接口上的连接。可以通过使用"bind"配置指令后跟一个或多个IP地址，来仅监听一个或多个选定的接口。

例如:
# bind 192.168.1.100 10.0.0.1

# bind 127.0.0.1 ::1

如果运行Redis的计算机直接暴露于互联网，绑定到所有网络接口将是危险的，因为它将实例暴露给互联网上的所有人。因此，默认情况下，我们取消注释以下bind指令，这将强制 Redis 只监听IPv4接口地址（这意味着 Redis 将只接受来自同一台计算机上运行的客户端的连接）。如果您确定希望您的实例监听所有接口，请注释掉以下行

bind 127.0.0.1

保护模式是一种安全保护措施，旨在防止Redis实例在网络上公开后被访问和滥用。当保护模式启用时，并且满足以下条件：

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

服务器仅接受来自IPv4和IPv6环回地址（即127.0.0.1和::1）的客户端连接，以及来自Unix域套接字的连接。默认情况下，保护模式是启用的。您应该仅在确定希望来自其他主机的客户端能够连接到Redis，即便没有配置身份验证，也没有使用“bind”指令明确指定接口集的情况下，才考虑禁用它。protected-mode yes 是Redis服务器的一个配置选项，意味着启用了保护模式。在保护模式下，Redis服务器仅接受来自本地回环地址（IPv4的127.0.0.1和IPv6的::1）以及Unix域套接字的连接请求。换句话说，Redis服务器在保护模式下会拒绝所有非本地的连接尝试，以此作为一种基本的安全措施，防止外部网络直接访问Redis实例，从而降低未授权访问和攻击的风险。如果你打算从网络上的其他主机访问Redis服务器，并且没有设置密码认证或其他安全措施，你可能需要将protected-mode设置为no。但是这样做存在安全隐患，通常建议在关闭保护模式的同时采取其他安全措施，比如设置访问密码、使用防火墙限制访问源等，以确保Redis实例的安全性。

protected-mode yes

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

port 6379

TCP监听（listen）的后台连接队列。在高请求率的环境中，为了防止慢客户端连接问题，您需要设置较大的后台连接队列。请注意，Linux内核会将其默默地截断为/proc/sys/net/core/somaxconn配置值，因此请确保同时增加somaxconn和tcp_max_syn_backlog的值，以达到期望的效果。tcp-backlog 511 是一个配置项，用于设置TCP监听socket的连接请求队列长度。当一个新的TCP连接请求到达时，如果当前连接数已达到最大值，这个请求会被放入一个等待队列中。tcp-backlog 511意味着这个队列最多可以有511个等待处理的连接请求。

tcp-backlog 511

Unix socket,指定Unix域套接字的路径，该套接字将用于监听传入的连接。如果没有指定，默认情况下Redis将不通过Unix域套接字监听连接unixsocket /tmp/redis.sock用于指定Unix域套接字（Unix domain socket）的文件路径。在这个例子中，路径是 /tmp/redis.sock。这意味着Redis服务器将会监听这个路径下的Unix域套接字，以便接受来自本地其他进程的连接请求。Unix域套接字相比于TCP套接字，提供了进程间通信的高效方式，特别适合在同一台机器上运行的程序之间快速、安全地交换数据。通过设置这个选项，Redis就能够通过Unix域套接字接口来服务于那些支持此类型连接的客户端，而非通过网络接口。

unixsocket /tmp/redis.sock

unixsocketperm 700意味着只有Redis服务器进程的拥有者（通常是启动Redis的用户）可以访问和使用这个Unix域套接字文件，这对于提升系统的安全性是有益的，因为它限制了对Redis服务进行访问的用户范围

unixsocketperm 700

如果客户端空闲超过N秒，则关闭该连接（设置为0则不启用此功能）。timeout 0 在Redis配置中的含义是，客户端连接永远不会因为空闲超时而被自动关闭。这意味着即使客户端长时间没有任何操作，Redis服务器也会保持连接开放，不会因为客户端空闲而主动断开连接。这对于需要长期保持连接活跃或有特殊心跳管理机制的应用场景是有用的。

timeout 0

TCP keepalive如果不为零，则在缺乏通信的情况下使用SO_KEEPALIVE选项发送TCP ACK（确认）信息到客户端。这有两个主要用途：
1、检测死连接：通过定期发送ACK，服务器可以检测到客户端是否仍然在线。如果客户端已经断开或网络中断，操作系统将最终通知服务器这一情况，这样Redis就可以释放不再活跃的连接资源。
2、保持连接活跃：在某些网络配置中，长时间无数据传输可能导致中间网络设备（如路由器或防火墙）认为连接已不再需要并将其断
开。通过定期发送这些ACK包，可以避免此类情况发生，保持TCP连接的活跃状态。

在Linux系统上，指定的值（以秒为单位）是用来发送ACK（确认）信号的时间周期。需要注意的是，要关闭一个连接，实际上需要的是这个时间周期的两倍。这是因为在Linux中，TCP KeepAlive首先会在这个周期结束时开始发送探测包，如果连续几个这样的探测包（默认是9个，每个间隔大约为该周期）都没有收到响应，才会最终关闭连接。因此，实际上从开始探测到认定连接无响应并关闭，总耗时会是设置值的两倍左右。而对于非Linux内核的系统，这个时间周期可能取决于操作系统的具体配置，不同的系统可能会有不同的默认行为和调整策略。tcp-keepalive的值设置为60s是一个合理值。tcp-keepalive 0 的作用是禁用Redis服务器端的TCP KeepAlive功能。这意味着Redis将不会利用TCP KeepAlive机制来定期向客户端发送探测包以检查连接是否仍然有效。在缺乏通信的情况下，如果希望完全依赖于应用层的心跳机制或者根本不关心空闲连接的存活状态，可以设置此选项为0。这样一来，中间网络设备或操作系统默认的TCP连接超时设置将决定空闲连接何时被终止，而不是由Redis主动管理。

tcp-keepalive 0

GENERAL

默认情况下，Redis不会作为守护进程（daemon）运行。如果你需要Redis以后台守护进程的方式运行，可以设置’daemonize’为’yes’。需要注意的是，当Redis以后台守护进程形式运行时，它会在/var/run/redis.pid路径下写入一个PID文件，以便于监控和管理进程。
但请注意，此功能在Windows系统上不受支持，因为Windows系统有其特有的服务管理和后台运行机制，所以在此配置中明确指出"NOT SUPPORTED ON WINDOWS"，意味着在Windows环境下不应启用此选项，应保持’daemonize no’的默认设置如果你使用upstart或systemd来启动Redis，Redis可以与你的管理系统交互。有以下几种配置选项：

supervised no：不进行任何监督交互。
supervised upstart：通过将Redis置于SIGSTOP模式来向upstart发送信号。
supervised systemd：通过向$NOTIFY_SOCKET变量指定的路径写入READY=1来向systemd发送就绪信号。
supervised auto：根据环境变量UPSTART_JOB或NOTIFY_SOCKET自动检测并选择upstart或systemd的管理方式。
注意：这些监管方式仅仅用来通知“进程已准备就绪”，并不会启用持续性的存活探测反馈给你的监管系统。并且，这些监督选项在Windows系统上不被支持，因此默认应设置为supervised no。如果指定了pid文件，Redis会在启动时将pid写入指定位置，并在退出时删除该文件。当服务器以非守护进程方式运行时，如果没有在配置中指定pid文件，则不会创建。而当服务器作为守护进程运行时，无论是否在配置中指定，都会使用pid文件，默认位置是"/var/run/redis.pid"。创建pid文件是尽力而为的：如果Redis无法创建pid文件，并不会影响什么，服务器仍会正常启动和运行。此功能在WINDOWS系统上不受支持，因此在Windows环境中不需要也不应该设置pidfile，
保持默认的pidfile /var/run/redis.pid注释或不适用此配置。指定服务器的日志详细程度级别。可选的级别包括：
debug（大量信息，适用于开发和测试）
verbose（许多不常用但也不至于像debug那样繁杂的信息）
notice（适中详细程度，可能是生产环境中需要的）
warning（只记录非常重要或关键的消息）
这个设置帮助调整Redis在运行时输出日志的详细程度，以适应不同的环境和需求，从调试阶段到生产环境都有相应的推荐级别。

loglevel notice

指定日志文件的名称。另外，也可以使用’stdout’来强制Redis将日志输出到标准输出（通常是命令行界面或终端）。logfile “” 在Redis配置中表示不将日志输出到任何文件，即不指定日志文件。这意味着Redis不会将日志信息写入到磁盘上的文件中。如果想要查看Redis的操作日志，可能需要通过其他方式，比如通过标准输出（如果配置成输出到stdout）来查看。

logfile ""

要启用到Windows事件日志的记录，只需将syslog-enabled设置为yes，并根据需要可选地更新其他syslog参数以满足您的需求。如果Redis作为Windows服务安装并启动，这将自动启用。

syslog-enabled no

指定Windows应用程序日志中事件的源名称。syslog-ident redis 配置项用于设置当Redis通过syslog协议发送日志时使用的身份标识（ident）。这个标识通常会在syslog日志条目中显示，用以区分不同的日志来源。通过设置为"redis"，所有Redis产生的日志条目在syslog中都将带有这个标记，便于日志分析和故障排查时快速识别出这些日志是由Redis服务产生的。

syslog-ident redis

设置数据库的数量。默认的数据库是DB 0，你可以根据每个连接的基础使用SELECT 命令来选择不同的数据库，其中dbid是一个介于0和’databases’-1之间的数字。这意味着你可以通过这个配置来决定Redis中可以创建多少个独立的数据库空间，每个数据库都可以存储独立的键值对集合，以实现数据的逻辑隔离

databases 16

SNAPSHOTTING(快照)

保存数据库到磁盘：save 是Redis中配置持久化策略的一个命令格式，用于定义在指定时间内数据变化次数达到某个阈值时，Redis自动执行数据保存到磁盘的操作。：表示时间间隔，即多少秒内。：表示在这段时间内，如果有多少次数据库的修改（添加、删除、更新等变化）发生。如果同时满足给定的秒数和对数据库执行的写操作次数，将保存数据库。
在下面的例子中，保存行为将是：
[在900秒（15分钟）后，如果至少有1个键发生变化
在300秒（5分钟）后，如果至少有10个键发生变化
在60秒后，如果至少有10000个键发生变化
注意：如果你想完全禁用保存功能，可以通过注释掉所有"save"行来实现。
save ""在Redis的配置文件中表示移除所有之前配置的自动保存（snapshotting）规则。这意味着Redis将不会根据时间间隔或写操作数量的变化来自动执行数据的保存操作。如果你希望完全依赖于其他持久化方法，如AOF（Append Only File），或者有外部脚本负责定期备份数据，可以使用这条命令来清除默认或之前设置的自动快照保存策略

save 900 1
save 300 10
save 60 10000

默认情况下，如果启用了RDB快照（至少设置了一个保存点）并且最近的后台保存任务失败，Redis将停止接受写入操作。这样做会让用户以一种严厉的方式意识到数据未能正确地持久化到磁盘上，否则可能会无人察觉，从而导致潜在的灾难性后果。一旦后台保存进程恢复正常工作，Redis会自动重新允许写入操作。然而，如果你已经建立了对Redis服务器及其持久化的适当监控，你可能希望禁用此特性，使得即使磁盘、权限等问题出现，Redis也能继续正常工作。这样可以在遇到问题时保持服务的连续性，同时依靠监控系统来及时发现并处理这些问题。

stop-writes-on-bgsave-error yes

当生成RDB（Redis Database）快照文件时，会使用LZF压缩算法来压缩字符串类型的值。这样做通常可以显著减小RDB文件的大小，从而节约存储空间，并可能加快传输速度。但是，这也意味着在保存快照时会消耗额外的CPU资源来进行压缩操作，在从快照文件恢复数据时也需要解压缩，这可能会增加一点点恢复时间。简而言之，启用此选项是为了在存储效率和CPU使用之间找到一个平衡。

rdbcompression yes

自从RDB版本5开始，文件末尾会放置一个CRC64校验和。这一做法增强了文件抵抗损坏的能力，但代价是在保存和加载RDB文件时会有性能损失（大约10%）。因此，如果你追求最大性能，可以考虑禁用这一功能。如果在创建RDB文件时禁用了校验和功能，那么这些文件将会有一个值为零的校验和，这一特殊值会告知加载程序跳过校验步骤。rdbchecksum yes配置选项表示在Redis中，当生成RDB（Redis Database）快照文件时，会在文件中包含一个CRC64校验和。这个校验和位于文件的末尾，用于在加载RDB文件时验证数据的完整性，确保文件没有被意外损坏。启用此选项虽然会略微增加保存和加载RDB文件时的性能开销（约10%），但它提高了数据恢复过程中的可靠性，确保数据的一致性和正确性。简言之，rdbchecksum yes是为了数据安全和完整性而牺牲一点性能的设置

rdbchecksum yes

dbfilename dump.rdb 是Redis服务器配置文件中的一个参数，用于指定Redis在执行RDB（Redis Database）持久化时，生成的数据快照文件的名称。默认情况下，如果没有特别配置，Redis会将内存中的数据库状态保存到名为 dump.rdb 的二进制文件中。这个文件扮演着非常关键的角色：数据恢复：当Redis服务器因为重启或其他原因需要恢复之前的状态时，它会自动查找并加载 dump.rdb文件，
将数据从磁盘载入到内存中，从而恢复到上一次持久化时的状态。备份与迁移：dump.rdb 文件也可以用于手动备份数据库或者在不同服务器之间迁移数据。灾难恢复：作为数据恢复策略的一部分，定期创建的RDB文件可以作为数据丢失情况下的恢复点，帮助快速恢复服务。通过修改dbfilename 参数，管理员可以根据需要自定义快照文件的名称，这对于管理多个Redis实例或者有特定命名规则的环境非常有用。不过，更改文件名时也需要注意相应的备份和恢复脚本或流程是否需要同步更新以匹配新的文件名。

dbfilename dump.rdb

数据库快照将会被写入到这个指定的目录下，此处一定要是个文件夹，而不是文件

dir ./

REPLICATION

主从复制。使用 slaveof 命令可以让一个Redis实例成为另一个Redis服务器的复制品。关于Redis复制，有几点需要尽快了解：Redis复制是异步的，但你可以配置主节点，在它似乎与至少给定数量的从节点未连接时，停止接受写入操作。这样可以确保数据的安全性，避免在部分从节点未同步到最新数据时就进行了写操作。当复制链接暂时中断且中断时间相对较短时，Redis从节点能够与主节点进行部分重新同步。根据你的需求，你可能需要合理配置复制积压缓冲区的大小（见配置文件的后续部分），以支持这种部分重新同步机制。复制过程是自动的，无需用户干预。在网络分区发生后，从节点会自动尝试重新连接到主节点并重新同步。这种设计确保了系统的高可用性和故障恢复能力，减少了运维工作量当前Redis服务器（之后称为从节点或Slave）会开始与指定的主节点建立连接，请求数据同步。从节点会自动接收并应用来自主节点的所有写操作，保持数据的副本与主节点一致，从而实现数据的复制和分布下。如果要取消复制，可以使用slaveof no one 命令，这样从节点会停止接受外部主节点的命令，转而成为一个独立的、可以接受读写操作的Redis服务器是主节点（Master）的IP地址，是主节点的端口号

slaveof <masterip> <masterport>

masterauth 是Redis配置文件中的一个指令，用于设置从节点（Slave）连接主节点（Master）时需要验证的密码。当你在主节点上设置了访问密码保护（一般通过 requirepass 配置项设置），从节点就必须使用这个 masterauth 配置项来提供正确的密码，以便能够成功地建立与主节点的复制连接。这样可以确保只有授权的从节点能够参与复制过程，增强了安全性。

masterauth <master-password>

slave-serve-stale-data:这个配置决定了当从节点发现自己与主节点断开连接，无法接收新的写操作更新时，是否应该继续响应客户端的读请求。如果设置为 yes，则即使从节点的数据可能不是最新的（即“stale data”陈旧数据），它仍然会继续服务客户端的读请求。这意味着在断连期间，从节点上的数据可能与主节点不一致，但这样做可以保证服务的连续性，对于只关心最终一致性或能容忍短时间数据不一致的应用场景是有益的。简而言之，当设置 slave-serve-stale-data yes 时，表明当从节点与主节点的连接中断时，它依然会继续响应客户端的读请求，尽管提供的数据可能不是最新的。这对于某些对实时性要求不高，但重视可用性的场景较为适用。如果slave-serve-stale-data被设置为’no’，那么对于除INFO和SLAVEOF之外的所有命令请求，从节点将不再尝试提供服务，而是回复一个错误信息“SYNC with master in progress”，表明它当前正忙于与主节点同步，无法处理其他请求。这样做可以确保客户端不会接收到不一致或过时的数据

slave-serve-stale-data yes

slave-read-only 此配置项控制从节点是否只允许执行读操作而禁止写操作。当设置为 yes 时，这意味着从节点被配置为只读模式。在这一模式下，从节点不会接受任何写入请求，仅响应读取查询。这是Redis复制（Replication）机制的典型配置，旨在确保数据的一致性。所有的写操作都在主节点上执行，然后同步到从节点。从节点的只读属性有助于维护数据的完整性和防止数据分歧。简而言之，slave-read-only yes 配置确认了Redis从节点处于只读状态，不允许执行任何写入操作，以支持主从架构中的数据复制和分发策略。

读从节点并非设计用于暴露给互联网上的不可信客户端。这只是防止实例误用的一层保护措施。然而，默认情况下，只读从节点仍会公开所有管理命令，如CONFIG、DEBUG等。在一定程度上，您可以通过使用’rename-command’命令来重命名所有管理/危险命令，以提升只读从节点的安全性。这样做可以在有限范围内改善只读从节点的安全状况，通过隐藏这些命令来减少潜在的误用风险

slave-read-only yes

SYNC strategy（同步策略）

WARNING: DISKLESS REPLICATION IS EXPERIMENTAL CURRENTLY

新的从节点以及无法继续差异接收复制流程的重新连接从节点，需要执行所谓的“全量同步”。全量同步过程中，主节点会向从节点传输一份RDB（Redis Database）文件。这一传输过程可以通过以下两种方式之一进行：

1、基于磁盘的同步：Redis主节点会创建一个新的进程，用于将RDB文件写入磁盘。随后，父进程会将此文件逐步传输给从节点。在此方式下，当当前正在生成RDB文件的子进程完成后，队列中的更多从节点可以立即开始接收RDB文件。

2、无盘复制：Redis主节点创建一个新的进程，直接将RDB文件写入到与从节点相连的套接字中，完全不触及磁盘。采用无盘复制时，一旦传输开始，新到达的从节点会被排队等待，直到当前传输结束才会启动新的传输。

当使用基于磁盘的复制时，在RDB文件生成期间，更多的从节点可以排队等待，并在当前生成RDB文件的子进程完成后立即接收文件。相比之下，使用无盘复制时，主节点会在开始传输前等待一段可配置的时间（以秒计），期望能有更多的从节点到达，从而实现并行传输。在磁盘速度较慢而网络带宽较大的情况下，无盘复制表现得更为优越。因为它消除了磁盘I/O的瓶颈，更能充分利用高速网络的带宽优势，加快了数据同步的速度。

repl-diskless-sync no

repl-ping-slave-period 10 是Redis服务器配置项之一，用于设置主节点向从节点发送PING命令的周期，以检测从节点是否仍然在线和保持连接活跃。这里的数字10表示周期为每10秒执行一次。这个配置帮助监控主从之间的连接状态，确保主节点能够及时发现从节点的断线情况。如果从节点在配置的周期内没有响应PING命令，主节点可能会认为该从节点已经离线，并可能采取相应的行动，比如在日志中记录该事件或触发重新连接尝试。通过调整这个参数，可以根据实际网络状况和需求来优化主从间的健康检查频率。

repl-ping-slave-period 10

该选项用于设置以下复制超时时间：1、从从节点角度看，在SYNC期间的大块传输I/O。2、从从节点角度看的主节点超时（数据传输、PING响应）。3、从主节点角度看的从节点超时（REPLCONF ACK PING响应）。重要的是确保此值大于repl-ping-slave-period设置的值，否则在主从节点间通信流量较低时，每次都会检测到超时。这意味着如果主从间的数据交换、心跳检测或确认响应不够频繁，而超时设置又过短，系统可能会误判为连接失败，尽管实际上连接仍然是正常的。因此，合理设置超时时间对于维持复制连接的稳定性至关重要。

repl-timeout 60

在SYNC之后，是否在从节点套接字上禁用TCP_NODELAY？如果选择“yes”，Redis将使用较少的TCP数据包和带宽向从节点发送数据。但这可能会增加数据在从节点侧出现的延迟，对于使用默认配置的Linux内核，延迟最多可达40毫秒。如果选择“no”，则数据在从节点上出现的延迟将减少，但复制将使用更多的带宽。默认情况下，我们为了低延迟进行优化，但在非常高流量的条件下或主从节点相隔多跳的情况下，将此设置为“yes”可能是个好主意。

repl-disable-tcp-nodelay no

设置复制积压（replication backlog）的大小。积压是一个缓冲区，当从节点断开连接一段时间时，它会累积从节点数据。这样一来，当从节点想要重新连接时，通常就不需要进行全面的重新同步（full resynchronization），而只需要部分重新同步（partial resynchronization）即可，即只需传递从节点断开期间错过的数据部分。复制积压越大，从节点可以断开连接的时间就越长，之后仍然能够执行部分重同步。只有当至少有一个从节点连接时，才会分配复制积压缓冲区。

repl-backlog-size 1mb

当主节点在一段时间内没有连接任何从节点后，之前为复制积压（backlog）分配的内存将会被释放。以下配置选项用于设置从最后一个从节点断开连接开始，需要经过多少秒后，复制积压缓冲区才会被释放。如果设置为0，则表示永远不会释放积压缓冲区。

repl-backlog-ttl 3600

从节点优先级是一个整数，由Redis在INFO命令的输出中发布。Redis Sentinel使用这个优先级来选择一个从节点，在主节点不再正常工作时将其提升为新的主节点。具有较低优先级编号的从节点被认为更适合晋升，例如，如果有三个优先级分别为10、100、25的从节点，Sentinel会选择优先级为10的那个，因为这是最低的。然而，一个特殊的优先级0标记了该从节点不能执行主节点的角色，因此优先级为0的从节点永远不会被Redis Sentinel选中以进行晋升。默认情况下，从节点的优先级是100。

slave-priority 100

主节点有可能在连接的从节点少于N个，并且这些从节点的延迟都在M秒以内时，停止接受写入操作。这里的N个从节点需要处于"在线"状态。所计算的延迟（单位为秒），要求小于或等于指定的值，它是根据从节点最后发送的ping消息来确定的，通常这些ping消息每秒发送一次。此选项并不能保证至少有N个复制节点会接受写入，但它可以将窗口期的风险控制在一定范围内，即如果可用的从节点数量不足，丢失写入的风险会限制在指定的秒数之内。例如，若要要求至少有3个从节点，它们的延迟都小于或等于10秒，则可以这样设置。

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

SECURITY

要求客户端在处理任何其他命令之前，必须发出 AUTH <PASSWORD> 命令。这在你不信任其他能够访问运行redis-server主机的环境里可能会很有用。为了保持向后兼容性并且因为大多数人并不需要认证（例如，他们运行自己的服务器），这个设置默认是被注释掉的。警告：由于Redis运行速度非常快，外部用户可以每秒对一台性能良好的服务器尝试多达15万次密码。这意味着你应该使用一个非常强大的密码，否则密码很容易被破解。

requirepass foobared

命令重命名。在共享环境中，可以更改危险命令的名称。例如，可以将CONFIG命令重命名为难以猜测的名称，以便它仍可用于内部工具，但对普通客户端不可用。示例：rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52也可以通过将其重命名为空字符串来完全禁用一个命令：rename-command CONFIG “” ，请注意，更改被记录在AOF文件中或传输给从节点的命令的名称可能导致问题。这意味着，如果命令被重命名后，之前记录的命令在重放时可能无法正确解析，或者从节点无法识别重命名后的命令，从而影响数据一致性或复制的正常进行。因此，在进行命令重命名时，需要谨慎考虑这些潜在的影响。

rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52
rename-command CONFIG ""

LIMITS

设置同一时间最大连接客户端的数量。默认情况下，此限制设置为10000个客户端。但是，如果Redis服务器无法配置进程文件限制以允许指定的限制，则允许的最大客户端数量将被设置为当前文件限制减去32（因为Redis保留了一些文件描述符供内部使用）。一旦达到此限制，Redis将关闭所有新的连接，并发送一个错误信息“达到最大客户端数量”。

maxclients 10000

如果Redis仅用作无任何形式的持久化内存缓存，即不需要后台AOF或RDB持久化，那么用于后台持久化的fork()机制就是多余的。作为一种优化手段，在Windows版本的Redis中，可以完全关闭所有持久化功能。这样做会将堆分配重定向到系统堆分配器，并禁用那些原本会导致fork操作的命令：BGSAVE和BGREWRITEAOF。此标志不能与其他配置AOF和RDB操作的任何其他标志结合使用。这意味着启用此选项时，Redis将完全专注于提供高速的内存缓存服务，而不考虑数据的持久保存或恢复，适用于对数据持久化没有需求或有其他备份机制的场景。

persistence-available [(yes)|no]

不要使用超过指定字节数量的内存。当达到内存限制时，Redis会尝试根据选定的逐出策略（参见maxmemory-policy）移除键。如果Redis无法根据策略移除键，或者策略设置为’noeviction’，Redis将开始对使用更多内存的命令（如SET、LPUSH等）返回错误，并继续响应只读命令（如GET）。此选项通常在将Redis用作LRU缓存，或为实例设置硬性内存限制（使用’noeviction’策略）时有用。警告：如果你有从节点连接到启用了maxmemory的实例上，供给从节点输出缓冲所需的内存大小会从已用内存计数中扣除，这样网络问题或重新同步就不会触发一个循环，即键因内存满而被逐出，进而导致从节点的输出缓冲区充满这些键的DEL命令，引起更多键被逐出，如此循环，直至数据库被清空。简而言之，如果你有从节点连接，建议设置一个更低的maxmemory限制，以便系统有一定空闲RAM供从节点的输出缓冲（但如果策略是’noeviction’，则不需要）。警告：如果不设置maxmemory，当堆限制达到时，Redis将以内存不足异常终止。注意：由于Redis使用系统页面文件分配堆内存，Windows任务管理器或其他工具（如ProcessExplorer）显示的工作集内存使用情况可能并不总是准确。例如，在后台保存RDB或AOF文件后，工作集值可能会显著下降。为了检查redis-server用于存储数据的确切内存使用量，请使用INFO client命令。INFO命令仅显示用于存储Redis数据的内存，不包括Windows进程自身需求额外使用的内存。INFO命令未报告的额外内存量可通过从Windows任务管理器报告的峰值工作集和INFO命令报告的used_memory_peak相减来计算得出。

maxmemory <bytes>

MAXMEMORY POLICY：当达到maxmemory限制时，Redis将根据所选择的策略决定移除哪些键。你可以从以下五种行为中选择：

volatile-lru：使用LRU（Least Recently Used，最近最少使用）算法移除设置了过期时间的键。
allkeys-lru：根据LRU算法移除任何键，不论是否设置了过期时间。
volatile-random：随机移除一个设置了过期时间的键。
allkeys-random：随机移除任意一个键。
volatile-ttl：移除具有最近过期时间的键（最小TTL）。
noeviction：不进行逐出，仅在写操作时返回错误。

注意：无论选择上述哪种策略，当没有适合逐出的键时，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（最近最少使用）和最小TTL算法并非精确算法，而是近似算法（为了节省内存），因此你可以根据需要调整其运行速度或准确性。默认情况下，Redis会检查五个键并挑选出最近最少使用的那个进行淘汰。你可以通过以下配置指令来改变采样大小。默认值5通常能产生足够好的结果。设置为10会更接近真实的LRU效果，但会略微增加CPU开销。设置为3则非常快速但精确度较低。

maxmemory-samples 5

APPEND ONLY MODE

默认情况下，Redis会异步地将数据集转储到磁盘上。在许多应用程序中，这种模式已经足够好了，但是如果出现Redis进程问题或者断电情况，可能会导致几分钟的写操作丢失（取决于配置的保存点）。“Append Only File” 是一种提供更好持久性的备份模式。例如，通过使用默认的数据fsync策略（请参见配置文件中的后续内容），Redis可以在像服务器停电这样的紧急情况下仅丢失一秒的写入数据，或者如果Redis进程本身出现问题但操作系统仍在正常运行，则可能只会丢失一次写入操作。AOF和RDB持久性可以同时启用而不会出现问题。如果在启动时启用了AOF，Redis将加载AOF文件，这个文件具有更好的持久性保证。

appendonly no

追加写入文件的名称（默认为：“appendonly.aof”）

appendfilename "appendonly.aof"

“appendfsync everysec” 是Redis配置文件中的一个选项，用于设置数据同步到磁盘的频率。当设置为 “appendfsync everysec” 时，表示Redis将每秒将写操作同步到磁盘一次。这种设置可以在保证一定性能的情况下提高数据持久性，因为每秒都会将数据写入磁盘，确保即使发生意外情况（比如服务器停电），也最多只会丢失一秒的数据。另外，还有其他选项可供选择，例如 “appendfsync always” 表示每次写操作都会立即同步到磁盘，这样可以提供最高的数据持久性，但可能会影响性能。而 “appendfsync no” 则表示数据不会被强制同步到磁盘，而是依赖操作系统自身的机制来处理数据同步，这种模式可能会降低数据持久性

appendfsync everysec

将AOF fsync策略设置为always或everysec，并且后台保存进程（后台保存或AOF日志后台重写）执行大量I/O操作时，某些Linux配置下Redis可能会在fsync()调用上阻塞太久。需要注意的是，目前还没有对此进行修复，因为即使在不同线程中执行fsync也会阻塞我们的同步写入（write(2)）调用。为了缓解这个问题，可以使用以下选项来防止在主进程中调用fsync()，同时后台有BGSAVE或BGREWRITEAOF正在进行。这意味着在另一个子进程正在保存时，Redis的耐久性与"appendfsync none"相同。在实际情况下，这意味着在最坏情况下（使用默认的Linux设置），可能会丢失多达30秒的日志。如果遇到延迟问题，请将其设置为"yes"。否则，将其保留为"no"是从耐久性角度来看最安全的选择。

“no-appendfsync-on-rewrite no” 是Redis配置文件中的一个选项，用于控制在执行AOF重写时是否允许同步磁盘。当设置为 “no-appendfsync-on-rewrite no” 时，表示在进行AOF重写期间允许同步磁盘。在Redis中，AOF重写是指通过减少AOF文件的体积来优化AOF日志文件，去除其中冗余和重复的命令。如果设置了 “no-appendfsync-on-rewrite yes”，则表示在AOF重写期间不会执行AOF文件的同步操作，可以提高AOF重写的性能，但也可能会增加数据丢失的风险。而设置为 “no-appendfsync-on-rewrite no” 则是较为安全的选择，确保在AOF重写期间依然执行AOF文件的同步操作，保证数据的完整性和一致性。

no-appendfsync-on-rewrite no

自动重写追加仅文件。 Redis 能够在 AOF 日志文件大小按指定百分比增长时，自动隐式地调用 BGREWRITEAOF 命令来重写日志文件。其工作原理如下：Redis 会记录上次重写后 AOF 文件的大小（如果自重启以来尚未进行过重写，则使用启动时 AOF 的大小作为基准）。这个基准大小会与当前文件大小进行比较。如果当前大小超过了指定的百分比，就会触发重写操作。此外，您还需要指定 AOF 文件重写的最小大小，这对于即使达到了百分比增长阈值，但仍避免对较小的 AOF 文件进行不必要的重写很有帮助。如果要禁用自动 AOF 重写功能，可以将百分比设为零。

“auto-aof-rewrite-percentage 100” 是Redis配置文件中的一个选项，用于设置当AOF日志文件大小超过上一次重写时的百分比阈值时，自动触发AOF重写。在这里，设置为100表示当AOF日志文件大小达到上一次重写大小的100%时，即使没有达到指定的尺寸限制，也会触发自动进行AOF重写。通过设置这个参数，可以确保在AOF日志文件不断增长并且达到一定比例时，自动执行AOF重写以优化AOF文件的体积，减少冗余和重复的操作，以提高性能和节省磁盘空间。

“auto-aof-rewrite-min-size 64mb” 是Redis配置文件中的一个选项，用于设置执行自动AOF重写所需的最小AOF文件大小阈值。在这里，设置为64MB表示只有当AOF日志文件的大小达到或超过64MB时，才会触发自动执行AOF重写操作。通过设置这个参数，可以确保AOF日志文件达到一定的大小时才会进行AOF重写，避免频繁执行AOF重写操作带来的性能开销。这样可以在一定程度上控制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配置选项来控制。如果aof-load-truncated设置为yes，Redis会加载被截断的AOF文件，并开始记录日志提醒用户这一情况。相反，如果该选项设为no，服务器则会报错并拒绝启动。此时，用户需要在重启服务器前，使用redis-check-aof工具修复AOF文件。需要注意的是，如果AOF文件在中间部分被发现损坏，无论此选项如何设置，服务器都将退出并报错。此选项仅适用于Redis尝试从AOF文件读取更多数据但找不到足够字节的情况。

aof-load-truncated yes 是Redis数据库配置中的一个设置项，用于控制Redis在启动时如何处理可能已损坏或不完整的AOF（Append Only File）文件。AOF是Redis的一种持久化方式，通过记录所有的写操作指令来保证数据的持久性。当设置为 yes 时，如果Redis检测到AOF文件的末尾可能因为某些原因（如系统崩溃、电源故障等）而被意外截断，Redis仍会尝试加载这个不完整的AOF文件。Redis会加载文件中完整且正确的部分，并且在启动日志中记录这一情况，通知管理员AOF文件可能存在损坏。这样做的好处是可以尽量恢复数据，避免因文件损坏而导致Redis无法启动。相反，如果设置为 no，Redis在启动时如果发现AOF文件有截断或损坏的情况，将不会启动，而是报错并要求用户先手动修复AOF文件。这可能需要使用 redis-check-aof --fix 命令来修复损坏的文件，之后Redis才能成功启动。因此，aof-load-truncated yes 是一种较为灵活且恢复导向的配置，它使Redis能够在遇到文件损坏时仍尝试恢复并提供服务，尽管可能需要人工进一步检查和干预来完全解决问题。

aof-load-truncated yes

在重写AOF文件时，Redis能够在其AOF文件中使用RDB前缀，以便更快地进行重写和恢复操作。当此选项启用时，重写后的AOF文件由两部分组成：{[RDB文件]，[AOF尾部]}当加载Redis时，它会识别到AOF文件以"REDIS"字符串开头，并加载这一前缀中的RDB文件，随后继续加载AOF的后续部分。这意味着在恢复过程中，Redis首先通过快速加载RDB快照迅速建立基本的数据状态，然后通过执行AOF日志的剩余部分来精确地回放之后的所有数据变更操作，从而加速了整个启动和数据恢复的过程。

aof-use-rdb-preamble yes 是一个Redis配置项。Redis是一个键值存储系统，它同时支持两种持久化方式：AOF（Append Only File，仅追加文件）和RDB（Redis DataBase，快照）。这个配置项是关于如何在AOF持久化中利用RDB格式的一个设置。当设置为yes时，Redis会在AOF文件的开头使用一个RDB格式的“前言”来记录数据库的某一时刻的快照状态。这意味着在AOF重写或者启动恢复时，Redis可以先通过加载这个RDB前言快速地恢复到一个基础数据状态，然后再逐步应用之后的AOF日志操作来达到数据的完全恢复。这样做可以加快Redis的重启和故障恢复速度，因为它结合了RDB快速恢复的优点和AOF的详细操作记录优点。简而言之，aof-use-rdb-preamble yes配置意味着在AOF文件中利用RDB格式来加速Redis服务器的启动和故障恢复过程。

aof-use-rdb-preamble yes

LUA SCRIPTING

Lua脚本的最大执行时间，以毫秒为单位。如果达到最大执行时间，Redis将记录脚本仍在允许的最大时间后执行，并将开始以错误响应查询。当一个长时间运行的脚本超过最大执行时间时，只有SCRIPT KILL和SHUTDOWN NOSAVE命令可用。前者可用于停止尚未调用写入命令的脚本。后者是唯一在脚本已经发出写入命令但用户不想等待脚本自然终止时关闭服务器的方法。将其设置为0或负值以取消执行时间限制而不发出警告。

“lua-time-limit 5000” 这个指令意味着设置Lua脚本的执行时间限制为5000毫秒（即5秒）。这意味着当Lua脚本开始运行后，如果在5秒内脚本没有执行完毕，将会因为超时而被强制终止。这个限制通常用于防止某个脚本因无限循环或其他原因消耗过多资源，从而确保系统的稳定性和其他任务的正常执行。在不同的应用环境或配置文件中，具体设置方式可能会有所不同。

lua-time-limit 5000

REDIS CLUSTER

普通的Redis实例不能成为Redis集群的一部分；只有作为集群节点启动的节点才可以。为了启动一个Redis实例作为集群节点，需要通过取消以下注释来启用集群支持。

cluster-enabled yes

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

cluster-config-file nodes-6379.conf 这个配置项指定了Redis集群节点使用的集群配置文件的名称。在这个例子中，文件名为nodes-6379.conf，其中6379通常代表该Redis节点监听的端口号。这个文件自动由Redis生成和维护，包含了该节点所属集群的配置信息，包括节点的ID、IP地址、端口以及它与其他节点的连接信息等。此配置告诉Redis将关于该集群节点的所有必要配置信息保存到名为nodes-6379.conf的文件中。每个集群节点都应该有自己独立的配置文件，且文件名应根据实际情况（比如端口号）进行相应调整，以避免冲突。此文件对于Redis集群的正常运作至关重要，但不应直接手动修改，而是应该通过Redis集群的管理命令来操作集群结构。

cluster-config-file nodes-6379.conf

集群节点超时是指一个节点必须无法到达多少毫秒后，它才会被认为处于故障状态。大多数其他内部时间限制都是节点超时时间的倍数。

cluster-node-timeout 15000 这个配置项设置了Redis集群中节点的超时时间，具体值为15000毫秒（即15秒）。这意味着如果一个集群节点在15秒内没有响应其他节点的ping请求或者其他通信操作，它将被集群中的其他节点认为是不可达或已失败。一旦节点被标记为失败，集群可能开始执行故障转移操作，重新分配该节点负责的槽（slot），以保证集群的高可用性。

cluster-node-timeout 15000

当主节点发生故障时，其副本（replica）在数据看起来过旧的情况下会避免开始故障转移（failover）过程。由于副本无法直接准确测量其“数据年龄”，因此会执行以下两个检查来辅助决策：1、基于复制偏移量的排序：如果有多个副本能够进行故障转移，它们会交换消息以尝试让具有最佳复制偏移量（即从主节点处理了更多数据）的副本获得优先权。副本会尝试根据偏移量排名，并根据其排名延迟故障转移的开始时间。2、最近交互时间检查：每个副本都会计算与主节点最后一次交互的时间。这可以是最近一次的ping响应或接收的命令时间（如果主节点仍处于“已连接”状态），或者自与主节点断开连接以来经过的时间（如果复制链接当前不可用）。如果最后一次交互时间过久，副本将完全不会尝试故障转移。用户可以调整第二点中的条件。具体来说，如果副本自上次与主节点交互以来经过的时间超过以下值，它将不会执行故障转移：

(节点超时时间 * 副本有效性因子) + 复制心跳间隔时间

例如，如果节点超时时间为30秒，副本有效性因子设为10，假设默认的复制心跳间隔时间为10秒，那么副本在与主节点失去联系超过310秒后将不会尝试故障转移。副本有效性因子的大小选择很关键：过大的值可能导致数据过旧的副本进行故障转移，而过小的值可能使集群根本无法选举出合适的副本。为了实现最高可用性，可以将副本有效性因子设置为0，这意味着无论副本上一次与主节点交互是在何时，副本都将始终尝试对主节点进行故障转移（尽管它们仍会根据偏移量排名尝试延迟）。设置为0是唯一能保证在所有分区问题解决后，集群总能继续运行的值。

cluster-replica-validity-factor 10

集群中的副本（replica）能够迁移到无工作副本的孤立项（orphaned master）上。这些孤立项指的是失去了所有工作副本的主节点。这种迁移能力增强了集群对抗故障的能力，因为在没有工作副本的情况下，如果孤立项发生故障，就无法进行故障转移。副本仅在为其原主节点至少还有一定数量的其他工作副本时，才会迁移到孤立项上。这个数量被称为“迁移障碍”（migration barrier）。例如，如果迁移障碍设置为1，那么副本仅在至少还有一个其他工作副本为其原主节点服务时才会迁移。这个值通常反映了你希望集群中每个主节点拥有的副本数量。默认情况下，迁移障碍值为1（表示副本仅在原主节点至少还保留有一个副本时才会迁移）。要禁用迁移，可以将其设置为一个非常大的值。虽然可以设置为0，但这通常只在调试时有用，在生产环境中使用则存在风险。

cluster-migration-barrier 1

默认情况下，当Redis集群节点检测到至少有一个哈希槽（hash slot）未被覆盖（没有可用节点服务它）时，就会停止接受查询。这样，如果集群部分宕机（例如，有一系列的哈希槽不再被覆盖），整个集群最终会变得不可用。只有当所有槽位再次被覆盖时，它才会自动恢复可用状态。然而，有时你希望集群中仍在工作的那部分，能继续为仍被覆盖的键空间部分接受查询。为了实现这一点，只需将cluster-require-full-coverage选项设置为no。这样，即使集群部分节点或哈希槽数不完整，工作中的集群部分仍会为它覆盖的键空间提供服务。

cluster-require-full-coverage yes

SLOW LOG

Redis慢查询日志是一个系统，用于记录超过特定执行时间的查询。这个执行时间不包括与客户端通信、发送响应等I/O操作的时间，而仅仅是指实际执行命令所需的时间（这是命令执行阶段中唯一线程被阻塞，同时不能服务其他请求的阶段）。你可以通过两个参数来配置慢查询日志：一个参数告诉Redis，命令需要超过多少微秒的执行时间（以微秒为单位），才会被记录；另一个参数是慢日志的长度。当新的命令被记录时，最旧的命令将从记录的命令队列中移除。下面的时间单位是微秒，所以10000000相当于一秒。注意，负数会禁用慢查询日志，而设置为零则会强制记录每一个命令。

slowlog-log-slower-than 10000

慢查询日志的长度是没有限制的，但请记住它会消耗内存。你可以通过执行SLOWLOG RESET命令来回收慢查询日志所占用的内存。

slowlog-max-len 128

LATENCY MONITOR

Redis延迟监控子系统在运行时对不同操作进行采样，以便收集与Redis实例潜在延迟来源相关的数据。用户可以通过LATENCY命令获取这些信息，打印图表并得到报告。系统仅记录那些执行时间等于或超过由latency-monitor-threshold配置指令指定的毫秒数的操作。当其值设置为零时，延迟监控关闭。默认情况下，延迟监控是禁用的，因为如果你没有遇到延迟问题，通常不需要此功能，并且收集数据虽对性能影响很小，但在高负载下仍可被测量到。如有需要，可以通过运行时命令"CONFIG SET latency-monitor-threshold "轻松启用延迟监控。

latency-monitor-threshold 0

EVENT NOTIFICATION

PUBLISH __keyspace@0__:foo del 是Redis中与键空间通知（Keyspace Notifications）相关的一个命令用法。这个命令是用来通过Redis的发布/订阅（Pub/Sub）系统来发送一个通知的。具体解释如下：PUBLISH 是Redis命令，用于在给定频道上发布一条消息。
__keyspace@0__:foo 是频道名，这里的 keyspace是指键空间通知频道的前缀，@0 指的是数据库索引（Redis可以在多个数据库中运行，0是默认数据库），foo则是具体的键名。所以整体表示在第0号数据库中名为foo的键发生变化的通知频道。del 是消息内容，表示这个通知是因为执行了DEL命令，即foo键被删除。综上所述，这个命令意味着在Redis中，当键foo从数据库0中被删除时，系统会自动向名__keyspace@0__:foo的频道发布一条消息，内容是del，以此来通知所有订阅了该频道的客户端关于这一键删除事件的信息。
PUBLISH __keyspace@0__:foo del

PUBLISH __keyevent@0__:del foo 命令在Redis中表示向特定的键事件通知通道发布一个消息。这里的细节分解如下：PUBLISH 是Redis的发布命令，用于将一条消息发送到指定的频道。__keyevent@0__: 是一个特殊前缀，代表键事件（Key Event）通知的频道，其中的 @0 表示发生在数据库索引为0的数据库中。del 是事件类型，表示这是一条关于键被删除(DEL)的事件通知。foo 是触发此事件的键名，即数据库中被删除的键为foo。因此，该命令的作用是在Redis的数据库0中，手动发布一条关于键foo被删除(DEL操作)的事件消息至对应的键事件(keyevent)频道。通常，这类消息是由Redis自动发布的，用于通知订阅了相应频道的客户端有关键变化的信息，但你也可以手动触发这样的消息来模拟事件或做特殊用途。
PUBLISH __keyevent@0__:del foo

Redis 支持通过发布/订阅（Pub/Sub）机制向客户端通知有关键空间中的事件。这项功能在 Redis 官方文档网站的键空间通知部分页中有详细说明。

举例来说，如果启用了键空间事件通知功能，当客户端在数据库0中对键 “foo” 执行 DEL 操作时，将会通过 Pub/Sub 发布两条消息：

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

可以从中看到，第一个消息通过 __keyspace@<db>__ 前缀通知了键操作，第二个消息则通过 __keyevent@<db>__ 前缀通知了具体操作和键名。可以从中选取 Redis 将会通知的事件类别，每个类别由单个字符标识：

K：键空间事件，使用 __keyspace@<db>__ 前缀发布。
E：键事件，使用 __keyevent@<db>__ 前缀发布。
g：通用命令（非特定类型），比如 DEL、EXPIRE、RENAM等。
$：字符串命令
l：列表命令
s：集合命令
h：哈希命令
z：有序集合命令
x：过期事件（每次键过期时生成）
e：驱逐出事件（因达到最大内存限制而驱逐出键时）
A：g$lshzxe 的别名，意味着 “AKE” 字符串包含所有上述事件。

“notify-keyspace-events” 配置置项接受一个字符串参数，该字符串由零个或多个字符组成。空字符串表示禁用通知功能。例如，要启用列表和通用事件，从事件名称的角度看，可以使用：notify-keyspace-events Elg第二个例子，要获取过期键的流，通过订阅名为 __keyevent@0__:expired 的频道，可以使用：notify-keyspace-events Ex默认情况下，所有通知都是禁用的，因为大多数用户不需要此特性，而且它有一定的开销。需要注意，如果没指定K或E中的至少一个，将不会有任何事件被传递。

notify-keyspace-events "" 是Redis配置项的一部分，用于控制Redis键空间通知（Keyspace Notifications）的开启与类型。当设置为双引号（“”），即空字符串时，这意味着禁用了所有的键空间通知功能。键空间通知允许客户端订阅特定的频道以接收关于数据库键的创建、更新或删除等事件通知。这些通知对于监控数据库变动、实时更新缓存一致性、或者数据审计等场景非常有用。Redis提供了多种类型的事件通知，可以用字母来标识，例如"E"代表键 expiration 事件，"g"代表 generic 事件，等等。当配置项中指定了这些字母，相应的事件会被激活。然而，当设置为notify-keyspace-events ""时，Redis将不会广播任何与键相关的事件，包括键的增删改查等操作，这对于优化性能或减少不必要的网络流量在某些场景下是有帮助的，尤其是当应用程序并不依赖这些实时键空间变更通知时。

notify-keyspace-events ""

ADVANCED CONFIG

哈希（Hashes）在具有少量条目且最大的条目没有超过给定阈值时，会使用一种内存高效的数据结构进行编码。这些阈值可以通过以下配置指令进行设置。不过，请注意，具体的配置指令和阈值设定细节需要参考Redis的官方文档或配置文件（通常是redis.conf），因为实际的指令和选项可能会随着Redis版本的不同而有所变化。一般而言，Redis提供了诸如hash-max-ziplist-entries和hash-max-ziplist-value等配置项来控制哈希表何时从压缩列表（ziplist）转换为哈希表，以优化内存使用。这些配置允许用户根据自己的数据特点微调Redis以达到最优的内存利用率。

hash-max-ziplist-ziplist-entries 512 是一个Redis配置项，用于设置哈希数据结构在何种条件下从压缩列表（ziplist）转换为哈表编码。具体来说，这个配置项的意思是：当一个哈希中的条目数量超过512个时，Redis将不再使用ziplist编码，而是转而使用更通用但可能占用更多内存的哈表编码方式来存储哈数据结构。这个设置允许用户根据实际应用场景调整，以在内存使用效率和性能之间找到平衡点。

hash-max-ziplist-value 64 是Redis配置项的一部分，用于控制哈希（Hash）数据结构中单个条目的值大小。具体地，这个设置意味着当哈中的任何条目的值大小（以字节为单位）超过64字节时，Redis将不再使用ziplist（一种紧凑的编码格式）来存储这个哈，而是选择其他更适合大值存储的方式，这可能消耗更多的内存但提供了灵活性。通过调整这个阈值，用户可以根据自己数据的特点优化内存使用和性能。

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

列表在Redis中也采用了一种特殊的编码方式以节省大量空间。对于内部列表节点允许的条目数，可以设置为固定的最大尺寸或元素的最大数量来指定。

若使用固定的最大尺寸，可选值范围是-5至-1，意义如下：

-5：最大尺寸为64KB（不推荐用于常规工作负载）
-4：最大尺寸为32KB（不推荐）
-3：最大尺寸为16KB（可能也不推荐）
-2：最大尺寸为8KB（良好）
-1：最大尺寸为4KB（良好）

正数则意味着每个列表节点确切存储该数量的元素，不多不少也不少。

通常，最高性能的选项是-2（8KB尺寸）或-1（4KB），但如果你的使用场景独特，应根据需要调整这些设置。这意味着根据你的具体需求权衡定量存储空间使用和性能，选择最合适的配置来优化Redis列表数据结构的存储效率。

list-max-ziplist-size -2

列表数据结构在Redis中也可以被压缩，以进一步节省内存空间。压缩深度（compress depth）指的是在列表的每侧（头部和尾部）有多少个ziplist节点是排除于压缩之外*的。也就是说，列表的头部和尾部总是保持未压缩状态，以确保快速的push和pop操作。

下面是几个压缩设置的解释：

0: 禁用以禁用所有列表的压缩功能。
1: 压缩深度1意味着“直到列表内部至少深入1个节点才开始压缩”，无论是从头部还是尾部开始。因此，列表的两端节点（头部和尾部）总是保持未压缩，中间节点则可以被压缩。
2: 在这个设置下，头部的下一个节点和尾部的前一个节点不压缩，但两者之间的所有节点（node）都进行压缩。即，[head]->[下一个]->node->…->node->[前一个]->[tail]。
3 及更高数值依此类推：压缩规则扩展，意味着头部和尾部的更深层次节点（如[下一个]和[前一个]）不压缩，但它们之间的所有节点都被压缩。

总之，这个设置允许用户根据列表操作的特性来微调优压缩策略，以在性能和空间效率之间取得平衡。例如，深度值越大，列表中越多的内部节点可以被压缩，从而节省更多空间，但可能稍微牺牲一些访问这些节点的速度。

list-compress-depth 0

集合（Sets）在一种特定情况下会使用一种特殊的编码：当集合中的字符串恰好都是以基数10表示的、落在64位有符号整数范围内的整数时。以下配置项设定了集合的大小限制，以便使用这种特殊编码来节省内存。简单来说，这个配置允许你在满足一定条件的集合上启用一种高效的内存存储方式，即当集合中的所有元素都是可表示为64位带符号整型整数的十进制字符串时，Redis会采用一种特殊编码来节约内存。你需要设置集合的大小阈值来激活这一特性。

set-max-intset-entries 512

类似于哈希和列表，有序集合（Sorted Sets）也采用了特殊编码来节省大量空间。这种编码仅在有序集合的长度和元素都低于以下限制时使用：具体限制没有在您的问题中列出，但通常Redis针对有序集合的编码优化包括ziplist（ziplist）和intset两种特殊编码。ziplist用于较小的有序集合，当集合元素个数和每个元素的值大小都不超过配置的阈值时（类似于哈希和列表的ziplist配置）。而intset编码则专门用于所有成员都是整数值型且在一定范围内的有序集合，这样可以进一步压缩存储空间。要应用这些编码，Redis通过配置文件中的相关参数来设定，比如zset-max-intset-entries和zset-max-ziplist-value等（这些配置项名称是示意性的，实际配置可能有所不同），来控制何时及如何对有序集合使用优化编码以达到节省空间的目的。

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

超日志稀疏表示的字节限制。此限制包括了16字节的头部。当使用稀疏表示的超日志超出此限制时，它将被转换为密集表示。大于160的值实际上是无用处的，因为在那时密集表示更为内存高效。建议的值约为30，以便在拥有高效编码带来的好处的同时不大幅降低PFADD操作的执行速度，PFADD操作在稀疏表示下是O(N)。当CPU资源不是问题，空间才是主要考量，并且数据集中包含大量基数在0到1500之间的超日志时，这个值可以提升到约100。

hll-sparse-max-bytes 3000

主动rehashing（重新散列）每10毫秒使用1毫秒的CPU时间来帮助重排列表（顶级键到值映射表）的Redis散列表。Redis使用的散列表实现（见dict.c）执行懒惰性散列：你在重散列上运行得越多，执行的重散列"步骤"就越多"，因此，如果服务器空闲，重散列永远不会完成，散列表表会使用一些额外的内存。默认情况下，每秒使用这10毫秒的时间主动散列主字典，尽可能释放内存。如果不确定：如果你有严格的延迟要求并且环境中Redis偶尔回复查询时有2毫秒延迟不是好事，使用"activerehashing no"。如果你没有这样的严格要求，但希望尽快释放内存，使用"activerehashing yes"。

activerehashing yes

客户端输出缓冲区限制可用于强制断开那些由于某种原因未能足够快地从服务器读取数据的客户端（常见的原因是Pub/Sub客户端无法像发布者生产消息那样快速消费消息）。

此限制可以针对三类客户端分别设置：

正常规客户端，包括MONITOR客户端
从属客户端
订阅至少一个pub/sub频道或模式的客户端

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

client-output-limit <类别> <硬限制> <软限制> <软秒数>

一旦达到硬限制，客户端将立即断开连接，或者如果达到软限制并且持续达到指定的秒数（连续地）。例如，如果硬限制是32兆字节，软限制是16兆节/10秒，当输出缓冲区大小达到32兆字节时，客户端将立即断开连接，但如果客户端达到6兆节并持续超过限制10秒，也将断开连接。

默认情况下，常规客户端不受限制，因为它们不以推送方式接收数据，而是在请求之后，因此只有异步客户端可能创建数据请求速度超过读取数据速度的场景。

而对于pubsub和从属客户端则存在默认限制，因为订阅者和从属客户端是以推送方式接收数据。

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

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

Redis通过调用一个内部函数来执行许多后台任务，比如超时关闭客户端连接、清除从未被请求的已过期键等。并非所有任务都以相同频率执行，但Redis会根据设定的"hz"值来检查要执行的任务。默认情况下，"hz"设置为10。提高该值会在Redis空闲时使用更多CPU，但同时在有许多键同时过期时响应更快，并且超时处理更精确。范围在1到50之间，但超过10的值通常不是个好主意。多数用户应使用默认的10，并只在需要极低延迟的环境下提高到10。