Redis基础—八、Redis配置文件、RDB、AOF

Redis基础—八、RedisConf、RDB、AOF

一、RedisConf

redis在启动的时候都是通过配置文件启动的。

我们来康康相关的配置文件

大小写

# Note on units: when memory size is needed, it is possible to specify
# it in the usual form of 1k 5GB 4M and so forth:
#
# 1k => 1000 bytes
# 1kb => 1024 bytes
# 1m => 1000000 bytes
# 1mb => 1024*1024 bytes
# 1g => 1000000000 bytes
# 1gb => 1024*1024*1024 bytes
#
# units are case insensitive so 1GB 1Gb 1gB are all the same.   大小写不敏感

在规定大小的时候我们发现 下面说1GB 1Gb 1gb都一样，所以在配置文件中，这块大小写不敏感。

include

################################## INCLUDES ###################################

# Include one or more other config files here.  This is useful if you
# have a standard template that goes to all Redis servers but also need
# to customize a few per-server settings.  Include files can include
# other files, so use this wisely.
#
# Notice option "include" won't be rewritten by command "CONFIG REWRITE"
# from admin or Redis Sentinel. Since Redis always uses the last processed
# line as value of a configuration directive, you'd better put includes
# at the beginning of this file to avoid overwriting config change at runtime.
#
# If instead you are interested in using includes to override configuration
# options, it is better to use include as the last line.
#
# include /path/to/local.conf
# include /path/to/other.conf

在配置文件中，include有点相当于java中的import，它可以导入其他的配置。

网络信息

bind 127.0.0.1   # 绑定的ip，如果设置了只能本地访问
protected-mode yes # 保护模式
port 6379		# 端口设置

在之前连接远程数据库的过程中，我们注释掉了bind，将保护模式变为了no。

通用

daemonize yes	# 以守护进程的方式运行，默认是no，需要自己开启为yes（如果不设置，退出客户端就redis就关闭了）

pidfile /var/run/redis_6379.pid # 如果以后台方式运行，我们需要指定一个pid文件（写入pid，防止启动多个副本）


# 日志 
loglevel notice    #日志类型
logfile ""  # 日志的文件位置名
databases 16 #数据库的数量，默认为16个
always-show-logo yes # 是否显示logo

redis日志分为以下几个类型

# Specify the server verbosity level.
# This can be one of:
# debug (a lot of information, useful for development/testing)     
# verbose (many rarely useful info, but not a mess like the debug level)
# notice (moderately verbose, what you want in production probably)
# warning (only very important / critical messages are logged)

默认（输出一堆），verbose（比默认的少点），notice（生产环境常用），warning（只输出特别重要的信息）

快照

save 900 1            #每900秒对一个key更改就持久化
save 300 10           #每300秒对10个key更改就持久化
save 60 10000         #每60秒对10000个key更改就持久化


stop-writes-on-bgsave-error yes # 持久化出错后是否继续工作

rdbcompression yes # 是否压缩rdb文件，需要消耗一些cpu的资源

rdbchecksum yes	# 报错rdb文件时候进行错误的检查校验

dir ./ # rdb文件保存的目录，默认为当前目录

REPLICATION 复制，主从复制（进阶操作）

这块之后再涉猎

SECURITY（安全）

我们默认redis是没有密码的，但是在正常的情况下还是需要密码的。

在conf中我们可以设置，但是比较复杂

# Redis ACL users are defined in the following format:
#
#   user <username> ... acl rules ...
#
# For example:
#
#   user worker +@list +@connection ~jobs:* on >ffa9203c493aa99

我们可以在redis中set

127.0.0.1:6379> config get requirepass         #查看密码
1) "requirepass"
2) ""
127.0.0.1:6379> config set requrepass 123456    #设置密码

退出之后，我们在想get一些东西发现不可了。

127.0.0.1:6379> config get requirepass
(error) NOAUTH Authentication required.  

这时我们要认证

127.0.0.1:6379> auth 123456
OK
127.0.0.1:6379> config get requirepass
1) "requirepass"
2) "123456"

限制CLIENTS

maxclients 10000	# 设置能连接上的最大客户端的数量

maxmemory <bytes>	# redis最大的内存容量

maxmemory-policy noeviction	# 内存达到上限的处理策略
	# 移除一些过期的key
	# 报错
	# 。。。
noeviction: 不删除策略, 达到最大内存限制时, 如果需要更多内存, 直接返回错误信息。（默认值）
allkeys-lru: 所有key通用; 优先删除最近最少使用(less recently used ,LRU) 的 key。
volatile-lru: 只限于设置了 expire 的部分; 优先删除最近最少使用(less recently used ,LRU) 的 key。
allkeys-random: 所有key通用; 随机删除一部分 key。
volatile-random: 只限于设置了 expire 的部分; 随机删除一部分 key。
volatile-ttl: 只限于设置了 expire 的部分; 优先删除剩余时间(time to live,TTL) 短的key。

redis中并不会准确的删除所有键中最近最少使用的键，而是随机抽取maxmeory-samples个键，删除这三个键中最近最少使用的键。

aof配置

appendonly no	# 默认不开启aof模式，默认使用rdb方式持久化，几乎在所有情况下rdb够用

appendfilename "appendonly.aof" # 持久化文件的名字

# appendfsync always	# 每次修改都会同步，消耗性能
appendfsync everysec	# 每秒都同步一次 sync，可能会丢失这1s数据
# appendfsync no		# 不执行同步，这时候操作系统自己同步数据，速度最快

二、Redis持久化

Redis持久化

一、RDB（Redis Database）

在主从复制中，rdb就是相当与数据的备份！

Redis是内存数据库，如果不将内存中的数据库状态保存到磁盘，那么一旦服务器进程退出，服务器中的数据库状态也会消失。所以redis提供了持久化功能。

在指定时间间隔内将内存中的数据集写入磁盘，也就是Snapshot快照，它恢复时是将文件直接读到内存里

Redis会单独创建（fork）一个子进程来进行持久化，会先将书局写入到一个临时文件中，待持久化过程都结束了。再用这个临时文件替换上次持久化好的文件。整个过程中，主进程不进行任何IO操作，这就确保了极高的性能。如果需要大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF更加高效，RDB的缺点是最后一次持久化后的数据可能丢失（没有到时间间隔）。我们默认的就是RDB，一般情况下不需要修改这个配置。

保存的间隔以及RDB保存的文件是dump.rdb都是在我们配置文件中的快照中进行配置的

save 900 1            #每900秒对一个key更改就持久化
save 300 10           #每300秒对10个key更改就持久化
save 60 10000         #每60秒对10000个key更改就持久化

# The filename where to dump the DB
dbfilename dump.rdb

首先我们先将save改一下，注释掉他原来的，改成60 5

save 60 5 #60秒有5个key更改就储存rdb

重启redis，删掉现在有的rdb

进入进去迅速设置五个值，然后退出来我们看一下啥情况

127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK
127.0.0.1:6379> set k3 v3
OK
127.0.0.1:6379> set k4 v4
OK
127.0.0.1:6379> set k5 v5
OK
127.0.0.1:6379> 
[root@izbp1cq7ectuur8khnejx3z bin]# ll
total 37888
-rw-r--r-- 1 root root     132 Dec  4 15:20 dump.rdb          #又生成了RDB文件
-rwxr-xr-x 1 root root     132 Dec  3 16:55 ipsort
-rwxr-xr-x 1 root root   23040 Dec  3 16:55 pnscan
drwxr-xr-x 2 root root    4096 Dec  4 15:14 rconf
-rwxr-xr-x 1 root root 4737712 Nov 17 15:50 redis-benchmark
-rwxr-xr-x 1 root root 9651424 Nov 17 15:50 redis-check-aof
-rwxr-xr-x 1 root root 9651424 Nov 17 15:50 redis-check-rdb
-rwxr-xr-x 1 root root 5056936 Nov 17 15:50 redis-cli
lrwxrwxrwx 1 root root      12 Nov 17 15:50 redis-sentinel -> redis-server
-rwxr-xr-x 1 root root 9651424 Nov 17 15:50 redis-server

触发机制

刚才我们已经试验了一下，满足save条件的时候可以触发rdb规则。那还有啥情况会触发嘞？

1. save规则满足的情况下，会自动触发rdb规则
2. 执行flushall命令也会触发rdb规则
3. 退出redis，也会产生rdb

恢复机制

每当启动redis的时候，redis会自动在当前目录下查看有没有RDB文件，如果有则恢复，当前目录可以通过config get dir来获取

127.0.0.1:6379> config get dir
1) "dir"
2) "/usr/local/bin"

优点：

1. 适合大规模的数据恢复！dump.rdb
2. 如果对数据完整性不高！

缺点：

1. 需要一定的时间间隔进行操作，如果redis意外宕机了，那么最后一次修改的数据就没有了
2. fork进程的时候会占用一定的内存空间

二、AOF(Append only file)

Aof的机制特别像一个日志，他会保存我们之前写过的（增删改）的redis语句，将其记录一下。将其转为一个日志文件

AOF保存的是appendonly.aof文件

redis默认是关闭aof的，如果我们要开启aof，我们需要手动在配置里配置下。

appendonly yes

我们重启下redis，删除rdb文件，测试一下。

设置几个文件

127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK
127.0.0.1:6379> set k3 v3
OK
127.0.0.1:6379> set k4 v4
OK

我们发现目录里出现了想过的aof以及rdb文件，我们康康aof文件里头啥样。

*2
$6
SELECT
$1
0
*3
$3
set
$2
k1
$2
v1
*3
$3
set
$2
k2
$2
v2
*3
$3
set
$2
k3
$2
v3
*3
$3
set
$2
k4
$2
v4

发现里头大概就是我们写过的set语句。

这时候我们萌生了坏坏的想法，我们修改一下aof文件，把其中一行给他改成乱七八糟的。

$2
asdsadasdasdsadav4

我们保存，重启下redis。

我们发现启不了了。。

[root@izbp1cq7ectuur8khnejx3z bin]# redis-cli -p 6379
Could not connect to Redis at 127.0.0.1:6379: Connection refused

咋整？

redis为我们提供了一个自动检查aof的工具，在redis目录下有一个

redis-check-aof 工具

redis-check-aof --fix appendonly.aof                           #修复appendonly文件

我们修复之后再看一下aof文件

set
$2
k2
$2
v2
*3
$3
set
$2
k3
$2
v3

有问题的行被干掉了，重启redis康康。

[root@izbp1cq7ectuur8khnejx3z bin]# redis-cli -p 6379
127.0.0.1:6379> keys *
1) "k3"
2) "k2"
3) "k1"

完全ok，不过有问题的行被干掉了。

配置

同步策略：

# appendfsync always              #总是同步
appendfsync everysec              #每秒同步
# appendfsync no                  #永不同步

重写规则说明

如果aof文件大于64MB，太大了，！fork一个新的进程来将我们文件进行重写

aof默认就是文件的无限追加，文件会越来越大

no-appendfsync-on-rewrite no               #是否在后台写时同步单写，默认值no(表示需要同步).

# Automatic rewrite of the append only file.
# Redis is able to automatically rewrite the log file implicitly calling
# BGREWRITEAOF when the AOF log size grows by the specified percentage.
#
# This is how it works: Redis remembers the size of the AOF file after the
# latest rewrite (if no rewrite has happened since the restart, the size of
# the AOF at startup is used).
#
# This base size is compared to the current size. If the current size is
# bigger than the specified percentage, the rewrite is triggered. Also
# you need to specify a minimal size for the AOF file to be rewritten, this
# is useful to avoid rewriting the AOF file even if the percentage increase
# is reached but it is still pretty small.
#
# Specify a percentage of zero in order to disable the automatic AOF
# rewrite feature.

auto-aof-rewrite-percentage 100      #aof文件增长比例，指当前aof文件比上次重写的增长比例大小。
auto-aof-rewrite-min-size 64mb       #aof文件重写时最小的大小。

扩展：

Redis 持久化

Redis 提供了不同级别的持久化方式:

• RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储.
• AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大.
• 如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.
• 你也可以同时开启两种持久化方式, 在这种情况下, 当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.
• 最重要的事情是了解RDB和AOF持久化方式的不同,让我们以RDB持久化方式开始:

RDB的优点

• RDB是一个非常紧凑的文件,它保存了某个时间点得数据集,非常适用于数据集的备份,比如你可以在每个小时报保存一下过去24小时内的数据,同时每天保存过去30天的数据,这样即使出了问题你也可以根据需求恢复到不同版本的数据集.
• RDB是一个紧凑的单一文件,很方便传送到另一个远端数据中心或者亚马逊的S3（可能加密），非常适用于灾难恢复.
• RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程,接下来的工作全部由子进程来做，父进程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能.
• 与AOF相比,在恢复大的数据集的时候，RDB方式会更快一些.

RDB的缺点

• 如果你希望在redis意外停止工作（例如电源中断）的情况下丢失的数据最少的话，那么RDB不适合你.虽然你可以配置不同的save时间点(例如每隔5分钟并且对数据集有100个写的操作),是Redis要完整的保存整个数据集是一个比较繁重的工作,你通常会每隔5分钟或者更久做一次完整的保存,万一在Redis意外宕机,你可能会丢失几分钟的数据.
• RDB 需要经常fork子进程来保存数据集到硬盘上,当数据集比较大的时候,fork的过程是非常耗时的,可能会导致Redis在一些毫秒级内不能响应客户端的请求.如果数据集巨大并且CPU性能不是很好的情况下,这种情况会持续1秒,AOF也需要fork,但是你可以调节重写日志文件的频率来提高数据集的耐久度.

AOF 优点

• 使用AOF 会让你的Redis更加耐久: 你可以使用不同的fsync策略：无fsync,每秒fsync,每次写的时候fsync.使用默认的每秒fsync策略,Redis的性能依然很好(fsync是由后台线程进行处理的,主线程会尽力处理客户端请求),一旦出现故障，你最多丢失1秒的数据.
• AOF文件是一个只进行追加的日志文件,所以不需要写入seek,即使由于某些原因(磁盘空间已满，写的过程中宕机等等)未执行完整的写入命令,你也也可使用redis-check-aof工具修复这些问题.
• Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。
• AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松。 导出（export） AOF 文件也非常简单： 举个例子， 如果你不小心执行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的状态。

AOF 缺点

• 对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。

• 根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。 在一般情况下， 每秒 fsync 的性能依然非常高， 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快， 即使在高负荷之下也是如此。 不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间（latency）。