常用
daemonize
daemonize no/yes 是否后台运行
pidfile
pidfile /var/run/redis.pid
当为默认不作为守护进程运行（no）,当为守护进程运行的时候，会写一个pid在/var/run/redis.pid
prot
prot 6379
监听端口，默认6379，如果设置成0，则redis不在socket上监听任何客户端连接
tcp-backlog
tcp-backlog 511
在 TCP 监听中，最大容纳数量受多个因素影响。对于 Redis 来说，其配置中的 tcp-backlog 用于设置 TCP 监听的最大容纳数量。默认情况下，Redis 的 tcp-backlog 通常为 511 。在高并发环境下，可能需要将这个值调高以避免客户端连接缓慢的问题。但要注意，Linux 内核会将这个值缩小到 /proc/sys/net/core/somaxconn 的值，所以要提升并发量，需要同时修改这两个值才能达到目的。在 Linux 操作系统中，TCP 队列由两部分组成：监听队列（listen queue）和已完成队列（completed queue）。监听队列用于存储等待进行三次握手的连接，而已完成队列用于存储已经完成三次握手的连接，等待应用程序接受。TCP 监听的最大容纳数量相关的参数包括：net.ipv4.tcp_max_syn_backlog ：控制了 TCP 监听队列的最大大小，默认通常设置为 128 。如果服务器经常面临连接排队问题，可以增加这个值，以容纳更多的等待连接。net.core.somaxconn ：控制了系统级别的监听队列的最大大小，默认通常设置为 128 。总之，TCP 监听的最大容纳数量的设置需要综合考虑服务器的硬件资源、系统配置以及实际的并发需求等因素。
bind
bind 后面填写ip地址，多个ip用空格隔开。在 Redis 的 redis.conf 配置文件中，bind 配置属性用于指定 Redis 服务器绑定的 IP 地址。其主要作用是控制 Redis 服务器监听哪些网络接口的连接请求。例如：bind 127.0.0.1 表示 Redis 服务器只接受来自本地回环地址（localhost）的连接请求，这提供了一定的安全性，限制了外部网络对 Redis 服务器的直接访问。
bind 0.0.0.0 则表示 Redis 服务器将监听所有可用的网络接口，包括本地网络和公共网络。但这样设置可能会带来一定的安全风险，因为外部网络的任何主机都有可能尝试连接到 Redis 服务器。一般来说，如果您只希望在本地开发环境中使用 Redis，并且不希望外部网络访问，可以将 bind 设置为 127.0.0.1 。而在生产环境中，需要根据具体的网络架构和安全策略来谨慎设置 bind 的值。
unixsocketperm
unixsocketperm /tmp/redis.sock 指定unix socket路径在 Redis 的 redis.conf 配置文件中，unixsocket 配置用于启用 Unix 套接字（Unix socket）支持。Unix 套接字是一种进程间通信机制，常用于在同一台主机上的不同进程之间进行高效通信。通过设置 unixsocket ，您可以指定 Unix 套接字的路径，例如：unixsocket /tmp/redis.sock 。使用 Unix 套接字的优点包括：相比于通过网络套接字（如 TCP/IP）进行通信，Unix 套接字的开销更低，因为它不需要进行网络协议的处理。提供了一种更安全的本地通信方式，因为只有具有适当权限的进程才能访问指定的套接字文件。例如，如果您的应用程序和 Redis 服务器都在同一台主机上运行，并且对性能和安全性有较高要求，那么可以使用 Unix 套接字进行通信。
unixsocketperm
unixsocketperm 755 配置用于设置 Unix 套接字文件的权限。它决定了哪些用户和用户组对该套接字文件具有访问权限。
例如，如果设置为 unixsocketperm 770 ，这意味着所有者和同组用户具有读、写和执行权限，而其他用户则没有任何权限。
timeout
timeout 0 指定一个client空闲多少秒后关闭连接（0就是不管）
tcp-keepalive
tcp-keepalive 300
里的 300 表示每隔 300 秒发送一个保活探测数据包。如果在指定的时间内没有收到对方的响应，就认为连接已经断开。设置合适的 TCP 心跳（保活）机制有以下好处：及时检测和关闭异常的空闲连接，释放系统资源。避免因为网络故障或其他原因导致的连接假死状态，提高系统的稳定性和可靠性。假设在一个高并发的生产环境中，如果没有启用 TCP 心跳机制，一些长时间没有数据交互的连接可能会处于一种不可用的状态，但服务器和客户端都无法察觉。启用了合适的心跳机制后，就能够及时发现并关闭这些无效连接，从而提高系统的整体性能和资源利用率。
loglevel
loglevel notice
用于设置 Redis 服务器的日志级别。
Redis 支持以下几种日志级别，从低到高分别为：
debug：最详细的日志级别，包含大量的调试信息。
verbose：比 debug 级别略低，但仍然提供了较为详细的信息。
notice：记录重要的一般性信息，如服务器启动、配置更改等。
warning：记录可能的问题或警告信息。
logfile
logfile 指定文件路径
syslog-enabled no
syslog-enabled no
如果将 syslog-enabled 设置为 yes，Redis 会将其生成的日志信息发送到系统的日志系统中。如果设置为 no（默认值），则 Redis 会按照其自身的日志配置进行输出。
syslog-ident redis
syslog-ident redis
syslog-ident 用于指定在将 Redis 日志发送到系统日志（syslog）时使用的标识字符串，如果将 syslog-ident 设置为 RedisServer ，那么在系统日志中看到的来自 Redis 的消息可能会以类似于 RedisServer: [相关日志内容] 的形式呈现。
syslog-facility local0
syslog-facility local0
syslog-facility 用于指定将 Redis 日志发送到系统日志（syslog）时使用的设施（facility）。
系统日志设施定义了日志消息的类型或来源分类。常见的设施包括 local0 到 local7 ，以及 user 、 auth 、 cron 等。
例如，如果将 syslog-facility 设置为 local0 ，则 Redis 的日志会被标记为来自 local0 设施。
databases
databases 16 设置数据库的数量，默认0
databases 用于设置 Redis 数据库的数量。
默认情况下，Redis 配置了 16 个数据库，您可以通过修改 databases 的值来更改数据库的数量。
例如，如果您将 databases 设置为 8 ，那么 Redis 将提供 8 个数据库供您使用，编号从 0 到 7 。
快照
save
save <间隔时间（秒）> <写入次数>
save 900 1 900 秒内如果至少有 1 个 key 的值变化，则保存
save 300 10 300 秒内如果至少有 10 个 key 的值变化，则保存
save 60 10000 60 秒内如果至少有 10000 个 key 的值变化，则保存
stop-writes-on-bgsave-error yes
stop-writes-on-bgsave-error yes
默认情况下，如果 redis 最后一次的后台保存失败，redis 将停止接受写操作，这样以一种强硬的方式让用户知道数据不能正确的持久化到磁盘，否则就会没人注意到灾难的发生。
如果后台保存进程重新启动工作了，redis 也将自动的允许写操作,然而你要是安装了靠谱的监控，你可能不希望 redis 这样做，那你就改成 no 好了。
rdbcompression
rdbcompression yes
是否在 dump .rdb 数据库的时候使用 LZF 压缩字符串,默认都设为 yes,如果你希望保存子进程节省点 cpu ，你就设置它为 no
rdbchecksum
rdbchecksum yes
是否校验rdb文件
dbfilename
dbfilename dump.rdb
dbfilename 用于指定 Redis 数据库的文件名。
默认情况下，其值通常为 dump.rdb
主从复制
slaveof
slaveof
主从复制。使用 slaveof 来让一个 redis 实例成为另一个reids 实例的副本。注意这个只需要在 slave 上配置。
masterauth
masterauth
如果 master 需要密码认证，就在这里设置
slave-serve-stale-data
slave-serve-stale-data yes
当一个 slave 与 master 失去联系，或者复制正在进行的时候
如果为 yes ，slave 仍然会应答客户端请求，但返回的数据可能是过时，或者数据可能是空的在第一次同步的时候
如果为 no ，在你执行除了 info he salveof 之外的其他命令时，slave 都将返回一个 "SYNC with master in progress" 的错误，
slave-read-only
你可以配置一个 slave 实体是否接受写入操作。默认是只读
slave-read-only yes
repl-ping-slave-period
repl-ping-slave-period 10
Slaves 在一个预定义的时间间隔内发送 ping 命令到 server。默认 10秒
repl-timeout
repl-timeout 60
设置主从复制过期时间，这个值一定要比 repl-ping-slave-period 大
repl-backlog-size
repl-backlog-size 1mb
设置主从复制容量大小。这个 backlog 是一个用来在 slaves 被断开连接时
存放 slave 数据的 buffer，所以当一个 slave 想要重新连接，通常不希望全部重新同步，
只是部分同步就够了，仅仅传递 slave 在断开连接时丢失的这部分数据。
这个值越大，salve 可以断开连接的时间就越长
repl-backlog-ttl
repl-backlog-ttl 3600
在某些时候，master 不再连接 slaves，backlog 将被释放。
如果设置为 0 ，意味着绝不释放 backlog 。
slave-priority
slave-priority 100
默认优先级为 100。
当 master 不能正常工作的时候，Redis Sentinel 会从 slaves 中选出一个新的 master，
这个值越小，就越会被优先选中，但是如果是 0 ， 那是意味着这个 slave 不可能被选中。
min-slaves-to-write
min-slaves-to-write 2
用于配置主服务器在执行写操作时要求至少连接的从服务器数量。
例如，如果将 min-slaves-to-write 设置为 2 ，并且 min-slaves-max-lag 设置为 10 ，那么主服务器在执行写操作时，会检查是否至少有 2 个从服务器的连接延迟小于 10 秒。如果不满足这个条件，主服务器将拒绝执行写操作。
这个配置的主要作用是确保在主服务器进行写操作时，有足够数量的从服务器处于良好的连接和同步状态，以提高数据的一致性和可靠性。
假设您的 Redis 部署在一个对数据一致性要求较高的环境中，通过设置合适的 min-slaves-to-write 和 min-slaves-max-lag 值，可以防止在从服务器同步不及时的情况下进行写操作，从而减少数据不一致的风险。
min-slaves-max-lag
min-slaves-max-lag 10
这个配置用于设置主服务器判断从服务器延迟的阈值。
具体来说，如果从服务器与主服务器之间的复制延迟超过 10 秒，那么主服务器可能会根据 min-slaves-to-write 的配置来决定是否拒绝执行写操作。
例如，如果 min-slaves-to-write 被设置为 1 ，并且有一个从服务器的复制延迟超过了 10 秒，那么主服务器可能会暂停接受写操作，以确保数据的一致性和可靠性。
假设您的 Redis 集群中，主服务器和从服务器之间的网络偶尔出现波动。通过设置 min-slaves-max-lag 10 ，可以在网络不稳定导致从服务器复制延迟较大时，暂时限制主服务器的写操作，避免数据不一致的情况进一步恶化。
安全
requirepass
requirepass foobared
设置认证密码
Command
Command renaming
命令重命名
功能允许您更改某些 Redis 命令的名称。
这主要用于增强安全性，防止未经授权的用户执行某些关键或危险的命令。
例如，您可以将 FLUSHALL 命令重命名为 REALLY_FLUSH_ALL ，这样只有知道新名称的授权用户才能执行该操作。
限制
maxclients
maxclients 10000
一旦达到最大限制，redis 将关闭所有的新连接，并发送一个'max number of clients reached'的错误。
eviction
eviction（淘汰）
相关的配置用于处理当 Redis 内存使用达到上限时的策略。
Redis 提供了几种淘汰策略，例如：
volatile-lru：从设置了过期时间的键中，移除最近最少使用的键。
allkeys-lru：从所有键中，移除最近最少使用的键。
volatile-random：从设置了过期时间的键中，随机移除一些键。
allkeys-random：从所有键中，随机移除一些键。
volatile-ttl：从设置了过期时间的键中，移除剩余生存时间最短的键。
通过配置合适的淘汰策略，可以在内存不足时，根据您的业务需求决定哪些数据被删除以释放内存。
例如，如果您的 Redis 主要用于缓存临时数据，并且希望优先删除快要过期的数据，可以选择 volatile-ttl 策略。
假设您的 Redis 用作缓存服务器，存储了大量的用户会话数据，这些数据都设置了过期时间。在内存紧张时，选择 volatile-lru 策略能够删除最久未使用的会话数据，以保证新的会话数据能够被存储。
maxmemory
maxmemory
最大使用内存
如果设置 maxmemory 100mb ，则表示 Redis 服务器最多可以使用 100MB 的内存。
当 Redis 的内存使用量达到这个上限时，就会根据您配置的淘汰策略（如前面提到的 volatile-lru 等）来删除一些数据，以释放内存空间，确保新的数据能够被存储和处理。
5个内存策略
volatile-lru -> 使用 LRU 算法移除包含过期设置的 key 。
allkeys-lru -> 根据 LRU 算法移除所有的 key 。
volatile-random ->移除一个设置了过期时间的随机键。
allkeys-random ->删除一个随机键，任何键
volatile-ttl ->移除具有最接近的到期时间（较小的生存时间）的键。
noeviction -> 不让任何 key 过期，只是给写入操作返回一个错误
maxmemory-samples
maxmemory-samples
是与内存淘汰策略相关的配置选项。
它用于指定在选择要淘汰的键时进行抽样的数量。
例如，如果 maxmemory-samples 设置为 5 ，那么在执行诸如 volatile-lru 或 allkeys-lru 等基于最近最少使用（LRU）的淘汰策略时，Redis 会从内存中的数据中随机抽取 5 个样本，然后根据这些样本的使用情况来决定要淘汰的键。
较大的 maxmemory-samples 值会使淘汰决策更准确，但也会带来一些额外的计算开销。较小的值则计算开销较小，但可能导致淘汰决策不够精确。
假设您的 Redis 数据库中有大量的键，并且内存使用非常紧张。如果将 maxmemory-samples 设置得较高，比如 10 ，那么在选择要淘汰的键时会更加准确，可能更有效地释放内存。但这可能会在一定程度上影响 Redis 的性能。相反，如果设置为较小的值，如 3 ，则计算速度会更快，但可能会出现误淘汰一些仍在频繁使用的键的情况。
仅追加模式
appendonly
appendonly no
appendonly no 表示禁用 AOF（Append Only File，仅追加文件）持久化模式。
默认情况下，Redis 使用 RDB（Redis Database）方式进行持久化。当 appendonly 被设置为 no 时，Redis 不会将写操作追加记录到 AOF 文件中。
如果将其设置为 yes，则启用 AOF 持久化，Redis 会将每一个写命令追加到 AOF 文件中，这样在服务器重启时，可以通过重放 AOF 文件中的命令来恢复数据。
假设您的应用对数据的完整性和可靠性要求较高，并且可以接受相对较低的写入性能影响，那么将 appendonly 设置为 yes 可能是一个更好的选择。但如果您更注重写入性能，并且对数据丢失有一定的容忍度，或者已经通过其他方式进行了数据备份，那么保持 appendonly no 的默认设置可能更合适。
appendfilename
appendfilename "appendonly.aof"
用于指定 AOF（Append Only File，仅追加文件）的文件名。
当启用 AOF 持久化（即 appendonly 设置为 yes）时，Redis 会将写操作记录追加到指定名称的文件中。在这个例子中，文件名为 appendonly.aof 。
例如，如果发生服务器意外关闭或故障，在重新启动 Redis 服务器时，它会读取这个 appendonly.aof 文件来恢复之前的写操作，以确保数据的完整性和一致性。
假设您希望对不同的 Redis 实例或不同的应用场景使用不同的 AOF 文件，就可以通过修改这个配置项来指定特定的文件名，方便进行管理和区分。
appendfsync
appendfsync
用于控制 AOF（Append Only File，仅追加文件）持久化的同步策略。
它有以下几种可选值：
always：每次执行写命令都会立即将数据同步到 AOF 文件，这能最大限度地保证数据不丢失，但会对性能产生较大影响。
everysec：每秒将数据同步到 AOF 文件一次。在性能和数据安全性之间取得平衡，是较为常用的选项。
no：由操作系统决定何时将数据同步到 AOF 文件，这种方式速度最快，但数据丢失的风险相对较大。
no-appendfsync-on-rewrite
no-appendfsync-on-rewrite
用于控制在进行 AOF（Append Only File，仅追加文件）重写期间是否禁止 appendfsync 操作。
默认情况下，该选项为 no ，这意味着在 AOF 重写期间，appendfsync 操作仍然按照其原本的配置进行（例如，如果 appendfsync 被设置为 everysec ，那么在重写期间仍然每秒同步一次）。
如果将其设置为 yes ，则在 AOF 重写期间，不会执行 appendfsync 操作，这可能会提高 AOF 重写的性能，但会增加数据丢失的风险。
例如，如果您的 Redis 服务器的磁盘 I/O 性能有限，并且您对数据丢失有一定的容忍度，将 no-appendfsync-on-rewrite 设置为 yes 可以加快 AOF 重写的速度。
假设您的 Redis 主要用于缓存数据，并且有其他备份机制来保证数据的最终一致性，那么将该选项设置为 yes 可能是可行的，以优化服务器的性能。但如果数据的完整性至关重要，保持默认的 no 值可能更合适。
auto-aof-rewrite-percentage
auto-aof-rewrite-percentage
用于控制 AOF（Append Only File，仅追加文件）自动重写的触发比例。
它是一个百分比值，默认通常为 100。
这个配置选项结合
auto-aof-rewrite-min-size
一起使用。当 AOF 文件的当前大小超过上一次重写后的大小的一定比例（由 auto-aof-rewrite-percentage 设定），并且 AOF 文件的大小达到 auto-aof-rewrite-min-size 所设定的最小值时，Redis 会自动触发 AOF 重写操作。
例如，如果 auto-aof-rewrite-percentage 被设置为 100，auto-aof-rewrite-min-size 被设置为 64mb，并且上一次重写后的 AOF 文件大小为 64mb，那么当当前的 AOF 文件大小达到 128mb 时，Redis 会自动触发重写。
假设您的 Redis 写入操作非常频繁，导致 AOF 文件增长迅速，您可以适当降低 auto-aof-rewrite-percentage 的值（比如设置为 50），以便更频繁地进行重写，减少 AOF 文件的体积，提高数据恢复的效率。
lua-time-limit
lua-time-limit
用于设置在 Redis 中执行 Lua 脚本的最大运行时间限制。
例如，如果将 lua-time-limit 设置为 5000（单位为毫秒），那么当一个 Lua 脚本的执行时间超过 5 秒时，Redis 将会终止该脚本的执行，并返回一个错误。
这个配置的主要目的是防止长时间运行的 Lua 脚本阻塞 Redis 服务器，影响其他操作的正常执行。
假设您有一个复杂的 Lua 脚本用于处理大量数据，如果没有合理的时间限制，可能会导致 Redis 在这段时间内无法响应其他客户端的请求。通过设置 lua-time-limit ，可以确保即使脚本出现异常情况，也不会对整个 Redis 服务的可用性造成过大的影响。
REDIS 集群
cluster-enabled
cluster-enabled yes
启用或停用集群
cluster-config-file
cluster-config-file nodes-6379.conf
用于指定 Redis 集群的配置文件名称。
这个配置文件会自动生成和维护，用于存储集群的节点信息、状态等重要数据。
例如，当 Redis 集群启动时，它会读取这个配置文件来了解集群的拓扑结构和节点状态。
假设在集群运行过程中，节点发生了添加、删除或故障转移等操作，这些变化会被记录在这个配置文件中，以便下次启动时能够正确恢复集群的状态。
cluster-node-timeout
cluster-node-timeout 15000
表示设置节点超时时间为 15000 毫秒（15 秒）。
这意味着如果一个节点在 15 秒内没有向其他节点发送任何消息或响应，那么它将被视为不可达或故障节点。
例如，如果一个节点由于网络问题或其他原因导致通信中断超过 15 秒，其他节点会认为该节点出现故障，并可能触发故障转移或重新配置集群的操作。
假设在一个网络环境不太稳定的场景中，为了避免由于短暂的网络波动导致节点被误判为故障，可以适当增加这个超时时间。但过长的超时时间可能会导致故障恢复的延迟。相反，如果对故障响应的及时性要求很高，可以适当缩短这个超时时间，但要注意可能会增加误判的概率。
cluster-slave-validity-factor
cluster-slave-validity-factor 10
用于确定从节点在主节点不可用时成为有效替换主节点的条件。
具体来说，这个因子与 cluster-node-timeout 配置一起工作。计算方式是：从节点与主节点失去联系的时间乘以 cluster-slave-validity-factor 的结果如果小于 cluster-node-timeout 的值，那么该从节点被认为是有效的主节点候选。
例如，如果 cluster-node-timeout 是 15000 毫秒（15 秒），cluster-slave-validity-factor 是 10，那么如果从节点与主节点失去联系的时间小于 1500 毫秒（1.5 秒），它就被认为是有效的主节点候选。
假设主节点经常出现短暂的不可用情况，但很快就能恢复正常。如果将 cluster-slave-validity-factor 设置得较大，比如 10，那么从节点就不会轻易地被提升为主节点，避免了不必要的主从切换。但如果主节点的故障可能持续较长时间，设置一个较小的值可以更快地让从节点提升为主节点，减少服务中断的时间。
cluster-migration-barrier
cluster-migration-barrier 1
用于控制主节点迁移的条件。
它表示一个主节点至少需要有 1 个健康的从节点，才允许进行主节点的迁移操作。
例如，如果一个主节点没有从节点，或者所有从节点都处于不健康状态，那么即使有其他更适合的节点位置，也不会将该主节点迁移过去。
假设您的 Redis 集群对数据的可用性要求较高，设置 cluster-migration-barrier 为 1 可以确保在主节点迁移时，有一定的备份保障，降低数据丢失的风险。但在一些资源有限的环境中，可能需要根据实际情况调整这个值，以更灵活地进行主节点的迁移和资源分配。
慢日志
slowlog-log-slower-than
slowlog-log-slower-than 10000
用于设置慢查询日志的阈值。这里的 10000 表示执行时间超过 10000 微秒（即 10 毫秒）的命令会被记录到慢查询日志中。
例如，如果一个命令的执行时间为 15 毫秒，那么它将被视为慢查询并被记录下来。
假设您的 Redis 服务对性能要求较高，通过设置这个阈值，可以及时发现执行时间较长的命令，以便进行优化和改进。例如，如果您发现某些常见的操作经常被记录为慢查询，就可以考虑对相关的数据结构、算法或配置进行调整，以提高性能。
slowlog-max-len
slowlog-max-len 128
用于设置慢查询日志的最大长度。
这意味着 Redis 只会保留最近的 128 条慢查询记录。当新的慢查询产生时，如果慢查询日志的数量已经达到 128 条，那么最早的记录会被删除，以保证日志的长度不超过设定值。
例如，如果 Redis 持续产生慢查询，并且慢查询日志已经达到了 128 条的上限，那么再产生新的慢查询时，最早的那条记录就会被移除，为新的记录腾出空间。
假设您的系统对性能监控的历史数据需求不是特别大，将 slowlog-max-len 设置为 128 可以在一定程度上节省内存资源，同时仍然能够获取到近期的关键慢查询信息，用于性能分析和优化。但如果您需要更长期的慢查询历史记录来进行深入的性能趋势分析，可能需要适当增大这个值。
活动通知
notify-keyspace-events
notify-keyspace-events "Elg"
用于配置键空间通知事件的类型。
"Elg" 是一个事件标志组合，其中：
E 表示键过期事件（Expired）。
l 表示键被删除事件（Deleted）。
g 表示通用命令（Generic commands），例如 DEL、EXPIRE、RENAME 等的执行事件。
通过设置这个配置，Redis 可以在发生指定类型的键空间事件时发送通知，这对于构建一些依赖于键状态变化的应用非常有用。
例如，如果您有一个应用需要在某个键过期或被删除时执行特定的操作，通过配置键空间通知并监听相应的事件，就可以及时做出响应。
假设您正在开发一个缓存系统，当缓存中的键过期时，您希望自动从数据库重新加载数据。通过启用键过期通知，并在应用中处理相应的事件，就可以实现这个功能。
notify-keyspace-events
notify-keyspace-events "Ex"
用于配置键空间通知事件。
其中：
E 表示键过期事件（Expired）。
x 表示删除事件（Evicted，当内存满了，根据淘汰策略删除键时触发）。
通过设置为 Ex，Redis 会在键过期和因内存满被淘汰删除时发送通知。
例如，如果您的应用需要在键因为过期或内存满被淘汰时执行一些清理或后续处理操作，配置这个选项可以让您接收到相关通知并进行相应处理。
假设您的 Redis 用作缓存，当缓存中的键因为过期或内存满被删除时，您希望更新相关的统计信息或者通知其他模块，启用这样的键空间通知就能满足需求。
notify-keyspace-events
notify-keyspace-events ""
被设置为空字符串 "" 时，表示禁用所有的键空间通知事件。
这意味着 Redis 不会发送任何关于键的创建、修改、删除、过期等操作的通知。
例如，如果之前您的应用配置了特定的键空间通知事件来进行一些处理，但在某些情况下不再需要这些通知，将其设置为空字符串就可以停止接收和处理相关通知，从而减少系统的复杂性和资源消耗。
假设您的应用在某个阶段对键空间的变化不再敏感，或者这些通知对性能产生了较大影响，将其禁用可以优化 Redis 的性能和应用的运行效率。
高级配置
hash-max-ziplist-entries
hash-max-ziplist-entries 512
用于配置哈希（Hash）数据结构在使用压缩列表（ziplist）存储时，最大的键值对数量。
当一个哈希对象的键值对数量小于或等于 512 时，Redis 会使用压缩列表来存储这个哈希对象，以节省内存。
例如，如果您有一个哈希对象存储了一些不太频繁访问且数据量较小的信息，如用户的一些简单属性，并且键值对数量在 512 以内，Redis 就会以更紧凑的压缩列表形式存储，从而减少内存占用。
假设您的应用中有很多小型的哈希数据，每个哈希中的键值对数量通常都不多，将 hash-max-ziplist-entries 合理设置为 512 可以有效地优化内存使用。但如果这些哈希可能会快速增长并超过 512 个键值对，那么可能需要根据实际情况调整这个值，或者考虑使用其他更适合的数据结构。
hash-max-ziplist-value
hash-max-ziplist-value 64
用于配置当哈希（Hash）使用压缩列表（ziplist）存储时，单个值的最大字节长度。
如果哈希中某个值的字节长度超过 64 ，那么 Redis 就不会再使用压缩列表来存储整个哈希，而是转换为更常规的数据结构。
例如，如果一个哈希中的某个值是一段较长的文本，其字节长度超过了 64 ，那么为了避免影响压缩列表的性能和存储效率，Redis 会改变存储方式。
假设您的哈希中大部分值都比较短，将这个值设置为 64 可以让更多的哈希使用压缩列表存储，节省内存。但如果您的哈希中经常有较长的值，可能需要适当增大这个设置，或者考虑一开始就不使用压缩列表来存储哈希。
list-max-ziplist-entries
list-max-ziplist-entries 512
用于设定列表（List）在使用压缩列表（ziplist）存储时，所允许的最大元素数量。
当一个列表的元素数量小于或等于 512 时，Redis 会采用压缩列表这种更节省内存的方式来存储该列表。
例如，如果您有一个列表用于存储少量的元素，比如最近的 512 个操作记录，由于元素数量未超过设定值，Redis 就会以压缩列表的形式存储这个列表，从而降低内存消耗。
假设您的应用中存在很多小型的列表数据，且元素数量通常不超过 512 ，将该配置设置为 512 可以有效地优化内存使用。但如果这些列表可能会快速增长并超过 512 个元素，那么可能需要根据实际情况调整这个配置值，或者考虑使用其他更适合的数据存储结构。
list-max-ziplist-value
list-max-ziplist-value 64
用于设定当列表（List）使用压缩列表（ziplist）存储时，单个元素的最大字节长度。
如果列表中某个元素的字节长度超过 64 ，Redis 就不再使用压缩列表来存储整个列表，而是转换为其他更合适的数据结构。
例如，如果列表中存储的是一些较短的字符串或小整数，且长度都在 64 字节以内，Redis 会以压缩列表来存储，以节省内存空间。
假设您的列表中大部分元素都比较短，将这个值设置为 64 可以让更多的列表使用压缩列表存储，从而优化内存使用。但如果您的列表中经常有较长的元素，可能需要适当增大这个设置，或者一开始就不选择使用压缩列表来存储列表数据。
set-max-intset-entries
set-max-intset-entries 512
用于设置集合（Set）在使用整数集合（intset）存储时所允许的最大元素数量。
当一个集合的元素数量小于或等于 512 ，并且元素都是整数时，Redis 会使用整数集合这种紧凑的数据结构来存储该集合，以节省内存。
例如，如果您有一个集合用于存储少量的整数元素，比如最近的 512 个用户 ID，由于元素数量未超过设定值且都是整数，Redis 就会以整数集合的形式存储这个集合。
假设您的应用中有很多小型的集合数据，且元素都是整数且数量通常不超过 512 ，将该配置设置为 512 可以有效地优化内存使用。但如果这些集合可能会快速增长并超过 512 个元素，或者元素不全是整数，那么可能需要根据实际情况调整这个配置值，或者考虑使用其他更适合的数据存储结构。
zset-max-ziplist-entries
zset-max-ziplist-entries 128
用于设定有序集合（Sorted Set，简称 ZSet）在使用压缩列表（ziplist）存储时所允许的最大元素数量。
当一个有序集合的元素数量小于或等于 128 时，Redis 会采用压缩列表这种更节省内存的方式来存储该有序集合。
例如，如果您有一个小型的有序集合，比如存储最近 128 个商品的评分，由于元素数量未超过设定值，Redis 就会以压缩列表的形式来存储它，从而减少内存占用。
假设您的应用中有许多规模较小且元素数量通常不超过 128 的有序集合，将此配置设置为 128 能够有效优化内存使用。然而，如果这些有序集合可能会迅速增长并超过 128 个元素，那么您可能需要根据实际情况调整这个配置值，或者考虑使用其他更适合的存储结构。
zset-max-ziplist-value
zset-max-ziplist-value 64
用于设置当有序集合（Sorted Set，简称 ZSet）使用压缩列表（ziplist）存储时，单个元素成员（member）的最大字节长度。
如果有序集合中某个元素成员的字节长度超过 64 ，Redis 就不会再使用压缩列表来存储整个有序集合，而是转换为其他更合适的数据结构。
例如，如果有序集合中存储的元素成员大多是较短的字符串，且长度都在 64 字节以内，Redis 会以压缩列表来存储以节省内存。
假设您的有序集合中的元素成员通常都比较短，将这个值设置为 64 可以让更多的有序集合使用压缩列表存储，从而优化内存使用。但如果有序集合中经常有较长的元素成员，可能需要适当增大这个设置，或者一开始就不选择使用压缩列表来存储有序集合。
hll-sparse-max-bytes
hll-sparse-max-bytes 3000
用于配置 HyperLogLog 数据结构在稀疏存储模式下所允许的最大字节数。
当 HyperLogLog 数据结构使用稀疏存储时，如果其占用的字节数超过 3000 ，Redis 会将其转换为密集存储模式以节省内存并提高计算效率。
例如，如果您的 HyperLogLog 数据在初始阶段元素较少，处于稀疏存储状态，但随着元素的不断增加，占用字节数超过 3000 ，Redis 就会自动切换存储模式。
假设您的应用中 HyperLogLog 用于统计一些数量较大但不是特别巨大的不重复元素，将这个值设置为 3000 可以在内存使用和计算效率之间取得较好的平衡。但如果您预计统计的元素数量非常大或者对内存使用有更严格的限制，可能需要根据实际情况调整这个配置值。
activerehashing
activerehashing yes
用于启用主动重哈希（Active Rehashing）功能。
当启用主动重哈希时，Redis 会在后台逐步对哈希表进行扩展或收缩操作，以优化内存使用和性能。
例如，如果您不断地添加或删除键值对，导致哈希表的负载因子（Load Factor）发生变化，达到需要重新调整哈希表大小的条件时，主动重哈希会在后台自动进行，而不会阻塞服务器的正常操作。
假设您的 Redis 数据库中数据的增减操作非常频繁，启用主动重哈希可以使 Redis 更高效地管理内存和处理请求，减少因为哈希表调整而可能导致的性能波动。
client-output-buffer-limit
client-output-buffer-limit normal 0 0 0
这个配置用于限制普通客户端（非发布/订阅客户端）的输出缓冲区大小。
这里的三个 0 分别表示：
第一个 0 ：缓冲区大小限制（字节），设置为 0 表示没有硬限制。
第二个 0 ：缓冲区持续写入量限制（字节/秒），设置为 0 表示没有限制。
第三个 0 ：缓冲区持续空闲时间限制（秒），设置为 0 表示没有限制。
这意味着对于普通客户端，Redis 不会对其输出缓冲区的大小、持续写入量和持续空闲时间进行严格的限制。
例如，如果一个客户端正在向 Redis 发送大量的数据，但由于这个配置，Redis 不会因为缓冲区达到一定大小或其他条件而主动断开与该客户端的连接。
假设您的应用场景中，普通客户端的数据发送模式较为多样化，难以预测其流量特征，将这些限制设置为 0 可以提供更大的灵活性，但也需要注意可能会因为某些异常客户端占用过多资源而影响服务器性能。
client-output-buffer-limit
client-output-buffer-limit slave 256mb 64mb 60
这个配置用于限制从节点（slave）客户端的输出缓冲区。
具体来说：
256mb 表示缓冲区大小的硬限制，即当从节点客户端的输出缓冲区达到 256MB 时，Redis 会采取相应的措施。
64mb 表示缓冲区持续写入量的限制，即每秒钟写入缓冲区的数据量不能超过 64MB。
60 表示缓冲区持续空闲时间的限制，如果缓冲区空闲时间超过 60 秒，Redis 也会采取行动。
例如，如果从节点客户端的输出缓冲区数据量达到 256MB，或者在 1 秒钟内写入缓冲区的数据超过 64MB，又或者缓冲区空闲了 60 秒，Redis 可能会断开与该从节点的连接，或者采取其他策略来防止缓冲区过度占用资源。
假设在一个大规模的 Redis 主从复制架构中，通过设置这样的限制，可以有效地管理从节点的缓冲区使用，避免因为某个从节点的异常行为导致主节点的性能受到影响，保障整个系统的稳定性和可靠性。
client-output-buffer-limit
client-output-buffer-limit pubsub 32mb 8mb 60
用于对发布/订阅（Pub/Sub）客户端的输出缓冲区进行限制。
具体含义如下：
32mb 表示发布/订阅客户端的输出缓冲区大小上限为 32MB。一旦缓冲区达到这个大小，Redis 可能会采取相应措施。
8mb 表示每秒钟允许写入缓冲区的最大数据量为 8MB。如果写入速度超过这个限制，可能会触发处理机制。
60 表示如果缓冲区连续空闲 60 秒，Redis 也会进行相应处理。
例如，如果某个发布/订阅客户端的缓冲区数据量快速增长达到 32MB，或者每秒写入的数据量超过 8MB，又或者缓冲区空闲了 60 秒，Redis 可能会关闭与该客户端的连接，以防止资源过度消耗。
假设您的 Redis 系统中有大量的发布/订阅客户端，通过设置这样的缓冲区限制，可以确保系统的稳定性和性能，避免个别客户端的异常行为对整个系统造成不良影响。
aof-rewrite-incremental-fsync
aof-rewrite-incremental-fsync yes
用于启用 AOF（Append Only File，仅追加文件）重写时的增量同步（Incremental fsync）功能。
当这个选项设置为 yes 时，在 AOF 重写过程中，Redis 会定期将新生成的 AOF 数据同步到磁盘，以减少数据丢失的风险。
例如，如果在重写 AOF 文件的过程中服务器突然宕机，由于启用了增量同步，已经同步到磁盘的部分数据可以得到保留，从而提高了数据的可靠性。
假设您的 Redis 服务对数据的持久性和可靠性要求较高，启用这个选项可以在 AOF 重写期间提供更好的数据保护，但可能会对重写期间的性能产生一定的影响。需要根据您的具体业务需求和系统环境来权衡是否启用。
include
include
include /path/to/local.conf
这行指令通常在配置文件中出现。它的作用是将指定路径下的 local.conf 文件的内容包含到当前的配置中。
例如，在 Web 服务器（如 Nginx 或 Apache）的配置中，使用 include 指令可以将一些特定的设置，如特定域名的配置、特定目录的访问规则等，从单独的文件中引入，从而使整个配置结构更加清晰和易于管理。