redis的一些知识-配置文件解释
redis的一些知识-配置文件解释
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 ::12.监听端口
# 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 63793.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 yes4.持久化的策略——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的集群、扩容框架，可能更值得学习使用。