Ubuntu 20.04 64位+ Docker20.10.11
1.拉取镜像
docker pull redis:6.2.8
2.创建需要挂载的目录
mkdir -p /home/redis/conf
mkdir -p /home/redis/conf/data
3.创建文件
touch /home/redis/conf/redis.conf
为什么要创建目录和文件？
将redis 的配置文件进行挂载，以配置文件方式启动redis 容器。（挂载：即将宿主的文件和容器内部目录相关联，相互绑定，在宿主机内修改文件的话也随之修改容器内部文件），也是为了将redis的数据持久化
redis.conf对应的文件内容
#Redis配置文件示例。
#注意:为了读取配置文件，Redis必须以文件路径作为第一个参数启动:
# ./redis服务器/path/to/redis.conf
#关于单位的说明:当需要内存大小时，可以以1k 5GB 4M等通常形式指定:
#1k=>1000字节
#1kb=>1024字节
#1m=>1000000字节
#1mb=>1024*1024字节
#1g=>1000000000字节
#1gb=>1024*1024*1024字节
#单位不区分大小写，因此1GB 1GB 1GB都相同。
##################################INCLUDES包括###################################
#在此处包含一个或多个其他配置文件。如果您有一个适用于所有Redis服务器的标准模板，但还需要自定义一些每台服务器的设置，那么这很有用。Include文件可以包含其他文件，因此请明智地使用此选项。
#注意:选项“include”不会被admin或Redis Sentinel的命令“CONFIG REWRITE”重写。由于Redis总是使用最后处理的行作为配置指令的值，因此您最好将includes放在该文件的开头，以避免在运行时覆盖配置更改。
#如果您对使用include覆盖配置选项感兴趣，最好使用include作为最后一行。
#include /path/to/local.conf
#include /path/to/other.conf
##################################MODULES模块#####################################
#启动时加载模块。如果服务器无法加载模块，它将中止。可以使用多个loadmodule指令。
#loadmodule /path/to/my_module.so
#loadmodule /path/to/other_module.so
##################################NETWORK网络#####################################
#默认情况下，如果未指定“绑定”配置指令，Redis将侦听主机上所有可用网络接口的连接。可以使用“绑定”配置指令，后跟一个或多个IP地址，只监听一个或更多个选定的接口。每个地址都可以加上前缀“-”，这意味着如果地址不可用，redis将不会无法启动。不可用仅指与任何网络接口不对应的地址。已在使用的地址将始终失败，不支持的协议将始终被忽略。
#示例:
#bind 192.168.1.100 10.0.0.1 #侦听两个特定的IPv4地址
#bind 127.0.0.1 ::1 #侦听环回IPv4和IPv6
#bind *-::* #与默认值一样，所有可用接口
#~~~警告~~~如果运行Redis的计算机直接暴露在互联网上，绑定到所有接口都是危险的，并且会将实例暴露给互联网上的所有人。因此，默认情况下，我们取消注释以下bind指令，这将强制Redis仅侦听IPv4和IPv6（如果可用）环回接口地址（这意味着Redis只能接受来自运行它的同一主机的客户端连接）。
#如果您确定希望实例侦听所有接口，只需注释掉以下行。
#bind 127.0.0.1 -::1
#保护模式是一层安全保护，以避免在互联网上打开的Redis实例被访问和利用。
#当保护模式打开时，如果:1）服务器未使用“bind”指令显式绑定到一组地址。2）未配置密码。则服务器仅接受来自IPv4和IPv6环回地址127.0.0.1和::1以及Unix域套接字的客户端连接。
#默认情况下，已启用保护模式。只有当您确定希望来自其他主机的客户端连接到Redis时，才应该禁用它，即使未配置身份验证，也没有使用“bind”指令显式列出一组特定的接口。
protected-mode no
#接受指定端口上的连接，默认值为6379（IANA#815344）。
#如果指定端口0，Redis将不会侦听TCP套接字。
port 6379
#TCP列表（）积压。
#在每秒请求数高的环境中，您需要大量的积压工作，以避免客户端连接速度慢的问题。注意，Linux内核会自动将其截断为/proc/sys/net/core/somaxconn的值，因此请确保同时提高somaxconn和tcp_max_syn_backlog的值，以获得所需的效果。
tcp-backlog 511
#Unix套接字。
#指定将用于侦听传入连接的Unix套接字的路径。没有默认设置，因此如果未指定，Redis将不会在unix套接字上侦听。
#unixsocket /run/redis.sock
#unixsocketterm 700
#客户端空闲N秒后关闭连接（0表示禁用）
timeout 0
#TCP保持活动。
#如果非零，则使用SO_KEEPALIVE在没有通信的情况下向客户端发送TCP ACK。这有两个原因:
#1）检测死对等体。
#2）强制中间的网络设备考虑连接处于活动状态。
#在Linux上，指定的值（以秒为单位）是用于发送ACK的时间段。
#请注意，要关闭连接，需要双倍的时间。
#在其他内核上，周期取决于内核配置。
#此选项的合理值为300秒，这是从Redis 3.2.1开始的新Redis默认值。
tcp-keepalive 300
#################################TLS/SSL#####################################
#默认情况下，TLS/SSL被禁用。要启用它，可以使用“tls-port”配置指令来定义tls侦听端口。要在默认端口上启用TLS，请使用:
#port 0
#tls-port 6379
#配置X.509证书和私钥，用于向连接的客户端、主机或群集对等方验证服务器。这些文件应为PEM格式。
#tls-cert-file redis.crt
#tls-key-file redis.key
#如果密钥文件是使用密码短语加密的，那么它也可以包含在这里。
#tls-key-file-pass secret
#通常，Redis对服务器功能（接受连接）和客户端功能（从主机复制、建立集群总线连接等）使用相同的证书。
#有时颁发的证书具有将其指定为仅客户端证书或仅服务器证书的属性。在这种情况下，可能需要为传入（服务器）和传出（客户端）连接使用不同的证书。为此，请使用以下指令:
#tls-client-cert-file client.crt
#tls-client-key-file client.key
#如果密钥文件是使用密码短语加密的，那么它也可以包含在这里。
#tls-client-key-file-pass secret
#配置DH参数文件以启用旧版本OpenSSL（<3.0）所需的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群集总线使用普通TCP连接。要为总线协议启用TLS，请使用以下指令:
#tls-cluster yes
#默认情况下，仅启用TLSv1.2和TLSv1.3，强烈建议禁用正式弃用的旧版本，以减少攻击面。
#您可以明确指定要支持的TLS版本。允许的值不区分大小写，包括“TLSv1”、“TLSv1.1”、“TLCv1.2”、“TLS v1.3”（OpenSSL>=1.1.1）或任何组合。
#要仅启用TLSv1.2和TLSv1.3，请使用:
#tls-protocols "TLSv1.2 TLSv1.3"
#配置允许的密码。有关此字符串语法的更多信息，请参阅密码（1ssl）手册页。
#注意:此配置仅适用于<=TLSv1.2。
#tls-ciphers DEFAULT:!MEDIUM
#配置允许的TLSv1.3密码套件。有关此字符串语法的更多信息，特别是TLSv1.3密码套件，请参阅密码（1ssl）手册页。
#tls-ciphersuites TLS_CHACHA20_POLY1305_SHA256
#选择密码时，请使用服务器的首选项，而不是客户端的首选项。默认情况下，服务器遵循客户端的首选项。
#tls-prefer-server-ciphers yes
#默认情况下，启用TLS会话缓存以允许支持TLS会话缓存的客户端进行更快、更便宜的重新连接。请使用以下指令禁用缓存。
#tls-session-caching no
#更改缓存的默认TLS会话数。零值将缓存设置为无限大小。默认大小为20480。
#tls-session-cache-size 5000
#更改缓存TLS会话的默认超时。默认超时为300秒。
#tls-session-cache-timeout 60
#################################GENERAL总则#####################################
#默认情况下，Redis不作为守护程序运行。如果需要，请使用“yes”。
#注意，当守护进程化时，Redis将在/var/run/Redis.pid中写入一个pid文件。
#当Redis由upstart或systemd管理时，此参数没有影响。
daemonize no
#如果您从upstart或systemd运行Redis，Redis可以与您的监督树交互。选项:
#supervised no -无监督交互
#supervised upstart -通过将Redis置于SIGSTOP模式来发出upstart信号，需要在upstart作业配置中使用“expectstop”
#supervised systemd -通过在启动时将READY=1写入$NOTIFY_SOCKET，并定期更新Redis状态来通知systemd。
#supervised auto -基于upstart_JOB或NOTIFY_SOCKET环境变量检测upstart或systemd方法
#注意:这些监督方法仅表示“过程准备就绪”。它们不允许向您的监督者进行连续ping。
#默认值为“否”。要在upstart/systemd下运行，只需取消注释以下行:
#supervised auto
#如果指定了pid文件，Redis会在启动时将其写入指定的位置，并在退出时将其删除。
#当服务器运行非后台进程时，如果配置中未指定任何pid文件，则不会创建任何pid文件。当服务器被后台处理时，即使未指定，也会使用pid文件，默认为“/var/run/redis.pid”。
#创建一个pid文件是最好的结果:如果Redis无法创建它，那么不会发生任何错误，服务器将正常启动和运行。
#注意，在现代Linux系统上，“/run/redis.pid”更符合要求，应改用。
pidfile /var/run/redis_6379.pid
#指定服务器详细级别。这可以是以下之一:
#debug（大量信息，对开发/测试有用）
#verbose（许多不怎么有用的信息，但不像调试级别那样混乱）
#notice（适度详细，您可能希望在生产中使用什么）
#warning（仅记录非常重要/关键的消息）
loglevel notice
#指定日志文件名。空字符串也可以用于强制Redis登录标准输出。注意，如果您使用标准输出进行日志记录，但使用后台进程，则日志将被发送到/dev/null
logfile ""
#要启用系统日志记录，只需将“syslog enabled”设置为yes，然后根据需要更新其他syslog参数。
#syslog-enabled no
#指定syslog标识。
#syslog-ident redis
#指定syslog工具。必须是USER或介于LOCAL0-LOCAL7之间。
#syslog-facility local0
#要禁用内置的崩溃日志（这可能会在需要时生成更干净的内核转储），请取消注释以下内容:
#crash-log-enabled no
#要禁用作为崩溃日志一部分运行的快速内存检查（这可能会让redis更快终止），请取消注释以下内容:
#crash-memcheck-enabled no
#设置数据库的数量。默认数据库是DB 0，您可以使用select＜dbid＞根据每个连接选择不同的数据库，其中dbid是介于0和“databases”-1之间的数字
databases 16
#默认情况下，只有在开始登录到标准输出时，如果标准输出是TTY并且禁用了syslog日志记录，Redis才会显示ASCII艺术logo。基本上，这意味着通常只在交互式会话中显示logo。
#但是，通过将以下选项设置为yes，可以强制执行4.0之前的行为，并始终在启动日志中显示ASCII艺术logo。
always-show-logo no
#默认情况下，Redis修改进程标题（如“top”和“ps”中所示）以提供一些运行时信息。通过将以下设置为“否”，可以禁用此功能并保留进程名称。
set-proc-title yes
#在更改流程标题时，Redis使用以下模板构造修改后的标题。
#模板变量在大括号中指定。支持以下变量:
# {title} 父进程执行的进程的名称，或子进程的类型。
# {listen-addr} 绑定地址或“*”，后跟TCP或TLS端口侦听，或Unix套接字（如果只有可用的话）。
# {server-mode} 特殊模式，即"[sentinel]" or "[cluster]"（“[哨兵]”或“[集群]”）。
# {port} TCP端口正在侦听，或0
# {tls-port} tls端口正在侦听，或0
# {unixsocket} Unix域套接字正在侦听，或“”。
# {config-file} 使用的配置文件的名称。
proc-title-template "{title} {listen-addr} {server-mode}"
################################SNAPSHOTTING拍摄快照################################
#将数据库保存到磁盘。
#保存＜秒＞＜更改＞
#如果给定的秒数和给定的对数据库的写入操作次数都发生，Redis将保存数据库。
#可以使用单个空字符串参数完全禁用快照，如下例所示:
#save ""
#除非另有规定，否则默认情况下Redis将保存数据库:
#*在3600秒（一小时）后，如果至少更换了一个按键
#*在300秒（5分钟）后，如果至少更换了100个按键
#*在60秒后，如果至少更换了10000个按键
#可以通过取消注释以下三行来显式设置这些值。
#save 3600 1
#save 300 100
#save 60 10000
#默认情况下，如果启用了RDB快照（至少一个保存点）并且最近的后台保存失败，Redis将停止接受写入。
#这会让用户意识到（以一种强硬的方式）数据没有正确地保存在磁盘上，否则很可能没有人注意到，会发生一些灾难。
#如果后台保存过程再次开始工作，Redis将自动允许再次写入。
#但是，如果您已经设置了对Redis服务器和持久性的正确监控，则可能需要禁用此功能，以便即使磁盘、权限等出现问题，Redis仍能照常工作。
stop-writes-on-bgsave-error yes
#转储.rdb数据库时使用LZF压缩字符串对象？
#默认情况下，压缩是启用的，因为它几乎总是成功的。
#如果您想在保存子项中保存一些CPU，请将其设置为“否”，但如果您有可压缩的值或键，则数据集可能会更大。
rdbcompression yes
#由于RDB的版本5，CRC64校验和放在文件末尾。
#这使得格式更耐损坏，但在保存和加载RDB文件时，性能会受到影响（约10%），因此您可以禁用它以获得最大性能。
#在禁用校验和的情况下创建的RDB文件的校验和为零，这将告诉加载代码跳过检查。
rdbchecksum yes
#在加载RDB或RESTORE负载时，启用或禁用ziplist和listpack等的完整环境检查。这减少了稍后处理命令时断言或崩溃的机会。
#选项:
#no -切勿进行完整环境检查
#yes -始终执行完整环境检查
#clients -仅对用户连接执行完整环境检查。不包括：RDB文件、从主连接接收的RESTORE命令以及具有跳过清理负载ACL标志的客户端连接。
#默认值应为“clients”，但由于它当前影响通过MIGRATE进行的集群重新分发，因此默认情况下临时设置为“no”。
#sanitize-dump-payload no
#转储DB的文件名
dbfilename dump.rdb
#在未启用持久性的实例中删除复制使用的RDB文件。默认情况下，此选项处于禁用状态，但在某些环境中，出于法规或其他安全考虑，应尽快删除主控器保留在磁盘上的RDB文件，以便为副本提供数据，或按副本存储在磁盘上，以便为初始同步加载这些文件。请注意，此选项仅适用于同时禁用AOF和RDB持久性的实例，否则将被完全忽略。
#获得相同效果的另一种（有时更好）方法是在主实例和副本实例上使用无盘复制。然而，在从库的情况下，无磁盘并不总是一种选择。
rdb-del-sync-files no
#工作目录。
#DB将写入此目录中，文件名在上面使用“dbfilename”配置指令指定。
#仅附加文件也将在此目录中创建。
#请注意，必须在此处指定目录，而不是文件名。
dir ./
#################################REPLICATION复制#################################
#主从复制。使用replicaof使Redis实例成为另一个Redis服务器的从库。尽快了解有关Redis复制的一些事情。
# +------------------+ +---------------+
# | Master | ---> | Replica |
# | (receive writes) | | (exact copy) |
# +------------------+ +---------------+
#1）Redis复制是异步的，但如果主机似乎未连接到至少给定数量的从库，则可以配置主机停止接受写入。
#2）如果复制链路丢失的时间相对较短，则Redis从库能够与主服务器执行部分重新同步。您可能希望根据您的需要，使用合理的值来配置复制积压大小（请参阅本文件的下一节）。
#3）复制是自动的，不需要用户干预。在网络分区后，从库会自动尝试重新连接到主机并与它们重新同步。
#replicaof <masterip> <masterport>
#如果主机受密码保护（使用下面的“requirepass”配置指令），则可以在启动复制同步过程之前告知从库进行身份验证，否则主机将拒绝从库请求。
#masterauth <master-password>
#但是，如果您使用的是Redis ACL（适用于Redis版本6或更高版本），并且默认用户无法运行PSYNC命令和/或复制所需的其他命令，则这是不够的。在这种情况下，最好配置一个用于复制的特殊用户，并指定主用户配置如下:
#masteruser <username>
#当指定了masteruser时，从库将使用新的AUTH形式对其主机进行身份验证:AUTH＜username＞＜password＞。
#当从库失去与主机的连接时，或者当复制仍在进行时，从库可以以两种不同的方式操作:
#1）如果replica-serve-stale-data设置为“yes”（默认值），则从库仍将回复客户端请求，可能会使用过期数据，或者如果这是第一次同步，则数据集可能为空。
#2）如果replica-serve-stale-data设置为“no”，则从库将对除以下命令外的所有命令回复错误“SYNC with master in progress”:INFO、REPLICATION、AUTH、PING、SHUTDOWN、REPLCONF、ROLE、CONFIG、SUBSCRIBE、UNSUBSCRIBE，PSUBSCRIBB、PUNSUBSCRIBE、PUNSUB、COMMAND、POST、HOST和LATENCY。
replica-serve-stale-data yes
#您可以将从库实例配置为接受或不接受写入。对从库实例进行写操作可能有助于存储一些临时数据（因为在与主库重新同步后，写入从库上的数据将很容易被删除），但如果客户端由于配置错误而写入从库，也可能会导致问题。
#从Redis 2.6默认情况下从库是只读的。
#注意:只读从库的设计不会暴露给internet上不受信任的客户端。它只是一个防止误用实例的保护层。
#默认情况下，只读从库仍会导出所有管理命令，如CONFIG、DEBUG等。在一定程度上，您可以使用“rename-command”来隐藏所有管理/危险命令，从而提高只读从库的安全性。
replica-read-only yes
#复制SYNC策略:磁盘或套接字。
#新的从库和重新连接的从库无法继续复制过程，只是接收到差异，需要执行所谓的“完全同步”。RDB文件从主机传输到从库。
#传输可以通过两种不同的方式进行:
#1）磁盘备份:Redis主机创建一个新进程，将RDB文件写入磁盘。稍后，文件由父进程以增量方式传输到从库。
#2）无磁盘:Redis主机创建了一个新的进程，该进程直接将RDB文件写入从库套接字，而根本不接触磁盘。
#通过磁盘备份复制，在生成RDB文件时，只要生成RDB的当前子级完成其工作，就可以将更多从库排队并与RDB文件一起使用。使用无盘复制，一旦传输开始，到达的新从库将被排队，并且新的传输将在当前传输终止时开始。
#当使用无盘复制时，主机在开始传输之前等待一段可配置的时间（以秒为单位），希望多个从库能够到达并并行传输。
#使用慢速磁盘和快速（大带宽）网络，无盘复制工作得更好。
repl-diskless-sync no
#当启用无盘复制时，可以配置服务器等待的延迟，以便生成通过套接字将RDB传输到从库的子级。
#这一点很重要，因为一旦传输开始，就不可能为到达的新从库提供服务，这些从库将排队等待下一次RDB传输，因此服务器会等待一段时间，以便让更多从库到达。
#延迟以秒为单位指定，默认情况下为5秒。要完全禁用它，只需将其设置为0秒，传输将尽快开始。
repl-diskless-sync-delay 5
# -----------------------------------------------------------------------------
#警告:RDB无盘加载是实验性的。由于在这种设置中，从库不会立即将RDB存储在磁盘上，因此在故障切换期间可能会导致数据丢失。RDB无盘加载+不处理I/O读取的Redis模块也可能导致Redis在与主机的初始同步阶段发生I/O错误时中止。只有当你知道自己在做什么时才使用。
# -----------------------------------------------------------------------------
#从库可以直接从套接字加载它从复制链接读取的RDB，或者将RDB存储到一个文件中，并在从主服务器完全接收到该文件后读取该文件。
#在许多情况下，磁盘比网络慢，存储和加载RDB文件可能会增加复制时间（甚至会增加主磁盘的“写时拷贝”内存和备用缓冲区）。
#然而，直接从套接字解析RDB文件可能意味着我们必须在收到完整的RDB之前刷新当前数据库的内容。因此，我们有以下选项:
#“disabled” -不使用无盘加载（先将rdb文件存储到磁盘）
#“on-empty-db” -仅在完全安全时使用无盘加载。
#“swapdb” -在直接从套接字解析数据时，在RAM中保留当前db内容的从库。请注意，这需要足够的内存，如果没有内存，则可能会导致OOM死亡。
repl-diskless-load disabled
#从库以预定义的间隔向服务器发送PING。可以使用repl_ping_replica_period选项更改此间隔。默认值为10秒。
#repl-ping-replica-period 10
#以下选项设置的复制超时:
#1）从库的角度来看，SYNC期间的批量传输I/O。
#2）从库（数据、ping）的角度来看，主超时。
#3）主库的角度来看，从库超时（REPLCONF ACK ping）。
#务必确保该值大于为replping复制周期指定的值，否则每次主服务器和从库之间的通信量低时都会检测到超时。默认值为60秒。
#repl-timeout 60
#在SYNC之后禁用复制套接字上的TCP_NODELAY？
#如果选择“yes”，Redis将使用更少的TCP数据包和更少的带宽向从库发送数据。但这可能会增加数据出现在从库端的延迟，对于使用默认配置的Linux内核，延迟可达40毫秒。
#如果选择“no”，数据出现在从库侧的延迟将减少，但复制将使用更多的带宽。
#默认情况下，我们针对低延迟进行优化，但在非常高的流量条件下，或者当主服务器和从库相隔很远时，将此设置为“yes”可能是一个好主意。
repl-disable-tcp-nodelay no
#设置复制积压工作的大小。backlog是一个缓冲区，当从库断开连接一段时间时，它会累积副本数据，因此当从库想要再次连接时，通常不需要完全重新同步，但部分重新同步就足够了，只需传递断开连接时从库丢失的部分数据。
#复制积压量越大，从库可以承受断开连接的时间就越长，以后可以执行部分重新同步。
#只有在至少连接了一个从库时，才会分配积压工作。
#repl-backlog-size 1mb
#主服务器在一段时间内没有连接的从库后，积压工作将被释放。以下选项配置释放积压缓冲区所需的秒数，从上一个从库断开连接开始。
#请注意，从库永远不会释放积压工作以等待超时，因为它们可能会在以后升级为主从库，并且应该能够正确地与其他从库“部分重新同步”:因此它们应该始终累积积压工作。
#值为0表示从不释放积压工作。
#repl-backlog-ttl 3600
#从库优先级是Redis在INFO输出中发布的整数。Redis Sentinel使用它来选择一个从库，如果主库不再正常工作，则将其升级为主库。
#优先级低的从库被认为更适合升级，因此，例如，如果有三个优先级为10、100、25的从库，Sentinel将选择优先级为10的从库，即最低的从库。
#但是，特殊优先级为0的从库将无法执行主从库的角色，因此Redis Sentinel永远不会选择优先级为0从库进行升级。
#默认情况下，优先级为100。
replica-priority 100
# -----------------------------------------------------------------------------
#默认情况下，Redis Sentinel在其报告中包含所有从库。从库可以从Redis Sentinel的公告中排除。“sentinel replica<master>”命令将忽略未通知的从库，并且不会向Redis sentinel的客户端公开。
#此选项不会更改从库优先级的行为。即使从库已宣布设置为“否”，从库也可以升级为主库。要防止此行为，请将从库优先级设置为0。
#replica-announced yes
#如果连接的从库少于N个，且延迟小于或等于M秒，则主机可以停止接受写入。
#N个从库需要处于“online”状态。
#延迟（以秒为单位，<=指定值）是根据由从库接收的最后一次ping（通常每秒发送一次）计算得出的。
#此选项不能保证N个从库将接受写入，但会在没有足够的从库可用时将丢失写入的暴露窗口限制在指定的秒数内。
#例如，如果需要至少3个延迟<=10秒的从库，请使用:
#min-replicas-to-write 3
#min-replicas-max-lag 10
#将其中一个或另一个设置为0将禁用该功能。
#默认情况下，要写入的最小从库设置为0（禁用功能），最小从库最大延迟设置为10。
#Redis主机能够以不同的方式列出附加从库的地址和端口。例如，“INFO复制”部分提供了这些信息，Redis Sentinel在其他工具中使用这些信息来发现从库实例。
#该信息的另一个可用位置是主控器的“ROLE”命令的输出。
#从库通常报告的列出的IP地址和端口通过以下方式获得:
#IP:通过检查从库用于连接到主机的套接字的对等地址，自动检测地址。
#Port:该端口在复制握手期间由从库通信，通常是从库用于侦听连接的端口。
#然而，当使用端口转发或网络地址转换（NAT）时，从库实际上可以通过不同的IP和端口对访问。从库可以使用以下两个选项，以便向其主机报告一组特定的IP和端口，以便INFO和ROLE都报告这些值。
#如果只需要覆盖端口或IP地址，则不需要同时使用这两个选项。
#replica-announce-ip 5.5.5.5
#replica-announce-port 1234
###############################KEYS TRACKING密钥跟踪#################################
#Redis实现了对客户端缓存值的服务器辅助支持。这是使用一个无效表来实现的，该表使用按密钥名称索引的基数密钥来记住客户端拥有哪些密钥。反过来，这用于向客户端发送无效消息。请查看此页面以了解有关该功能的更多信息： https://redis.io/topics/client-side-caching
#当为客户端启用跟踪时，假设所有只读查询都被缓存：这将迫使Redis将信息存储在无效表中。当修改密钥时，这些信息将被清除，并向客户端发送无效消息。然而，如果工作负载主要由读取控制，Redis可以使用越来越多的内存来跟踪许多客户端获取的密钥。
#因此，可以为无效表配置最大填充值。默认情况下，它被设置为1M个键，一旦达到此限制，Redis将开始驱逐无效表中的键，即使它们没有被修改，只是为了回收内存：这反过来会迫使客户端使缓存的值无效。基本上，表的最大大小是在服务器端跟踪谁缓存了什么信息所需的内存与客户端在内存中保留缓存对象的能力之间的权衡。
#如果将该值设置为0，则意味着没有限制，Redis将在无效表中保留所需数量的键。
#在“stats”INFO部分中，您可以在每个给定时刻找到关于无效表中键数的信息。
#注意：当在广播模式下使用密钥跟踪时，服务器端不使用内存，因此此设置无效。
#tracking-table-max-keys 1000000
##################################SECURITY安全###################################
#警告:由于Redis速度非常快，外部用户可以在现代盒子上每秒尝试多达100万个密码。这意味着你应该使用非常强的密码，否则它们很容易被破解。
#请注意，由于密码实际上是客户端和服务器之间的共享秘密，任何人都不应该记住，因此密码可以很容易地是/dev/urandom或其他任何形式的长字符串，因此通过使用长且不可使用的密码，就不可能进行暴力攻击。
#Redis ACL用户的定义格式如下:
#user <username> ... acl rules ...
#例如:
#user worker +@list +@connection ~jobs:* on >ffa9203c493aa99
#特殊用户名“default”用于新连接。如果此用户具有“nopass”规则，则新连接将立即作为“默认”用户进行身份验证，而无需通过AUTH命令提供任何密码。否则，如果“默认”用户未标记为“nopass”，则连接将以未经身份验证的状态启动，并且需要AUTH（或HELLO命令AUTH选项）才能进行身份验证并开始工作。
#描述用户可以做什么的ACL规则如下:
# on 可以作为此用户进行身份验证
# off 不再可能与该用户进行身份验证，但是已经通过身份验证的连接仍然有效。
# skip-sanitize-payload 已跳过RESTORE转储负载环境。
# sanitize-payload RESTORE转储负载已清理（默认）。
# +<command> 允许执行该命令
# -<command> 不允许执行该命令
# +@<category> 允许执行此类类别中所有具有有效类别的命令，例如@admin、@set、@sortedset。。。等等，请参阅server.c文件中描述和定义Redis命令表的完整列表。特殊类别@all表示所有命令，但当前存在于服务器中，将来将通过模块加载。
# +<command>|subcommand 允许使用其他禁用命令的特定子命令。请注意，此表单不允许像-DEBUG|SEGFAULT那样为负数，而只能是以“+”开头的加法。
# allcommands +@all的别名。注意，这意味着能够执行通过模块系统加载的所有未来命令。
# nocommands -@all的别名
# ~<pattern> 添加可以作为命令的一部分提及的按键模式。例如，~*允许所有键。该模式是一个类似于KEYS的glob样式的模式。可以指定多个模式。
# allkeys ~*的别名
# resetkeys 刷新允许的密钥模式列表。
# &<pattern> 添加用户可以访问的Pub/Sub频道的glob样式模式。可以指定多个通道模式。
# allchannels &*的别名
# resetchannels 刷新允许的频道模式列表。
# ><password> 将此密码添加到用户的有效密码列表中。例如，>mypass将向列表中添加“mypass”。此指令清除“nopass”标志（请参阅下文）。
# <<password> 从有效密码列表中删除此密码。
# nopass 删除用户的所有设置密码，并将用户标记为不需要密码:这意味着每个密码都将对该用户有效。如果此指令用于默认用户，则每个新连接都将立即与默认用户进行身份验证，而不需要任何显式AUTH命令。请注意，“resetpass”指令将清除此条件。
# resetpass 刷新允许的密码列表。此外，还将删除“nopass”状态。“resetpass”后，用户没有关联的密码，如果不添加密码（或稍后将其设置为“nopass”），则无法进行身份验证。
# reset P执行以下操作: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
#ACL日志
#ACL日志跟踪与ACL关联的失败命令和身份验证事件。ACL日志对于排除ACL阻止的失败命令非常有用。ACL日志存储在内存中。您可以使用ACL日志重置来回收内存。在下面定义ACL日志的最大条目长度。
acllog-max-len 128
#使用外部ACL文件
#不必在此文件中配置用户，可以使用仅列出用户的独立文件。这两种方法不能混用:如果在这里配置用户，同时激活外部ACL文件，服务器将拒绝启动。
#外部ACL用户文件的格式与redis.conf内部用于描述用户的格式完全相同。
#aclfile/etc/redis/users.acl
#重要提示:从Redis 6开始，“requirepass”只是新ACL系统之上的一个兼容性层。选项的效果将只是为默认用户设置密码。客户端仍然会像往常一样使用AUTH＜password＞进行身份验证，或者如果遵循新协议，则更明确地使用AUTH默认＜password＞:两者都可以工作。
#requirepas与aclfile选项和ACL LOAD命令不兼容，这将导致requirepas被忽略。
#requirepass foobared
#默认情况下，新用户使用限制性权限进行初始化，方法与此ACL规则“off resetkeys”等效-@all'. 从Redis 6.2开始，还可以使用ACL规则管理对Pub/Sub频道的访问。如果新用户受acl pubsub默认配置指令控制，则默认的Pub/Sub频道权限，该指令接受以下值之一:
#allchannels:授予对所有Pub/Sub频道的访问权resetchchannels；取消对所有Pub/Sub频道的访问
#为了在升级Redis 6.0时确保向后兼容，acl pubsub默认设置为“allchannels”权限。
#未来兼容性说明:在未来版本的Redis中，很可能会将指令的默认值“allchannels”更改为“resetchannels”，以提供更好的开箱即用Pub/Sub安全性。因此，建议您为所有用户显式定义Pub/Sub权限，而不是依赖隐式默认值。为所有现有用户设置了显式Pub/Sub后，应取消注释以下行。
#acl-pubsub-default resetchannels
#命令重命名（已弃用）。
# ------------------------------------------------------------------------
#警告:如果可能，请避免使用此选项。相反，使用ACL从默认用户中删除命令，并仅将它们放在您为管理目的创建的某些管理员用户中。
# ------------------------------------------------------------------------
#可以在共享环境中更改危险命令的名称。例如，CONFIG命令可能会被重命名为难以猜测的内容，因此它仍然可用于内部使用工具，但不可用于一般客户端。
#示例:
#rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52
#也可以通过将命令重命名为空字符串来完全终止命令:
#rename-command CONFIG ""
#请注意，更改登录到AOF文件或传输到副本的命令的名称可能会导致问题。
###################################CLIENTS客户####################################
#设置同时连接的最大客户端数。默认情况下，此限制设置为10000个客户端，但是如果Redis服务器无法将进程文件限制配置为允许指定的限制，则允许的最大客户端数设置为当前文件限制减去32（因为Redis保留了一些文件描述符供内部使用）。
#一旦达到限制，Redis将关闭所有新连接，并发送错误“已达到的最大客户端数”。
#重要事项:使用Redis群集时，最大连接数也与群集总线共享:群集中的每个节点都将使用两个连接，一个传入，另一个传出。在非常大的簇的情况下，必须相应地调整限制大小。
#maxclients 10000
##############################MEMORY MANAGEMENT存储器管理################################
#将内存使用限制设置为指定的字节数。
#当达到内存限制时，Redis将尝试根据所选的逐出策略删除密钥（请参阅maxmemory策略）。
#如果Redis无法根据策略删除密钥，或者如果策略设置为“noevision”，则Redis将开始对使用更多内存的命令（如set、LPUSH等）进行错误回复，并继续对GET等只读命令进行回复。
#当使用Redis作为LRU或LFU缓存，或为实例设置硬内存限制（使用“noevision”策略）时，此选项通常很有用。
#警告:如果将副本附加到启用了maxmemory的实例，则将从已用内存计数中减去馈送副本所需的输出缓冲区的大小，这样网络问题/重新同步将不会触发密钥被逐出的循环，反过来，副本的输出缓冲区时满了被逐出的密钥的DEL，从而触发删除更多密钥，等等，直到数据库被完全清空。
#简而言之。。。如果附加了副本，建议您设置maxmemory的下限，以便系统上有一些可用的RAM用于副本输出缓冲区（但如果策略为“noevision”，则不需要这样做）。
#maxmemory <bytes>
#最大内存策略:当达到最大内存时，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和易失性ttl都使用近似随机化算法实现。
#注意:使用上述任何策略，当没有合适的键用于驱逐时，Redis将在需要更多内存的写操作时返回错误。这些命令通常用于创建新键、添加数据或修改现有键。几个示例是:SET、INCR、HSET、LPUSH、SUNIONSTORE、SORT（由于STORE参数）和EXEC（如果事务包含任何需要内存的命令）。
#默认值为:
#maxmemory-policy noeviction
#LRU、LFU和最小TTL算法不是精确算法，而是近似算法（为了节省内存），因此您可以调整其速度或精度。默认情况下，Redis将检查五个键并选择最近使用最少的键，您可以使用以下配置指令更改样本大小。
#默认值为5会产生足够好的结果。10非常接近真实的LRU，但需要更多的CPU。3的速度更快，但不是很准确。
#maxmemory-samples 5
#驱逐处理在默认设置下运行良好。如果写入流量异常大，则可能需要增加此值。降低该值可能会降低延迟，从而降低处理效率0=最小延迟，10=默认值，100=不考虑延迟的过程
#maxmemory-eviction-tenacity 10
#从Redis 5开始，默认情况下，副本将忽略其最大内存设置（除非在故障切换后或手动将其升级为主副本）。这意味着密钥的逐出将只由主机处理，当密钥在主机端逐出时，向副本发送DEL命令。
#此行为可确保主副本和副本保持一致，并且通常是您想要的，但是，如果您的副本是可写的，或者您希望副本具有不同的内存设置，并且您确定对副本执行的所有写入都是幂等的，那么您可以更改此默认值（但请确保了解您正在执行的操作）。
#请注意，由于副本默认情况下不会退出，因此它可能会使用比通过maxmemory设置的内存更多的内存（副本上的某些缓冲区可能更大，或者数据结构有时会占用更多内存等等）。因此，请确保您监视副本，并确保它们有足够的内存，在主机达到配置的最大内存设置之前，不会出现真正的内存不足情况。
#replica-ignore-maxmemory yes
#Redis以两种方式回收过期的密钥:在访问时发现这些密钥已过期，以及在后台回收，即所谓的“活动过期密钥”。对密钥空间进行缓慢且交互式的扫描，以查找要回收的过期密钥，这样就可以释放内存中过期且在短时间内无法再次访问的密钥。
#过期周期的默认工作将尽量避免超过10%的过期密钥仍在内存中，并尽量避免消耗超过总内存的25%，并增加系统延迟。但是，可以将通常设置为“1”的过期“工作量”增加到更大的值，最大值为“10”。在其最大值时，系统将使用更多的CPU、更长的周期（从技术上讲，可能会引入更多的延迟），并且将容忍系统中仍然存在的更少的已过期密钥。这是内存、CPU和延迟之间的权衡。
#active-expire-effort 1
#############################LAZY FREEING惰性释放####################################
#Redis有两个基元来删除键。一种叫做DEL，是对对象的阻止删除。这意味着服务器停止处理新命令，以便以同步方式回收与对象相关联的所有内存。如果删除的键与一个小对象关联，则执行DEL命令所需的时间非常短，与Redis中的大多数其他O（1）或O（log_N）命令相当。但是，如果密钥与包含数百万个元素的聚合值相关联，则服务器可以阻塞很长时间（甚至几秒）以完成操作。
#出于上述原因，Redis还提供非阻塞删除原语，如UNLINK（非阻塞DEL）和FLUSHOLL和FLUSHDB命令的ASYNC选项，以回收后台内存。这些命令在恒定时间内执行。另一个线程将以尽可能快的速度递增释放背景中的对象。
#FLUSHOLL和FLUSHDB的DEL、UNLINK和ASYNC选项由用户控制。这取决于应用程序的设计，以了解何时使用其中之一是一个好主意。然而，作为其他操作的副作用，Redis服务器有时不得不删除密钥或刷新整个数据库。
#具体来说，在以下情况下，Redis独立于用户调用删除对象:
#1）在驱逐时，由于maxmemory和maxmemory策略配置，以便在不超过指定内存限制的情况下为新数据腾出空间。
#2）由于过期:必须从内存中删除具有相关生存时间的密钥（请参阅expire命令）。
#3）由于在可能已经存在的密钥上存储数据的命令的副作用。例如，RENAME命令可以在替换为另一个密钥内容时删除旧密钥内容。类似地，SUNIONSTORE或SORT with STORE选项可以删除现有密钥。SET命令本身删除指定键的任何旧内容，以便用指定字符串替换它。
#4）在复制期间，当副本与其主数据库执行完全重新同步时，整个数据库的内容将被删除，以便加载刚刚传输的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
#FLUSHDB、FLUSHOLL和SCRIPT FLUSH支持异步和同步删除，这可以通过将[SYNC|ASYNC]标志传递到命令中来控制。当两个标志都未传递时，此指令将用于确定是否应异步删除数据。
lazyfree-lazy-user-flush no
################################THREADED I/O线程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线程设置为1将照常使用主线程。
#当启用I/O线程时，我们只使用线程进行写操作，即线程执行write（2）系统调用并将客户端缓冲区传输到套接字。但是，也可以使用以下配置指令启用读取线程和协议解析，方法是将其设置为yes:
#io-threads-do-reads no
#通常线程读取没有多大帮助。
#注1:此配置指令不能在运行时通过CONFIG SET更改。Aso此功能当前在启用SSL时不起作用。
#注2:如果您想使用Redis基准测试Redis加速，请确保您也以线程模式运行基准，使用--threads选项匹配Redis线程数，否则您将无法注意到改进。
############################ KERNEL OOM CONTROL内核OOM控制 ##############################
#在Linux上，可以提示内核OOM杀手在内存不足时应该首先杀死哪些进程。
#启用此功能可使Redis根据其角色主动控制其所有进程的oom_score_adj值。默认分数将尝试在所有其他进程之前杀死后台子进程，并在主进程之前杀死副本。
#Redis支持三种选项:
# no: 不要更改oom-score-adj（默认值）。
# yes: “relative”的别名见下文。
# absolute: oom-score-adj-values中的值按原样写入内核。
# relative: 当服务器启动时，相对于oom_score_adj的初始值使用值，然后将其限制在-1000到1000的范围内。因为初始值通常为0，所以它们通常与绝对值匹配。
oom-score-adj no
#当使用oom score adj时，此指令控制用于主进程、副本和后台子进程的特定值。值的范围为-2000到2000（越高意味着越有可能被杀死）。.
#非特权进程（非根进程，且没有CAP_SYS_RESOURCE功能）可以自由增加其值，但不能将其降低到初始设置以下。这意味着将oom-score-adj-values设置为“相对”，并将oom-score-adj-values设置为正值将始终成功。
oom-score-adj-values 0 200 800
####################KERNEL transparent hugepage CONTROL KERNEL透明护肩控制######################
#通常，默认情况下，内核透明巨大页面控件设置为“madvise”或“never”（/sys/kernel/mm/Transparent_hugepage/ennabled），在这种情况下，此配置无效。在将其设置为“总是”的系统上，redis将尝试专门为redis进程禁用它，以避免fork（2）和CoW的延迟问题。
#如果出于某种原因，您希望保持启用状态，可以将此配置设置为“no”，将内核全局设置为“always”。
disable-thp yes
##############################APPEND ONLY MODE仅追加模式###############################
#默认情况下，Redis将数据集异步转储到磁盘上。这种模式在许多应用程序中都足够好，但Redis进程出现问题或断电可能会导致几分钟的写入丢失（取决于配置的保存点）。
#“仅附加文件”是另一种持久性模式，可提供更好的持久性。例如，使用默认的数据fsync策略（见后面的配置文件），在服务器断电等严重事件中，Redis可能只丢失一秒钟的写入，或者如果Redis进程本身发生了问题，但操作系统仍在正常运行，则只会丢失一次写入。
#AOF和RDB持久性可以同时启用而不会出现问题。
#如果启动时启用了AOF，Redis将加载AOF，即具有更好持久性保证的文件。
#请检查https://redis.io/topics/persistence了解更多信息。
appendonly yes
#仅附加文件的名称（默认值:“appendonly.aof”）
appendfilename "appendonly.aof"
#fsync（）调用告诉操作系统在磁盘上实际写入数据，而不是在输出缓冲区中等待更多数据。有些操作系统确实会刷新磁盘上的数据，有些其他操作系统则会尽快尝试刷新。
#Redis支持三种不同的模式:
#no:不要fsync，只要让操作系统在需要时刷新数据即可。更快。
#always:在每次写入仅追加日志后进行fsync。慢，最安全。
#everysec:fsync每秒仅一次。妥协
#默认值是“everysec”，因为这通常是速度和数据安全之间的正确折衷。这取决于您是否可以将此设置放宽为“否”，以便操作系统在需要时刷新输出缓冲区，以获得更好的性能（但如果您能够忍受某些数据丢失的想法，请考虑默认的持久性模式，即快照），或者相反，使用“总是”，这非常慢，但比每秒钟都安全一点。
#更多详情请查看以下文章: 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或BGREWRITEAFF进行时在主进程中调用fsync（）。
#这意味着当另一个孩子正在保存时，Redis的持久性与“appendfsync none”相同。实际上，这意味着在最坏的情况下（使用默认的Linux设置）可能会丢失多达30秒的日志。
#如果您有延迟问题，请选择“是”。否则，从耐久性的角度来看，选择“否”是最安全的。
no-appendfsync-on-rewrite no
#自动重写仅附加文件。当AOF日志大小增长指定的百分比时，Redis能够自动重写隐式调用BGREWRITEEAOF的日志文件。
#这就是它的工作原理:Redis会记住最近一次重写后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设置为yes，则会加载一个被截断的aof文件，并且Redis服务器会开始发出日志通知用户该事件。
#否则，如果该选项设置为“否”，服务器将因错误而中止并拒绝启动。当该选项设置为no时，用户需要在重新启动服务器之前使用“redis check AOF”实用程序修复AOF文件。
#请注意，如果发现AOF文件在中间损坏，服务器仍将退出并返回错误。只有当Redis尝试从AOF文件中读取更多数据，但找不到足够的字节时，此选项才适用。
aof-load-truncated yes
#当重写AOF文件时，Redis能够在AOF文件中使用RDB前导码，以便更快地进行重写和恢复。启用此选项后，重写的AOF文件由两个不同的节组成:
#[RDB file][AOF tail]
#加载时，Redis识别AOF文件以“Redis”字符串开头，并加载前缀RDB文件，然后继续加载AOF尾部。
aof-use-rdb-preamble yes
################################LUA SCRIPTING LUA脚本###############################
#Lua脚本的最大执行时间（毫秒）。
#如果达到了最长执行时间，Redis将记录脚本在最长允许时间后仍在执行，并将开始回复带有错误的查询。
#当长时间运行的脚本超过最大执行时间时，只有script KILL和SHUTDOWN NOSAVE命令可用。第一个可用于停止尚未调用任何写入命令的脚本。第二种方法是在脚本已经发出写入命令但用户不想等待脚本自然终止的情况下关闭服务器的唯一方法。
#将其设置为0或负值，以无警告地无限执行。
lua-time-limit 5000
################################REDIS CLUSTER|| REDIS集群###############################
#正常的Redis实例不能是Redis集群的一部分；只有作为群集节点启动的节点才能。为了将Redis实例作为群集节点启动，启用群集支持取消注释以下内容:
#cluster-enabled yes
#每个群集节点都有一个群集配置文件。此文件不打算手动编辑。它由Redis节点创建和更新。
#每个Redis群集节点都需要不同的群集配置文件。
#确保在同一系统中运行的实例没有重叠的群集配置文件名。
#cluster-config-file nodes-6379.conf
#群集节点超时是节点必须无法访问才能被认为处于故障状态的毫秒数。
#大多数其他内部时间限制是节点超时的倍数。
#cluster-node-timeout 15000
#如果故障主机的数据看起来太旧，则故障主机的副本将避免启动故障切换。
#从库没有一种简单的方法可以准确测量其“数据年限”，因此执行以下两项检查:
#1）如果有多个从库能够进行故障切换，它们会交换消息，以便尝试以最佳复制偏移量（处理了来自主副本的更多数据）为从库提供优势。副本将尝试通过偏移量获取其等级，并在故障切换开始时应用与其等级成比例的延迟
#2）每个副本计算与主副本最后一次交互的时间。这可以是最后一次收到的ping或命令（如果主机仍处于“已连接”状态），也可以是自与主机断开连接后经过的时间（如果复制链路当前已关闭）。如果上一次交互太旧，则从库根本不会尝试故障切换。
#用户可以调整点“2”。特别是，如果自上次与主机交互以来，所用时间大于:
#（节点超时*集群从库有效系数）+从库复制周期
#因此，例如，如果节点超时为30秒，集群从库有效性系数为10，并且假设默认的replping副本周期为10秒，那么如果副本无法与主服务器通信超过310秒，则副本将不会尝试故障切换。
#较大的集群从库有效性系数可能会允许具有太旧数据的副本故障切换到主机，而太小的值可能会阻止群集选择副本。
#为了实现最大可用性，可以将集群从库有效性因子设置为0，这意味着无论副本上次与主机交互的时间如何，都将始终尝试对主机进行故障切换。（然而，他们总是尝试应用与偏移等级成比例的延迟）。
#零是唯一能够保证当所有分区恢复时，集群始终能够继续运行的值。
#cluster-replica-validity-factor 10
#集群从库能够迁移到孤立的主机，即没有工作副本的主机。这提高了群集抵御故障的能力，因为如果没有工作副本，孤立的主机在发生故障时无法进行故障切换。
#从库仅在其旧主机至少还有给定数量的其他工作从库时迁移到孤立主机。这个数字是“迁移障碍”。迁移障碍为1意味着从库只有在其主副本至少有1个其他工作从库时才会迁移，依此类推。它通常反映集群中每个主机所需的副本数量。
#默认值为1（副本仅在其主副本保留至少一个副本时迁移）。要禁用迁移，只需将其设置为非常大的值或将群集允许从库迁移设置为“no”即可。
#可以设置值0，但仅对调试有用，在生产中很危险。
#cluster-migration-barrier 1
#关闭此选项允许使用较少的自动群集配置。它同时禁用向孤立主机的迁移和从变为空的主机的迁移。
#默认值为“yes”（允许自动迁移）。
#cluster-allow-replica-migration yes
#默认情况下，如果Redis群集节点检测到至少有一个哈希槽未覆盖（没有可用节点为其提供服务），则会停止接受查询。
#这样，如果集群部分关闭（例如，不再覆盖一系列哈希槽），则所有集群最终都将不可用。
#一旦再次覆盖所有插槽，它就会自动返回可用状态。
#然而，有时您希望正在工作的集群的子集继续接受对仍然覆盖的部分密钥空间的查询。为此，只需将集群requirefullcoverage选项设置为no。
#集群需要全覆盖是的#此选项设置为“是”时，可防止从库在主机故障时尝试对其主机进行故障切换。但是，如果强制执行此操作，从库仍然可以执行手动故障切换。
#这在不同的情况下非常有用，尤其是在多个数据中心操作的情况下，如果不是在完全DC故障的情况下我们希望一方永远不会升级。
#cluster-replica-no-failover no
#当设置为yes时，该选项允许节点在集群处于关闭状态时提供读取流量，只要它认为自己拥有插槽。
#这对两种情况都很有用。第一种情况是当应用程序在节点故障或网络分区期间不需要数据一致性时。
#其中一个例子是缓存，只要节点拥有数据，它就应该能够为其提供服务。
#第二个用例是不满足推荐的三个碎片但希望稍后启用集群模式和扩展的配置。1或2碎片配置中的主中断会导致整个集群的读/写中断，如果没有设置此选项，则只有写中断。
#如果没有法定数量的主机，插槽所有权将不会自动更改。
#cluster-allow-reads-when-down no
#为了设置集群，请务必阅读以下文档:https://redis.io网站。
##########################CLUSTER DOCKER/NAT support 集群DOCKER/NAT支持########################
#在某些部署中，Redis群集节点地址发现失败，原因是地址被NAT化或端口被转发（典型情况是Docker和其他容器）。
#为了使Redis集群在这样的环境中工作，需要一个静态配置，每个节点都知道自己的公共地址。以下四个选项用于此范围，分别是:
# cluster-announce-ip(集群公告ip)
# cluster-announce-port(群集通告端口)
# cluster-announce-tls-port(集群通告tls端口)
# cluster-announce-bus-port(集群公告总线端口)
#每个节点都会向节点指示其地址、客户端端口（用于不带TLS和带TLS的连接）和集群消息总线端口。然后将信息发布在总线数据包的报头中，以便其他节点能够正确映射发布信息的节点的地址。
#如果集群tls设置为yes，并且集群宣告tls端口被省略或设置为零，那么集群宣告端口引用tls端口。还要注意，如果集群tls设置为no，集群宣告tls端口无效。
#如果不使用上述选项，将改用正常的Redis群集自动检测。
#请注意，重新映射时，总线端口可能不在客户端端口+10000的固定偏移量，因此您可以根据重新映射的方式指定任何端口和总线端口。如果未设置总线端口，将照常使用10000的固定偏移量。
#示例:
# cluster-announce-ip 10.1.1.5
# cluster-announce-tls-port 6379
# cluster-announce-port 0
# cluster-announce-bus-port 6380
##################################SLOW LOG 慢日志###################################
#Redis慢速日志是一种记录超过指定执行时间的查询的系统。执行时间不包括与客户机交谈、发送回复等I/O操作，而只是实际执行命令所需的时间（这是命令执行的唯一阶段，此时线程被阻塞，无法同时处理其他请求）。
#您可以使用两个参数来配置慢日志:一个参数告诉Redis为了记录命令所需的执行时间（以微秒为单位），另一个参数是慢日志的长度。记录新命令时，最旧的命令将从记录命令队列中删除。
#以下时间以微秒表示，因此1000000相当于1秒。请注意，负数将禁用慢速日志，而值为零将强制记录每个命令。
slowlog-log-slower-than 10000
#此长度没有限制。只需注意它会消耗内存。
#您可以使用SLOWLOG RESET回收慢速日志使用的内存。
slowlog-max-len 128
################################LATENCY MONITOR延迟监视器##############################
#Redis延迟监控子系统在运行时对不同的操作进行采样，以收集与Redis实例可能的延迟源相关的数据。
#通过LATENCY命令，用户可以打印图形并获取报告。
#系统仅记录在等于或大于通过延迟监视器阈值配置指令指定的毫秒数的时间内执行的操作。当其值设置为零时，延迟监视器将关闭。
#默认情况下，延迟监控是禁用的，因为如果您没有延迟问题，则通常不需要延迟监控，并且收集数据会对性能产生影响，虽然很小，但可以在大负载下进行测量。如果需要，可以使用命令“CONFIG SET Latency monitor threshold<毫秒>”在运行时轻松启用延迟监控。
slowlog-max-len 128
#############################EVENT NOTIFICATION事件通知##############################
#Redis可以将密钥空间中发生的事件通知Pub/Sub客户端。此功能记录在https://redis.io/topics/notifications
#例如，如果启用了keyspace事件通知，并且客户端对数据库0中存储的键“foo”执行DEL操作，则将通过Pub/Sub发布两条消息:
# PUBLISH __keyspace@0__:foo del
# PUBLISH __keyevent@0__:del foo
#可以从一组类中选择Redis将通知的事件。每个类都由一个字符标识:
# K 密钥空间事件，以__Keyspace@<db>__前缀发布。
# E Keyevent事件，以__Keyevent@<db>__前缀发布。
# g 通用命令（非特定类型），如DEL、EXPIRE、RENAME。。。
# $ SString 命令
# l List 命令
# s Set 命令
# h Hash 命令
# z Sorted set 命令
# x 过期事件（每次密钥过期时生成的事件）
# e 逐出事件（为最大内存逐出密钥时生成的事件）
# t Stream 命令
# d 模块键类型事件
# m 关键未命中事件（注意:它不包括在“A”类中）
# A g$lshzxetd的别名，因此“AKE”字符串表示所有事件（由于其独特性质而从“A”中排除的关键未命中事件除外）。
#“notify keyspace events”将由零个或多个字符组成的字符串作为参数。空字符串表示禁用通知。
#示例:要从事件名称的角度启用列表和通用事件，请使用:
# notify-keyspace-events Elg
#示例2:获取订阅频道名称的过期密钥流__keyevent@0__:过期使用:
#notify-keyspace-events Ex
#默认情况下，所有通知都被禁用，因为大多数用户不需要此功能，而且该功能有一些开销。请注意，如果您没有指定K或E中的至少一个，则不会传递任何事件。
notify-keyspace-events ""
###############################GOPHER SERVER||GOPHER服务器#################################
#Redis包含Gopher协议的实现，如RFC 1436所规定(https://www.ietf.org/rfc/rfc1436.txt).
#Gopher协议在90年代末非常流行。它是web的替代方案，服务器端和客户端的实现都非常简单，因此Redis服务器只有100行代码来实现这一支持。
#你现在和Gopher做什么？好吧，Gopher从未真正死去，最近有一场运动是为了让Gopher恢复由纯文本文档组成的更具层次性的内容。一些人想要一个更简单的互联网，另一些人认为主流互联网变得太受控制，为那些想要新鲜空气的人创造一个替代空间是很酷的。
#无论如何，在Redis的10岁生日，我们把Gopher协议作为礼物送给了它。
#---它是如何工作的---
#Redis Gopher支持使用Redis的内联协议，特别是两种无论如何都是非法的内联请求:空请求或任何以“/”开头的请求（没有以这样的斜杠开头的Redis命令）。正常的RESP2/REP3请求完全不在Gopher协议实现的路径之外，也照常提供服务。
#如果您在启用Gopher时打开与Redis的连接，并向其发送一个类似“/foo”的字符串，如果有一个名为“/foo”的密钥，则通过Gopher协议提供服务。
#为了创建一个真正的Gopher“洞”（Gopher talking中Gopher站点的名称），您可能需要以下脚本: https://github.com/antirez/gopher2redis
#---安全警告---
#如果您计划将Redis放到互联网上的服务器Gopher页面的公共访问地址，请确保为实例设置密码。
#设置密码后:
# 1. Gopher服务器（启用时，不是默认情况）仍将通过Gopher提供内容。
# 2. 但是，在客户端进行身份验证之前，不能调用其他命令。
#因此，请使用“requirepass”选项来保护您的实例。
#注意，当启用“io threads do reads”时，当前不支持Gopher。
#要启用Gopher支持，请取消注释以下行，并将选项从no（默认值）设置为yes。
# gopher-enabled no
###############################ADVANCED CONFIG高级配置###############################
#当哈希具有少量条目且最大条目不超过给定阈值时，使用内存高效的数据结构对哈希进行编码。可以使用以下指令配置这些阈值。
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
#列表还以一种特殊的方式进行编码，以节省大量空间。
#每个内部列表节点允许的条目数可以指定为固定的最大大小或最大元素数。
#对于固定的最大大小，使用-5到-1，表示:
#-5:最大大小:64 Kb <--不建议用于正常工作负载
#-4:最大大小:32 Kb <--不推荐
#-3:最大大小:16 Kb <--可能不建议使用
#-2:最大大小:8 Kb <--良好
#-1:最大大小:4 Kb <--良好
#正数表示每个列表节点最多存储该数量的元素。
#性能最高的选项通常是-2（8 Kb大小）或-1（4 Kb大小），但如果您的用例是唯一的，请根据需要调整设置。
list-max-ziplist-size -2
#列表也可以被压缩。
#Compress depth是从列表的*每*侧到*排除*压缩的快速列表ziplist节点的数量。对于快速推/弹出操作，列表的头部和尾部始终未压缩。设置包括:
#0:禁用所有列表压缩
#1:depth 1表示“直到列表中的一个节点之后才开始压缩，从头部或尾部开始”。所以:[head]->node->node->…->node->[tail][head]，[tail]将始终未压缩；内部节点将被压缩。
#2:[head]->[next]->node->node->…->node->[prev]->[tail]2这里的意思是:不要压缩head或head->next或tail->prev或tail，而是压缩它们之间的所有节点。
#3:[head]->[next]->[next]->node->node->…->节点->〔prev〕->〔prev〕->〔tail〕等。
list-compress-depth 0
#在一种情况下，集合有一种特殊的编码:当集合仅由字符串组成时，这些字符串恰好是64位有符号整数范围内以10为基数的整数。
#以下配置设置设置了集合大小的限制，以便使用这种特殊的内存节省编码。
set-max-intset-entries 512
#与哈希和列表类似，排序集也经过特殊编码，以节省大量空间。此编码仅在排序集的长度和元素低于以下限制时使用:
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
#HyperLogLog稀疏表示字节限制。限制包括16字节的标头。当使用稀疏表示的HyperLogLog超过此限制时，它将转换为密集表示。
#大于16000的值是完全无用的，因为此时密集表示的内存效率更高。
#建议的值为~3000，以便在不降低太多PFADD（稀疏编码为O（N））的情况下获得空间效率编码的好处。当CPU不是问题，但空间是问题，并且数据集由基数在0-15000范围内的许多HyperLogLogs组成时，该值可以提高到约10000。
hll-sparse-max-bytes 3000
#流宏节点最大大小/项。流数据结构是一个大节点的基数树，在其中编码多个项。使用此配置，可以配置单个节点的大小（以字节为单位），以及在附加新流条目时切换到新节点之前可能包含的最大项目数。如果以下任何设置设置为零，则该限制将被忽略，因此例如，可以通过将最大字节设置为0并将最大条目设置为所需值来仅设置最大条目限制。
stream-node-max-bytes 4096
stream-node-max-entries 100
#主动重新散列每100毫秒CPU时间使用1毫秒，以帮助重新散列主Redis哈希表（将顶级键映射到值的哈希表）。Redis使用的哈希表实现（请参见dict.c）执行了一个惰性的重新散列：在重新散列的哈希表中运行的操作越多，执行的重新散列“步骤”就越多，因此如果服务器空闲，则重新散列永远不会完成，哈希表会使用更多的内存。
#默认值是每秒10次使用这一毫秒，以便主动重新刷新主词典，在可能的情况下释放内存。
#如果不确定：如果您有硬性延迟要求，并且Redis可以以2毫秒的延迟不时回复查询，这在您的环境中不是一件好事，请使用“activerehashing no”。
#如果您没有这样的硬性要求，但希望尽快释放内存，请使用“activerehashingyes”。
activerehashing yes
#客户端输出缓冲区限制可用于强制断开由于某些原因（一个常见的原因是Pub/Sub客户端无法以发布者能够产生的速度消耗消息）而无法足够快地从服务器读取数据的客户端。
#可以为三种不同类型的客户端设置不同的限制：
#normal ->正常客户端，包括MONITOR客户端
#replica ->副本客户端
#pubsub ->客户端订阅了至少一个pubsub频道或模式
#每个客户端输出缓冲区限制指令的语法如下：
#客户端输出缓冲区限制＜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数据进行一次fsync。这对于更增量地将文件提交到磁盘并避免大的延迟峰值非常有用。
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使用对数行为的概率增量。给定旧计数器的值，当访问密钥时，计数器在
#这样：
# 1. 提取0和1之间的随机数R。
# 2. 概率P被计算为1/（old_value*lfl_log_factor+1）。
# 3. 只有当R<P时，计数器才会递增。
#默认的lfu对数因子为10。这是一个表，说明频率计数器如何随着不同对数因子的不同访问次数而变化:
#
# +--------+------------+------------+------------+------------+------------+
# | factor | 100 hits | 1000 hits | 100K hits | 1M hits | 10M hits |
# +--------+------------+------------+------------+------------+------------+
# | 0 | 104 | 255 | 255 | 255 | 255 |
# +--------+------------+------------+------------+------------+------------+
# | 1 | 18 | 49 | 255 | 255 | 255 |
# +--------+------------+------------+------------+------------+------------+
# | 10 | 10 | 18 | 142 | 255 | 255 |
# +--------+------------+------------+------------+------------+------------+
# | 100 | 8 | 11 | 49 | 143 | 255 |
# +--------+------------+------------+------------+------------+------------+
#
#注:上表是通过运行以下命令获得的:
# redis-benchmark -n 1000000 incr foo
# redis-cli object freq foo
#注2:计数器初始值为5，以便为新对象提供累积命中的机会。
#计数器衰减时间是必须经过的时间（以分钟为单位），以便密钥计数器除以2（如果其值小于等于10，则递减）。
#lfu衰减时间的默认值为1。特殊值0表示每次扫描计数器时，计数器都会衰减。
# lfu-log-factor 10
# lfu-decay-time 1
###########################ACTIVE DEFRAGMENTATION活动碎片整理#######################
#什么是活动碎片整理？
#主动（在线）碎片整理允许Redis服务器压缩内存中数据的小分配和释放之间留下的空间，从而允许回收内存。
#碎片化是每个分配器（幸运的是Jemalloc）和某些工作负载都会发生的自然过程。通常需要重新启动服务器以降低碎片，或者至少清除所有数据并重新创建。然而，由于Oran Agra for Redis 4.0实现了这一功能，在服务器运行时，这个过程可以在运行时以“热”方式进行。
#基本上，当碎片超过某个级别时（请参阅下面的配置选项），Redis将通过利用某些特定的Jemalloc特性（以了解分配是否导致碎片并将其分配到更好的位置），开始在连续内存区域中创建值的新副本，同时，释放数据的旧副本。对所有键递增重复此过程将导致碎片降至正常值。
#需要了解的重要事项:
# 1. 默认情况下，此功能是禁用的，只有当您编译Redis以使用我们随Redis源代码提供的Jemalloc副本时，此功能才有效。这是Linux版本的默认设置。
# 2. 如果没有碎片问题，则永远不需要启用此功能。
# 3. 一旦遇到碎片，您可以在需要时使用命令“CONFIG SET activedefrag yes”启用此功能。
#配置参数能够微调碎片整理过程的行为。如果您不确定它们的含义，那么保持默认值不变是一个好主意。
# Enabled active defragmentation
# activedefrag no
#启动活动碎片整理所需的最小碎片浪费量
# active-defrag-ignore-bytes 100mb
#启动活动碎片整理的最小碎片百分比
# active-defrag-threshold-lower 10
#我们使用最大努力的最大碎片百分比
# active-defrag-threshold-upper 100
#CPU百分比的碎片整理工作量最小，达到较低阈值时使用
# active-defrag-cycle-min 1
#达到上限阈值时使用的最大碎片整理工作量（CPU百分比）
# active-defrag-cycle-max 25
#将从主字典扫描处理的set/hash/zset/list字段的最大数量
# active-defrag-max-scan-fields 1000
#默认情况下，将启用用于清除的Jemalloc后台线程
jemalloc-bg-thread yes
#可以将Redis的不同线程和进程固定到系统中的特定CPU，以最大化服务器的性能。
#这对于将不同的Redis线程固定在不同的CPU上非常有用，而且对于确保在同一主机上运行的多个Redis实例将固定到不同的CPU也非常有用。
#通常，您可以使用“taskset”命令执行此操作，但也可以通过Redis配置直接执行，无论是在Linux还是FreeBSD中。
#您可以固定服务器/IO线程、bio线程、aof重写子进程和bgsave子进程。指定cpu列表的语法与taskset命令相同:
#将redis服务器/io线程设置为cpu相关性0,2,4,6:
# server_cpulist 0-7:2
#将生物线程设置为cpu相关性1,3:
#bio_cpulist 1,3
#将aof重写子进程设置为cpu相关性8、9、10、11:
# aof_rewrite_cpulist 8-11
#将bgsave子进程设置为cpu相关性1,10,11
# bgsave_cpulist 1,10-11
#在某些情况下，如果redis检测到系统处于坏状态，它会发出警告，甚至拒绝启动，可以通过设置以下配置来抑制这些警告，该配置使用空格分隔的警告列表来抑制
# ignore-warnings ARM64-COW-BUGG
4.创建容器
docker run \
--name redis \
-p 6379:6379 \
--restart=always \
-v /home/redis/conf/redis.conf:/etc/redis/redis.conf \
-v /home/redis/conf/data:/data \
redis-server /etc/redis/redis.conf \
--appendonly yes \
-d redis:6.2.8 \
--requirepass 密码
–appendonly yes/no
- 默认情况下，Redis将数据集异步转储到磁盘上。这种模式在许多应用程序中都足够好，但Redis进程出现问题或断电可能会导致几分钟的写入丢失（取决于配置的保存点）。
- “仅附加文件”是另一种持久性模式，可提供更好的持久性。例如，使用默认的数据fsync策略（见后面的配置文件），在服务器断电等严重事件中，Redis可能只丢失一秒钟的写入，或者如果Redis进程本身发生了问题，但操作系统仍在正常运行，则只会丢失一次写入。
- AOF和RDB持久性可以同时启用而不会出现问题。
- 如果启动时启用了AOF，Redis将加载AOF，即具有更好持久性保证的文件。
- 请检查https://redis.io/topics/persistence了解更多信息。
236
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
