redis的一些知识-配置文件解释

时间:2022-12-17 20:35:54

redis比较常用,但大部分人都是简单使用一下redis存一些key value,不太关心redis的持久化问题、事务、最大客户端连接数等问题。这一篇就是讲一些平时不太注意的事情。

redis配置文件解释

在redis的安装目录中,可以找到redis.conf,这个文件就是redis的主要配置文件,里面配置了很多属性。我挑几个可能用的着的来看一下,其他的可以看看这篇https://www.cnblogs.com/zhang-ke/p/5981108.html。

里面的注释没有翻译,都是些简单的单词,应该都认识。

1.绑定ip

# By default, if no "bind" configuration directive is specified, Redis listens
# for connections from all the network interfaces available on the server.
# It is possible to listen to just one or multiple selected interfaces using
# the "bind" configuration directive, followed by one or more IP addresses.
#
# Examples:
#
# bind 192.168.1.100 10.0.0.1
bind 127.0.0.1 ::1
2.监听端口

# Accept connections on the specified port, default is 6379 (IANA #815344).
# If port 0 is specified Redis will not listen on a TCP socket.
port 6379
3.Protected mode保护模式。要是配置里没有指定bind和密码,开启该参数后,redis只允许本地访问,拒绝外部访问。要是开启了bind和密码,则外部可以访问。

# Protected mode is a layer of security protection, in order to avoid that
# Redis instances left open on the internet are accessed and exploited.
#
# When protected mode is on and if:
#
# 1) The server is not binding explicitly to a set of addresses using the
#    "bind" directive.
# 2) No password is configured.
#
# The server only accepts connections from clients connecting from the
# IPv4 and IPv6 loopback addresses 127.0.0.1 and ::1, and from Unix domain
# sockets.
#
# By default protected mode is enabled. You should disable it only if
# you are sure you want clients from other hosts to connect to Redis
# even if no authentication is configured, nor a specific set of interfaces
# are explicitly listed using the "bind" directive.
protected-mode yes
4.持久化的策略——RDB快照

# Save the DB on disk:
#
#   save <seconds> <changes>
#
#   Will save the DB if both the given number of seconds and the given
#   number of write operations against the DB occurred.
#
#   In the example below the behaviour will be to save:
#   after 900 sec (15 min) if at least 1 key changed
#   after 300 sec (5 min) if at least 10 keys changed
#   after 60 sec if at least 10000 keys changed
#
#   Note: you can disable saving completely by commenting out all "save" lines.
#
#   It is also possible to remove all the previously configured save
#   points by adding a save directive with a single empty string argument
#   like in the following example:
#
#   save ""

save 900 1
save 300 10
save 60 10000

# RDB快照生成错误时,是否停止客户端写入,默认为true。

stop-writes-on-bgsave-error yes

# Compress string objects using LZF when dump .rdb databases?
rdbcompression yes

# The filename where to dump the DB
dbfilename dump.rdb
# The DB will be written inside this directory, with the filename specified
# above using the 'dbfilename' configuration directive.
#
# The Append Only File will also be created inside this directory.
#
# Note that you must specify a directory here, not a file name.
dir /usr/local/var/db/redis/

距离上一次快照如果15分钟内有1个key发生变化,则持久化。

距离上一次快照5分钟内有10个key发生变化,则持久化。

目的就是如果你的key变化比较频繁,那么生成AOF的间隔越短。生成快照是redis数据落地到硬盘,为未来可能出现崩溃时,容灾恢复使用。可以说是非常重要的一个东西,值得学习一下。

那么快照是怎么生成的呢,上面的配置是让redis服务端来创建快照的,客户端也可以手工来创建快照。

客户端可以通过BGSAVE命令来创建一个快照,redis会通过fork来创建一个子进程,然后子进程负责将快照写入硬盘,而父进程则继续处理命令请求。这种是不阻塞的。

也可以通过SAVE命令来创建一个快照,但SAVE是阻塞的,接到SAVE命令的redis服务器在快照创建完毕之前将不再响应任何其他命令。通常我们不会使用该命令,只有在没有足够内存去执行BGSAVE的情况下,又或者能容忍创建快照的时间等待的情况下,才会使用该命令。

当redis接到SHUTDOWN命令时,或者接到标准TERM信号时,会执行一个SAVE命令,阻塞所有客户端,不再接受任何客户端请求,并在SAVE命令执行完毕后关闭服务器。

注意点:使用redis保存的数据量较小时,譬如只有几个GB,使用快照甚至默认的配置都是没问题的。redis通过创建子进程将数据保存到硬盘,生成快照需要的时间很短,比读完这句话的时间还要短。但当数据量很大时,达到了几十甚至上百GB时,并且系统剩余的内存也不多,那么执行BGSAVE可能会导致系统长时间停顿,甚至卡死。没增加1GB,BGSAVE就会额外增加10-20毫秒的开销。当剩余内存很少时,耗时会大幅增加,redis有可能会停止响应一段时间。

为了防止redis因创建子进程而卡顿,我们可以考虑关闭自动生成快照,可以选择用手工发送BGSAVE或者SAVE来保存。优点是卡顿的时间可控了,我们可以选择半夜去发送保存的命令。由于生成快照的频率大幅减少,那么面临的问题就是中途的系统崩溃,信息丢失。这个问题可以通过AOF持久化来解决。

5.设置密码

################################## SECURITY ###################################

# Require clients to issue AUTH <PASSWORD> before processing any other
# commands.  This might be useful in environments in which you do not trust
# others with access to the host running redis-server.
#
# This should stay commented out for backward compatibility and because most
# people do not need auth (e.g. they run their own servers).
#
# Warning: since Redis is pretty fast an outside user can try up to
# 150k passwords per second against a good box. This means that you should
# use a very strong password otherwise it will be very easy to break.
#
# requirepass foobared
开启requirepass xxxxxxxxxxxxxxx
后面填上你的明文密码就可以了,由于redis速度很快,为避免暴利破解,可以将密码设置20位以上。

6.最大同时连接的client数量

# Set the max number of connected clients at the same time. By default
# this limit is set to 10000 clients, however if the Redis server is not
# able to configure the process file limit to allow for the specified limit
# the max number of allowed clients is set to the current file limit
# minus 32 (as Redis reserves a few file descriptors for internal uses).
#
# Once the limit is reached Redis will close all the new connections sending
# an error 'max number of clients reached'.
#
# maxclients 10000
保持连接的client数量不能超过1万,超过的话,新连接会报错‘max number of clients reached’。这里就需要我们注意两个方面,一是注意及时释放执行完毕的连接,二是如果并发量过大,考虑调大该值或水平扩容做集群。

一般情况下,连接是会自动释放的,但某些特殊的操作api会导致连接不被释放。

7.数据持久化——AOF

大部分情况下,RDB快照已经能满足需求了,当意外宕机时,RDB会丢失从上一个快照到宕机时间内的数据。

AOF(Append Only File)是另一种持久化方式,和RDB可以共存,它是通过一个文件来记录所有的写命令,然后就可以在宕机时恢复所有的数据。因为每一条写命令都被追求到文件末尾,宕机恢复时,redis通过执行AOF文件所有命令来完成数据的恢复。

# By default Redis asynchronously dumps the dataset on disk. This mode is
# good enough in many applications, but an issue with the Redis process or
# a power outage may result into a few minutes of writes lost (depending on
# the configured save points).
#
# The Append Only File is an alternative persistence mode that provides
# much better durability. For instance using the default data fsync policy
# (see later in the config file) Redis can lose just one second of writes in a
# dramatic event like a server power outage, or a single write if something
# wrong with the Redis process itself happens, but the operating system is
# still running correctly.
#
# AOF and RDB persistence can be enabled at the same time without problems.
# If the AOF is enabled on startup Redis will load the AOF, that is the file
# with the better durability guarantees.
#
# Please check http://redis.io/topics/persistence for more information.

appendonly no

# The name of the append only file (default: "appendonly.aof")

appendfilename "appendonly.aof"
AOF默认是关闭的,改成yes就会开启。下面的那个是aof的file name。

既然aof是对写命令进行落地到磁盘的,那么必然会产生IO的开销。

# appendfsync always
appendfsync everysec
# appendfsync no
这个是aof落地的策略。

always是所有的写命令都同步写入硬盘,这样做会严重降低redis的速度,同时也能让redis崩溃时,数据损失量最小。此时,redis的速度将决定于磁盘的写速度。一般我们不会采用该方式。

everysec是每秒执行一次,将写命令同步到硬盘。是默认选项。

no代表让操作系统来决定何时进行同步,不推荐使用。

在使用everysec时,redis的性能损耗很小,每秒同步一次,那么也就是说我们最多损失掉1秒的redis数据。

可以看到AOF可以很方便而灵活的来进行redis的持久化,而且容灾性也不错。那么AOF的缺陷是什么呢?

答案就是AOF的体积非常大,由于AOF保存了每一条写入的命令,所以文件增长很快速。当然如果你是读多写少的应用,那容器问题就相对较小。redis在重启后会依次执行AOF的记录,来还原redis保存的信息。如果文件很大,那么这个缓存加载将会很漫长。

为了解决AOF过大,我们可以通过BGREWRITEAOF命令来移除AOF的冗余命令并重写AOF文件,这样会使AOF体积尽可能的小。这个命令原理和BGSAVE类似,也是fork子进程来完成。需要注意,如果文件过大,那么在重写完毕并删除老的大AOF文件时,要知道删除一个几十GB的文件,也会使系统挂起数秒之多。当然,AOF的压缩,也可以通过配置来自动执行,可以设置auto-aof-rewrite-percentage和auto-aof-rewrite-min-size来自动执行AOF。第一个代表比上一次重写后体积增大1倍(配置100),第二个代表且文件体积大于60M(配置60),将自动执行rewrite操作。

8.此外还有一些当内存满时,redis根据什么策略来删除可以。还有一些集群、水平扩容时的配置等等。有用到的可以去研究看看。官方虽然有redis的水平扩容,配置也很简单,但是貌似口碑一般,国内一些第三方公司出了一些redis的集群、扩容框架,可能更值得学习使用。