Redis配置文件

我好帅啊~

已于 2023-03-17 08:52:19 修改

阅读量1.8k

点赞数

分类专栏： Redis 数据库文章标签： redis 数据库

于 2022-11-10 16:41:07 首次发布

本文链接：https://blog.csdn.net/m0_56808407/article/details/127785151

版权

数据库同时被 2 个专栏收录

4 篇文章 1 订阅

订阅专栏

Redis

3 篇文章 0 订阅

订阅专栏

文章目录

Units（单位）
- 数据单位换算
- 包含其它配置文件的信息 include path
Network 网络相关
- IP绑定
- 保护模式 protected-mode
- 端口号 port
- tcp-backlog（TCP半连接队列长度配置）
- timeout（是否超时无操作关闭连接）
- tcp-keepalive（TCP连接保活策略）
GENERAL 通用配置
- daemonize（启动方式）
- pidfile（进程pid文件）
- loglevel logfile（日志）
- databse（指定数据库的数量）
- always-show-logo（启动是否显示logo）
SNAPSHOTTING（快照）
- save （数据保存到硬盘）
- stop-writes-on-bgsave-error（最后一次保存数据失败后是否停止接受数据）
- rdbcompression（是否进行压缩存储）
- rdbchecksum （CRC64算法来进行数据校验）
- dbfilename（设置快照的文件名）
- dir（设置快照文件的存放路径）
SECURITY（安全相关）
- ACL配置
CLIENTS 客户端配置
MEMORY MANAGEMENT 内存管理
- 最大内存限制
- 达到最大内存限制时的策略
- 使用LRU/LFU/TTL算法时采样率
- 从库不淘汰数据
- 过期keys驻留在内存中的比例
LAZY FREEING 懒惰删除
- 相关配置：
THREADED I/O（线程 I/O）
- redis.conf相关配置翻译
- 配置IO线程数
- KERNEL OOM CONTROL 设置OOM时终止哪些进程
- - Redis支持三个选项：
  - 分别控制主进程、从进程和后台子进程的值
APPEND ONLY MODE AOF持久化配置
- 开始/关闭aof
- aof文件名称
- 执行fsync()系统调用刷盘的频率
- 自动重写aof文件
- AOF文件末尾被截断
- 开启混合持久化
LUA SCRIPTING-LUA脚本相关
- 配置LUA脚本最大执行时长
REDIS CLUSTER 集群配置
- 允许集群模式
- 集群配置文件
- 节点超时时间
- 设置副本有效因子
- 设置master故障转移时保留的最少副本数
- 哈希槽全覆盖检查
- 是否自动故障转移
- 集群失败时允许节点处理读请求
CLUSTER DOCKER/NAT support
SLOW LOG 慢日志
- 设置慢日志记录阈值
- 慢日志文件大小
LATENCY MONITOR 延迟监控
- 设置延迟阈值
EVENT NOTIFICATION 事件通知
GOPHER SERVER Gopher协议
ADVANCED CONFIG 高级设置
- 设置Hash底层数据结构由ziplist转为hashtable的阈值
- 设置List底层数据结构quicklist中单个ziplist的大小
- 设置压缩List中ziplist为quicklistLZF结构
- 设置Set底层intset最大entities个数/intset升级为hashtable的阈值
- 设置ZSet底层数据结构由ziplist转为skiplist的阈值
- 设置HyperLogLog底层稀疏矩阵转为稠密矩阵的阈值
- 自定义Stream宏节点大小
- 开启Rehash
- 客户端输出缓存控制
- 配置客户端query buffer大小
- Redis协议批量请求单个字符串限制
- Redis执行任务频率
- 动态hz配置
- AOF重写时执行fsync刷盘策略
- 保存RDB文件时执行fsync刷盘策略
- LFU设置（Redis LFU淘汰策略）
- ACTIVE DEFRAGMENTATION 碎片整理
原文作者：

Units（单位）

数据单位换算

# 用于指定存储单位的大小换算关系，不区分大小写，只支持bytes，不支持bits
# 1k => 1000 bytes
# 1kb => 1024 bytes
# 1m => 1000000 bytes
# 1mb => 1024*1024 bytes
# 1g => 1000000000 bytes
# 1gb => 1024*1024*1024 bytes
#
# units are case insensitive so 1GB 1Gb 1gB are all the same.
# 单位不区分大小写，所以1GB 1Gb 1gB 都相同

包含其它配置文件的信息 include path

对于公共部分配置，可按以下方式配置引入

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

Network 网络相关

IP绑定

属性：bind IP1 [IP2 …]
- 主要bind只能有一行配置，如果有多个网卡要监听，就配置多个ip，用空格隔开.
- 本机的IP地址是和网卡（network interfaces）绑定在一起的，配置这项后，Redis只会接收来自指定网卡的数据包
- 这项配置绑定的IP是本机的IP地址,不是客户端的IP地址。
例如：bind 127.0.0.1、bind 192.168.1.100 10.0.0.1 、bind 127.0.0.1 ::1

保护模式 protected-mode

属性：protected-mode yes
- yes：在没有指定bind或没有指定密码的情况下，只能本地访问。

端口号 port

属性：port 6379
配置Redis监听的端口号，默认6379。
Accept connections on the specified port, default is 6379 (IANA #815344).
- 接受指定端口上的连接，默认为6379
If port 0 is specified Redis will not listen on a TCP socket.
- 如果指定了端口0,Redis将不会监听TCP套接字

tcp-backlog（TCP半连接队列长度配置）

属性：tcp-backlog 511
在进行TCP/IP连接时，内核会维护两个队列
syns queue用于保存已收到sync但没有接收到ack的TCP半连接请求。
- 由/proc/sys/net/ipv4/tcp_max_syn_backlog指定
accept queue，用于保存已经建立的连接，也就是全连接。
- 由/proc/sys/net/core/somaxconn指定。
根据配置的注释，需要同时提高somaxconn和tcp_max_syn_backlog的值来确保生效。

timeout（是否超时无操作关闭连接）

属性：timeout 0。
- 客户端经过多少时间（单位秒）没有操作就关闭连接
- 0代表永不关闭

tcp-keepalive（TCP连接保活策略）

属性：tcp-keepalive 60
- 单位为秒，
- 如设置为60秒：
  - server端会每60秒向连接空闲的客户端发起一次ACK请求，以检查客户端是否已经挂掉。
  - 对于无响应的客户端则会关闭其连接。
- 如果设置为0，则不会进行保活检测。

GENERAL 通用配置

daemonize（启动方式）

属性：daemonize yes
- 是否以守护（后台）进程的方式启动，
- 默认no。

pidfile（进程pid文件）

属性：pidfile /var/run/redis_6379.pid
- redis启动后会把pid写入到pidfile指定的文件中。
- 如上所示：把pid写入到redis_6379.pid

loglevel logfile（日志）

loglevel用于配置日志打印机别，默认notice：
属性：loglevel notice
- debug：能设置的最高的日志级别，打印所有信息，包括debug信息。
- verbose：打印除了debug日志之外的所有日志。
- notice：打印除了debug和verbose级别的所有日志。
- warning：仅打印非常重要的信息。
属性：logfile "路径"
- 输出文件

databse（指定数据库的数量）

属性：databases 16
- redis默认有16个数据库
- 默认从0开始

always-show-logo（启动是否显示logo）

属性：always-show-logo yes

SNAPSHOTTING（快照）

这里的配置主要用来做持久化操作。

save （数据保存到硬盘）

属性：save 秒数 key的数量
用来配置触发 Redis的持久化条件，也就是什么时候将内存中的数据保存到硬盘。
默认如下配置：
- save 900 1：表示900 秒内如果至少有 1 个 key 的值变化，则保存
- save 300 10：表示300 秒内如果至少有 10 个 key 的值变化，则保存
- save 60 10000：表示60 秒内如果至少有 10000 个 key 的值变化，则保存
- save ""：表时只用Redis的缓存功能，不需要持久化
  - 需要注释掉所有其他的 save 行来停用保存功能

stop-writes-on-bgsave-error（最后一次保存数据失败后是否停止接受数据）

属性：stop-writes-on-bgsave-error yes
- yes: 失败后停止接收数据。
- no：失败后不停止接收数据。
  - 不会意识到数据没有正确持久化到磁盘上，
  - 没有人会注意到灾难（disaster）发生了。
Redis如果重启后可以重新开始接收数据

rdbcompression（是否进行压缩存储）

属性：rdbcompression yes
- 默认值是yes。
对于存储到磁盘中的快照，可以设置是否进行压缩存储。
yes：开启、redis会采用LZF算法进行压缩。
no：关闭、不消耗CPU来进行压缩，但存储在磁盘上的快照会较大。

rdbchecksum （CRC64算法来进行数据校验）

属性：rdbchecksum yes
- 默认值是yes。
- yes：增加大约10%的性能消耗，使用CRC64算法来进行数据校验
- no：关闭此功能。

dbfilename（设置快照的文件名）

属性：dbfilename filename
- 默认是 dump.rdb

dir（设置快照文件的存放路径）

SECURITY（安全相关）

################################## SECURITY ###################################
# 警告:由于Redis非常快，外部用户可以尝试每秒100万个密码
# Warning: since Redis is pretty fast, an outside user can try up to 1 million passwords per second against a modern box.

# 这意味着你应该使用非常强的密码，否则很容易被破解
# This means that you should use very strong passwords, otherwise they will be very easy to break.

# 请注意，因为密码实际上是客户端之间的共享秘密和服务器，以及不应该被任何人记住的密码
# Note that because the password is really a shared secret between the client and the server, and should not be memorized by any human, the password

可以很容易地是来自/dev/urandom或其他类型的长字符串，所以通过使用长而不可猜的密码，暴力攻击将不可能发生
# can be easily a long string from /dev/urandom or whatever, so by using a long and unguessable password no brute force attack will be possible.

ACL配置

简介

ACL：访问控制列表。
有两种方法配置ACL：
- 在命令行通过ACL命令进行配置
- 在Redis配置文件中开始，可以直接在redis.conf中配置，也可以通过外部aclfile配置:aclfile path
- 配置语法：user <username> ... acl rules ....
- 例如 user worker +@list +@connection ~jobs:* on >ffa9203c493aa99
redis默认有一个default用户。如果default具有nopass规则（就是说没有配置密码），那么新连接将立即作为default用户登录，无需通过AUTH命令提供任何密码。
否则，连接会在未验证状态下启动，并需要AUTH验证才能开始工作。

描述用户可以做的操作的ACL规则如下

启用或禁用用户（已经建立的连接不会生效）

on 启用用户，该用户可以验证身份登陆。
off 禁用用户，该用户不允许验证身份登陆。

允许/禁止用户执行某些命令

+<command> 允许用户执行command指示的命令✅
-<command> 禁止用户执行command指示的命令🈲
+@<category> 允许用户执行category分类中的所有命令✅
-@<category> 禁止用户执行category分类中的所有命令🈲
+<command>|subcommand 允许执行某个被禁止的command的子命令subcommand。没有对应的-规则。✅
allcommands +@all的别名，允许执行所有命令。✅
nocommands -@all的别名，禁止执行所有命令。🈲

允许/禁止用户访问某些Key

~<pattern> 添加用户可以访问的Key
- ~*代表用户可以访问所有key，
- ~K*代表用户可访问以K开头的key。
allkeys 等价于~*
resetkeys ~<pattern> 刷新允许模式的列表，会覆盖之前设置的模式。
- 例如 user test ~* resetkeys ~K*，则只允许访问匹配K*的键，~*失效。

为用户配置有效密码

><password> 将密码添加到用户的有效密码列表中。
- 例如user test >mypass on，则用户test可以使用mypass验证。
<<password> 将密码从用户的有效密码列表中删除，即不可以使用该密码验证。
nopass 使用任意密码都可以成功验证。
resetpass 清除用户可用密码列表的数据，并清除 nopass 状态。
- 之后该用户不能登陆。直到重新设置密码/设置nopass。
reset 重置用户到初始状态。该命令会执行以下操作：resetpass, resetkeys, off,-@all。

ACL日志配置

设置ACL日志最大长度，默认128个记录。这个日志是存在内存里的。
acllog-max-len 128

外部ACL文件配置

默认位置etc/redis/users.acl，我们可以在这个文件中定义所有用户的ACL控制信息。
aclfile /etc/redis/users.acl

配置默认用户default的密码

该配置只对默认用户default生效。
requirepass yourpass 1

CLIENTS 客户端配置

设置最大同时客户端连接数
设置可以同时连接客户端的最大数量。默认该项设置为 10000 个客户端。
达到限制值后的连接会被拒绝并会返回错误信息。
maxclients 10000

MEMORY MANAGEMENT 内存管理

最大内存限制

指定Redis最大内存限制。
达到内存限制时，Redis将尝试删除已到期或即将到期的Key。
maxmemory <bytes>

达到最大内存限制时的策略

配置达到最大内存限制后，Redis进行何种操作。默认noeviction
maxmemory-policy noeviction
共有8种策略可供选择。
- volatile-lru 只对设置了过期时间的Key进行淘汰，淘汰算法近似的LRU。
- allkeys-lru 对所有Key进行淘汰，LRU。
- volatile-lfu 只对设置了过期时间的Key进行淘汰，淘汰算法近似的LFU。
- allkeys-lfu 对所有Key进行淘汰，LFU。
- volatile-random 只对设置了过期时间的Key进行淘汰，淘汰算法为随机淘汰。
- allkeys-random 对所有Key进行淘汰，随机淘汰。
- volatile-ttl 只对设置了过期时间的Key进行淘汰，删除即将过期的即ttl最小的。
- noeviction 永不删除key，达到最大内存再进行数据装入时会返回错误。
对于可以通过删除key来释放内存的策略，如果没有key可以删除了，那么也会报错。

使用LRU/LFU/TTL算法时采样率

Redis使用的是近似的LRU/LFU/minimal TTL算法。
为了节约内存以及提升性能。
Redis配置文件有maxmemory-samples选项，可以配置每次取样的数量。
Redis每次会选择配置数量的key，然后根据算法从中淘汰最差的key。
maxmemory-samples 5
可以通过修改这个配置来获取更高的淘汰精度或者更好的性能。
默认值5就可以获得很好的结果。
选择10可以非常接近真是的LRU算法，但是会耗费更多的CPU资源。
3的话更快但是淘汰结果不是特别准确。

从库不淘汰数据

配置Redis主从复制时，从库超过maxmemory也不淘汰数据。
这个配置主要是为了保证主从库的一致性
- 因为Redis的淘汰策略是随机的，如果允许从库自己淘汰key，那么会导致主从不一致的现象出现（master节点删除key的命令会同步给slave节点）。
  replica-ignore-maxmemory yes

过期keys驻留在内存中的比例

设置过期keys仍然驻留在内存中的比重
默认是为1，表示最多只能有10%的过期key驻留在内存中
该值设置的越小，那么在一个淘汰周期内，消耗的CPU资源也更多，因为需要实时删除更多的过期key。
active-expire-effort 1

LAZY FREEING 懒惰删除

# Redis has two primitives to delete keys. One is called DEL and is a blocking
# deletion of the object. It means that the server stops processing new commands
# in order to reclaim all the memory associated with an object in a synchronous
# way. If the key deleted is associated with a small object, the time needed
# in order to execute the DEL command is very small and comparable to most other
# O(1) or O(log_N) commands in Redis. However if the key is associated with an
# aggregated value containing millions of elements, the server can block for
# a long time (even seconds) in order to complete the operation.
# 
# For the above reasons Redis also offers non blocking deletion primitives
# such as UNLINK (non blocking DEL) and the ASYNC option of FLUSHALL and
# FLUSHDB commands, in order to reclaim memory in background. Those commands
# are executed in constant time. Another thread will incrementally free the
# object in the background as fast as possible.
# DEL, UNLINK and ASYNC option of FLUSHALL and FLUSHDB are user-controlled.
# It's up to the design of the application to understand when it is a good
# idea to use one or the other. However the Redis server sometimes has to
# delete keys or flush the whole database as a side effect of other operations.
# Specifically Redis deletes objects independently of a user call in the
# following scenarios:
#
# 1) On eviction, because of the maxmemory and maxmemory policy configurations,
#    in order to make room for new data, without going over the specified
#    memory limit.
# 2) Because of expire: when a key with an associated time to live (see the
#    EXPIRE command) must be deleted from memory.
# 3) Because of a side effect of a command that stores data on a key that may
#    already exist. For example the RENAME command may delete the old key
#    content when it is replaced with another one. Similarly SUNIONSTORE
#    or SORT with STORE option may delete existing keys. The SET command
#    itself removes any old content of the specified key in order to replace
#    it with the specified string.
# 4) During replication, when a replica performs a full resynchronization with
#    its master, the content of the whole database is removed in order to
#    load the RDB file just transferred.
#
# In all the above cases the default is to delete objects in a blocking way,
# like if DEL was called. However you can configure each case specifically
# in order to instead release memory in a non-blocking way like if UNLINK
# was called, using the following configuration directives.

翻译：

Redis有两个删除keys的原语。一个是DEL并且它是一个阻塞的删除对象的操作。意味着server会停止处理新的command以便以同步的方式回收与对象关联的所有内存。如果被删除的key关联的是一个小对象，那么执行DEL命令所需要的时间非常短，与Redis中其它O(1)或O(log_N)的命令时间开销几乎一样。然鹅，如果key与包含了数百万个元素的大对象相关联，那么服务器为了完成删除命令会阻塞很长时间（甚至几秒钟）。
出于以上原因，Redis提供了非阻塞的删除原语，例如UNLINK(非阻塞式的DEL)和FLUSHALL、FLUSHDB命令的ASYNC选项，以便在后台回收内存。这些命令会在常量（固定的）时间内执行。另外一个线程会在后台尽可能快的以渐进式的方式释放对象。
使用DEL,UNLINK以及FLUSHALL和FLUSHDB的ASYNC选项是由用户来控制的。这应该由应用程序的设计来决定使用其中的哪一个。然鹅，作为其它操作的副作用，Redis server有时不得不去删除keys或者刷新整个数据库。具体来说，Redis在以下情况下会独立于用户调用而删除对象：
1）由于maxmemory 和maxmemory policy的设置，为了在不超出指定的内存限制而为新对象腾出空间而逐出旧对象；
2）因为过期：当一个key设置了过期时间且必须从内存中删除时；
3）由于在已经存在的key上存储对象的命令的副作用。例如，RENAME命令可能会删除旧的key的内容，当该key的内容被其它内容代替时。类似的，SUNIONSTORE或者带STORE选项的SORT命令可能会删除已经存在的keys。SET命令会删除指定键的任何旧内容，以便使用指定字符串替换。
4）在复制过程中，当副库与主库执行完全重新同步时，整个数据库的内容将被删除，以便加载刚刚传输的RDB文件。
在上述所有情况下，默认情况是以阻塞方式删除对象，就像调用DEL一样。但是，你可以使用以下配置指令专门配置每种情况，以非阻塞的方式释放内存，就像调用UNLINK一样。

THREADED I/O（线程 I/O）

redis.conf相关配置翻译

Redis大体上是单线程的
但是也有一些场景使用额外的线程去做的
- 如：UNLINK、slow I/O accesses。
现在还可以在不同的I/O线程中处理Redis客户端socket读写。
- 只是网络IO为多线程，
- 执行命令还是单线程！
- 特别是因为写操作很慢，通常Redis的用户使用pipeline来提升每个核心下的Redis性能，并且运行多个Redis实例来实现扩展。
- 使用多线程I/O，不需要使用pipeline和实例切分，就可以轻松的提升两倍的性能。
默认情况下，多线程是禁用的
建议只在至少有4个或更多内核的机器中启用多线程，至少保留一个备用内核。
使用超过8个线程不太可能有多大帮助。
建议仅当您确实存在性能问题时才使用线程化I/O，因为除非Redis实例能够占用相当大的CPU时间，否则使用此功能没有意义。

配置IO线程数

如果你的机器是4核的，可以配置2个或者3个线程。
如果你有8核，可以配置6个线程。
配置参数：io-threads 4
将io-threads设置为1将只使用主线程。
当启用I/O线程时，我们只使用多线程进行写操作，也就是说，执行write(2)系统调用并将Client缓冲区传输到套接字。
也可以通过此配置指令设置为yes来启用读取线程和协议解析：io-threads-do-reads no
需要注意的两点是：
- 这两个配置不能运行时通过CONFIG SET来改变，而且开启SSL功能时，多线程I/O同样不会生效。
- 如果想用benchmark脚本测试多线程下的性能提升，确保benchmark也是多线程模式，在后面加上--threads参数，来匹配Redis的线程数。不然看不到什么性能提升。

KERNEL OOM CONTROL 设置OOM时终止哪些进程

在Linux上，可以提示内核OOM killer在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选项（不为no）时，该指令控制用于主、从和后台子进程的特定值。
- 数值范围为-2000到2000（越高意味着死亡的可能性越大）。
非特权进程（不是根进程，也没有CAP_SYS_RESOURCE功能）可以自由地增加它们的价值，但不能将其降低到初始设置以下。这意味着将oom score adj设置为“相对”，并将oom score adj值设置为正值将始终成功

分别控制主进程、从进程和后台子进程的值

参数：oom-score-adj-values 0 200 800

APPEND ONLY MODE AOF持久化配置

开始/关闭aof

参数：appendonly no

aof文件名称

参数：appendfilename "appendonly.aof"

执行fsync()系统调用刷盘的频率

参数：appendfsync everysec
- 值/可选项
  - everysec：每秒执行，可能会丢失最后一秒的数据。
  - always：每次写操作执行，数据最安全，但是对性能有影响。
  - no：不强制刷盘，由内核决定什么时候刷盘，数据最不安全，性能最好。当有后台保存任务时，关闭appendfsync
当后台在执行save任务或者aof文件的rewrite时，会对磁盘造成大量I/O操作，
在某些Linux配置中，Redis可能会在fsync()系统调用上阻塞很长时间。
注意：目前还没有很好的解决方法，因为即使是在不同的线程中执行fsync()调用也会阻塞write(2)调用。
为了缓解上述问题，可以使用以下选项，防止在进行BGSAVE或者BGREWRITEAOF时在主进程中调用fsync()。
这意味这如果有其它子进程在执行saving任务时，Redis的行为相当于配置了appendfsync none。实际上，这意味着在最坏的情况下（使用Linux默认设置），可能丢失最多30s的日志。
如果您有延迟的问题（性能问题），将此设置为“yes”，否则，设置为“no”。从持久化的角度看，这是最安全的选择。
- no-appendfsync-on-rewrite no

自动重写aof文件

在AOF文件大小增长到了指定的百分比（相对于上次AOF文件大小的增长量）或者最小体积时，自动调用BGREWRITEAOF命令重写AOF文件。
参数：
- auto-aof-rewrite-percentage 100
- auto-aof-rewrite-min-size 64mb

AOF文件末尾被截断

在Redis启动过程的最后，当AOF数据加载回内存时，可能会发现AOF文件被截断。
当运行Redis的系统崩溃时，可能会发生这种情况，尤其是在安装ext4文件系统时，没有data=ordered选项
当Redis本身崩溃或中止，但操作系统仍然正常工作时，这种情况不会发生
Redis可以在出现这种情况时带着错误退出，也可以加载尽可能多的数据（现在是默认值），并在发现AOF文件在最后被截断时启动。
以下选项控制此行为：aof-load-truncated yes
- yes：则会加载一个被截断的aof文件，Redis服务器开始发送日志，通知用户该事件。
- no：服务器将因错误而中止并拒绝启动。当选项设置为“no”时，用户需要使用“redis-check-aof”实用程序修复AOF文件，然后才能重新启动服务器。
- 请注意，如果在中间发现AOF文件已损坏，服务器仍将退出并出现错误。
- 此选项仅适用于Redis尝试从AOF文件读取更多数据，但找不到足够字节的情况。

开启混合持久化

参数： aof-use-rdb-preamble yes
当重写AOF文件时，Redis能够在AOF文件中使用RDB前导，以更快地重写和恢复。
启用此选项后，重写的AOF文件由两个不同的节组成：
- [RDB file]
- [AOF tail]
加载时，Redis识别出AOF文件以“Redis”字符串开头，并加载带前缀的RDB文件，然后继续加载AOF尾部。

LUA SCRIPTING-LUA脚本相关

配置LUA脚本最大执行时长

属性：lua-time-limit 5000
单位毫秒，默认5s。
当脚本运行时间超过限制后，Redis将开始接受其他命令当不会执行，而是会返回BUSY错误。

REDIS CLUSTER 集群配置

允许集群模式

属性：cluster-enabled yes
只有以集群模式启动的Redis实例才能作为集群的节点

集群配置文件

属性：cluster-config-file nodes-6379.conf
由Redis创建维护，不需要我们关心内容，只需要配好位置即可

节点超时时间

属性：cluster-node-timeout 15000
集群模式下，master节点之间会互相发送PING心跳来检测集群master节点的存活状态。
超过配置的时间没有得到响应，则认为该master节点主观宕机。

设置副本有效因子

属性：cluster-replica-validity-factor 10
副本数据太老旧就不会被选为故障转移的启动者。
副本没有简单的方法可以准确测量其“数据年龄”，因此需要执行以下两项检查：
- 第一项
  - 如果有多个复制副本能够进行故障切换，则它们会交换消息，以便尝试为具有最佳复制偏移量的副本提供优势（已经从master接收了尽可能多的数据的节点更可能成为新master）。
  - 复制副本将尝试按偏移量获取其排名，并在故障切换开始时应用与其排名成比例的延迟（排名越靠前的越早开始故障迁移）。
- 第二项
  - 每个副本都会计算最后一次与其主副本交互的时间。
  - 这可以是最后一次收到的PING或命令（如果主机仍处于“已连接”状态），也可以是与主机断开连接后经过的时间（如果复制链路当前已关闭）。
  - 如果最后一次交互太旧，复制副本根本不会尝试故障切换。
第二项的值可以由用户调整。
- 如果自上次与master交互以来，经过的时间大于(node-timeout * cluster-replica-validity-factor) + repl-ping-replica-period，则不会成为新的master。
较大的cluster-replica-validity-factor可能允许数据太旧的副本故障切换到主副本
而太小的值可能会阻止群集选择副本。
最大可用性
- 将cluster-replica-validity-factor设置为0，
- 代表为：无论副本上次与主机交互的时间是什么，副本都将始终尝试故障切换主机（不过，他们总是会尝试应用与其偏移等级成比例的延迟）。
0是唯一能够保证当所有分区恢复时，集群始终能够继续的值（保证集群的可用性）。

设置master故障转移时保留的最少副本数

属性：cluster-migration-barrier 1
群集某个master的slave可以迁移到孤立的master，即没有工作slave的master。
这提高了集群抵御故障的能力，因为如果孤立master没有工作slave，则在发生故障时无法对其进行故障转移。
只有在slave的旧master的其他工作slave的数量至少为给定数量时，slave才会迁移到孤立的master。这个数字就是cluster-migration-barrier。
值为1意味着slave只有在其master至少有一个其他工作的slave时才会迁移，以此类推。
它通常反映集群中每个主机所需的副本数量。
默认值为1（仅当副本的主副本至少保留一个副本时，副本才会迁移）。
要禁用迁移，只需将其设置为非常大的值。
可以设置值0，但仅对调试有用，在生产中很危险。

哈希槽全覆盖检查

属性：cluster-require-full-coverage yes
- no：正在工作的集群的子集继续接受对仍然覆盖的密钥空间部分的查询
- yes：
  - 默认情况下，如果Redis群集节点检测到至少有一个未覆盖的哈希槽（没有可用的节点为其提供服务），它们将停止接受查询。
  - 如果集群部分关闭（例如，一系列哈希槽不再被覆盖），那么所有集群最终都将不可用。
  - 一旦所有插槽再次被覆盖，它就会自动返回可用状态。

是否自动故障转移

属性：cluster-replica-no-failover yes
配置为yes时，可防止副本在主机故障期间尝试故障切换master
主机仍然可以执行手动故障切换。

集群失败时允许节点处理读请求

属性：cluster-allow-reads-when-down no
此选项设置为“yes”时，允许节点在集群处于关闭状态时提供读取流量，只要它认为自己拥有这些插槽。
- 这对两种情况很有用：
  - 适用于在节点故障或网络分区期间应用程序不需要数据一致性的情况。只要节点拥有它应该能够为其提供服务的数据。
  - 适用于不满足三个分片集群，但又希望启用群集模式并在以后扩展的配置。
- 不设置该选项而使用1或2分片配置中的master中断服务会导致整个集群的读/写服务中断。
- 如果设置此选项，则只会发生写中断。
- 如果达不到master的quorum（客观宕机）数值，插槽所有权将不会自动更改。

CLUSTER DOCKER/NAT support

声明访问IP、port
以下三项设置对NAT网络或者Docker的支持。
因为NAT端口映射的IP地址在局域网之外是没办法访问到的，因此在这种情况下，要声明集群的公网网关（NAT映射）/宿主机的IP地址，以便局域网之外也可以访问到NAT映射后的/Docker容器内的Redis集群中的每个实例。
cluster-announce-bus-port集群节点之间进行数据交换的额外端口。
cluster-announce-ip
cluster-announce-port
cluster-announce-bus-port

SLOW LOG 慢日志

Redis的慢查询日志功能用于记录执行时间超过给定时长的命令请求，用户可以通过这个功能产生的日志来监视和优化查询速度

设置慢日志记录阈值

属性：slowlog-log-slower-than 时间
- 单位：微妙
- 超过这个值的命令会被记录到慢日志中，默认10000微秒。

慢日志文件大小

属性：slowlog-max-len 128
- 默认128。
可以通过这个配置改变慢日志文件的最大长度，超过这个长度后最旧的记录会被删除。

LATENCY MONITOR 延迟监控

Redis延迟监控子系统在运行时对不同的操作进行采样，以收集与Redis实例可能的延迟源相关的数据。
通过延迟命令，用户可以打印图表和获取报告。
系统仅记录在等于或大于通过延迟监视器阈值配置指令指定的毫秒数的时间内执行的操作。当其值设置为零时，延迟监视器将关闭。
默认情况下，延迟监控是禁用的
如果没有延迟问题，通常不需要延迟监控，而且收集数据会对性能产生影响，虽然影响很小，但可以在大负载下进行测量。
如果需要，可以在运行时使用命令CONFIG SET latency-monitor-threshold <millists>启用延迟监控。

设置延迟阈值

属性：latency-monitor-threshold 0

EVENT NOTIFICATION 事件通知

Redis keyspace notifications官方网站： https://redis.io/docs/manual/keyspace-notifications/

属性：notify-keyspace-events ""
- 可以在一组类中选择Redis将通知的事件。每个类由一个字符标识：
  - K Keyspace事件，通过__keyspace@<db>__前缀发布。
  - E Keyevent事件，通过__keyevent@<db>__ 前缀发布。
  - g 通用命令（非特定类型），例如DEL，EXPIRE，RENAME…
  - $ String相关命令
  - l List相关命令
  - s Set相关命令
  - h Hash相关命令
  - z Sorted Set（ZSet）相关命令
  - x 过期事件（每次key过期时生成的事件）
  - e 回收事件（达到maxmemory时回收key的事件）
  - t Stream相关命令
  - m Key-miss events，访问的key不存在时触发
  - A g$lshzxet的别名，因此AKE代表了除了m之外的所有事件。
实时的监控keys和values的更改。
Redis可以将key space中发生的事件通过发布/订阅通知客户端。
例如：如果notify-keyspace-events已经启用，并且客户端对数据库0中存储的键foo执行DEL操作，则将通过Pub/Sub发布两条消息：
- PUBLISH keyspace@0:foo del
- PUBLISH keyevent@0:del foo
默认情况下所有事件通知都是关闭的，因为大多数用户不需要这些特性。且需要至少有K或者E时事件通知才会生效。

GOPHER SERVER Gopher协议

属性：gopher-enabled no
- no：关闭Gopher协议（默认）
- yes：开启Gopher协议

ADVANCED CONFIG 高级设置

设置Hash底层数据结构由ziplist转为hashtable的阈值

属性：
- hash-max-ziplist-entries 512
- hash-max-ziplist-value 64
当Hash类型的keys只包含了少量的实体并且实体的大小没有超过给定的阈值时，Hash底层会使用ziplist来存储数据而不是使用hashtable以节省空间。
当一个Hash类型的key包含的实体数量超过了hash-max-ziplist-entries的值或者某个实体的大小超过了hash-max-ziplist-value的值（单位字节），那么底层编码就会升级成hashtable。

设置List底层数据结构quicklist中单个ziplist的大小

属性：list-max-ziplist-size -2
- 默认值是-2
- 总共提供了-5到-1五个选项：
  - -5：最大大小为64Kb，不推荐作为正常情况下的负载
  - -4：最大大小为32Kb，不推荐
  - -3：最大大小为16Kb，大概可能估计好像不是很推荐（原文：probably not recommended）
  - -2：最大大小为8Kb，推荐
  - -1：最大大小为4Kb，推荐
Redis中List数据结构的底层使用的是quicklist的数据结构，本质上是ziplist作为节点串起来的linkedlist。
可以通过该项设置来改变每个ziplist的最大大小
ziplist中的fill属性，超过这个值就会开启一个新的ziplist

设置压缩List中ziplist为quicklistLZF结构

属性：list-compress-depth 0
- 0：代表不压缩，默认值
- 1：两端各一个节点不压缩
- 2：两端各两个节点不压缩
- ...：依次类推。。。
List数据结构两端访问频率比较高，但是中间部分访问频率不是很高的情况，那么使用ziplist存放这部分结构就有点浪费
可以把这部分结构进行压缩（LZF算法压缩）

设置Set底层intset最大entities个数/intset升级为hashtable的阈值

属性：set-max-intset-entries 512
- 默认512个。
Set数据结构只有在一种情况下会使用intset来存储
Set由能转成10进制且数值在64bit有符号整形数值组成。
此配置设置了intset能存储的最大entities数量，超过这个数量会转成hashtable存储。

设置ZSet底层数据结构由ziplist转为skiplist的阈值

属性：
- zset-max-ziplist-entries 128
- zset-max-ziplist-value 64
当超过此属性设置的阈值时，ZSet底层存储结构会由ziplist转为skiplist。

设置HyperLogLog底层稀疏矩阵转为稠密矩阵的阈值

属性：hll-sparse-max-bytes 3000
HyperLogLog当在计数比较小时会使用稀疏矩阵来存储，只有当计数达到阈值时，才会转为稠密矩阵。
超过16000的值是完全无用的，因为这种情况下使用稠密矩阵更加节省内存。
建议值3000左右，以便在不降低太多PFADD速度的情况下获取空间有效编码的好处，稀疏编码的PFADD的时间复杂度为O(N)。
不考虑CPU占用时而考虑内存占用时，这个值可以升到10000左右。

自定义Stream宏节点大小

属性：stream-node-max-bytes 4096
通过stream-node-max-bytes选项修改Stream中每个宏节点能够占用的最大内存

属性：stream-node-max-entries 100
通过stream-node-max-entries参数指定每个宏节点中可存储条目的最大数量。

开启Rehash

属性：activerehashing yes
- yes：能够尽可能快的释放内存，有时候会对请求存在2毫秒的延时，适用与实时性较低的场景
- no：需要非常严格的实时性的情况下可以考虑关闭此功能
Redis将在每100毫秒时使用1毫秒的CPU时间来对redis的hash表进行重新hash，可以降低内存的使用。

客户端输出缓存控制

属性：client-output-buffer-limit <class> <hard limit> <soft limit> <soft seconds>
- 对于三种不同类型的客户端，克制设置不同的限制：
  - normal：一般客户端包含监控客户端
  - replica：副本客户端（slave）
  - pubsub：客户端至少订阅了一个pubsub通道或模式。
示例：ps：（硬限制或软限制都可以通过将其设置为零来禁用，也就是下方配置）
- client-output-buffer-limit normal 0 0 0
- client-output-buffer-limit replica 256mb 64mb 60
- client-output-buffer-limit pubsub 32mb 8mb 60
客户端输出缓冲区限制可用于强制断开由于某种原因从服务器读取数据速度不够快的客户端（一个常见原因是发布/订阅客户端不能像发布服务器生成消息那样快地使用消息）。
一旦达到<hard limit>限制或者达到<soft limit>之后又过了<soft seconds>秒，那么客户端会立即被断开连接。
例如，如果<hard limit>为32兆字节，<soft limit>和<soft seconds>分别为16兆字节，10秒，则如果输出缓冲区的大小达到32兆字节，客户端将立即断开连接，但如果客户端达到16兆字节并连续超过限制10秒，客户端也将断开连接。
默认情况下，普通客户端不受限制，因为它们不会在没有请求（以推送方式）的情况下接收数据，而是在请求之后接收数据，因此只有异步客户端可能会创建一个场景，其中请求数据的速度比读取数据的速度快。
pubsub和副本客户端有一个默认限制，因为订阅者和副本以推送方式接收数据。

配置客户端query buffer大小

属性：client-query-buffer-limit 1gb
客户端query buffer大小不能超过该项配置的值。
每个Client都有一个query buffer(查询缓存区或输入缓存区), 它用于保存客户端的发送命令，
redis server从query buffer获取命令并执行。
如果程序的Key设计不合理，客户端使用大量的query buffer，这会导致redis server比较危险，很容易达到maxmeory限制，导致缓存数据被清空、数据无法写入和oom.

Redis协议批量请求单个字符串限制

属性：proto-max-bulk-len 512mb
- 默认512mb

Redis执行任务频率

属性：hz 10
- 默认值：10
Redis调用一个内部函数来执行许多后台任务，比如在超时时关闭客户端连接，清楚从未被请求过的过期key…
并非所有任务都已相同的频率执行，但Redis根据指定的hz值检查要执行的任务。
提高这个值会让Redis在空闲的时候占用更多的CPU，但同时也会让Redis在有很多keys同时过期时响应更快并且可以更精确的处理超时。
范围在1到500之间，但是超过100通常不是一个好主意。
大多数用户应该使用缺省值10，只有在需要非常低延迟的环境中才应该将值提高到100。

动态hz配置

属性：dynamic-hz yes
- 默认开启。
根据客户端连接的数量动态的调整hz的值，当有更多的客户端连接时，会临时以hz设置基准提高该hz的值。

AOF重写时执行fsync刷盘策略

属性：aof-rewrite-incremental-fsync yes
当一个子系统重写AOF文件时，如果启用了以下选项，则该文件将每生成32MB的数据进行fsync同步。这对于以更增量的方式将文件提交到磁盘并避免较大的延迟峰值非常有用。

保存RDB文件时执行fsync刷盘策略

属性：rdb-save-incremental-fsync yes
当redis保存RDB文件时，如果启用以下选项，则每生成32 MB的数据，文件就会同步一次。这对于以更增量的方式将文件提交到磁盘并避免较大的延迟峰值非常有用。

LFU设置（Redis LFU淘汰策略）

属性：
- lfu-log-factor 10
- lfu-decay-time 1

ACTIVE DEFRAGMENTATION 碎片整理

主动（在线）碎片整理允许Redis服务器压缩内存中数据的少量分配和释放之间的空间（内存碎片），从而回收内存。
碎片化是每个分配器（幸运的是，Jemalloc比较少发生这种情况）和某些工作负载都会发生的自然过程。通常需要重启服务器以降低碎片，或者至少清除所有数据并重新创建。然而，多亏了Oran Agra为Redis 4.0实现的这一功能，这个过程可以在服务器运行时以“hot”的方式在运行时发生（类似热部署的意思，不需要停止服务）。
基本上，当碎片超过某个级别（参见下面的配置选项）时，Redis将通过利用特定的Jemalloc功能（以了解分配是否导致碎片并将其分配到更好的位置）开始在连续内存区域中创建值的新副本，同时释放数据的旧副本。对所有键递增地重复该过程将导致碎片降至正常值。
需要了解的重要事项：
1.默认情况下，此功能被禁用，并且仅当您编译Redis以使用我们随Redis源代码提供的Jemalloc副本时，此功能才有效。这是Linux版本的默认设置。
2.如果没有碎片问题，则无需启用此功能。
3.一旦遇到内存碎片，可以在需要时使用命令CONFIG SET activedefrag yes启用此功能。
配置参数能够微调碎片整理过程的行为。如果你不确定它们是什么意思，最好不要改变默认值。

开启活动碎片整理

属性：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

最大扫描量

# Maximum number of set/hash/zset/list fields that will be processed from
# 将被处理的set/hash/zset/list字段的最大数量
# the main dictionary scan
# 主字典扫描

属性：active-defrag-max-scan-fields 1000

使用后台线程

属性：jemalloc-bg-thread yes

原文作者：

@haiqiang0225