Redis 配置文件

bind 127.0.0.1

默认127.0.0.1，即本地回环地址；
默认情况下，如果未指定“bind”配置指令，则Redis会允许所有ip的访问。使用以下命令可以只允许指定ip的访问。
# bind 192.168.1.100 10.0.0.1

protected-mode no

默认值yes，即开启;
如果Redis在启动时，未开启bind和密码设置功能，只能通过回环地址本地访问。
关闭保护模式，此时外部网络可以直接访问。
开启保护模式，需配置bind ip或指定密码。

port 6379

默认值6379；
指定redis运行的端口，由于Redis是单线程模型，因此单机开多个Redis进程的时候会修改端口。

tcp-backlog 511

默认值511；
此参数是指：已完成三次握手的TCP连接队列，默认值511，但是Linux系统内核参数socket最大连接的值默认是128，对应文件/proc/sys/net/core/somaxconn，当系统并发量大且客户端连接缓慢时，应该将两个值进行参考设置。

建议将/proc/sys/net/core/somaxconn的值设置为2048，
如果重启生效，需要在/etc/sysctl.conf中设置：
net.core.somaxconn = 2048
执行sysctl -p生效

timeout 0

默认值0；
表示客户端连接空闲N秒后，将断开连接。设置0表示禁用，永不超时.

tcp-keepalive 300

默认值300；
客户端连接的保活时间，避免服务器阻塞。设置为0时，表示永不检测。

daemonize no

默认值no;
默认情况下，Redis不会作为守护程序运行。
注意，Redis守护进程将在/var/run/redis.pid中写入一个pid文件。

pidfile /var/run/redis_6379.pid

默认/var/run/redis_6379.pid；
守护进程，进程号保存文件位置。

loglevel notice

默认值notice;
定义日志级别。
debug（记录大量日志信息，适用于开发、测试阶段）
verbose（较多日志信息）
notice（适量日志信息，使用于生产环境）
warning（仅有部分重要、关键信息才会被记录） 

logfile ""

默认值""；
定义redis日志文件位置。

databases 16

默认值16；
设置数据库的数目。默认的数据库是DB 0 ，可以在每个连接上使用select  <dbid> 命令选择一个不同的数据库，dbid 是 0 到'databases'-1之间的数字

注意：集群模式的时候，只能使用0号数据库

always-show-logo yes

默认值yes;
Redis开始登录时显示的ASCII图标。4.0以后可以自由设置。

save 900 1
save 300 10
save 60 10000

默认以上三个。
redis进行rdb持久化的设置。分别表示：
900秒内有1个key发生变化，就持久化
300秒内有10个key发生变化，就持久化
60秒内有1000个key发生变化，就持久化

如果redis只是用于缓存的功能，可以不开启rdb持久化。设置为save ""即可。

stop-writes-on-bgsave-error yes

默认值yes；
当启用了RDB且最后一次后台保存数据失败，Redis是否停止接收数据。这会让用户意识到数据没有正确持久化到磁盘上，否则没有人会注意到灾难（disaster）发生了。如果Redis重启了，那么又可以重新开始接收数据了

rdbcompression yes

默认值yes；
对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能，但是存储在磁盘上的快照会比较大。

rdbchecksum yes

默认值yes；
在存储快照后，我们还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。

dbfilename dump.rdb

默认dumo.rdb;
rdb持久化文件名称。

rdb-del-sync-files no

默认值no，不开启。
定义rdb文件是否删除同步锁

dir /usr/local/redis-6.0.8/data

redis rdb持久化文件目录。

masterauth 123456

设置slave节点同步数据时的认证密码

replica-serve-stale-data yes

默认值为yes。当一个 slave 与 master 失去联系，或者复制正在进行的时候，slave 可能会有两种表现：

1) 如果为 yes ，slave 仍然会应答客户端请求，但返回的数据可能是过时，或者数据可能是空的在第一次同步的时候 
2) 如果为 no ，在你执行除了 info he salveof 之外的其他命令时，slave 都将返回一个 "SYNC with master in progress" 的错误

slave-read-only yes

配置Redis的Slave实例是否接受写操作，即Slave是否为只读Redis。默认值为yes。

replica-read-only

从 Redis 2.6 版本开始，Redis 的从服务器在默认状态下只允许执行读命令。

Redis 之所以将从服务器默认设置为只读服务器，是为了确保从服务器只能通过与主服务器进行数据同步来得到更新，从而保证主从服务器之间的数据一致性。

但在某些情况下，我们可能想要将一些不太重要或者临时性的数据储存在从服务器里面，又或者不得不在从服务器里面执行一些带有写性质的命令（比如 ZINTERSTORE 命令，它只能将计算结果储存在数据库里面，不能直接返回计算结果）。这时我们可以通过将 replica-read-only 配置选项的值设置为 no 来打开从服务器的写功能。

使用可写从服务器的注意事项
在使用可写的从服务器时，用户需要注意以下几个方面：

在主从服务器都可写的情况下，程序必须将写命令发送到正确的服务器上面，不能把需要在主服务器执行的写命令发送给从服务器执行，也不能把需要在从服务器执行的写命令发送给主服务器执行，否则就会出现数据错误。

从服务器执行写命令得到的数据，可能会被主服务器发送的写命令覆盖。比如说，如果从服务器在执行了客户端发送的 SET msg "hello from client" 命令之后，又接收到了主服务器发送的 SET msg "hello from master" 命令，那么客户端写入的 msg 键将被主服务器写入的 msg 键覆盖。因为这个原因，客户端在从服务器上面执行写命令时，应该尽量避免与主服务器发生键冲突，换句话说，用户应该让客户端和主服务器分别对从服务器数据库中不同的键进行写入，而不要让客户端和主服务器都去写相同的键。

当从服务器与主服务器进行完整同步时，从服务器数据库包含的所有数据都将被清空，其中包括客户端写入的数据。

为了减少内存占用，降低键冲突发生的可能性，并确保主从服务器的数据同步操作可以顺利进行，客户端写入到从服务器的数据应该在使用完毕之后尽快删除。一个比较简单的方法是在客户端向从服务器写入数据的同时，为数据设置一个比较短的过期时间，使得这些数据可以在使用完毕之后自动被删除。

repl-diskless-sync no

主从数据复制是否使用无硬盘复制功能。默认值为no。

主服务器在进行完整同步的时候，需要在本地创建 RDB 文件，然后通过套接字将这个 RDB 文件传送给从服务器。

但是，如果主服务器所在宿主机器的硬盘负载非常大又或者性能不佳，创建 RDB 文件引起的大量硬盘写入将对主服务器的性能造成影响，并导致复制进程变慢。

为了解决这个问题，Redis 从 2.8.18 版本开始引入无需硬盘的复制特性（diskless replication）：启用了这个特性的主服务器在接收到 REPLICAOF 命令时将不会再在本地创建 RDB 文件，而是会派生出一个子进程，然后由子进程通过套接字直接将 RDB 文件写入至从服务器。这样主服务器就可以在不创建 RDB 文件的情况下，完成与从服务器的数据同步。

要注意的是，无需硬盘的复制特性只是避免了在主服务器上创建 RDB 文件，但仍然需要在从服务器上创建 RDB 文件。

repl-diskless-sync-delay 5

当启用无硬盘备份，服务器等待一段时间后才会通过套接字向从站传送RDB文件，这个等待时间是可配置的。
这一点很重要，因为一旦传送开始，就不可能再为一个新到达的从节点服务。新请求的从节点则要排队等待下一次RDB传送。因此服务器等待一段时间以期更多的从节点到达。延迟时间以秒为单位，默认为5秒。要关掉这一功能，只需将它设置为0秒，传送会立即启动。默认值为5。

repl-diskless-load disabled

无硬盘备份策略
disabled       不使用
on-empty-db    仅在完全安全时才使用
swapdb         解析时在RAM中保留当前数据库内容的副本，这需要足够的内存

repl-disable-tcp-nodelay no

同步之后是否禁用从站上的TCP_NODELAY 如果你选择yes，redis会使用较少量的TCP包和带宽向从站发送数据。但这会导致在从站增加一点数据的延时。  
Linux内核默认配置情况下最多40毫秒的延时。如果选择no，从站的数据延时不会那么多，但备份需要的带宽相对较多。默认情况下我们将潜在因素优化，但在高负载情况下或者在主从站都跳的情况下，把它切换为yes是个好主意。默认值为no。

requirepass 123456

redis启用密码认证一定要requirepass和masterauth同时设置。

如果主节点设置了requirepass登录验证，在主从切换，slave在和master做数据同步的时候首先需要发送一个ping的消息给主节点判断主节点是否存活，再监听主节点的端口是否联通，发送数据同步等都会用到master的登录密码，否则无法登录，log会出现响应的报错。
也就是说slave的masterauth和master的requirepass是对应的，所以建议redis启用密码时将各个节点的masterauth和requirepass设置为相同的密码，降低运维成本。当然设置为不同也是可以的，注意slave节点masterauth和master节点requirepass的对应关系就行。

masterauth作用：主要是针对master对应的slave节点设置的，在slave节点数据同步的时候用到。
requirepass作用：对登录权限做限制，redis每个节点的requirepass可以是独立、不同的。

rename-command

命令重命名，对于一些危险命令例如：
flushdb（清空数据库）

flushall（清空所有记录）

config（客户端连接后可配置服务器）

keys（客户端连接后可查看所有存在的键）   

例如：
可以将命令禁用：
# rename-command CONFIG ""

也可以对命令设置别名
rename-command flushall abc

maxclients 10000

设置客户端最大并发连接数，默认无限制，Redis可以同时打开的客户端连接数为Redis进程可以打开的最大文件。  描述符数-32（redis server自身会使用一些），如果设置 maxclients为0 。表示不作限制。
当客户端连接数到达限制时，Redis会关闭新的连接并向客户端返回max number of clients reached错误信息

maxmemory 6GB

设置redis可以使用的最大物理内存，有几种设置方式：
maxmemory 1,073,741,824

maxmemory 1,073,741,824B

maxmemory 1GB

不带单位默认为B。但需要注意KB和K、MB和M、GB和G是不同的，如1K表示1000字节，而1KB则为1024字节。如果maxmemory值为0，表示不做限制。

Redis会占用非常大内存，所以通常需要关闭系统的OOM，方法为将“/proc/sys/vm/overcommit_memory”的值设置为1（通常不建议设置为2）
也可以使用命令sysctl设置，如：sysctl vm.overcommit_memory=1，但注意一定要同时修改文件/etc/sysctl.conf，执行“sysctl -p”，以便得系统重启后仍然生效。

可选值：0、1、2。
0， 表示内核将检查是否有足够的可用内存供应用进程使用；如果有足够的可用内存，内存申请允许；否则，内存申请失败，并把错误返回给应用进程。
1， 表示内核允许分配所有的物理内存，而不管当前的内存状态如何。
2， 表示内核允许分配超过所有物理内存和交换空间总和的内存

maxmemory-policy allkeys-lru

当内存使用达到最大值时，redis使用的键清除策略。有以下几种：

（1）默认生效的是永不过期策略（noeviction policy） 
 在noeviction策略中，没有键设置为过期。如果redis没有可用内存，任何写操作都会导致redis错误。

（2） volatile-lru 将最近较少使用的键驱逐
这些键必须通过 expire set 命令设置了超时的。当redis内存耗尽时，redis开始删除那些设置了过期时间的键，即便该键仍然有剩余时间。

（3）allkeys-lru 基于键的TTL值来驱逐键。
当键值存储到redis，并通过expire设置了超时时间，当redis没有键值写入，且已接近最大内存，会根据设置的TTL依据LRU算法进行驱逐。忽略没有设置过期时间的键。

（4）volatile-random 基于键上设置的过期状态随机驱逐一个键
需要O(n)时间复杂度的操作来计算创建的这些键是否已被驱逐。

（5）allkeys-random 整个键空间中随机驱逐一个键

（6）volatile-ttl redis会尝试根据键的剩余时间(TTL)清除键。

maxmemory-samples 3

redis的LRU算法是不准确的，因为redis并不会自动选择最佳的候选键来驱逐，例如最少使用的键或者最早访问的键。相反，redis默认行为是选取5个键的samples，并驱逐当中最少使用的那个。
如果想要增加LRU算法的精确性，可以更改redis.conf文件中的maxmemory-samples指令，或者在运行时通过config set maxmemory-samples命令进行设置。

将maxmemory-samples增加到10，从而提升redisLRU算法的性能，效果接近真实LRU算法，但是副作用就是消耗更多的CPU计算能力。将maxmemory-samples降至3，从而减少了redisLRU算法的精确性，不过相应地加快了处理速度。

appendonly yes

启动reids aof持久化方式。
默认redis使用的是rdb方式持久化，这种方式在许多应用中已经足够用了。但是redis如果中途宕机，会导致可能有几分钟的数据丢失，根据save来策略进行持久化
Append Only File是另一种持久化方式
可以提供更好的持久化特性。Redis会把每次写入的数据在接收后都写入appendonly.aof文件，每次启动时Redis都会先把这个文件的数据读入内存里，先忽略RDB文件。默认值为no。

appendfilename

aof文件名，默认是"appendonly.aof"

appendfsync

aof持久化策略的配置；
no表示不执行fsync，由操作系统保证数据同步到磁盘，速度最快

appendfsync always
每次收到写命令就立即强制写入磁盘，是最有保证的完全的持久化，但速度也是最慢的，一般不推荐使用。 

appendfsync everysec
每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，是受推荐的方式。 可能会导致丢失这1s数据 

no-appendfsync-on-rewrite no

在aof重写或者写入rdb文件的时候，会执行大量IO，此时对于everysec和always的aof模式来说，执行fsync会造成阻塞过长时间，no-appendfsync-on-rewrite字段设置为默认设置为no。
如果对延迟要求很高的应用，这个字段可以设置为yes，否则还是设置为no，这样对持久化特性来说这是更安全的选择。   
设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入，默认为no，建议yes。
Linux的默认fsync策略是30秒。可能丢失30秒数据。默认值为no。

auto-aof-rewrite-percentage 100

默认值为100。aof自动重写配置，当目前aof文件大小超过上一次重写的aof文件大小的百分之多少进行重写，即当aof文件增长到一定大小的时候，Redis能够调用bgrewriteaof对日志文件进行重写。
当前AOF文件大小是上次日志重写得到AOF文件大小的二倍（设置为100）时，自动启动新的日志重写过程。

auto-aof-rewrite-min-size 64mb

设置允许重写的最小aof文件大小，避免了达到约定百分比但尺寸仍然很小的情况还要重写。

aof-load-truncated no

默认值yes;
aof文件可能在尾部是不完整的，当redis启动的时候，aof文件的数据被载入内存。重启可能发生在redis所在的主机操作系统宕机后，尤其在ext4文件系统没有加上data=ordered选项，出现这种现象redis宕机或者异常终止不会造成尾部不完整现象，可以选择让redis退出，或者导入尽可能多的数据。

如果选择的是yes，当截断的aof文件被导入的时候，会自动发布一个log给客户端然后load。
如果是no，用户必须手动redis-check-aof修复AOF文件才可以。

lua-time-limit

一个lua脚本执行的最大时间，单位为ms。默认值为5000.

cluster-enabled yes

集群模式启动redis设置为yes，表示开启集群，否则会以单实例启动。

cluster-config-file nodes-6379.conf

这是redis集群运行时服务自身维护的配置文件。
Redis群集节点每次发生更改时自动保留群集配置（基本上为状态）的文件，以便能够 在启动时重新读取它。 该文件列出了群集中其他节点，它们的状态，持久变量等等。 由于某些消息的接收，通常会将此文件重写并刷新到磁盘上。

cluster-node-timeout 15000

集群超时时间（毫秒），节点超时多久则认为它宕机了。如果主节点超过指定的时间不可达，进行故障切换，将其对应的从节点提升为主。
注意，每个无法在指定时间内到达大多数主节点的节点将停止接受查询。

cluster-require-full-coverage no

默认为yes，表示只有所有哈希槽有主节点管理的时候，集群才可以接受查询。no 表示 当集群哈希槽的一部分没有主节点接管或者主节点宕机没有从节点进行故障切换时，仍然可以提供服务。

cluster-migration-barrier 1

可以配置值为1。master的slave数量大于该值，slave才能迁移到其他孤立master上，如这个参数若被设为2，那么只有当一个主节点拥有2个可工作的从节点时，它的一个从节点会尝试迁移。

cluster-replica-validity-factor 10

集群副本有效因子
此参数设置后，需要在集群可用性和数据的完整性之间进行取舍。

例如：设置了副本有效性因子为cluster-replica-validity-factor 10 ，节点超时时间 cluster-node-timeout 5000，且副本的复制周期为10秒，那么如果从节点与主节点的最后一次交互的时间大于(node-timeout * replica-validity-factor) + repl-ping-replica-period）的值，将不会进行故障转移。

如果需要集群的最大可用性，可以将此值设置为0，表示忽略从节点最后一次和主节点交互的时间，从节点始终进行故障转移。但数据的完整性最低

min-replicas-max-lag
min-replicas-to-write

因为复制的在线更新操作以异步方式进行，所以当主从服务器之间的连接不稳定，又或者从服务器未能收到主服务器发送的更新命令时，主从服务器就会出现数据不一致的情况。

为了尽可能地降低数据不一致的出现几率，Redis 从 2.8 版本开始引入了两个以 min-replicas 开头的配置选项.

用户设置了这两个配置选项之后，主服务器只会在从服务器的数量大于等于 min-replicas-to-write 选项的值，并且这些从服务器与主服务器最后一次成功通讯的间隔不超过 min-replicas-max-lag 选项的值时才会执行写命令。

举个例子，假设我们想要让主服务器只在拥有至少 3 个从服务器，并且这些从服务器与主服务器最后一次成功通讯的间隔不超过 10 秒钟的情况下才执行写命令，那么可以使用配置选项：
min-replicas-max-lag 10
min-replicas-to-write 3

通过使用这两个配置选项，我们可以让主服务器只在主从服务器连接良好的情况下执行写命令。因为在线更新的异步性质，min-replicas-max-lag 和 min-replicas-to-write 并没有办法完全地杜绝数据不一致出现，但它们可以有效地减少因为主从服务器连接不稳定而导致的数据不一致，并降低因为没有从服务器可用而导致数据丢失的可能性。