【Redis】Redis配置文件详解（二）

【Redis】Redis配置文件详解（一）https://developer.aliyun.com/article/1393282

LUA SCRIPTING-LUA脚本相关

• 配置LUA脚本最大执行时长

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

lua-time-limit 5000

REDIS CLUSTER 集群配置

• 允许集群模式
  只有以集群模式启动的Redis实例才能作为集群的节点
  

cluster-enabled yes

• 集群配置文件

由Redis创建维护，不需要我们关心内容，只需要配好位置即可

cluster-config-file nodes-6379.conf

• 节点超时时间

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

cluster-node-timeout 15000

• 设置副本有效因子

副本数据太老旧就不会被选为故障转移的启动者。

副本没有简单的方法可以准确测量其“数据年龄”，因此需要执行以下两项检查：

• 如果有多个复制副本能够进行故障切换，则它们会交换消息，以便尝试为具有最佳复制偏移量的副本提供优势（已经从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是唯一能够保证当所有分区恢复时，集群始终能够继续的值（保证集群的可用性）。

cluster-replica-validity-factor 10

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

群集某个master的slave可以迁移到孤立的master，即没有工作slave的master。这提高了集群抵御故障的能力，因为如果孤立master没有工作slave，则在发生故障时无法对其进行故障转移。

只有在slave的旧master的其他工作slave的数量至少为给定数量时，slave才会迁移到孤立的master。这个数字就是cluster-migration-barrier。值为1意味着slave只有在其master至少有一个其他工作的slave时才会迁移，以此类推。它通常反映集群中每个主机所需的副本数量。

默认值为1（仅当副本的主副本至少保留一个副本时，副本才会迁移）。要禁用迁移，只需将其设置为非常大的值。可以设置值0，但仅对调试有用，并且在生产中很危险。

cluster-migration-barrier 1

• 哈希槽全覆盖检查

默认情况下，如果Redis群集节点检测到至少有一个未覆盖的哈希槽（没有可用的节点为其提供服务），它们将停止接受查询。这样，如果集群部分关闭（例如，一系列哈希槽不再被覆盖），那么所有集群最终都将不可用。一旦所有插槽再次被覆盖，它就会自动返回可用状态。

然而，有时您希望正在工作的集群的子集继续接受对仍然覆盖的密钥空间部分的查询。为此，只需将cluster-require-full-coverage选项设置为no。

cluster-require-full-coverage yes

• 是否自动故障转移

当设置为“yes”时，此选项可防止副本在主机故障期间尝试故障切换master。但是，如果被迫这样做，主机仍然可以执行手动故障切换。

这在不同的场景中很有用，尤其是在多个数据中心运营的情况下，如果不在DC（DataCenter？）完全故障的情况下，我们希望其中一方永远不会升级为master。

cluster-replica-no-failover no

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

此选项设置为“yes”时，允许节点在集群处于关闭状态时提供读取流量，只要它认为自己拥有这些插槽。

这对两种情况很有用。第一种情况适用于在节点故障或网络分区期间应用程序不需要数据一致性的情况。其中一个例子是缓存，只要节点拥有它应该能够为其提供服务的数据。

第二个用例适用于不满足三个分片集群，但又希望启用群集模式并在以后扩展的配置。不设置该选项而使用1或2分片配置中的master中断服务会导致整个集群的读/写服务中断。如果设置此选项，则只会发生写中断。如果达不到master的quorum（客观宕机）数值，插槽所有权将不会自动更改。

cluster-allow-reads-when-down no

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

• 设置慢日志记录阈值

超过这个值的命令会被记录到慢日志中，默认10000微秒。

slowlog-log-slower-than <microseconds>

• 慢日志文件大小

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

slowlog-max-len 128

LATENCY MONITOR 延迟监控

Redis延迟监控子系统在运行时对不同的操作进行采样，以收集与Redis实例可能的延迟源相关的数据。

通过延迟命令，用户可以打印图表和获取报告。

系统仅记录在等于或大于通过延迟监视器阈值配置指令指定的毫秒数的时间内执行的操作。当其值设置为零时，延迟监视器将关闭。

默认情况下，延迟监控是禁用的，因为如果没有延迟问题，通常不需要延迟监控，而且收集数据会对性能产生影响，虽然影响很小，但可以在大负载下进行测量。如果需要，可以在运行时使用命令CONFIG SET latency-monitor-threshold 轻松启用延迟监控。

• 设置延迟阈值

latency-monitor-threshold 0

EVENT NOTIFICATION 事件通知

实时的监控keys和values的更改。

Redis可以将key space中发生的事件通过发布/订阅通知客户端。

例如，如果notify-keyspace-events已经启用，并且客户端对数据库0中存储的键foo执行DEL操作，则将通过Pub/Sub发布两条消息：

• PUBLISH keyspace@0:foo del
• PUBLISH keyevent@0:del foo

可以在一组类中选择Redis将通知的事件。每个类由一个字符标识：

• K Keyspace事件，通过__keyspace@__前缀发布。
• E Keyevent事件，通过__keyevent@__ 前缀发布。
• 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不存在时触发
• Ag$lshzxet的别名，因此AKE代表了除了m之外的所有事件。

默认情况下所有事件通知都是关闭的，因为大多数用户不需要这些特性。且需要至少有K或者E时事件通知才会生效。

notify-keyspace-events ""

GOPHER SERVER Gopher协议

开启Gopher协议，大体意思就是说这是一个90年代很流行的Web协议，客户端和服务端实现都非常简单，Redis服务器只需要100行代码就能支持它。一些人想要一个更简单的互联网，另一些人认为主流互联网变得过于受控，为想要一点新鲜空气的人创造一个替代空间是很酷的。总之，为了庆祝🎉Redis诞生10周年，Redis的作者将这个协议支持作为礼物🎁送给了Redis。

# Redis contains an implementation of the Gopher protocol, as specified in
# the RFC 1436 (https://www.ietf.org/rfc/rfc1436.txt).
#
# The Gopher protocol was very popular in the late '90s. It is an alternative
# to the web, and the implementation both server and client side is so simple
# that the Redis server has just 100 lines of code in order to implement this
# support.
#
# What do you do with Gopher nowadays? Well Gopher never *really* died, and
# lately there is a movement in order for the Gopher more hierarchical content
# composed of just plain text documents to be resurrected. Some want a simpler
# internet, others believe that the mainstream internet became too much
# controlled, and it's cool to create an alternative space for people that
# want a bit of fresh air.
#
# Anyway for the 10nth birthday of the Redis, we gave it the Gopher protocol
# as a gift.
#
# --- HOW IT WORKS? ---
#
# The Redis Gopher support uses the inline protocol of Redis, and specifically
# two kind of inline requests that were anyway illegal: an empty request
# or any request that starts with "/" (there are no Redis commands starting
# with such a slash). Normal RESP2/RESP3 requests are completely out of the
# path of the Gopher protocol implementation and are served as usual as well.
#
# If you open a connection to Redis when Gopher is enabled and send it
# a string like "/foo", if there is a key named "/foo" it is served via the
# Gopher protocol.
#
# In order to create a real Gopher "hole" (the name of a Gopher site in Gopher
# talking), you likely need a script like the following:
#
#   https://github.com/antirez/gopher2redis
#
# --- SECURITY WARNING ---
#
# If you plan to put Redis on the internet in a publicly accessible address
# to server Gopher pages MAKE SURE TO SET A PASSWORD to the instance.
# Once a password is set:
#
#   1. The Gopher server (when enabled, not by default) will still serve
#      content via Gopher.
#   2. However other commands cannot be called before the client will
#      authenticate.
#
# So use the 'requirepass' option to protect your instance.
#
# Note that Gopher is not currently supported when 'io-threads-do-reads'
# is enabled.
#
# To enable Gopher support, uncomment the following line and set the option
# from no (the default) to yes.
#
# gopher-enabled no

ADVANCED CONFIG 高级设置

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

当Hash类型的keys只包含了少量的实体并且实体的大小没有超过给定的阈值时，Hash底层会使用ziplist来存储数据而不是使用hashtable以节省空间。

hash-max-ziplist-entries 512
hash-max-ziplist-value 64

当一个Hash类型的key包含的实体数量超过了hash-max-ziplist-entries的值或者某个实体的大小超过了hash-max-ziplist-value的值（单位字节），那么底层编码就会升级成hashtable。

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

Redis中List数据结构的底层使用的是quicklist的数据结构，本质上是ziplist作为节点串起来的linkedlist。可以通过该项设置来改变每个ziplist的最大大小（ziplist中的fill属性，超过这个值就会开启一个新的ziplist）。总共提供了-5到-1五个选项：

• -5：最大大小为64Kb，不推荐作为正常情况下的负载
• -4：最大大小为32Kb，不推荐
• -3：最大大小为16Kb，大概可能估计好像不是很推荐（原话：probably not recommended）
• `-2：最大大小为8Kb，good（原话）
• -1：最大大小为4Kb，good（原话）

默认值是-2

list-max-ziplist-size -2

• 设置压缩List中ziplist为quicklistLZF结构

大神们觉着ziplist不够zip啊，所以再压缩一下吧。实际上是考虑了这样的场景，即List数据结构两端访问频率比较高，但是中间部分访问频率不是很高的情况，那么使用ziplist存放这部分结构就有点浪费，是不是可以把这部分结构进行压缩（LZF算法压缩）呢？这个选项就是进行这个操作的。有下面几个值：

• 0：代表不压缩，默认值
• 1：两端各一个节点不压缩
• 2：两端各两个节点不压缩
• ...：依次类推。。。

list-compress-depth 0

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

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

set-max-intset-entries 512

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

当超过下面设置的阈值时，ZSet底层存储结构会由ziplist转为skiplist。

zset-max-ziplist-entries 128 
zset-max-ziplist-value 64

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

HyperLogLog当在计数比较小时会使用稀疏矩阵来存储，只有当计数达到阈值时，才会转为稠密矩阵。

超过16000的值是完全无用的，因为这种情况下使用稠密矩阵更加节省内存。

建议的值是3000左右，以便在不降低太多PFADD速度的情况下获取空间有效编码的好处，稀疏编码的PFADD的时间复杂度为O(N)。当不考虑CPU占用时而考虑内存占用时，这个值可以升到10000左右。

hll-sparse-max-bytes 3000

• 自定义Stream宏节点大小

可以通过stream-node-max-bytes选项修改Stream中每个宏节点能够占用的最大内存，或者通过stream-node-max-entries参数指定每个宏节点中可存储条目的最大数量。

stream-node-max-bytes 4096
stream-node-max-entries 100

• 开启Rehash

Redis将在每100毫秒时使用1毫秒的CPU时间来对redis的hash表进行重新hash，可以降低内存的使用。当你的使用场景中，有非常严格的实时性需要，不能够接受Redis时不时的对请求有2毫秒的延迟的话，把这项配置为no。如果没有这么严格的实时性要求，可以设置为yes，以便能够尽可能快的释放内存。

activerehashing yes

• 客户端输出缓存控制

客户端输出缓冲区限制可用于强制断开由于某种原因从服务器读取数据速度不够快的客户端（一个常见原因是发布/订阅客户端不能像发布服务器生成消息那样快地使用消息）。

对于三种不同类型的客户端，克制设置不同的限制：

• normal：一般客户端包含监控客户端
• replica：副本客户端（slave）
• pubsub：客户端至少订阅了一个pubsub通道或模式。

每个客户端输出缓冲区限制指令语法：

client-output-buffer-limit <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

• 配置客户端query buffer大小

客户端query buffer大小不能超过该项配置的值。

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

client-query-buffer-limit 1gb

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

默认512mb，可以通过下面选项修改

proto-max-bulk-len 512mb

• Redis执行任务频率

Redis调用一个内部函数来执行许多后台任务，比如在超时时关闭客户端连接，清楚从未被请求过的过期key…

并非所有任务都已相同的频率执行，但Redis根据指定的hz值检查要执行的任务。

默认情况下，hz的值为10.提高这个值会让Redis在空闲的时候占用更多的CPU，但同时也会让Redis在有很多keys同时过期时响应更快并且可以更精确的处理超时。

范围在1到500之间，但是超过100通常不是一个好主意。大多数用户应该使用缺省值10，只有在需要非常低延迟的环境中才应该将值提高到100。

hz 10

• 动态hz配置

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

dynamic-hz yes

• AOF重写时执行fsync刷盘策略

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

aof-rewrite-incremental-fsync yes

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

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

rdb-save-incremental-fsync yes

• LFU设置

设置Redis LFU相关。Redis LFU淘汰策略实现有两个可调整参数：lfu-log-factor和lfu-decay-time。

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
# the main dictionary scan
active-defrag-max-scan-fields 1000

• 使用后台线程

jemalloc-bg-thread yes