一、概述
redis
的配置文件中,有着许多说明和可配置项,了解它们能够更好的使用redis
去解决开发中遇到的困难。
此配置文件基于linux
下的redis-6.2.4
版本。
二、单位换算描述-units
在配置文件开头就有这么一段:
这里描述了一些基本的度量单位是如何与bytes
进行换算的。
并且说明了单位不区分大小写,写1GB
、1gb
、1Gb
、1gB
效果都是一样的。
三、包含配置-include
意思就是说环境中使用的 redis.conf
可以包含其他的 redis.conf
。
解开红框处的注释,被引入的配置文件会整合成一个配置文件来使用。
在使用redis
主从复制,搭建集群的时候,这个配置通常都会使用到。
也就是说多个redis
实例的时候是可以把公共的配置文件提取出来然后再用include
来进行引入的。
四、网络相关配置
4.1 bind
默认情况bind=127.0.0.1
,代表只能接受本机的访问请求。后面的::1
是ipv6
的地址。
在不写的bind
情况下,代表无限制接受任何ip
地址的访问。
生产环境肯定要配置上应用服务器的地址,服务器是需要远程访问的。
4.2 保护模式-protected-mode
保护模式模式默认是开启的。
开启了protected-mode
(保护模式),那么在没有设定bind ip
且没有设密码的情况下,也只接受本机的响应。
如果学习时想要方便,让哪里都可以访问,可以注释掉bind
配置,并且把保护模式改成no
。
4.3 端口号配置-Port
redis
默认端口6379
就是在这里配置的。
多实例时,就是在这里修改每个实例的端口。
4.4 tcp半连接队列长度配置 tcp-backlog
设置tcp
的backlog
,backlog
是一个连接队列,队列总和=未完成三次握手队列 + 已经完成三次握手队列。
在高并发环境下一般需要一个高backlog
值来避免慢客户端连接问题。
因为Linux
内核会将这个值减小到/proc/sys/net/core/somaxconn
的值(128)。
所以需要确认增大/proc/sys/net/core/somaxconn
和/proc/sys/net/ipv4/tcp_max_syn_backlog
(128)
两个值来达到想要的效果。
4.5 超时关闭-timeout
它可以决定一个空闲的客户端维持多少秒会关闭,0
表示关闭该功能。即永不关闭。
默认的配置也是0
。
4.6 tcp心跳检测 tcp-keepalive
对访问客户端的一种心跳检测,每个n
秒检测一次。
单位为秒,如果设置为0
,则不会进行Keepalive
检测,建议设置成60
。
五、通用配置-general
5.1 是否配置为守护进程
配置是否为守护进程,默认值为no
。
让redis
成为守护进程,意味着redis
可以后台运行,所以一般都会把它设置为yes
。
但是,如果redis
是服务脚本启动的,那么不管该参数为什么,redis
都会运行成为一个守护进程。
5.2 pid文件位置配置-pidfile
配置存放pid
文件的位置,每个实例会产生一个不同的pid
文件。
5.3 日志级别配置-loglevel
指定日志记录级别,redis
总共支持四个级别:
debug
:能设置的最高的日志级别,打印所有信息,包括debug信息。verbose
:打印除了debug
日志之外的所有日志。notice
:打印除了debug
和verbose
级别的所有日志。warning
:仅打印非常重要的信息。
默认的日志级别为为notice。
四个级别根据使用阶段来选择,生产环境选择notice
或者warning
。
5.4 日志文件输出路径配置-logfile
该路径默认为空。可以根据自己需要把日志文件输出到指定位置。
5.6 数据库数量配置-databases
设定redis
中库的数量,默认数量是16
,这也是大家众所周知的数量。
5.7 是否总是显示logo
默认是值是no
。
六、密码配置-requirepass
在命令中设置密码,只是临时的。重启redis
服务器,密码就还原了。
永久设置,需要再配置文件中进行设置。
把下面注释解开,把foobared
修改成自己相要的密码即可。
由于redis
响应较高,所以被破解密码时,响应也很快。如果密码不够复杂,那么可能很快就被暴力破
解了,因此尽量使用长且复杂的密码作为redis
的访问密码。
七、客户端最大连接数-maxclients
设置redis
同时可以与多少个客户端进行连接。
这里虽然注释了,但是默认maxclients
就是10000
。如果达到了此限制,redis
则会拒绝新的连接请求。
并且向这些连接请求方发出max number of clients reached
以作回应。
八、内存管理
8.1 redis最大内存配置-maxmemory
建议最好设置,否则,将内存占满,会造成服务器宕机以及部分数据丢失。
这是因为一旦到达内存使用上限,redis
将会试图删除已到期或即将到期的Key。
移除规则可以通过maxmemory-policy
来指定。
8.2 达到最大内存时的移除策略-maxmemory-policy
这里主要有八种策略可以选择:
volatile-lru
:使用LRU
算法移除key
,只对设置了过期时间的Key进行淘汰。(最近最少使用策略)allkeys-lru
: 在所有集合key
中,使用LRU
算法移除key
。volatile-lfu
:使用LFU
算法移除key
,只对设置了过期时间的Key进行淘汰。。allkeys-lfu
:在所有集合key
中,使用LFU
算法移除key
。volatile-random
:只对设置了过期时间的Key进行淘汰,淘汰算法为随机淘汰。allkeys-random
: 在所有集合key
中,移除随机的key
。volatile-ttl
: 移除那些TTL
值最小的key
,即那些最近要过期的key
。noeviction
: 永不删除key,针对写操作,达到最大内存再进行数据装入时会返回错误。
redis使用的默认策略为noeviction。
8.3 设置样本数量-maxmemory-samples
设置样本数量,LRU
算法和最小TTL
算法都并非是精确的算法,而是估算值。
所以可以设置样本的大小,redis
默认会检查这么多个key
并选择其中LRU
的那个。
一般设置3
到7
的数字,数值越小样本越不准确,但性能消耗越小。默认值5
就可以获得很好的效果。
九、AOF持久化配置
9.1 开始/关闭AOF-appendonly
配置文件中默认是关闭aof
的,想要开启把no
改成yes
即可。
9.2 AOF文件名称-appendfilename
默认的文件名称是appendonly.aof
,一般也无需修改这个文件名称。
9.3 持久化同步策略-appendfsync
主要有三种策略可供选择:
everysec
:每秒执行,发送异常时可能会丢失最后一秒的数据。always
:每次写操作执行,数据最安全,但是对性能有影响。no
:不强制刷盘,不主动同步数据,由内核决定什么时候刷盘,数据最不安全,性能最好。
这里三者都提供了,只需要解开想要的持久化同步策略的注释,再把原来的持久化策略注释掉即可
9.4 后台有保存任务时,暂时停止appendfsync
可以理解为,有数据保存到redis
是,暂时停止持久化。默认并没有开启。
9.5 自动重写AOF文件
在AOF
文件大小增长到了指定的百分比(相对于上次AOF
文件大小的增长量)或者最小体积时。
会自动调用BGREWRITEAOF
命令重写AOF
文件。
自动重写AOF
文件的最小大小是64mb
。
9.6 AOF文件末尾截断时的处理策略-aof-load-truncated
默认是true
,发生文件截断时,依旧加载文件。
9.7 开启混合持久化-aof-use-rdb-preamble
开启混合持久化,更快的AOF
重写和启动时数据恢复。
十、配置LUA脚本最大执行时长-lua-time-limit
lua-time-limit
配置的单位毫秒,默认是5
秒。
当脚本运行时间超过限制后,redis
将开始接受其他命令当不会执行,而是会返回BUSY
错误。
十一、redis集群配置-REDIS CLUSTER
11.1 允许开启集群模式-cluster-enabled
注意以集群模式启动的redis
实例才能作为集群的节点。
11.2 集群配置文件-cluster-config-file
这个文件redis
会自行创建和维护,我们只需要解开注释即可,文件名一般都无需更改。
11.3 集群节点超时时间-cluster-node-timeout
单位是毫秒。
在集群模式下,master
节点之间会互相发送PING
心跳来检测集群master
节点的存活状态。
超过配置的时间没有得到响应,则认没有响应的master
节点宕机。
11.4 副本有效因子-cluster-replica-validity-factor
该配置用于决定当redis
集群中,一个master
宕机后,如何选择一个slave
节点完成故障转移自动恢复。
较大的值可能允许数据太旧的副本故障切换到主副本,而太小的值可能会阻止群集选择副本。
如果设置为0
,则不管slave
与 master
之间断开多久,都认为自己有资格成为master
;
11.5 master故障转移时保留的最少副本数-cluster-migration-barrier
默认值为1
(仅当副本的主副本至少保留一个副本时,副本才会迁移)。
要禁用迁移,只需将其设置为非常大的值。可以设置值0
,但仅对调试有用,并且在生产中很危险。
11.6 哈希槽全覆盖检查-cluster-require-full-coverage
默认值是true
,如果希望正在工作的集群的子集继续接受对仍然覆盖的密钥空间部分的查询可以把它设置为no
11.7 自动故障转移-cluster-replica-no-failover
默认值为no
,当设置为yes
时,此选项可防止副本在主机故障期间尝试故障切换master
。
但是,如果被迫这样做,主机仍然可以执行手动故障切换。
11.8 集群宕机时允许节点处理读请求-cluster-allow-reads-when-down
默认值为no
。
11.9 对NAT网络或者Docker的支持
这里还给了个使用示例:
十二、慢日志
慢查询日志功能用于记录执行时间超过给定时长的命令请求。
用户可以通过这个功能产生的日志来监视和优化查询速度。
12.1 慢日志记录阈值-slowlog-log-slower-than
命令执行时间超过这个值就会被记录到慢日志中,默认值是10000
微秒。
12.2 慢日志文件大小-slowlog-max-len
慢日志文件超过这个长度后最旧的记录会被删除,默认值是128条。
十三、延迟监控-latency-monitor-threshold
单位是毫秒,默认情况下,延迟监控是禁用的。
因为如果没有延迟问题,通常不需要延迟监控,而且收集数据会对性能产生影响,
十四、事件通知-notify-keyspace-events
默认情况下所有事件通知都是关闭的,因为大多数用户不需要这些特性。
十五、是否开启gopher协议
默认这个配置是被注释了的,而且默认值也是不开启。
十六、高级设置
16.1 设置Hash底层数据结构由ziplist转为hashtable的阈值
由于hash
类型的数据结构主要有两种:ziplist
(压缩列表),hashtable
(哈希表)。
当field-value
长度较短且个数较少时,使用ziplist
,否则使用hashtable
。
意思就是当一个Hash
类型的key
包含的实体数量超过了hash-max-ziplist-entries
的值或者某个实体的大小超
过了hash-max-ziplist-value
的值(单位字节),那么底层编码就会升级成hashtable
。
16.2 设置List底层数据结构quicklist中单个ziplist的大小
redis
将链表和ziplist
结合起来组成了quicklist
。也就是将多个ziplist
使用双向指针串起来使用。
在配置文件中它可以有五个选项:
- -5:最大大小为
64Kb
,不推荐作为正常情况下的负载 - -4:最大大小为
32Kb
,不推荐 - -3:最大大小为
16Kb
,大概可能估计好像不是很推荐(原话:probably not recommended
) - -2:最大大小为
8Kb
,推荐(原话:good
) - -1:最大大小为
4Kb
,推荐(原话:good
)
默认值是-2。
16.3 设置如何继续压缩List中ziplist
ziplist
还可以继续进行压缩。
可以如下设置它的值:
0
:代表不压缩,默认值1
:两端各一个节点不压缩2
:两端各两个节点不压缩...
:依次类推。。。
16.4 设置set底层intset升级为hashtable的阈值
单位是字节。
16.5 ZSet底层数据结构由ziplist转为skiplist的阈值
单位是字节。
16.6 设置HyperLogLog底层稀疏矩阵转为稠密矩阵的阈值
HyperLogLog
当在计数比较小时会使用稀疏矩阵来存储,只有当计数达到阈值时,才会转为稠密矩阵。
超过16000
的值是完全无用的,因为这种情况下使用稠密矩阵更加节省内存。
注释中给出的建议值是3000
。
这样以便在不降低太多PFADD
速度的情况下获取空间有效编码的好处。稀疏编码的PFADD
的时间复杂度为O(N)
。
当更少考虑CPU
占用时更多考虑内存占用时,这个值可以升到10000
左右。
16.7 自定义Stream宏节点大小
stream-node-max-bytes
选项修改Stream中每个宏节点能够占用的最大内存。
stream-node-max-entries
参数指定每个宏节点中可存储条目的最大数量。
16.8 是否开启Rehash
redis
在每100
毫秒时使用1
毫秒的CPU
时间来对redis
的hash
表进行重新hash
,可以降低内存的使用。
当有非常严格的实时性需要时,不能够接受redis
时不时的对请求有2
毫秒的延迟的话,把这项配置为no
。
如果没有这么严格的实时性要求,可以设置为yes
,以便能够尽可能快的释放内存。
16.9 客户端输出缓存控制
下面的三种客户端说明:
normal
:一般客户端包含监控客户端replica
:副本客户端(slave
)pubsub
:客户端至少订阅了一个pubsub
通道或模式
客户端输出缓冲区限制指令语法:
client-output-buffer-limit <class> <hard limit> <soft limit> <soft seconds>
一旦达到hard limit
限制或者达到soft limit
之后又过了soft seconds
秒,那么客户端会立即被断开连接。
16.10 配置客户端query buffer大小
每个Client
都有一个query buffer
(查询缓存区或输入缓存区), 它用于保存客户端的发送命令。
客户端query buffer
大小不能超过该项配置的值。
16.11 Redis协议批量请求单个字符串限制
proto-max-bulk-len
默认值是512mb
。
16.12 执行任务频率
redis
会调用一个内部函数来执行许多后台任务,比如在超时时关闭客户端连接,清楚从未被请求过的过期key
等。
redis
会根据指定的hz
值检查要执行的任务。它范围在1
到500
之间,但是不超过100
。
大部分情况下应该使用缺省值10
,只有在需要非常低延迟的环境中才应该将值提高到100
。
16.13 动态任务执行频率
根据客户端连接的数量动态的调整hz
的值。
当有更多的客户端连接时,会临时以hz
设置基准提高该hz
的值。默认开启。
16.14 AOF重写时执行fsync策略
当redis
重写AOF
文件时,如果启用了以下选项,则该文件将每生成32MB
的数据进行fsync
同步。
这对于以更增量的方式将文件提交到磁盘并避免较大的延迟峰值非常有用。
16.15 保存RDB文件时执行fsync策略
当redis
保存RDB
文件时,如果启用以下选项,则每生成32 MB
的数据,文件就会同步一次。
这对于以更增量的方式将文件提交到磁盘并避免较大的延迟峰值非常有用。
16.16 LFU设置
这两个值的配置需要结合LUF
算法,这里就不赘述了。
一般就使用默认值即可。
十七、碎片整理
默认情况下,此功能被禁用,并且仅当编译
redis
以使用随redis
源代码提供的emalloc
副本时。此功能才有效。这是
Linux
版本的默认设置。如果没有碎片问题,则无需启用此功能。
一旦遇到内存碎片,可以在需要时使用命令
CONFIG SET activedefrag yes
启用此功能。配置参数能够微调碎片整理过程的行为。如果你不确定它们是什么意思,最好不要改变默认值
17.1 开启活动碎片整理
activedefrag no
17.2 启动活动碎片整理的最小内存碎片阈值
active-defrag-ignore-bytes 100mb
17.3 启动活动碎片整理的最小内存碎片百分比
active-defrag-threshold-lower 10
17.4 尝试释放的最大百分比
active-defrag-threshold-upper 100
17.5 最少CPU使用率
active-defrag-cycle-min 1
17.6 最大CPU使用率
active-defrag-cycle-max 25
17.7 最大扫描量
# Maximum number of set/hash/zset/list fields that will be processed from# the main dictionary scanactive-defrag-max-scan-fields 1000
17.8 是否使用后台线程
jemalloc-bg-thread yes
activedefrag yes`启用此功能。
- 配置参数能够微调碎片整理过程的行为。如果你不确定它们是什么意思,最好不要改变默认值
17.1 开启活动碎片整理
activedefrag no
17.2 启动活动碎片整理的最小内存碎片阈值
active-defrag-ignore-bytes 100mb
17.3 启动活动碎片整理的最小内存碎片百分比
active-defrag-threshold-lower 10
17.4 尝试释放的最大百分比
active-defrag-threshold-upper 100
17.5 最少CPU使用率
active-defrag-cycle-min 1
17.6 最大CPU使用率
active-defrag-cycle-max 25
17.7 最大扫描量
# Maximum number of set/hash/zset/list fields that will be processed from# the main dictionary scanactive-defrag-max-scan-fields 1000
17.8 是否使用后台线程
jemalloc-bg-thread yes