Redis 的安装与配置详解【Redis系列一】

〇、前言

关于 Redis 在日常开发中还是用的比较多的，特别是在秒杀、消息队列、排行榜等数据交互时效要求较高的场景，Redis 都可以轻松应对。

本文将针对 Redis 进行简单介绍，以及如何安装，并罗列下全部配置项。后续还将另行发文汇总 Redis 的常用数据结构和常见问题等。

一、什么是 Redis？

Redis（Remote Dictionary Server 远程字典服务）是一个开源的高性能的非关系型键值对 key-value 数据库，具有快速的读写、灵活和可扩展的特性。正因为这些优秀的特性，Redis 在日常开发中也是比较靠前的一个选项。

Redis 数据读写为什么那么快？

首先 Redis 是一个基于内存的数据结构存储系统，避免了磁盘 I/O 操作的延迟；

高效的数据结构设计。例如使用简单动态字符串（SDS），提高了数据处理的效率；

单线程模型。虽然听起来似乎会限制性能，但在 Redis 的场景下，这种设计简化了并发处理，是每个操作都具有原子性，避免了多线程带来的锁和上下文切换的开销；

非阻塞式IO。通过事件驱动的方式，即使在执行慢查询时也不会阻塞整个系统。

一般情况下，Redis 每秒的读写次数可以达到十万次（官方数据显示，单台 Redis 服务器，写大约 81000 次/秒，读大约 110000 次/秒）。

Redis 的灵活性表现在那些方面？

数据结构的多样性。Redis 支持多种数据结构，如字符串、列表、集合、有序集合和哈希等，这些数据结构的灵活性使得 Redis 能够满足各种不同的应用需求，例如缓存、计数器、排行榜等；

多用途性。Redis 可以作为数据库、缓存和消息中间件使用，这得益于其丰富的数据类型和高性能的特性；

持久化支持。Redis 支持 RDB 快照和 AOF 日志两种持久化方式，可以将内存中的数据保存到磁盘中，以便在服务重启后能够恢复数据，这增加了数据的安全性和可靠性。

Redis 的可扩展性表现在那些方面？

线性扩展能力。Redis 能够线性扩展到 1000 多个节点，这意味着随着系统负载的增加，可以通过添加更多的节点来保持性能；

集群化设计。Redis 通过引入 hash slot 的概念，实现了数据的分布式存储和负载均衡。在 Redis Cluster 中，整个数据库被分为 16384 个槽，每个节点可以负责 0 到 16384 个槽，这使得我们可以根据需要动态增加或减少节点，而不会影响系统的可用性；

高可用性保障。通过增加 Slave 节点作为数据副本，Redis 能够在节点故障时自动进行 failover，确保服务的连续性。节点之间通过 gossip 协议交换状态信息，并通过投票机制完成角色转换；

灵活的数据分布。管理员可以通过 cluster addslots 命令将一个或多个槽指派给节点，以此来调整数据分布和负载均衡策略。

二、Windows  下载、安装与简单测试

2.1 下载

推荐下载地址：https://github.com/tporadowski/redis/releases  目前最新版本为 Redis for Windows 5.0.14.1，下文也以此版本为例。

.msi 是 Windows 安装包格式，可以安装，修改，卸载指定程序。说白了 .msi 就是 Windows installer 的数据包，把所有和安装文件相关的内容封装在一个包里。此外：它还包含有关安装过程自己的信息，例如：安装序列、目标文件夹路径、安装选项和控制安装过程的属性。

.zip 是一个压缩包，解压之后可通过命令行进行操作，不需要安装。

2.2 .zip 压缩包

压缩包的文件内容：

2.2.1 开启 Redis 服务

在当前目录打开命令行：（文件目录输入 cmd，回车）（也可以通过命令：cd /d F:\Redis-x64-5.0.14.1）

然后通过如下命令开启服务：

redis-server.exe redis.windows.conf
# redis.windows.conf 为指定配置文件，可省略

默认端口为 6379，出现图上的图标说明redis服务启动成功。

为了方便使用命令，可以配置 Path 路径：（配置完成后，新打开的 cmd 命令窗口就可以直接输入 Redis 命令）

2.2.2 将 Redis 服务注册为系统服务，避免命令行窗口需一直打开

将 Redis 注册为系统服务后，系统可以在启动时自动启动 Redis，无需手动启动。

打开 cmd 命令窗口，切换到 Redis 安装目录（因为要指定配置文件），执行以下命令将 Redis 注册为系统服务。

# cd 进入 Redis 主目录
cd /d F:\Redis-x64-5.0.14.1
# 注册 Redis 为系统服务，并指定配置文件
redis-server --service-install redis.windows.conf --loglevel verbose
# 开启服务
redis-server --service-start
# 停止服务
redis-server --service-stop
# 删除 Redis 系统服务
# 删除不影响已开启的服务正常运行，停止服务后才会消失
redis-server --service-uninstall

如下图提示为成功添加：

快捷键 Win + R ，输入 services.msc 打开服务列表找到 Redis，将其启动类型设置为自动启动，并启动此服务。

2.2.3 通过 redis-cli.exe 连接 Redis 服务并测试

在任意路径可以通过如下命令连接 Redis 服务：

redis-cli.exe -h 127.0.0.1 -p 6379
# 或直接使用
redis-cli

# 测试结果：
F:\Redis-x64-5.0.14.1>redis-cli
127.0.0.1:6379> ping
PONG
127.0.0.1:6379>
# ping 返回结果 PONG 视为成功连接

Redis 默认拥有 16 个数据库，初始默认使用 0 号库，在命令行中通过 select 命令将数据库切换到 8 号数据库：

#切换到 8 号库
127.0.0.1:6379> select 8
OK
127.0.0.1:6379[8]>

设置键值对并查询，以及手动关闭 Redis 服务：

# 设置一个键值对
127.0.0.1:6379[8]> set first_key first_value
OK
# 根据键查询对应的值
127.0.0.1:6379[8]> get first_key
"first_value"
# 手动关闭 Redis 服务
127.0.0.1:6379[8]> shutdown
not connected>

命令行中，单击 Esc 键，退出当前连接的 Redis 数据库。

2.3 .msi 安装包

2.3.1 手动安装

2.3.2 配置文件，默认是：redis.windows-service.conf

在上一章节中通过 .zip 压缩包的操作，都是专门指定配置文件：redis.windows.conf。

但本章节是通过安装包来的，系统服务是自动添加的，默认的配置文件则是：redis.windows-service.conf。

快捷键 Win + R ，输入 services.msc 打开服务列表找到 Redis，如下打开服务属性：

2.3.4 测试服务可用

由于在安装过程中，已自动添加了环境变量中的 Path 配置，则可以直接在 cmd 访问 redis-cli.exe。

# cd 进入执行文件所在路径
C:\WINDOWS\system32>cd /d C:\Program Files\Redis
C:\Program Files\Redis>cd ..
# 不必须在执行文件路径下运行
C:\Program Files>redis-cli
# ping 结果为 PONG 表示成功
127.0.0.1:6379> ping
PONG
127.0.0.1:6379> set second_key second_value
OK
127.0.0.1:6379> get second_key
"second_value"
127.0.0.1:6379>

参考：https://blog.csdn.net/weixin_44893902/article/details/123087435        

三、Linux 下载、安装和简单测试

3.1 下载

Redis 全版本文件地址：http://download.redis.io/releases/，在其后加上带版本号的包名即可，比如：http://download.redis.io/releases/redis-7.2.4.tar.gz。

Linux 可以直接通过命令来下载：

# -P 指定下载至目标文件夹
[root@localhost ~]# wget -P /home/user/downloads/ http://download.redis.io/releases/redis-7.2.4.tar.gz
# 进入目标文件夹
[root@localhost ~]# cd /home/user/downloads
[root@localhost downloads]# ls
redis-7.2.4.tar.gz
[root@localhost downloads]# mkdir /usr/local/redistest
[root@localhost downloads]# tar -zxvf redis-7.2.4.tar.gz -C /usr/local/redistest
[root@localhost downloads]# cd /usr/local/redistest/
[root@localhost redistest]# ls
redis-7.2.4
[root@localhost redistest]# cd redis-7.2.4
[root@localhost redis-7.2.4]#

由于 Redis 依赖于 gcc 环境，若没安装需通过如下命令安装：

yum install gcc

3.2 编译、安装

# 编译，大概需要五分钟左右
[root@localhost redis-7.2.4]# make
# 安装，默认可执行文件存放的路径为：/usr/local/bin
# PREFIX 参数配置自定义存放路径
[root@localhost redis-7.2.4]# make install
[root@localhost redis-7.2.4]# make PREFIX=/usr/local/redis install
# 进入可执行文件目录
[root@localhost redis-7.2.4]# cd /usr/local/redis/bin
[root@localhost bin]# ls
redis-benchmark  redis-check-aof  redis-check-rdb  redis-cli  redis-sentinel  redis-server

文件名	功能
redis-server	开启 Redis 服务
redis-cli	打开 Redis 客户端
redis-benchmark	性能测试
redis-check-aof	AOF 文件修复工具
redis-check-rdb	RDB 文件修复工具
redis-sentinel	Sentinel 服务器（2.8 以后），Redis 集群使用

3.3 开启、测试、关闭服务

可直接通过命令开启：./redis-server。此方法是前台开启，会一直占用命令窗口。

为了方便测试，可以通过修改配置文件的方式，来实现通过守护进程开启服务。

# cd 进入 redis 解压后的目录
[root@localhost bin]# cd /usr/local/redistest/redis-7.2.4
# 编辑配置文件 redis.conf
[root@localhost redis-7.2.4]# vim redis.conf
# 在查看模式直接输入 /daemonize 回车进行【关键字搜索】，然后单击字母 i 或 insert 进行编辑
# 将配置：daemonize no
# 改为：daemonize yes
# 然后按键 Esc 退出编辑，在输入 :wq 回车，保存并退出

[root@localhost redis-7.2.4]# cd /usr/local/redis/bin
[root@localhost bin]# ./redis-server /usr/local/redistest/redis-7.2.4/redis.conf
[root@localhost bin]# ./redis-cli
127.0.0.1:6379> set first_key fitst_value
OK
127.0.0.1:6379> get first_key
"fitst_value"
127.0.0.1:6379>
# 运行 Redis 客户端
[root@localhost bin]# ./redis-cli
127.0.0.1:6379> ping
PONG
127.0.0.1:6379> shutdown
not connected>
# 通过客户端直接关闭 Redis 服务
[root@localhost bin]# ./redis-cli shutdown
[root@localhost bin]#

3.4 注册为系统服务并设置开机启动

# 先将配置文件放至 /etc 文件夹（etc文件夹：存放【系统程序或者一般工具】的管理和配置文件）
# 创建 redis 文件夹
mkdir /etc/redis
# 将 redis 配置文件复制到新创建的文件夹，并重命名
#  注意，配置文件中的保护模式配置 protected-mode 需改为 yes，不然只能本机连接
cp /usr/local/redistest/redis-7.2.4/redis.conf /etc/redis/6379.conf

# 然后，将 redis 初始化脚本复制到文件夹：/etc/init.d（用于存放管理服务启动和停止的脚本）
# 将 redis_init_script 复制并重命名为 redis
cp /usr/local/redistest/redis-7.2.4/utils/redis_init_script /etc/init.d/redis
# 编辑脚本文件
vim /etc/init.d/redis

如下图脚本内容编辑：（EXEC：服务端进程；CLIEXEC：客户端进程；额外加的 & 符号：手动启动服务时默认后台运行）（键盘输入字母 i，或单击 insert 键，进入编辑状态）

修改后，单击键 Esc 退出编辑状态，:wq 命令保存并退出，继续后续步骤。

# 赋予脚本执行权限
chmod +x /etc/init.d/redis
# 将 redis 加入到自启动列表
chkconfig --add redis
# 查看全部自动启动项
chkconfig --list
# [root@localhost init.d]# chkconfig --list
#
# Note: This output shows SysV services only and does not include native
#       systemd services. SysV configuration data might be overridden by native
#       systemd configuration.
#
#       If you want to list systemd services use 'systemctl list-unit-files'.
#       To see services enabled on particular target use
#       'systemctl list-dependencies [target]'.
#
# netconsole      0:off   1:off   2:off   3:off   4:off   5:off   6:off
# network         0:off   1:off   2:on    3:on    4:on    5:on    6:off
# redis           0:off   1:off   2:on    3:on    4:on    5:on    6:off

# 开启自启动
chkconfig redis on
# 关闭自启动
chkconfig redis off

手动开启和关闭服务：

# 开启服务，以下两个语句均可
service redis start
systemctl start redis
# [root@localhost init.d]# service redis start
# Starting Redis server...
# [root@localhost init.d]# ps -ef|grep redis
# root      1691     1  0 17:49 ?        00:00:00 /usr/local/redis/bin/redis-server 0.0.0.0:6379
# root      1698  1533  0 17:50 pts/1    00:00:00 grep --color=auto redis

# 关闭服务，以下两个语句均可
service redis stop
systemctl stop redis
# [root@localhost init.d]# service redis stop
# Stopping ...
# Redis stopped
# [root@localhost init.d]# ps -ef|grep redis
# root      1717  1533  0 18:00 pts/1    00:00:00 grep --color=auto redis
# [root@localhost init.d]#

注意：在添加成功后，立即通过语句查看服务列表是没有 redis.service 的，机器重启后才能查到。

# 查看本机服务列表
systemctl list-units --type=service
# [root@localhost ~]# systemctl list-units --type=service
# UNIT                               LOAD   ACTIVE SUB     DESCRIPTION
# redis.service                      loaded active running LSB: Redis data structure server

另外，若想删除自启动并删除服务，需要同步删掉 /etc/init.d 中的脚本文件。

参考：https://developer.aliyun.com/article/789869     https://blog.csdn.net/qq_42810276/article/details/81296012

四、关于配置项

4.1 命令行查看、修改配置项

【查看】

通过 config get config_name 来查看具体单项的配置：

127.0.0.1:6379> config  get  loglevel
1) "loglevel"
2) "notice"

还可以通过 * 符号查看全部配置项，但是总的配置项有几百个，直接打印出来查阅较困难。

127.0.0.1:6379> config  get  *
  1) "aof-rewrite-incremental-fsync"
  2) "yes"
  3) "bio_cpulist"
......
387) "latency-tracking-info-percentiles"
388) "50 99 99.9"
389) "zset-max-listpack-value"
390) "64"
127.0.0.1:6379> 

注意：由于版本和操作系统的不同，配置项的数量会存在差异。

【修改】

语法：config set config_name config_value

如下示例，将日志级别由原来的 notice 更改为 debug：

127.0.0.1:6379> config  set  loglevel  debug
OK
127.0.0.1:6379> config  get  loglevel
1) "loglevel"
2) "debug"

值得注意的是，并非全部配置都可以通过命令来更改，例如配置允许远程访问：

  1）手动将默认的 bind 127.0.0.1，修改为指定的 IP 地址；

  2）将配置项保护模式关闭，参数 protected-mode 由原来的 yes 更改为 no；

  3）重启 redis 服务。

4.2 配置项详解

4.2.1 NETWORK & GENERAL 网络模块

• bind

【绑定的主机 IP】，例如：bind 127.0.0.1。默认开启。

只接收来自于该 IP 地址的请求。如果不进行设置，那么将处理所有请求。

• port

【监听的端口】，默认 6379：port 6379。默认开启。

• databases

【数据库数量配置】，默认 16：databases 16。默认开启

• protected-mode

【是否开启保护模式】，默认：protected-mode yes。默认开启。

选项：yes（默认）、no

保护模式生效是有条件的，不止配置为 yes 就可以的。即：bind 和 requirepass 均未配置，此时保护模式生效，只能通过本地连接。

  配置了 requirepass，保护模式失效，可以通过密码远程连接；

  配置了 bind，保护模式失效，可以通过 bind 的 ip 无密码连接。

当配置为 no，无论上面的哪种场景，客户端都可以根据 bind 及 requirepass 实际参数来连接到 redis。

• timeout

【客户端连接最大空闲时间】，单位：秒。默认：0（不设置超时）：timeout 0。默认开启。

如果在指定时间内没有操作则会自动断开连接。

• daemonize

【是否以守护进程开启 redis 服务】，选项 yes/no，默认 no：daemonize no。默认不配置。

选项：no（默认）、yes。

默认为 no，表示 Redis 不是以守护进程的方式运行，通过修改为 yes 启用守护进程。

• pidfile

【存放 redis 进程 pid 值的文件的路径】，例如：pidfile /var/run/redis.pid。默认不配置。

当 Redis 以守护进程方式运行时，会把进程 pid 写入自定义的文件中。这有助于实现自动化脚本的灵活运行。注意：Windows 系统不支持此项。

• tcp-backlog

【配置能够同时连接 Redis 的客户端数量】，或者说是 Redis 服务器监听端口时所使用网络连接队列的长度。默认 511：tcp-backlog 511。默认开启。

在 Linux 系统中，当一个客户端尝试与服务端建立 TCP 连接时，会经过三次握手的过程。在这个过程中，tcp-backlog 参数定义了已完成三次握手，但还未被应用程序 accept() 系统调用取走的连接队列长度。

tcp-backlog 的值也受到操作系统内核参数 somaxconn 的限制。如果 tcp-backlog 设置的值大于 somaxconn，实际生效的将是二者中的较小值。

合理地配置 tcp-backlog 参数可以帮助平衡服务器的负载和提高连接请求的处理能力，特别是在高并发场景下，避免因为短时间内大量连接请求而导致的服务不可用或性能下降。

• tcp-keepalive

【设置 TCP 连接的保活时间间隔】，默认 300 秒：tcp-keepalive 300。默认开启。

建立 TCP 连接通常需要进行三次握手，这个过程会消耗一定的时间。长连接避免了每次操作都要重新建立连接的开销，从而减少了网络延迟，提高整体性能。

值得注意的是，Redis 的 tcp-keepalive 设置会覆盖 Linux 系统的 tcp_keepalive_time 设置。

• loglevel

【日志级别配置】，默认：notice，即loglevel notice。默认开启。

debug：这是最低级别，用于记录调试信息，通常仅在开发和测试时使用。

verbose：比 debug 稍高一级，记录更多详细信息，但不包括过于频繁的事件，如每个命令的执行。

notice：记录一般操作信息，比 verbose 级别略高，通常用于生产环境，因为它会记录关键操作和潜在问题的信息。

warning：记录警告信息，表明可能存在潜在问题，但不一定影响服务的正常运作。

error：记录错误信息，这些信息指示发生了阻止 Redis 正常执行的问题。

• logfile

【指定日志文件的输出路径】，默认配置为空，即禁用日志功能：logfile ""。默认启用配置。

在配置文件中修改输出路径为自定义的文件夹和文件名。例如，可以设置为logfile "/usr/redis/log/redis.log"，这样日志就会被记录在指定的路径下。

• syslog-enabled、syslog-ident、syslog-facility

【用于日志管理】，默认均不开启/注释状态。默认均不开启。

syslog-enabled：是否启用将日志信息发送到系统日志服务器的功能，例如：syslog-enabled no。当设置为 "yes" 时，Redis 会将日志信息发送到系统日志服务，可以用于集中管理日志信息，方便进行监控和故障排查。

syslog-ident：设置一个标识符，它会被添加到每个发送到 syslog 的日志消息中，例如：syslog-ident redis。这有助于在查看系统日志时快速识别出哪些日志是由特定的 Redis 实例生成的。

syslog-facility：这个配置项允许你选择一个 syslog 设施（facility），例如：syslog-facility local0。它对应着 rsyslog.conf 中“# Save boot messages also to boot.log”的配置，一般是日志文件的保存目录，可以自行修改。

关于 rsyslog。它是 CentOS 6 及更高版本系统中使用的日志系统，它是一个支持多线程、多种协议的强大的日志服务，它不仅能够提供高效的日志记录和管理能力，还能通过网络协议支持远程日志收集和存储。配置文件通常位于：/etc/rsyslog.conf，可定义日志的存储位置、设置日志级别、指定网络传输设置等。可以通过grep "关键词" /var/log/messages通过命令行来快速查找日志。

4.2.2 SNAPSHOTTING 持久化机制

即 RDB（Redis Database File）持久化机制。

• save

【将内存中的数据同步到硬盘中的间隔配置】，包括时间和操作数。格式：save <seconds> <changes>。默认开启。

默认情况下有三个配置：

save 900 1：表示如果在 900 秒内有至少 1 个 key 发生变化，则进行一次 RDB 持久化。

save 300 10：表示如果在 300 秒内有至少 10 个 key 发生变化，则进行一次 RDB 持久化。

save 60 10000：表示如果在 60 秒内有至少 10,000 个 key 发生变化，则进行一次 RDB 持久化。

这些默认配置旨在平衡性能和数据安全性，通过不同时间粒度来适应不同的使用场景。

若要禁用自动快照功能，可以将 save 配置设为空，即：save ""。这需要用户手动执行SAVE或BGSAVE命令来触发快照保存。

• stop-writes-on-bgsave-error

【当持久化失败后，是否继续持久化工作】，默认是 yes，即：stop-writes-on-bgsave-error yes。默认开启。

配置为 yes：不再进行数据持久化操作，配置为 no：可以继续进行。

在大多数情况下，为了避免影响到应用程序的正常运行，建议将此配置项设置为 no，并通过监控系统来辅助错误处理和告警。

• rdbcompression

【用于控制是否对 RDB 持久化文件进行压缩】，值为 yes/no，默认 yes，即：rdbcompression yes。默认开启。

当 rdbcompression 设置为 yes 时，Redis 会在执行 RDB 持久化操作时，使用 LZF 算法对数据进行压缩，这有助于减少磁盘空间的使用。一般建议开启。

需要注意的是，压缩数据在加载时会需要额外的 CPU 时间来解压缩，这可能会对性能产生一定影响。如果希望节省 CPU 资源而不介意占用更多磁盘空间，可以将其设置为 no 来禁用压缩功能。

• rdbchecksum

【这个配置项决定是否对 RDB 文件进行校验】，值为 yes/no，默认 yes，即：rdbchecksum yes。默认开启。

若启用，Redis 会使用 CRC64 算法进行数据校验，以确保数据的完整性，但这会增加大约 10% 的性能消耗。如果对数据完整性有较高要求，建议保持启用状态。

• dbfilename

【用于指定数据库文件名】一般采用默认的 dump.rdb，即：dbfilename dump.rdb。默认开启。

在某些情况下，可能需要更改 dbfilename。比如：为了避免与旧的 RDB 或 AOF 文件冲突或者为了区分不同应用的 RDB 文件。

• dir

【用于指定 Redis 持久化文件和附件的存储目录】，默认是直接放在系统主目录下，即：dir ./。默认开启。

如果 Redis 是在集群模式下运行的，每个节点都需要配置一个单独的数据存储位置，确保文件的名称不会冲突。

4.2.3 REPLICATION 主从复制相关项

• replicaof

【在从服务器上配置此项，用于去复制主服务器的数据，作为备份】，默认不配置，语法：replicaof <masterip> <masterport>。默认不配置。（replica：ˈreplɪkə 复制品；仿制品）

当从服务器启动并配置了 replicaof 后，它将连接到主服务器并发送 SYNC 命令来开始复制过程。主服务器响应并开始向从服务器发送数据，包括所有写命令的日志文件。从服务器执行这些写命令来保持与主服务器的数据同步。在复制过程中，主服务器还会将后续的写命令实时发送给从服务器，以保持数据的一致性。

replicaof 配置通常只需要在从服务器上设置，而主服务器不需要进行任何特殊配置。

• masterauth

【用来配置 master 的密码】，默认不配置。masterauth <master-password>。默认不配置。

若 master 服务设置了密码，这此项就需要配置对应的密码内容，没有则无需配置。

• replica-serve-stale-data

【用于控制从服务器在与主服务器断开连接后的行为】，选项：yes/no，默认：replica-serve-stale-data yes。默认开启。

默认值为 no，此时连接断开后就不再提供数据服务，除了 INFO 和 SLAVOF 命令，错误提示“SYNC with master in progress”。这样做是为了确保数据的一致性，防止客户端读取到过期的数据。

配置为 yes 时，从服务器仍尽可能地提供数据服务。这可能包括一些过时的数据，因为从服务器在断开连接后无法再同步来自主服务器的更新。

• replica-read-only

【用于控制从服务器（replica）是否以只读模式运行】，选项：yes/no，默认：replica-read-only yes。默认开启。

默认设置为 yes，从服务器将拒绝所有写命令，确保从服务器上的数据不会被意外修改。这是主从复制架构中的一个安全措施，以防止从服务器上的误操作或应用程序错误影响数据的一致性。

• repl-diskless-sync

【用于控制在复制过程中是否使用无盘备份的方式进行数据同步】，选项：yes/no，默认：repl-diskless-sync no。默认开启。

设置为 yes 时，表示在执行全量复制操作时，Redis 主节点会创建一个子进程直接将 RDB 文件写入到从节点的套接字中，而不涉及磁盘操作。这种方式可以带来两个主要的好处：一是提高速度：在网络带宽较大且磁盘速度较慢的环境中，无盘备份方式可以更快地完成数据同步过程；二是减少资源占用：由于避免了磁盘 I/O 操作，可以在同步过程中节省系统资源，特别是在高负载情况下更为明显。

但使用无盘备份也存在一定的风险，主要是在网络状况不佳的情况下可能会导致数据丢失。因此，如果网络环境不稳定或者对数据安全性有较高要求的场景下，建议将 repl-diskless-sync 设置为 no，以确保通过传统的基于磁盘的复制方式进行数据同步，这样即使在网络传输中断的情况下也不会丢失数据。

• repl-diskless-sync-delay

【用于设置 diskless 复制的延迟时间】，默认设置为 5 秒，即：repl-diskless-sync-delay 5。默认开启。

配置为 5 意味着从节点会在与主节点建立复制连接后等待 5 秒钟再开始接收 rdb 数据。

若设置为 0，就是一旦复制开始，节点不会再接收新 slave 的复制请求直到下一个 rdb 传输，所以最好等待一段时间，等更多的 slave 连上来。

另外，这个延迟确保主节点有足够的时间来准备 rdb 数据，特别是当系统资源有限时，可以避免因主节点过载而导致的复制失败或数据丢失。

• repl-ping-slave-period

【用于控制在主从复制架构中，主节点（master）向从节点（slave）发送PING命令的时间间隔】，默认值为 10 秒，repl-ping-slave-period 10。默认不配置。

通过定期发送 ping 命令，主节点可以检测到从节点是否断线或停止响应。如果从节点在一定时间内没有回应 ping 命令，主节点会将其标记为离线状态，并可能触发相关的故障转移措施（如通知管理员或启动其他从节点进行同步）。

如果网络延迟较大或者希望减少网络流量，可以适当增加这个时间间隔；反之，如果希望更及时地检测从节点的状态，可以减少这个时间间隔。需要注意的是，设置过小的时间间隔可能会导致网络拥塞和不必要的负载，而设置过大的时间间隔则可能导致从节点故障的检测延迟。

• repl-timeout

【用于控制主从复制链接判断超时的时间】，默认 60 秒，repl-timeout 60。默认不配置。

master 和 slave 都有超时时间的设置。master 检测到 slave 上次发送的时间超过 60 秒，即认为 slave 离线，清除该 slave 信息。slave 检测到上次和 master 交互的时间超过 60 秒，则认为 master 离线。需要注意的是 repl-timeout 需要设置一个比 repl-ping-slave-period 更大的值，不然会经常检测到超时。

对于拥有大数据集的系统，可能需要增加时间值，以避免因网络延迟或数据处理缓慢导致的不必要的超时和重连。

• repl-disable-tcp-nodelay

【用于控制是否允许小的数据包被立即发送而不是等待合并】，选项为 yes/no，默认是优先合并后发送：repl-disable-tcp-nodelay no。默认开启。

tcp-nodelay 是一个 Linux 内核参数，用于禁用 Nagle 算法。Nagle 算法是一种减少网络拥塞的机制，它会尝试合并多个小的数据包为一个较大的数据包进行发送，以减少网络传输次数和提高效率。

对于需要低延迟复制的场景，可以更改为 yes；而对于希望减少网络负载的情况，可以默认设置为 no。

• repl-backlog-size

【用于控制主从复制过程中部分复制缓冲区大小】，默认 1MB，repl-backlog-size 1mb。默认不配置。

在主从复制机制中，当从节点（slave）断开与主节点（master）的连接并重新连接后，为了能够进行部分复制而不是全量复制，主节点会维护一个包含最近执行的命令的缓冲区。这个缓冲区就是所谓的 backlog，它允许从节点在重新连接后同步在断开期间错过的命令。

在实际生产环境中，可能需要根据具体的负载和网络状况来调整此配置的大小。如果从节点可能会因为网络问题或其他原因频繁断开连接，那么增加此配置的值可以减少因全量复制导致的性能影响。

需要注意的是，repl-backlog-size 只针对部分复制，即在从节点断线后重新连接时使用。如果从节点是全新的或者需要全量复制，那么会进行 rdb 传输而不是使用 backlog。

• repl-backlog-ttl

【用于控制在没有从节点连接时，复制缓冲区（replication backlog）的保留时间】，默认是 3600 秒，repl-backlog-ttl 3600。默认不配置。

如果设置为 0，则意味着这个缓冲区将不会被自动释放。

如果在指定时间内从节点没有重新连接，主节点将清除复制缓冲区的内容。

如果设置得太短，可能会导致从节点在断线重连后无法通过部分复制（partial replication）来同步数据，而不得不进行全量复制（full replication），这会增加主节点的负载和复制过程的时间。

• replica-priority

【作用是在主节点失效时，帮助Sentinel决定哪个从节点应该被提升为新的主节点】，默认值 100，值越小优先级越高，replica-priority 100。默认开启。

若配置成 0，意味着总不会被选中。

当主节点出现故障时，Sentinel 会考虑所有从节点的 replica-priority 值，并选择优先级最高的从节点作为新的主节点。如果两个从节点的 replica-priority 值相同，则 Sentinel 会选择复制偏移量（replication offset）最大的从节点。

此配置项可以确保在主节点失败时，集群能够快速且有序地选举出新的主节点。在设置时，需要根据实际的架构和需求来决定各个从节点的优先级，以确保系统的稳定运行。

• min-replicas-to-write

【用于设置在执行写操作时，至少需要多少个从节点（Slave）处于可用状态】，默认是 3 个，min-replicas-to-write 3。默认不配置。

默认 3 ，表示在执行写操作时，至少需要三个从节点处于可用状态。如果设置为 0，则表示不需要判断从节点，直接与主节点交互。这个参数的值可以根据实际需求进行调整，但需要注意的是，增加该值可以提高数据的可靠性，但也可能导致写操作的性能降低。

• min-replicas-max-lag

【用于设置从节点在与主节点进行数据复制时允许的最大延迟时间（lag）】，默认值为 10 秒，min-replicas-max-lag 10。默认不配置。

延迟小于此配置的秒数的 slave 才认为是健康的 slave。

在主从复制过程中，从节点的数据可能会落后于主节点。通过限制从节点的最大延迟时间，可以确保被提升为主节点的从节点具有较为更新的数据，从而维护数据的一致性。

min-replicas-to-write 3
min-replicas-max-lag 10
# 上边两个配置一般一起使用，表示至少三个副本且延迟 <=10 秒
# 其中一个为 0，标识禁用此功能

• replica-announce-ip
• replica-announce-port

【用于指定Redis实例在复制过程中向其他节点通告的 IP 地址和端口】，默认不配置。

在Redis主从复制架构中，从节点需要知道主节点的IP地址以建立连接。此配置就是用来告诉从节点，它的主节点的 IP 地址和端口，然后从节点就能够准确地连接到主节点并开始复制过程。

4.2.4 SECURITY 数据安全相关配置

• requirepass

【用于设置Redis实例的密码认证】，默认不配置此项，即无密码：# requirepass foobared。默认不配置。

通过使用此配置项，可以要求客户端在连接 Redis 实例时提供正确的密码才能进行操作。这有助于防止未经授权的访问和潜在的安全威胁。

需要 注意，因为 Redis 太快了，每秒可以认证 150 000 次密码，简单的密码很容易被攻破，因此强烈建议使用强密码，并结合其他安全措施，如防火墙规则、访问控制列表等，以进一步限制和保护对 Redis 服务的访问。此外，定期更换密码并监控异常访问行为也是保护 Redis 安全的好方法。

• rename-command

【可以修改或禁用 Redis 实例中的命令】，默认不配置。

此项配置有助于提高安全性，防止潜在的恶意行为或滥用。共有两种设置方式：

1）完全禁用命令：将命令重命名为空字符串，例如：rename-command CONFIG ""。这将禁用 CONFIG 命令，使其无法在 Redis 实例中执行。

2）修改命令名称：将命令重命名为其他名称，例如：rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52。这将把 CONFIG 命令的名称修改为一段随机数，客户端需要使用新的命令名称来执行相应的操作。

建议仅禁用或修改必要的命令以提高安全性，避免影响正常操作。默认情况下不配置此项，Redis 命令保持原始名称不变。

4.2.5 CLIENTS 客户端数量配置

• maxclients

【用于配置最多有多少个客户端同时连接】，默认 10000，maxclients 10000。默认不配置。

通过设置此项，可以限制 Redis 实例能够同时处理的最大客户端连接数，防止因过多的连接请求而导致系统资源耗尽或性能下降。

在实际生产环境中最好根据实际情况进行评估和调整。如果设置得过小，可能导致正常请求被拒绝；如果设置得过大，可能会导致系统资源耗尽或性能下降。

4.2.6 MEMORY MANAGEMENT 内存相关

• persistence-available

【用于指示 Redis 实例是否支持持久化功能】，选项 yes/no，默认支持：persistence-available yes。默认不配置。

Redis 提供了两种持久化方式：rdb（快照）和 aof（追加文件）。通过设置此项，可以告诉客户端 Redis 实例是否支持这两种持久化方式中的至少一种，这有助于客户端根据需要选择合适的持久化策略。

一般建议启用 Redis 的持久化功能，以防止数据丢失或系统故障导致的数据损坏。同时，需要定期备份数据并测试恢复过程，以确保数据的可靠性和完整性。

• maxmemory

【用于限制 Redis 实例能够使用的最大内存量】，此配置的值可以灵活配置，例如：maxmemory 100M。默认不配置。

配置值也可以是 100MB，类似的还可以为 10G、10GB，若不带单位就是 B 字节数。

在高并发场景下，Redis 可能会接收到大量的数据存储请求。通过设置此配置，可以限制 Redis 实例能够使用的最大内存量，防止因过多的数据存储而导致系统资源耗尽或性能下降。

注意 slave 的输出缓冲区是不计算在 maxmemory 内的，所以为了防止主机内存使用完，建议设置的 maxmemory 需要更小一些。

• maxmemory-policy

【用于设置内存淘汰策略的配置参数】，默认：maxmemory-policy noeviction。默认不配置。

当 Redis 的内存使用量超过 maxmemory 时，根据该策略来决定哪些数据需要被删除。

以下是全部可选项：

noeviction：默认策略，不会删除任何数据，只是拒绝写入操作。
allkeys-lru：从所有键中选择最近最少使用的键进行淘汰。
volatile-lru：从设置了过期时间的键中选择最近最少使用的键进行淘汰。
allkeys-random：从所有键中随机选择一个键进行淘汰。
volatile-random：从设置了过期时间的键中随机选择一个键进行淘汰。
volatile-ttl：从设置了过期时间的键中选择剩余存活时间最短的键进行淘汰。

为了避免误删重要数据，建议在测试环境中先进行测试再应用到生产环境。

• maxmemory-samples

【用于设置内存使用量统计的样本数量】，默认 5 个：maxmemory-samples 5。默认不配置。

在 Redis 中，为了估算内存使用量，Redis 会定期对当前已用的内存进行采样，并记录每个键值对占用的内存大小，本配置就是用来设置采样的数量。这个参数决定了内存使用量统计的准确性和性能开销。

合理设置此项，对于保护 Redis 实例免受过多数据存储的影响非常重要。如果设置得过小，可能导致内存使用量统计不准确；如果设置得过大，可能会增加性能开销。

• replica-ignore-maxmemory

【用于控制主从复制时是否忽略从节点的 maxmemory 设置】，选项 yes/no，默认是 yes 忽略：replica-ignore-maxmemory yes。默认不配置。

在 Redis 中，主从复制是一种常见的数据同步方式。当主节点的数据发生变化时，会将变化的数据同步到从节点上。如果从节点设置了 maxmemory 限制，那么在同步数据时可能会因为内存不足而拒绝写入操作。此配置就是用来控制是否忽略从节点的 maxmemory 设置，从而避免这种情况的发生。

4.2.7 LAZY FREEING 惰性删除机制配置

惰性删除机制默认是全部关闭的，需要根据实际需求进行单独配置。

• lazyfree-lazy-eviction：

控制是否在【内存淘汰时】使用惰性删除，默认 no。默认开启。

当设置为 yes 时，Redis 在内存淘汰时不会立即释放被删除对象的内存，而是等待下一次访问该对象时才进行释放。这可以提高性能，但可能会增加内存使用。

• lazyfree-lazy-expire：

控制是否在【处理过期键时】使用惰性删除，默认 no。默认开启。

当设置为 yes 时，Redis 在处理过期键时不会立即释放内存，而是等待下一次访问该键时才进行释放。这可以减少因频繁过期键而导致的性能开销。

• lazyfree-lazy-server-del：

控制是否在【客户端执行 DEL 命令时】使用惰性删除，默认 no。默认开启。

当设置为 yes 时，Redis 在执行 DEL 命令时不会立即释放内存，而是等待下一次访问该键时才进行释放。这可以提高大量删除操作的性能。

• replica-lazy-flush：

控制【主从复制时】是否使用惰性刷新，默认 no。默认开启。

当设置为 yes 时，从节点在接收到主节点的数据更新后不会立即刷新到磁盘，而是等待一段时间后再进行刷新。这可以减少磁盘 I/O，提高复制性能。

4.2.8 APPEND ONLY MODE 仅追加模式

• appendonly

【用于控制是否启用仅追加模式】，选项：yes/no，默认不开启 no：appendonly no。默认开启。

在仅追加模式下，Redis 将所有写操作都记录在 AOF（Append Only File）日志文件中，而不是直接写入内存。这种模式的主要优点是可以提供更好的数据持久性，因为即使 Redis 服务器崩溃或重启，也可以通过重放日志文件来恢复数据。

需要注意的是，仅追加模式需要更多的磁盘空间来存储日志文件，并且可能会对性能产生一定的影响。

• appendfilename

【用于指定仅追加模式（Append Only Mode）的日志文件名】，默认：appendfilename "appendonly.aof"。默认开启。

• appendfsync

【配置数据同步到磁盘的策略】，默认：appendfsync everysec。默认开启。

以下是策略选项：

always：每次执行写操作后，都会立即调用 fsync 将数据同步到磁盘。这种策略确保了极高的数据安全性，因为即使发生宕机，也不会丢失任何数据。但是，这会极大地削弱 Redis 的性能，因为每次写操作都需要等待数据同步到磁盘，这在高并发场景下可能导致性能瓶颈。
everysec（默认值）：这种模式下，Redis 会每秒最多调用一次 fsync 来同步数据到磁盘。这种策略在性能和数据安全性之间取得了平衡。一般情况下，不会对性能产生太大影响，同时也能保证较好的数据安全性。这种策略的性能并不是很糟糕，通常不会产生毛刺（资源占用激增），这得益于 Redis 引入了 BIO（Background I/O）线程，所有的 fsync 操作都异步交给了 BIO 线程处理。
no：在这种模式下，Redis 不会主动调用 fsync 来同步数据到磁盘，而是依赖操作系统来决定何时将数据从系统缓冲区刷到磁盘。这种策略提供了最好的性能，但数据安全性最低，因为如果发生宕机，可能会有部分数据丢失。

如果对数据安全性有极高的要求，可以选择 always；如果追求性能，可以选择 no；而 everysec 则是一个折中的选择，适合大多数情况。

• no-appendfsync-on-rewrite

【用于控制 AOF（Append Only File）重写时的 fsync 行为】，选项 yes/no，默认：no-appendfsync-on-rewrite no。但是建议配置为 yes。默认开启。

当 Redis 需要执行一些重写操作时，例如删除过期键或压缩 AOF 文件，它会创建一个新的 AOF 文件，并将旧的 AOF 文件重命名为备份文件。在这个过程中，如果启用了 appendfsync 选项，Redis 会在每次写入新的 AOF 文件时调用 fsync 来确保数据同步到磁盘。这可以保证在重写过程中不会丢失任何数据。然而，这种同步操作可能会对 Redis 的性能产生负面影响，因为它会阻塞 Redis 进程直到数据同步完成。为了解决这个问题，Redis 引入了 no-appendfsync-on-rewrite 选项。

设置为 yes 表示 rewrite 期间对新写操作不 fsync，暂时存在内存中，等 rewrite 完成后再写入，这样可以避免阻塞 Redis 进程，提高性能。

需要注意的是，由于本配置选项会导致数据同步延迟，因此在发生宕机等异常情况时，可能会丢失部分数据。

• auto-aof-rewrite-percentage
  auto-aof-rewrite-min-size

这两个选项通常一起使用，以确保在满足一定条件时触发 AOF 重写，以减小 aof 文件的大小并提高性能。默认值：auto-aof-rewrite-percentage 100；auto-aof-rewrite-min-size 64mb。默认开启。

auto-aof-rewrite-percentage：这个选项用于设置触发 AOF 重写的条件。它的值是一个百分比，表示当当前 aof 文件的大小超过上一次重写后的 AOF 文件大小的指定百分比时，将触发 AOF 重写。默认值为 100，表示每次重写都会生成一个新的 AOF 文件。

auto-aof-rewrite-min-size：设置允许重写的最小 AOF 文件大小，避免了达到约定百分比但尺寸仍然很小的情况还要重写。默认值为 64MB。

• aof-load-truncated

【用于控制 AOF（Append Only File）文件加载时的行为】，选项：yes/no，默认：aof-load-truncated yes。默认开启。

当设置为 yes 时，如果 AOF 文件在加载过程中被截断或损坏，Redis 会尝试从最后一个有效的命令开始重新执行剩余的命令，以尽可能地恢复数据。这可以确保数据的完整性，但可能会导致部分数据丢失。

当设置为 no 时，如果 AOF 文件在加载过程中被截断或损坏，Redis 将停止加载并报告错误。这可以防止数据丢失，但可能导致部分数据无法恢复。

• aof-use-rdb-preamble

【用于控制 AOF（Append Only File）文件的格式】，选项 yes/no，默认：aof-use-rdb-preamble yes。默认开启。

当设置为 yes 时，Redis 会在 AOF 文件中添加一个 RDB 格式的前导部分，以支持在 AOF 文件损坏或丢失时，通过加载 RDB 文件来恢复数据。这个前导部分包含了一些元数据和键值对的快照信息。

当设置为 no 时，Redis 不会在 AOF 文件中添加 RDB 格式的前导部分。这可以减少 AOF 文件的大小，但可能导致在 AOF 文件损坏或丢失时无法通过加载 RDB 文件来恢复数据。

4.2.9 LUA SCRIPTING 关于 lua 脚本的相关配置

• lua-time-limit

【用于设置Lua脚本的最大执行时间】，单位毫秒，默认：lua-time-limit 5000。默认开启。

默认情况下，Redis 允许 Lua 脚本无限期地运行，这可能会导致一些长时间运行的脚本占用过多的服务器资源，甚至导致服务器崩溃。为了避免这种情况，Redis 提供了此配置项来限制 Lua 脚本的执行时间。

此项的值可以是一个整数或一个浮点数，表示 Lua 脚本的最大执行时间。如果 Lua 脚本的执行时间超过了这个限制，Redis 将终止该脚本的执行并返回一个错误。

当一个脚本超过了最大时限，只有 SCRIPT KILL 和 SHUTDOWN NOSAVE 可以用。第一个可以杀没有调 write 命令的东西。要是已经调用了 write，只能用第二个命令杀。

4.2.10 REDIS CLUSTER 集群先关配置

• cluster-enabled

【用于启用或禁用 Redis 集群模式】，选项 yes/no，默认值为 yes，例如：# cluster-enabled yes。默认不开启。

设置为 yes 时，Redis 将启动集群模式，允许多个 Redis 实例组成一个分布式的集群，实现数据的分片和高可用性。在集群模式下，数据被分成多个分片，每个分片存储在不同的 Redis 实例上，从而实现了数据的分布式存储和负载均衡。

设置为 no 时，Redis 将运行在单实例模式下，所有数据都存储在一个 Redis 实例中。

需要注意的是，启用集群模式需要满足一定的条件，例如必须使用相同的配置文件、端口号等。

• cluster-config-file

【用于指定集群配置文件的路径】例如：# cluster-config-file nodes-6379.conf。默认不开启。

当使用 redis-cli 工具创建集群时，会自动生成一个名为 nodes.conf 的默认配置文件。但是，如果你想要自定义配置文件的名称或路径，可以使用本配置选项来指定集群配置文件。

需要注意的是，cluster-config-file 选项仅适用于 Redis Cluster 模式。对于单机模式，该选项将被忽略。

• cluster-node-timeout

【用于控制 Redis 集群节点的超时时间】，默认 15 秒：# cluster-node-timeout 15000。默认不开启。

在 Redis 集群中，节点之间的通信是通过异步的方式进行的。当一个节点向另一个节点发送命令或请求时，它会等待一段时间以接收来自目标节点的响应，这个等待的时间就是节点超时时间。如果在此时间内未收到来自目标节点的响应，则认为该节点不可达，可能会触发集群的故障转移机制。

较低的超时值可以更快地检测到节点故障，但也可能增加误判的风险；较高的超时值可以减少误判，但可能延迟故障检测和处理。

• cluster-replica-validity-factor

【用于控制集群中从节点（replica）的有效性因子】，默认：# cluster-replica-validity-factor 10。默认不开启。

在 Redis 集群中，每个主节点（master）可以有多个从节点（replica），用于复制和备份数据。为了确保数据的一致性和可用性，Redis 集群使用了一种称为复制偏移量（replication offset）的机制来跟踪主从节点之间的数据同步状态。本配置参数用于设置从节点的有效性因子，该因子决定了从节点与主节点之间的复制偏移量差异是否足够大，以触发故障转移。默认情况下，该参数的值为 10，表示如果从节点的复制偏移量与主节点的差异超过 10 个复制操作，则认为该从节点无效。

较低的偏移量值可以更快地检测到从节点的故障，但也可能增加误判的风险；较高的值可以减少误判，但可能延迟故障检测和处理。

• cluster-migration-barrier

【用于控制集群中节点迁移的屏障值】默认：# cluster-migration-barrier 1。默认不开启。

在 Redis 集群中，当一个主节点（master）需要迁移到另一个节点时，它会将数据复制到目标节点，并逐步减少自己的负载。这个过程称为节点迁移。本参数用于设置节点迁移的屏障值，该值决定了主节点在迁移过程中可以容忍的最大负载差异。默认情况下，该参数的值为 1，表示主节点在迁移过程中只能容忍 1 个键的差异。

较低的屏障值可以更快地完成节点迁移，但也可能增加数据不一致的风险；较高的值可以减少数据不一致的风险，但可能延迟节点迁移的完成。

• cluster-require-full-coverage

【用于设置集群是否需要完整的复制覆盖】，选项 yes/no，默认：# cluster-require-full-coverage yes。默认不开启。

设置为“yes”时，Redis 集群会要求每个主节点至少有一个从节点与其完全同步，即复制偏移量相等。这可以确保即使某个主节点发生故障，其数据仍然可以从从节点中恢复。

设置为“no”时，则 Redis 集群不会强制要求每个主节点都有一个完整的从节点复制。这意味着在某些情况下，主节点的数据可能无法完全恢复。

• cluster-replica-no-failover

【用于控制集群中从节点（replica）是否参与故障转移】，选项：yes/no，默认允许：# cluster-replica-no-failover no。默认不开启。

在 Redis 集群中，当主节点发生故障时，Redis 集群会通过故障转移机制将其中一个从节点提升为新的主节点，以继续提供服务。本参数用于设置集群中的从节点是否参与故障转移。

设置为 "yes" 时，Redis 集群不会将任何从节点提升为新的主节点，即使它们与原主节点的复制偏移量相等。这可以确保从节点的数据始终与主节点保持一致，避免数据不一致的风险。

设置为 "no"，则 Redis 集群允许从节点参与故障转移，即使它们的复制偏移量与原主节点相等。这意味着在某些情况下，从节点可能会被提升为新的主节点，导致数据不一致。

4.2.11 CLUSTER DOCKER/NAT support 在 Docker 环境下的配置

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

一个配置示例：

# cluster-announce-ip 10.1.1.5
# cluster-announce-port 6379
# cluster-announce-bus-port 6380
# 在上述示例中
# cluster-announce-ip 被设置为 10.1.1.5，表示 Redis 集群节点将使用该 IP 地址进行通信；
# cluster-announce-port 被设置为 6379，表示节点将使用该端口号进行通信；
# cluster-announce-bus-port 被设置为 6380，表示节点将使用该端口号进行集群总线通信。

4.2.12 SLOW LOG 耗时命令的记录配置

SLOW LOG 是用来记录 Redis 运行中执行比较慢的命令耗时。当命令的执行超过了指定时间，就记录在 SLOW LOG 中。SLOW LOG 保存在内存中，所以没有 IO 操作。

• slowlog-log-slower-than

【用于设置记录耗时操作的阈值】，默认 10000 微秒：slowlog-log-slower-than 10000。默认开启。

在 Redis 中，慢查询日志记录了执行时间超过指定阈值的命令。这个阈值就是由本配置参数设定的。当一个命令的执行时间超过了这个阈值，它就会被记录到慢查询日志中。

记录耗时操作，有助于系统故障排查和优化。

• slowlog-max-len

【用于控制慢查询日志的最大长度】，默认 128：slowlog-max-len 128。默认开启。

当慢查询日志达到最大长度时，最早的慢查询命令将被删除，以便为新的慢查询命令腾出空间。

4.2.13 LATENCY MONITOR 性能监测工具

LATENCY MONITOR 是 Redis 的一个性能监测工具，它能够在运行时对 Redis 实例执行的不同操作进行采样，收集与可能的延迟源相关的数据。这个功能从 Redis 版本 2.8.13 开始引入，目的是帮助用户和管理员了解 Redis 服务器在处理命令时的延迟情况，以便更好地分析和优化性能。

• latency-monitor-threshold

【用于控制延迟监控的阈值】，默认为 0 关闭监视：latency-monitor-threshold 0。默认开启。

通过设置本参数，可以指定一个时间阈值，当命令的执行时间超过这个阈值时，延迟监控就会触发并记录相关信息。

4.2.14 EVENT NOTIFICATION 配置事件通知

这个模块允许Redis服务器在执行特定操作时，通过发布与订阅（pub/sub）机制通知客户端关于数据集变化的实时信息。

• notify-keyspace-events

【用于控制事件通知的行为】，默认为空：notify-keyspace-events ""。默认开启。

通过本参数，可以指定哪些类型的键空间事件应该被通知给客户端。

# 全部选项和释义如下：
K：键空间通知，包括所有关于键空间的命令，如 DEL、EXPIRE、RENAME 等。
E：键事件通知，包括所有关于键的事件，如 SET、HSET、LPUSH 等。
g：通用命令通知，包括所有不涉及具体键的命令，如 FLUSHDB、FLUSHALL 等。
$：字符串特定命令通知，包括所有针对字符串的操作，如 APPEND、SETRANGE 等。
l：列表特定命令通知，包括所有针对列表的操作，如 LPUSH、RPOP 等。
s：集合特定命令通知，包括所有针对集合的操作，如 SADD、SREM 等。
h：哈希特定命令通知，包括所有针对哈希的操作，如 HSET、HDEL 等。
z：有序集合特定命令通知，包括所有针对有序集合的操作，如 ZADD、ZREMRANGEBYRANK 等。
x：过期事件通知，包括所有关于键过期的事件，如 EXPIRE、EXPIREAT 等。
e：驱逐事件通知，包括所有关于键驱逐的事件，如内存不足时进行的驱逐操作。
A：数据库 AOF 持久化事件通知，包括所有关于 AOF 持久化的事件，如 RDB 快照生成、AOF 重写等。
u：服务器用户管理事件通知，包括所有关于用户管理的事件，如创建用户、修改密码等。
p：服务器进程管理事件通知，包括所有关于进程管理的事件，如进程退出、重启等。

通过设置合理的事件类型，可以帮助 DBA 监控和识别那些可能导致性能问题的慢查询。但是要注意是的，过多的事件通知可能会导致大量的网络流量和资源消耗，而过少的通知则可能会漏掉一些重要的事件。

4.2.15 ADVANCED CONFIG 高级配置

这个模块通常包含一些不经常改动、对性能和资源有重要影响的参数。在 Redis 中，这些高级配置项可能涉及内存管理、数据持久化、事件通知等方面。由于它们通常需要更深入的理解和谨慎的配置，因此被称为“高级”配置。

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

在 Redis 中，哈希数据结构用于存储字段-值对的映射。为了优化内存使用和提高性能，Redis 使用压缩列表 ziplist 来存储较小的哈希表。当哈希表中的元素数量或单个值的大小超过设定的阈值时，Redis 会将压缩列表转换为更消耗内存但访问速度更快的哈希表 Hashtable。Hashtable 之所以高效，是因为它在设计上针对内存存储进行了优化，并且在并发处理上采用了先进的锁技术，以及根据数据规模动态调整存储结构等。

hash-max-ziplist-entries：该参数指定了一个哈希表中可以存储的最大条目数量。默认值为 512 个。默认开启。

hash-max-ziplist-value：该参数指定了哈希表中单个值的最大字节大小。默认值为 64 字节。默认开启。

通过调整这两个参数，可以平衡内存使用和性能。增大这些值可以节省内存，但可能会降低性能；减小这些值可以提高性能，但会增加内存使用。

• list-max-ziplist-size

【列表类型单个值大小的阈值设定】，默认级别是 -2，即 8kb：list-max-ziplist-size -2。默认开启。

级别对应的值大小如下：

#-5:最大大小：64 KB<--不建议用于正常工作负载
#-4:最大大小：32 KB<--不推荐
#-3:最大大小：16 KB<--可能不推荐
#-2:最大大小：8kb<--良好
#-1:最大大小：4kb<--良好

当超过配置的阈值后，将由原来的 ziplist 改为更高效的 Quicklist 数据结构。

QuickList 是 Redis 3.2 版本引入的一种新的数据结构，它结合了双端链表和压缩列表（ZipList）的优点。在 QuickList 中，每个节点都是一个 ZipList，这样的结构既保持了 ZipList 内存紧凑的优势，又通过链表提供了快速的插入和删除操作。这种设计使得 Redis 可以更有效地处理那些元素数量不多，但单个元素大小可能较大的列表数据。

• list-compress-depth

【用于设置当列表（List）数据类型中的元素为紧凑数字字符串时，进行压缩存储的最大深度】，默认值是0，表示禁用这种压缩存储方式：list-compress-depth 0。默认开启。

具体来说，当列表类型的值只包含十进制 64 位有符号整型数字构成的字符串时，Redis 可以使用一种特殊的编码方式来节省内存空间。那么本配置项，就是用来控制这种特殊编码方式在列表中可以应用的最大深度。如果一个列表包含了很多重复的数字，且这些数字都是 64 位有符号整型数字，那么 Redis 会将这些数字存储为一个特殊的字符串，而不是单独的每个元素都占用一个完整的数据结构。这样做可以减少内存的使用，提高存储效率。

配置为 1 时，就是头部和尾部各一个值不进行压缩，其间的全部值都进行压缩；配置为 2 时，同理前后各两个值不参与压缩，中间的值压缩，后续以此类推。Redis 并没有硬性规定最大值。理论上可以设置一个非常大的值，但实际可配置的最大值取决于系统资源和 Redis 实例的限制。

• set-max-intset-entries

【用于设置在 Redis 的集合（Set）数据类型中，整数集合（Intset）可以存储的最大元素数量】，set-max-intset-entries 512。默认开启。

当集合中的元素数量超过这个限制时，Redis 会使用 Set 或更高级的哈希表（HashTable）来存储集合元素。

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

【用于控制有序集合（ZSet）的底层存储结构】，默认开启。

zset 在底层可以通过 ziplist 或跳跃表（skiplist）来实现。当 zset 的元素数量和单个元素的大小在一定范围内时，Redis 会使用 ziplist 作为底层存储结构；当超出这个范围时，会转换为跳跃表。

zset-max-ziplist-entries：这个参数设置了一个阈值，当 ZSet 中的元素数量超过这个值时，Redis 会将底层结构从压缩列表 ziplist 转换为跳跃表 skiplist。默认值为 128 个。

zset-max-ziplist-value：这个参数指定了 ZSet 中单个元素的最大字节大小。如果 ZSet 中的任何元素的字节大小超过了这个值，Redis同样会将底层结构从压缩列表转换为跳跃表。默认值为 64 字节。

• hll-sparse-max-bytes

【用于配置 HyperLogLog 稀疏数据结构的最大字节数，超过时改为密集数据结构存储】，默认 300 字节：hll-sparse-max-bytes 3000。默认开启。

HyperLogLog 是一种用于估计集合中不同元素数量的概率算法。在 Redis 中，HyperLogLog 可以用于统计网站访问量、用户活跃度等场景。为了优化内存使用和提高性能，Redis 会使用稀疏数据结构来存储较小的 HyperLogLog 对象。当 HyperLogLog 对象的大小超过设定的阈值时，Redis 会将其转换为更消耗内存但访问速度更快的密集数据结构。

需要注意的是，如果 HyperLogLog 对象的数量较少且每个对象的字节大小较大，那么使用稀疏数据结构可能不会带来显著的性能提升，甚至可能导致性能下降。

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

【用于配置 Stream 数据结构的节点】，默认开启。

stream-node-max-bytes：这个参数的单位是字节（Byte），默认值为 4096，意味着每个 Stream 数据结构的节点默认最大占用 4096 字节的内存空间。如果设置了 0，则表示该节点的内存使用无上限。

stream-node-max-entries：此参数决定了单个节点在转移到新的节点之前可以包含的最大项目数，默认值为 100。同样，如果设置为 0，则表示节点中可以存储的元素数量没有限制。

在实际使用 Redis 的 Stream 功能时，合理地配置这两个参数能够帮助维护数据的有序性和访问性能，特别是在处理大量数据流时。

• activerehashing

【用于控制是否启用Hash表的主动重新哈希功能】，选项 yes/no，默认：activerehashing yes。默认开启。

当设置为 yes 时，Redis 会每 100 毫秒使用 1 毫秒的 CPU 时间来对 Hash 表进行重新哈希，这样做可以降低内存的使用。这个设置特别适用于那些有较为宽松实时性需求的场景，因为它可能会引入大约 2 毫秒的延迟。

虽然这个过程可以节省内存，但会消耗一定的 CPU 资源，因此，在资源受限的情况下，需要权衡内存和 CPU 资源的使用。

Redis 的核心数据结构之一是 Hash 表，它用于存储键值对。随着数据的不断插入和删除，为了保持高效的访问速度，Hash 表需要进行重新哈希（rehash）操作来保证负载因子（load factor）处于合理范围。这个过程通常是在后台进行的，但 activerehashing 选项可以让这个过程变得更加积极。在高负载和大数据量的环境中，合理地使用这个选项可以帮助提高 Redis 的性能和效率。

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

【用于控制客户端输出缓冲区大小限制的选项】，默认开启。

这个选项有三个参数，分别代表不同的客户端类型（普通 normal、复制 replica、发布订阅 pubsub）以及对应的硬限制、软限制和警告阈值。

client-output-buffer-limit normal 0 0 0
# 这个配置针对普通（normal）客户端连接
# 设置参数为 0 0 0 意味着关闭了硬限制、软限制和警告阈值，即不对普通客户端连接的输出缓冲区大小进行限制

client-output-buffer-limit replica 256mb 64mb 60
# 这个配置针对复制（Replica）客户端连接
# 设置了硬限制为 256MB，软限制为 64MB，警告阈值为 60 秒。这意味着：
# 硬限制：当复制客户端的输出缓冲区大小达到 256MB 时，Redis 会立即断开客户端连接
# 软限制：当复制客户端的输出缓冲区大小达到 64MB 时，Redis 会开始警告，但不会立即断开连接
# 警告阈值：当复制客户端的输出缓冲区大小连续 60 秒超过软限制时，Redis 会断开客户端连接

client-output-buffer-limit pubsub 32mb 8mb 60
# 这个配置针对发布订阅（Pub/Sub）客户端连接
# 设置了硬限制为 32MB，软限制为 8MB，警告阈值为 60 秒。这意味着：
# 硬限制：当发布订阅客户端的输出缓冲区大小达到 32MB 时，Redis 会立即断开客户端连接
# 软限制：当发布订阅客户端的输出缓冲区大小达到 8MB 时，Redis 会开始警告，但不会立即断开连接
# 警告阈值：当发布订阅客户端的输出缓冲区大小连续 60 秒超过软限制时，Redis 会断开客户端连接

此项配置项需要根据客户端类型和应用场景来调整 Redis 服务器对客户端输出缓冲区大小的限制，以确保系统的稳定性和性能。

• client-query-buffer-limit

【用于控制客户端传递给 Redis 的数据大小】，默认 1gb：# client-query-buffer-limit 1gb。默认不开启。

这个参数的设置，对于防止客户端发送过大的数据给 Redis 服务器，从而导致服务器资源耗尽非常重要。

默认情况下，这个限制被设置为 1GB。这意味着如果客户端尝试执行一个命令，其参数大小超过了这个限制，Redis 将不会执行该命令，并且可能会根据配置采取进一步的措施，比如断开客户端连接。

• proto-max-bulk-len

【用于设置批量请求中单个元素的最大大小】，默认 512mb：# proto-max-bulk-len 512mb。默认不开启。

在 Redis 协议中，批量请求通常指的是一次发送多个数据的操作，这些数据被打包成一个单独的字符串。为了确保服务器的稳定性和性能，Redis 对这种批量请求的大小做了限制。这有助于防止客户端发送过大的数据，导致Redis服务器资源耗尽，从而影响服务的稳定性和响应速度。

• hz

【用于设置 Redis 服务器的时钟频率 Hertz】，默认：hz 10。默认开启。

在 Redis 中，hz 参数控制着服务器的周期性操作，例如：

定时器：用于执行像 EXPIRE 这样的命令。
Pub/Sub：发布订阅模式的消息传递。
客户端超时：检测长时间无响应的客户端连接。
懒惰删除：自动删除长时间未使用的 Key。

默认情况下，hz 参数被设置为 10，这意味着 Redis 每秒执行 10 次上述周期性操作。如果将 hz 设置为更高的值，比如 20，Redis 将在一秒钟内执行 20 次这些操作，这将使得定时器更加精确，但同时也会增加 CPU 的使用率。

此处配置的 hz 就是基线频率（configured_hz），如果后续开启动态时钟频率，也是以此配置为基线值。

• dynamic-hz

【开启或关闭动态调整时钟频率 Hertz 的功能】，选项 yes/no。默认：dynamic-hz yes。默认开启。

配置为 yes 时，随着客户端连接数的变化，Redis 服务器将根据当前负载情况自动增加或减少实际的时钟频率（hz）。这样做的好处是，当服务器不繁忙时，可以降低 CPU 的使用率，而在高负载时，则能提高处理任务的频率，从而保持较好的性能和响应速度。通过动态调整 hz 值，Redis 尝试在保持高性能和节约资源之间找到平衡点。这特别适用于负载波动较大的场景，可以帮助服务器适应不同的工作负载。

如果连接的客户端数量增多，实际的 hz 值会相应提高，这意味着 Redis 执行定期任务（如过期键的删除、定时器的触发等）的频率会增加。相反，如果客户端数量减少，hz 值也会降低，以节省资源。

• aof-rewrite-incremental-fsync

【用于控制在 AOF 重写过程中刷写硬盘数据的策略】，选项 yes/no，默认：aof-rewrite-incremental-fsync yes。默认开启。

当该选项设置为 yes 时，意味着在 AOF 重写期间，Redis 会以增量的方式同步数据到硬盘。

AOF 重写是指 Redis 为了优化日志文件的大小和性能，会定期对 AOF 文件进行重写，移除不必要的写入命令，压缩日志文件的大小。

在 AOF 重写过程中，为了避免一次性写入大量数据导致硬盘 I/O 阻塞，本参数控制了每次写入硬盘的数据量。这个量为 32MB，即 Redis 会在每写入 32MB 的数据后，进行一次同步操作。这样可以有效防止在 AOF 重写时由于单次刷盘数据过多而造成硬盘的短暂阻塞，从而避免较大的延迟峰值。

• rdb-save-incremental-fsync

【用于控制在 RDB 保存过程中刷写硬盘数据的策略】，选项 yes/no，默认：rdb-save-incremental-fsync yes。默认开启。

和上一个配置相类似，本配置也是配置增量方式测操作，不同的是此项是针对 RDB。RDB 是 Redis 的一种持久化机制，它会在指定的时间间隔内生成数据集的时间点快照并保存到磁盘上。

在 RDB 保存过程中，为了避免一次性写入大量数据导致硬盘 I/O 阻塞，本参数控制了每次写入硬盘的数据量，同样是 32MB。如果启用这个选项，Redis 会在每写入一定量的数据后进行一次同步操作，这样可以减少对硬盘的影响，避免产生较大的延迟峰值。

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

这两个是与 LFU (Least Frequently Used) 缓存淘汰策略相关的配置参数。默认不开启。

lfu-log-factor 10：这个参数用于设置 LFU 算法中的对数因子。LFU 算法根据数据的访问频率来决定淘汰哪些数据，访问频率越低的数据越容易被淘汰。对数因子越大，表示访问频率的差异对淘汰的影响越小，即访问频率相近的数据被淘汰的概率较低。

lfu-decay-time 1：这个参数用于设置 LFU 算法中的衰减时间。衰减时间是指在一定时间内，访问频率会逐渐衰减。若衰减时间设置为 1 秒。这意味着在 1 秒内，如果某个数据没有被访问，那么它的访问频率会逐渐降低。

4.2.16 INCLUDES 引入额外的配置文件

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

【用于引入额外的配置文件】，默认无引用。

include 指令用于将其他配置文件的内容合并到当前配置文件中。这样做的目的是允许你将配置分散到多个文件中，以便于管理和组织复杂的配置设置。

配置项参考： https://cloud.tencent.com/developer/article/2038085