0%

redis配置

redis配置

注意:我使用的版本是6.0.10,不同版本可能略有差别

redis的配置主要集中在redis.conf文件中,接下来就来看一下redis.conf中包含了哪些内容

INCLUDES模块

该模块下可以使用include来包含其他的redis配置文件,将其他配置文件引入进来

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

GENERAL模块

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
#是否为守护线程 默认为no 如果需要在后台运行,改为yes
daemonize no

supervised no

#pid文件,运行多个redis时,指定不同的的pid文件和端口
pidfile /var/run/redis_6379.pid

# 日志级别 有四个级别
# debug verbose notice warning
loglevel notice

#日志文件 如果为空,控制台输出
logfile ""

#系统日志是否打开,是否把日志输出到syslog中
# syslog-enabled no

#如果系统日志打开,指定syslog里的日志标志,日志标识为redis
# syslog-ident redis

#指定syslog设备,值可以是USER或LOCAL0-LOCAL7
# syslog-facility local0

#数据库个数,可以使用 select <dbid>来切换数据库,默认使用的数据库是0
databases 16

always-show-logo yes

MODULES模块

1
2
3
4
5
6
7
################################## MODULES #####################################

# Load modules at startup. If the server is not able to load modules
# it will abort. It is possible to use multiple loadmodule directives.
#
# loadmodule /path/to/my_module.so
# loadmodule /path/to/other_module.so

NETWORK模块

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
################################## NETWORK #####################################

#指定redis和哪个网卡进行绑定,如果设置为0.0.0.0,将接收所有请求,默认Redis会响应本机所有可用网卡的连接请求
bind 127.0.0.1 ::1


protected-mode yes

#监听端口
port 6379

#设置tcp的backlog,backlog其实是一个连接队列,backlog队列总和=未完成三次握手队列 + 已经完成三次握手队列。在高并发环境下需要一个高backlog值来避免慢客户端连接问题。注意Linux内核会将这个值减小到/proc/sys/net/core/somaxconn的值,所以需要确认增大somaxconn和
tcp_max_syn_backlog两个值来达到想要的效果
tcp-backlog 511

# Unix socket.
#
#
# unixsocket /tmp/redis.sock
# unixsocketperm 700

# 设置客户端连接的超时时间,单位秒,如果客户端超过该时间没有发出任何指令,则关闭该连接,0表示不关闭
timeout 0

#单位为秒,如果设置为0,则不会进行Keepalive检测,建议设置成60
tcp-keepalive 300

TLS/SSL模块

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
################################# TLS/SSL #####################################

#
# port 0
# tls-port 6379


#
# tls-cert-file redis.crt
# tls-key-file redis.key

# Configure a DH parameters file to enable Diffie-Hellman (DH) key exchange:
#
# tls-dh-params-file redis.dh


#
# tls-ca-cert-file ca.crt
# tls-ca-cert-dir /etc/ssl/certs

#
# tls-auth-clients no
# tls-auth-clients optional

#
# tls-replication yes

#
# tls-cluster yes

#
# tls-protocols "TLSv1.2 TLSv1.3"

#
# tls-ciphers DEFAULT:!MEDIUM

#
# tls-ciphersuites TLS_CHACHA20_POLY1305_SHA256

#
# tls-prefer-server-ciphers yes

#
# tls-session-caching no

#
# tls-session-cache-size 5000

#
# tls-session-cache-timeout 60

SNAPSHOTTING模块

快照模块主要是用来配置RDB持久化的

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
################################ SNAPSHOTTING  ################################
# 如果想禁用RDB持久化的策略,只要不设置任何save指令,或者给save传入一个空字符串参数也可以
如果用户开启了RDB快照功能,那么在Redis持久化数据到磁盘时如果出现失败,默认情况下,Redis会停止接受所有的写请求。这样做的好处在于可以让用户很明确的知道内存中的数据和磁盘上的数据已经存在不一致了。如果下一次RDB持久化成功,redis会自动恢复接受写请求
#进行数据库快照存储的条件
#900秒内有一个key发生变化
save 900 1
#300秒内有10个key发生变化
save 300 10
# 60秒内有10000个key发生变化
save 60 10000

# 如果配置成no,表示你不在乎数据不一致或者有其他的手段发现和控制这种不一致,那么在快照写入失败时,也能确保redis继续接受新的写请求
stop-writes-on-bgsave-error yes

#rdb快照是否进行压缩,但是会消耗cpu
rdbcompression yes

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

# rdb快照文件名
dbfilename dump_6379.rdb

rdb-del-sync-files no
#存储位置,默认是当前路径
dir /usr/local/var/db/redis/

REPLICATION模块

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
################################# REPLICATION #################################
# 指定某一个redis作为另一个redis的从服务器,通过指定IP和端口来设置主redis。建议为从redis设置一个不同频率的快照持久化的周期,或者为从redis配置一个不同的服务端口
# replicaof <masterip> <masterport>


# 如果主redis设置了验证密码的话(使用requirepass来设置),则在从redis的配置中要使用masterauth来设置校验密码,否则的话,主redis会拒绝从redis的访问请求
# masterauth <master-password>
#

#
# masteruser <username>
#

# 设置当从redis失去了与主redis的连接,或者主从同步正在进行中时,redis该如何处理外部发来的访问请求。
如果设置为yes(默认),则从redis仍会继续响应客户端的读写请求。如果设置为no,则从redis会对客户端的请求返回“SYNC with master in progress”,当然也有例外,当客户端发来INFO请求和SLAVEOF请求,从redis还是会进行处理。从redis2.6版本之后,默认从redis为只读
replica-serve-stale-data yes

# 设置从Redis为只读
replica-read-only yes


repl-diskless-sync no


repl-diskless-sync-delay 5


#
# "disabled" - Don't use diskless load (store the rdb file to the disk first)
# "on-empty-db" - Use diskless load only when it is completely safe.
# "swapdb" - Keep a copy of the current db contents in RAM while parsing
# the data directly from the socket. note that this requires
# sufficient memory, if you don't have it, you risk an OOM kill.
repl-diskless-load disabled


# 设置从redis会向主redis发出PING包的周期,默认是10秒
# repl-ping-replica-period 10


# 设置主从同步的超时时间,要确保这个时限比repl-ping-slave-period的值要大,否则 每次主redis都会认为从redis超时
# repl-timeout 60

# 设置在主从同步时是否禁用TCP_NODELAY,如果开启,那么主redis会使用更少的TCP包和更少的带宽来向从redis传输数据。但是这可能会增加一些同步的延迟,大概会达到40毫秒左右。如果关闭,那么数据同步的延迟时间会降低,但是会消耗更多的带宽
repl-disable-tcp-nodelay no

# 设置同步队列长度。队列长度(backlog)是主redis中的一个缓冲区,在与 从redis断开连接期间,主redis会用这个缓冲区来缓存应该发给从redis的数据。这样的话,当 从redis重新连接上之后,就不必重新全量同步数据,只需要同步这部分增量数据即可
# repl-backlog-size 1mb

# 设置主redis要等待的时间长度,如果主redis等了这么长时间之后,还是无法连接到从redis,那么缓冲队列中的数据将被清理掉。设置为0,则表示永远不清理。默认是1个小时
# repl-backlog-ttl 3600

#设置从redis优先级,在主redis持续工作不正常的情况,优先级高的从redis将会升级为主redis。而编号越小,优先级越高。当优先级被设置为0时,这个从redis将永远也不会被选中。默认的优先级为100。
replica-priority 100



# 设置执行写操作所需的最少从服务器数量,如果至少有这么多个从服务器, 并且这些服务器的延迟值都少于 min-replicas-max-lag 秒, 那么主服务器就会执行客户端请求的写操作
# min-replicas-to-write 3

#设置最大连接延迟的时间, min-replicas-to-write和min-replicas-max-lag中有一个被置为0,则这个特性将被关闭。
# min-replicas-max-lag 10


# replica-announce-ip 5.5.5.5
# replica-announce-port 1234

KEYS TRACKING模块

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
############################### KEYS TRACKING #################################

# Redis implements server assisted support for client side caching of values.
# This is implemented using an invalidation table that remembers, using
# 16 millions of slots, what clients may have certain subsets of keys. In turn
# this is used in order to send invalidation messages to clients. Please
# check this page to understand more about the feature:
#
# https://redis.io/topics/client-side-caching
#
# When tracking is enabled for a client, all the read only queries are assumed
# to be cached: this will force Redis to store information in the invalidation
# table. When keys are modified, such information is flushed away, and
# invalidation messages are sent to the clients. However if the workload is
# heavily dominated by reads, Redis could use more and more memory in order
# to track the keys fetched by many clients.
#
# For this reason it is possible to configure a maximum fill value for the
# invalidation table. By default it is set to 1M of keys, and once this limit
# is reached, Redis will start to evict keys in the invalidation table
# even if they were not modified, just to reclaim memory: this will in turn
# force the clients to invalidate the cached values. Basically the table
# maximum size is a trade off between the memory you want to spend server
# side to track information about who cached what, and the ability of clients
# to retain cached objects in memory.
#
# If you set the value to 0, it means there are no limits, and Redis will
# retain as many keys as needed in the invalidation table.
# In the "stats" INFO section, you can find information about the number of
# keys in the invalidation table at every given moment.
#
# Note: when key tracking is used in broadcasting mode, no memory is used
# in the server side so this setting is useless.
#
# tracking-table-max-keys 1000000

MEMORY MANAGEMENT模块

redis的淘汰机制

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
############################## MEMORY MANAGEMENT ################################

# redis能够使用的最大内存。一旦到达内存使用上限,redis将会试图移除内部数据,移除规则可以通过maxmemory-policy来指定。如果redis无法根据移除规则来移除内存中的数据,或者设置了“不允许移除”,那么redis则会针对那些需要申请内存的指令返回错误信息,比如SET、LPUSH等。但是对于无内存申请的指令,仍然会正常响应,比如GET等。
如果你的redis是主redis(说明你的redis有从redis),那么在设置内存使用上限时,需要在系统中留出一些内存空间给同步队列缓存,只有在你设置的是“不移除”的情况下,才不用考虑这个因素
# maxmemory <bytes>

#设置了过期时间的键,选取最近最少使用的键抛弃(Least Recently Used)
# volatile-lru -> Evict using approximated LRU, only keys with an expire set.
#对于所有的键,选取最近最少使用的键抛弃(Least Recently Used)
# allkeys-lru -> Evict any key using approximated LRU.
#设置了过期时间的键,选取最少频率使用的键抛弃(Least Frequently Used)
# volatile-lfu -> Evict using approximated LFU, only keys with an expire set.
#对于所有的键,选取最少频率使用的键抛弃(Least Frequently Used)
# allkeys-lfu -> Evict any key using approximated LFU.
#对于设置过期时间的键,随机选取键抛弃
# volatile-random -> Remove a random key having an expire set.
#对于所有的键,随机选取键抛弃
# allkeys-random -> Remove a random key, any key.
#抛弃最近要过期的键
# volatile-ttl -> Remove the key with the nearest expire time (minor TTL)
#默认策略,不淘汰,如果内存已满,写操作返回错误
# noeviction -> Don't evict anything, just return an error on write operations.
# maxmemory-policy noeviction


# 设置样本数量,LRU算法和最小TTL算法都并非是精确的算法,而是估算值, 所以你可以设置样本的大小,redis默认会检查这么多个key并选择其中LRU的那个
# maxmemory-samples 5


# replica-ignore-maxmemory yes


# active-expire-effort 1

CLIENTS模块

1
2
3
4
################################### CLIENTS ####################################

# 限制同时连接的客户端数量,超过这个数量将不再接受其他连接请求
# maxclients 10000

LAZY FREEING模块

1
2
3
4
5
6
7
8
9
10
############################# LAZY FREEING ####################################


lazyfree-lazy-eviction no
lazyfree-lazy-expire no
lazyfree-lazy-server-del no
replica-lazy-flush no


lazyfree-lazy-user-del no

THREADED I/O模块

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
################################ THREADED I/O #################################

# Redis is mostly single threaded, however there are certain threaded
# operations such as UNLINK, slow I/O accesses and other things that are
# performed on side threads.
#
# Now it is also possible to handle Redis clients socket reads and writes
# in different I/O threads. Since especially writing is so slow, normally
# Redis users use pipelining in order to speed up the Redis performances per
# core, and spawn multiple instances in order to scale more. Using I/O
# threads it is possible to easily speedup two times Redis without resorting
# to pipelining nor sharding of the instance.
#
# By default threading is disabled, we suggest enabling it only in machines
# that have at least 4 or more cores, leaving at least one spare core.
# Using more than 8 threads is unlikely to help much. We also recommend using
# threaded I/O only if you actually have performance problems, with Redis
# instances being able to use a quite big percentage of CPU time, otherwise
# there is no point in using this feature.
#
# So for instance if you have a four cores boxes, try to use 2 or 3 I/O
# threads, if you have a 8 cores, try to use 6 threads. In order to
# enable I/O threads use the following configuration directive:
#
# io-threads 4
#
# Setting io-threads to 1 will just use the main thread as usual.
# When I/O threads are enabled, we only use threads for writes, that is
# to thread the write(2) syscall and transfer the client buffers to the
# socket. However it is also possible to enable threading of reads and
# protocol parsing using the following configuration directive, by setting
# it to yes:
#
# io-threads-do-reads no
#
# Usually threading reads doesn't help much.
#
# NOTE 1: This configuration directive cannot be changed at runtime via
# CONFIG SET. Aso this feature currently does not work when SSL is
# enabled.
#
# NOTE 2: If you want to test the Redis speedup using redis-benchmark, make
# sure you also run the benchmark itself in threaded mode, using the
# --threads option to match the number of Redis threads, otherwise you'll not
# be able to notice the improvements.

KERNEL OOM CONTROL模块

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
############################ KERNEL OOM CONTROL ##############################

# On Linux, it is possible to hint the kernel OOM killer on what processes
# should be killed first when out of memory.
#
# Enabling this feature makes Redis actively control the oom_score_adj value
# for all its processes, depending on their role. The default scores will
# attempt to have background child processes killed before all others, and
# replicas killed before masters.
#
# Redis supports three options:
#
# no: Don't make changes to oom-score-adj (default).
# yes: Alias to "relative" see below.
# absolute: Values in oom-score-adj-values are written as is to the kernel.
# relative: Values are used relative to the initial value of oom_score_adj when
# the server starts and are then clamped to a range of -1000 to 1000.
# Because typically the initial value is 0, they will often match the
# absolute values.
oom-score-adj no

# When oom-score-adj is used, this directive controls the specific values used
# for master, replica and background child processes. Values range -2000 to
# 2000 (higher means more likely to be killed).
#
# Unprivileged processes (not root, and without CAP_SYS_RESOURCE capabilities)
# can freely increase their value, but not decrease it below its initial
# settings. This means that setting oom-score-adj to "relative" and setting the
# oom-score-adj-values to positive values will always succeed.
oom-score-adj-values 0 200 800

APPEND ONLY MODE模块

AOF持久化配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
############################## APPEND ONLY MODE ###############################
#开启aof持久化策略,将接收到的每次写操作请求都追加到aof文件中,在redis重启时,会加载aof文件,优先级比rdb高
appendonly no

# aof文件名
appendfilename "appendonly.aof"

# 设置aof持久化频率
# 有三种选择
# always 每次写都强制调用fsync,这种模式下,redis会相对较慢,但数据最安全
# everysec 每秒启用一次fsync
# no 不调用fsync()。而是让操作系统自行决定sync的时间。这种模式下,redis的性能会最快
# appendfsync always
appendfsync everysec
# appendfsync no

# 设置当redis在rewrite的时候,是否允许appendsync。因为redis进程在进行AOF重写的时候,fsync()在主进程中的调用会被阻止,也就是redis的持久化功能暂时失效。默认为no,这样能保证数据安全
no-appendfsync-on-rewrite no

# 设置自动进行AOF重写的基准值,也就是重写启动时的AOF文件大小,假如redis自启动至今还没有进行过重写,那么启动时aof文件的大小会被作为基准值。这个基准值会和当前的aof大小进行比较。如果当前aof大小超出所设置的增长比例,则会触发重写。如果设置auto-aof-rewrite-percentage为0,则会关闭此重写功能
auto-aof-rewrite-percentage 100
# 设置一个最小大小,是为了防止在aof很小时就触发重写
auto-aof-rewrite-min-size 64mb


aof-load-truncated yes

aof-use-rdb-preamble yes

SECURITY模块

默认情况下使用redis不需要进行安全认证,因为在配置文件中requirepass是注释掉的

可以使用redis命令来查看当前的密码

1
config get requirepass

当然也可以使用redis命令来设置密码

1
config set requirepass 123456

设置密码之后再次进入客户端就需要输入密码进行认证了

1
auth 123456
1
2
3
4
5
6
7
8
9
10
11
################################## SECURITY ###################################

acllog-max-len 128

# aclfile /etc/redis/users.acl

# 设置客户端连接的密码
# requirepass foobared

# 对命令进行重命名,只读的从redis并不适合直接暴露给不可信的客户端。为了尽量降低风险,可以使用rename-command指令来将一些可能有破坏力的命令重命名,避免外部直接调用。如果要禁用某些命令,那就重命名为""就可以了
# rename-command CONFIG ""

LUA SCRIPTING模块

1
2
3
4
################################ LUA SCRIPTING  ###############################

#设置lua脚本的最大运行时间,单位是毫秒,如果此值设置为0或负数,则既不会有报错也不会有时间限制
lua-time-limit 5000

REDIS CLUSTER模块

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
################################ REDIS CLUSTER  ###############################

# Normal Redis instances can't be part of a Redis Cluster; only nodes that are
# started as cluster nodes can. In order to start a Redis instance as a
# cluster node enable the cluster support uncommenting the following:
#
# cluster-enabled yes

# Every cluster node has a cluster configuration file. This file is not
# intended to be edited by hand. It is created and updated by Redis nodes.
# Every Redis Cluster node requires a different cluster configuration file.
# Make sure that instances running in the same system do not have
# overlapping cluster configuration file names.
#
# cluster-config-file nodes-6379.conf

# Cluster node timeout is the amount of milliseconds a node must be unreachable
# for it to be considered in failure state.
# Most other internal time limits are a multiple of the node timeout.
#
# cluster-node-timeout 15000

# A replica of a failing master will avoid to start a failover if its data
# looks too old.
#
# There is no simple way for a replica to actually have an exact measure of
# its "data age", so the following two checks are performed:
#
# 1) If there are multiple replicas able to failover, they exchange messages
# in order to try to give an advantage to the replica with the best
# replication offset (more data from the master processed).
# Replicas will try to get their rank by offset, and apply to the start
# of the failover a delay proportional to their rank.
#
# 2) Every single replica computes the time of the last interaction with
# its master. This can be the last ping or command received (if the master
# is still in the "connected" state), or the time that elapsed since the
# disconnection with the master (if the replication link is currently down).
# If the last interaction is too old, the replica will not try to failover
# at all.
#
# The point "2" can be tuned by user. Specifically a replica will not perform
# the failover if, since the last interaction with the master, the time
# elapsed is greater than:
#
# (node-timeout * cluster-replica-validity-factor) + repl-ping-replica-period
#
# So for example if node-timeout is 30 seconds, and the cluster-replica-validity-factor
# is 10, and assuming a default repl-ping-replica-period of 10 seconds, the
# replica will not try to failover if it was not able to talk with the master
# for longer than 310 seconds.
#
# A large cluster-replica-validity-factor may allow replicas with too old data to failover
# a master, while a too small value may prevent the cluster from being able to
# elect a replica at all.
#
# For maximum availability, it is possible to set the cluster-replica-validity-factor
# to a value of 0, which means, that replicas will always try to failover the
# master regardless of the last time they interacted with the master.
# (However they'll always try to apply a delay proportional to their
# offset rank).
#
# Zero is the only value able to guarantee that when all the partitions heal
# the cluster will always be able to continue.
#
# cluster-replica-validity-factor 10

# Cluster replicas are able to migrate to orphaned masters, that are masters
# that are left without working replicas. This improves the cluster ability
# to resist to failures as otherwise an orphaned master can't be failed over
# in case of failure if it has no working replicas.
#
# Replicas migrate to orphaned masters only if there are still at least a
# given number of other working replicas for their old master. This number
# is the "migration barrier". A migration barrier of 1 means that a replica
# will migrate only if there is at least 1 other working replica for its master
# and so forth. It usually reflects the number of replicas you want for every
# master in your cluster.
#
# Default is 1 (replicas migrate only if their masters remain with at least
# one replica). To disable migration just set it to a very large value.
# A value of 0 can be set but is useful only for debugging and dangerous
# in production.
#
# cluster-migration-barrier 1

# By default Redis Cluster nodes stop accepting queries if they detect there
# is at least a hash slot uncovered (no available node is serving it).
# This way if the cluster is partially down (for example a range of hash slots
# are no longer covered) all the cluster becomes, eventually, unavailable.
# It automatically returns available as soon as all the slots are covered again.
#
# However sometimes you want the subset of the cluster which is working,
# to continue to accept queries for the part of the key space that is still
# covered. In order to do so, just set the cluster-require-full-coverage
# option to no.
#
# cluster-require-full-coverage yes

# This option, when set to yes, prevents replicas from trying to failover its
# master during master failures. However the master can still perform a
# manual failover, if forced to do so.
#
# This is useful in different scenarios, especially in the case of multiple
# data center operations, where we want one side to never be promoted if not
# in the case of a total DC failure.
#
# cluster-replica-no-failover no

# This option, when set to yes, allows nodes to serve read traffic while the
# the cluster is in a down state, as long as it believes it owns the slots.
#
# This is useful for two cases. The first case is for when an application
# doesn't require consistency of data during node failures or network partitions.
# One example of this is a cache, where as long as the node has the data it
# should be able to serve it.
#
# The second use case is for configurations that don't meet the recommended
# three shards but want to enable cluster mode and scale later. A
# master outage in a 1 or 2 shard configuration causes a read/write outage to the
# entire cluster without this option set, with it set there is only a write outage.
# Without a quorum of masters, slot ownership will not change automatically.
#
# cluster-allow-reads-when-down no

# In order to setup your cluster make sure to read the documentation
# available at http://redis.io web site.

CLUSTER DOCKER/NAT support模块

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
########################## CLUSTER DOCKER/NAT support  ########################

# In certain deployments, Redis Cluster nodes address discovery fails, because
# addresses are NAT-ted or because ports are forwarded (the typical case is
# Docker and other containers).
#
# In order to make Redis Cluster working in such environments, a static
# configuration where each node knows its public address is needed. The
# following two options are used for this scope, and are:
#
# * cluster-announce-ip
# * cluster-announce-port
# * cluster-announce-bus-port
#
# Each instructs the node about its address, client port, and cluster message
# bus port. The information is then published in the header of the bus packets
# so that other nodes will be able to correctly map the address of the node
# publishing the information.
#
# If the above options are not used, the normal Redis Cluster auto-detection
# will be used instead.
#
# Note that when remapped, the bus port may not be at the fixed offset of
# clients port + 10000, so you can specify any port and bus-port depending
# on how they get remapped. If the bus-port is not set, a fixed offset of
# 10000 will be used as usual.
#
# Example:
#
# cluster-announce-ip 10.1.1.5
# cluster-announce-port 6379
# cluster-announce-bus-port 6380

SLOW LOG模块

慢日志配置

1
2
3
4
5
6
7
################################## SLOW LOG ###################################

# 指定指定时间超过多少微秒的命令会被记录到日志上(1s 为1000000微妙),负数则会禁用慢日 志功能,而0则表示强制记录每一个命令
slowlog-log-slower-than 10000

# 服务器最多保存多少条慢查询日志,超过的话当一个新的命令被写入日志时,最老的一条会从命令日志队列中被移除。
slowlog-max-len 128

LATENCY MONITOR模块

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
################################ LATENCY MONITOR ##############################

# The Redis latency monitoring subsystem samples different operations
# at runtime in order to collect data related to possible sources of
# latency of a Redis instance.
#
# Via the LATENCY command this information is available to the user that can
# print graphs and obtain reports.
#
# The system only logs operations that were performed in a time equal or
# greater than the amount of milliseconds specified via the
# latency-monitor-threshold configuration directive. When its value is set
# to zero, the latency monitor is turned off.
#
# By default latency monitoring is disabled since it is mostly not needed
# if you don't have latency issues, and collecting data has a performance
# impact, that while very small, can be measured under big load. Latency
# monitoring can easily be enabled at runtime using the command
# "CONFIG SET latency-monitor-threshold <milliseconds>" if needed.
latency-monitor-threshold 0

EVENT NOTIFICATION模块

事件通知模块

如果某个键发生某种变化 可以通知 发布/订阅的客户端

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
############################# EVENT NOTIFICATION ##############################
# 设置是否开启Pub/Sub 客户端关于键空间发生的事件,有很多通知的事件类型,默认被禁用,因为用户通常不需要该特性,并且该特性会有性能损耗,设置成空字符串就是禁用
# 事件通知的参数选项
# K Keyspace events, published with __keyspace@<db>__ prefix.
# E Keyevent events, published with __keyevent@<db>__ prefix.
# g Generic commands (non-type specific) like DEL, EXPIRE, RENAME, ...
# $ String commands
# l List commands
# s Set commands
# h Hash commands
# z Sorted set commands
# x Expired events (events generated every time a key expires)
# e Evicted events (events generated when a key is evicted for maxmemory)
# t Stream commands
# m Key-miss events (Note: It is not included in the 'A' class)
# A Alias for g$lshzxet, so that the "AKE" string means all the events
# (Except key-miss events which are excluded from 'A' due to their
# unique nature).
notify-keyspace-events ""

GOPHER SERVER模块

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
############################### GOPHER SERVER #################################

# 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模块

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
############################### ADVANCED CONFIG ###############################

# hash数据结构使用ziplist的条件
# 设置使用ziplist的最大的entry数
hash-max-ziplist-entries 512
# 设置使用ziplist的值的最大长度
hash-max-ziplist-value 64


# -5: max size: 64 Kb <-- not recommended for normal workloads
# -4: max size: 32 Kb <-- not recommended
# -3: max size: 16 Kb <-- probably not recommended
# -2: max size: 8 Kb <-- good
# -1: max size: 4 Kb <-- good
list-max-ziplist-size -2


# 0: disable all list compression
# 1: depth 1 means "don't start compressing until after 1 node into the list,
# going from either the head or tail"
# So: [head]->node->node->...->node->[tail]
# [head], [tail] will always be uncompressed; inner nodes will compress.
# 2: [head]->[next]->node->node->...->node->[prev]->[tail]
# 2 here means: don't compress head or head->next or tail->prev or tail,
# but compress all nodes between them.
# 3: [head]->[next]->[next]->node->node->...->node->[prev]->[prev]->[tail]
# etc.
list-compress-depth 0

# 设置使用紧凑编码的最大的entry数
set-max-intset-entries 512

# 设置使用ziplist的最大的entry数
zset-max-ziplist-entries 128
# 设置使用ziplist的值的最大长度
zset-max-ziplist-value 64

# HyperLogLog 稀疏表示字节限制:这个限制包含了16个字节的头部,当一个HyperLogLog使用sparse representation,超过了这个限制,它就会转换到dense representation上
# 设置HyperLogLog 稀疏表示的最大字节数
hll-sparse-max-bytes 3000


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

# 开启之后,redis每100毫秒时使用1毫秒来对redis的hash表进行重新hash,可以降低内存的使用
# 如果要求实时性特别高的话(低于2ms),将该配置为no
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


#
# proto-max-bulk-len 512mb

# Redis调用内部函数来执行许多后台任务,Redis依照指定的hz值来执行检查任务,默认情况下,hz的被设定为10。提高该值将在Redis空闲时使用更多的CPU时,但同时当有多个key同时到期会使Redis的反应更灵敏,以及超时可以更精确地处理。范围是1到500之间,但是值超过100通常不是一个好主意。大多数用户应该使用10这个默认值,只有在非常低的延迟要求时有必要提高 到100
hz 10


dynamic-hz yes

# 当一个子进程重写AOF文件时,如果启用下面的选项,则文件每生成32M数据会被同步。为了增量式的写入硬盘并且避免大的延迟,这个指令是非常有用的
aof-rewrite-incremental-fsync yes


rdb-save-incremental-fsync yes


# lfu-log-factor 10
# lfu-decay-time 1

ACTIVE DEFRAGMENTATION模块

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
########################### ACTIVE DEFRAGMENTATION #######################
#
# What is active defragmentation?
# -------------------------------
#
# Active (online) defragmentation allows a Redis server to compact the
# spaces left between small allocations and deallocations of data in memory,
# thus allowing to reclaim back memory.
#
# Fragmentation is a natural process that happens with every allocator (but
# less so with Jemalloc, fortunately) and certain workloads. Normally a server
# restart is needed in order to lower the fragmentation, or at least to flush
# away all the data and create it again. However thanks to this feature
# implemented by Oran Agra for Redis 4.0 this process can happen at runtime
# in a "hot" way, while the server is running.
#
# Basically when the fragmentation is over a certain level (see the
# configuration options below) Redis will start to create new copies of the
# values in contiguous memory regions by exploiting certain specific Jemalloc
# features (in order to understand if an allocation is causing fragmentation
# and to allocate it in a better place), and at the same time, will release the
# old copies of the data. This process, repeated incrementally for all the keys
# will cause the fragmentation to drop back to normal values.
#
# Important things to understand:
#
# 1. This feature is disabled by default, and only works if you compiled Redis
# to use the copy of Jemalloc we ship with the source code of Redis.
# This is the default with Linux builds.
#
# 2. You never need to enable this feature if you don't have fragmentation
# issues.
#
# 3. Once you experience fragmentation, you can enable this feature when
# needed with the command "CONFIG SET activedefrag yes".
#
# The configuration parameters are able to fine tune the behavior of the
# defragmentation process. If you are not sure about what they mean it is
# a good idea to leave the defaults untouched.

# Enabled active defragmentation
# activedefrag no

# Minimum amount of fragmentation waste to start active defrag
# active-defrag-ignore-bytes 100mb

# Minimum percentage of fragmentation to start active defrag
# active-defrag-threshold-lower 10

# Maximum percentage of fragmentation at which we use maximum effort
# active-defrag-threshold-upper 100

# Minimal effort for defrag in CPU percentage, to be used when the lower
# threshold is reached
# active-defrag-cycle-min 1

# Maximal effort for defrag in CPU percentage, to be used when the upper
# threshold is reached
# 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 background thread for purging will be enabled by default
jemalloc-bg-thread yes

# It is possible to pin different threads and processes of Redis to specific
# CPUs in your system, in order to maximize the performances of the server.
# This is useful both in order to pin different Redis threads in different
# CPUs, but also in order to make sure that multiple Redis instances running
# in the same host will be pinned to different CPUs.
#
# Normally you can do this using the "taskset" command, however it is also
# possible to this via Redis configuration directly, both in Linux and FreeBSD.
#
# You can pin the server/IO threads, bio threads, aof rewrite child process, and
# the bgsave child process. The syntax to specify the cpu list is the same as
# the taskset command:
#
# Set redis server/io threads to cpu affinity 0,2,4,6:
# server_cpulist 0-7:2
#
# Set bio threads to cpu affinity 1,3:
# bio_cpulist 1,3
#
# Set aof rewrite child process to cpu affinity 8,9,10,11:
# aof_rewrite_cpulist 8-11
#
# Set bgsave child process to cpu affinity 1,10,11
# bgsave_cpulist 1,10-11

# In some cases redis will emit warnings and even refuse to start if it detects
# that the system is in bad state, it is possible to suppress these warnings
# by setting the following config which takes a space delimited list of warnings
# to suppress
#
# ignore-warnings ARM64-COW-BUG

欢迎关注我的其它发布渠道