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规则。那还有啥情况会触发嘞?
- save规则满足的情况下,会自动触发rdb规则
- 执行flushall命令也会触发rdb规则
- 退出redis,也会产生rdb
恢复机制
每当启动redis的时候,redis会自动在当前目录下查看有没有RDB文件,如果有则恢复,当前目录可以通过config get dir来获取
127.0.0.1:6379> config get dir
1) "dir"
2) "/usr/local/bin"
优点:
- 适合大规模的数据恢复!dump.rdb
- 如果对数据完整性不高!
缺点:
- 需要一定的时间间隔进行操作,如果redis意外宕机了,那么最后一次修改的数据就没有了
- 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)。