【原】【Redis28】Redis进阶：配置文件（二）

Redis进阶：配置文件（二）

继续我们的配置文件的学习，上回我们已经学习完了整个 Redis 配置文件的前半部分，今天我们就向后半部分进发。这一部分的内容说实话有更多的内容是更偏门的，都不知道是干嘛用的。还是那句话，本着了解的态度，死磕也要过一遍，以后万一哪天用到了，再详细深入的研究也不迟。

MEMORY MANAGEMENT 内存管理

内存管理的内容我们在之前的文章也简单地接触过。主要就是最大内存容量、内存淘汰策略之类的设置。

# 设置最大内存可用数量
# 之前的文章中也已经讲到过了
# maxmemory <bytes>

# 内存淘汰策略
# 当内存容量达到 maxmemory 设置的值之后，如何腾出新的内存空间
# 就是 LFU 、LRU 那些的，也是在内存优化部分讲过的，还记得吧
# maxmemory-policy noeviction

# 在进行内存淘汰的时候每次检查几个键
# LFU、LRU、最小过期时间这些算法都是近似算法而不是精确算法
# 它们的速度和准确性是需要根据系统资源匹配的
# 一般来说 5 就是比较合适的数值了
# 如果你想要更精确，比如 LFU 的 10 ，但这样就需要更多的 CPU 资源
# 设置成 3 的话速度快，但是精确度就降低了
# maxmemory-samples 5

# 大量淘汰内存时阻塞客户端的时间
# maxmemory-eviction-tenacity 10

# 从库是否忽略淘汰内存限制
# replica-ignore-maxmemory yes

# 清理过期键时的CPU占比消耗
# 1-10 越大占用CPU资源越多
# active-expire-effort 1

LAZY FREEING 惰性删除配置

与惰性删除相对应的就是主动删除。在早期的 Redis 版本中，DEL 之类的命令是需要占用主进程进行删除的，如果有大键需要删除，那么就很容易出现 KEYS * 的效果，也就是主进程卡半天。在之后的版本中，出现了惰性删除，也就是先切断连接，然后再由子进程或线程去进行删除，比如 UNLINK 命令。

# 针对有配置淘汰策略的情况下，发生内存淘汰时，是否使用 LazyFree
lazyfree-lazy-eviction no
# 针对过期的Key，开始删除清理时，是否使用 LazyFree
lazyfree-lazy-expire no
# 有些指令在操作时，如 rename ，会隐性地带一个 del 操作，是否使用 LazyFree
lazyfree-lazy-server-del no
# 对于从库，在刚启动，没有同步主库数据前，会先 FLUSHALL ，这时是否使用 LazyFree
replica-lazy-flush no

# 修改 del 的默认行为，让它变得和 unlink 一样
lazyfree-lazy-user-del no

# FLUSHDB, FLUSHALL, 和 SCRIPT FLUSH ，本来是支持用一个参数 [SYNC|ASYNC] 来指定同步还是异步操作的
# 开启这个之后，就让它们都变成异步的，不需要加参数了
lazyfree-lazy-user-flush no

THREADED I/O 线程IO配置

在线程相关的文章中，我们也已经学习过了，就只有两个配置。

# 线程数量
# io-threads 4

# 开启 IO 多线程功能，默认是关闭的
# io-threads-do-reads no

KERNEL OOM CONTROL 内核OOM控制

这一块的配置主要是和 Linux 的 OOM 机制有关，下面的注释中也已经写了。对于 OOM Killer 我也不是太了解，将来学习 Linux 相关的内容时我们再进行深入的学习了解。

# 在 Linux 中，如果内存不足会启动 OOM Killer 去杀进程
# 开启这个功能将可以让 Redis 控制 oom_score_adj 函数的值
# 在主进程被 kill 之前，根据数据库的情况去 kill 子进程
# 可以配置 no、yes、absolute、relative 等值
oom-score-adj no

# 当 oom-score-adj 被开启之后，这里就是它的参考值
oom-score-adj-values 0 200 800

KERNEL transparent hugepage CONTROL THP控制

同样也是 Linux 中的一种机制，不多赘述，有兴趣的小伙伴可以先去搜索了解一下 THP 是干嘛的，其实也是一种内存相关的优化策略。

# 是否启用 thp 机制 
disable-thp yes

APPEND ONLY MODE AOF相关配置

AOF 相关的配置，我们在持久化的文章中也学习过。一个是开启 AOF ，一个是 AOF 持久化方式，这两个是比较重要的配置。

# 是否开启 AOF
appendonly no

# AOF 文件名称
appendfilename "appendonly.aof"

# AOF 持久化方式
# appendfsync always
appendfsync everysec
# appendfsync no

# AOF 在自动重写和命令行 bgrewarite 时会冲突
# 设置为 no ，会阻塞一个一个去写
# 设置为 yes ，先写入缓冲区，再写文件，如果这时出现问题，可能会有丢失
no-appendfsync-on-rewrite no

# 重写时的文件扩容优化配置
# 学习 AOF 的时候讲到过
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# AOF 文件可能因为各种原因是不完整的
# 如果选择的是yes，当截断的aof文件被导入的时候，会自动发布一个log给客户端然后load
# 如果是no，用户必须手动redis-check-aof修复AOF文件才可以。默认值为 yes。
aof-load-truncated yes

# 重写时是否进行 RDB 压缩
# 之前讲过啦
aof-use-rdb-preamble yes

LUA SCRIPTING LUA脚本配置

LUA 脚本相关的配置，只有一个配置选项，就是 Lua 脚本执行的超时时间。

# 一个lua脚本执行的最大时间，单位为ms
lua-time-limit 5000

REDIS CLUSTER 分布式相关配置

Cluster 的配置在相关的文章中也已经学习过了。要注意的是，开启 Cluster 之后，会动态写入一些 Cluster 中各节点的配置信息。

# 是否开启 Cluster 模式
# cluster-enabled yes

# node 文件名称
# cluster-config-file nodes-6379.conf

# 节点超时时间
# cluster-node-timeout 15000

# 当一个Master拥有多少个正常的Slave时就要割让一个Slave出来
# 例如设置为2，表示当一个Master拥有2个可用的Slave时，它的一个Slave会尝试迁移
# cluster-migration-barrier 1

# 允许从库迁移
# cluster-allow-replica-migration yes

# 默认情况下，集群全部的slot有节点负责，集群状态才为ok，才能提供服务
# 设置为no，可以在slot没有全部分配的时候提供服务
# 不建议打开该配置，这样会造成分区的时候，小分区的master一直在接受写请求，而造成很长时间数据不一致
# cluster-require-full-coverage yes

# 设置是否进行故障转移
# 设置为 yes 表示不会进行自动故障转移
# cluster-replica-no-failover no

# 表示当集群因主节点数量达不到最小值或有散列槽没有分配而被标记为失效时, 节点将停止所有的客户端通讯
# cluster-allow-reads-when-down no

CLUSTER DOCKER/NAT support 集群Docker/NAT环境支持

在通过 Docker 使用 Cluster 时的一些配置，Docker 还了解不多，没有太多解释啦。

# cluster-announce-ip 10.1.1.5
# cluster-announce-tls-port 6379
# cluster-announce-port 0
# cluster-announce-bus-port 6380

SLOW LOG 慢日志配置

是的，你没看错，Redis 中也有慢查询，同样也会有慢查询日志。只不过这些日志不会记录在某个日志文件中，而是在 Redis 服务端直接保存在一个慢日志列表中。

# 指定执行时间超过多少微秒(1秒等于1000 000微秒)的命令请求会被记录到日志上
slowlog-log-slower-than 10000
# 日志最大保存数量
slowlog-max-len 128

如果 slowlog-log-slower-than 0 就会记录所有的命令，slowlog-log-slower-than -1 则会对于任何命令都不进行记录，只要是小于 0 的数字都不会进行记录。在客户端，我们可以通过 SHOWLOG 命令进行查看。

slowlog get [n]

LATENCY MONITOR 延迟监控配置

# 超过配置的时间，将该事件记录下来
latency-monitor-threshold 0

我们可以使用 DEBUG 命令模拟耗时操作，然后通过 LATENCY LATEST 命令可以查看到事件名、最近延迟的Unix时间戳、最近的延迟、最大延迟等。

127.0.0.1:6379> CONFIG SET latency-monitor-threshold 100
OK
127.0.0.1:6379> debug sleep 1
OK
(1.07s)
127.0.0.1:6379> LATENCY latest
1) 1) "command"
   2) (integer) 1657240891
   3) (integer) 1073
   4) (integer) 1073

EVENT NOTIFICATION 事件通知

这个功能是让客户端通过发布/订阅给定的频道或者模式，来获知数据库中键的变化，以及数据库中命令的执行情况。它的参数比较多，包括 K 键空间通知、E 键事件通知、s Set命令等等。

# 默认不开启，可以填入需要开启的通知内容
notify-keyspace-events ""

假如我们想要接收键事件通知和Set命令通知，可以设置为 Es 。

GOPHER SERVER gopher服务支持

gopher 是啥？不是 Go 语言相关的东西，具体是啥我也没查出来个所以然，所以这里就不多说了。它的配置就是一个开关，表示开启或关闭。

gopher-enabled no

ADVANCED CONFIG 高级配置

高级配置里面的东西比较多，不过大部分其实是我们之前学习的内部数据结构相关的配置，在 Redis进阶：内存优化https://mp.weixin.qq.com/s/QNsroDmtV7a4F2k68VNlmw 中有过详细的说明。

# Hash 类型底层数据结构使用 ziplist 的优化限值
hash-max-ziplist-entries 512
hash-max-ziplist-value 64

# List 类型使用 ziplist 大小限值
list-max-ziplist-size -2

# List 中 quicklist 两端压缩节点个数
# 0表示都不压缩
list-compress-depth 0

# set 类型中存储纯 int 数据时的最大数量
set-max-intset-entries 512

# sorted set 类型底层数据结构使用 ziplist 的优化限值
zset-max-ziplist-entries 128
zset-max-ziplist-value 64

# HyperLogLog 使用稀疏数据结构的限值
hll-sparse-max-bytes 3000

# Streams单个节点的字节数，以及切换到新节点之前可能包含的最大项目数
stream-node-max-bytes 4kb
stream-node-max-entries 100

# 主动重新散列每100毫秒CPU时间使用1毫秒，以帮助重新散列主Redis散列表（将顶级键映射到值）
activerehashing yes

# 客户端输出缓冲配置 分别针对一般情况、复制、订阅三种模式
# 超过限制的客户端将断开连接，可优化缓冲区溢出问题
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit replica 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60

# 客户端查询缓冲区累积的新命令大小
# client-query-buffer-limit 1gb

# 在Redis协议中，批量请求（即表示单个字符串的元素）通常限制为512 MB
# proto-max-bulk-len 512mb

# 默认情况下，hz设置为 10 及更高值时，在Redis处于空闲状态下，将使用更多CPU
# 可以配置 1-500 仅在需要非常低延迟的环境中将此值提高到100
hz 10

# 启用动态HZ时，实际配置的HZ将用作基线，但是一旦连接了更多客户端，将根据实际需要使用配置的HZ值的倍数
dynamic-hz yes

# 当一个子进程重写AOF文件时，如果启用下面的选项，则文件每生成32M数据会被同步
aof-rewrite-incremental-fsync yes

# 当redis保存RDB文件时，如果启用了以下选项，则每生成32 MB数据将对文件进行fsync。 这对于以递增方式将文件提交到磁盘并避免大延迟峰值非常有用
rdb-save-incremental-fsync yes

# 设置的越大，key的计数值就越难增长，因此就要求key的访问频度较高才能避免被淘汰
# lfu-log-factor 10
# 表示隔多久将计数器的值减一
# lfu-decay-time 1

ACTIVE DEFRAGMENTATION 活动碎片整理

最后就是一些活跃碎片整理，其实就是内存碎片的整理。这一块又是基础知识了，不知道大家有了解过内存对齐不？完美的对齐肯定是不存在的，所以一块内存页中多少都会有些闲置浪费空间。另外还有删除数据之后产生的碎片内容。

这一块的配置主要就是让不让 Redis 进行内存整理压缩，针对内存中数据的小分配和取消分配之间的剩余空间，从而让内存的利用更有效率。和大家在 Windows 上使用磁盘碎片整理是一个意思。

最后还有一小块 CPU 绑定的配置，放在一起看了。

# 是否允许进行碎片整理
# 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


# io线程 cpu 绑定到指定CPU核，可以减少CPU切换，后面几个都是，能够起到优化速度效果
# server_cpulist 0-7:2
#
# 设置 bio 绑定到指定CPU核，后台子线程
# bio_cpulist 1,3
#
# 设置 AOF REWRITE 子进程 绑定到指定的CPU核
# aof_rewrite_cpulist 8-11
#
# 设置 BGSAVE 子进程 绑定到指定的CPU核
# bgsave_cpulist 1,10-11

总结

好了，整个配置文件中的内容咱们都过了一遍，当然，并不是非常深入的每一个都去尝试了一下。而且大部分注释也是根据官方的英文翻译的，有一些真的是不知道在讲啥。不过就像最开始说的，咱们不管怎么样，先过一遍，有个印象就够了。