Redis入门(一)之API与数据持久化

1.写在前面

前面的一段时间在学习elasticsearch，elasticsearch还剩一篇MySQL同步到elasticsearch的数据的博客，比较难写，这段时间尽量更新上来，今天就让我们来学习Redis的相关的知识吧！从Redis的安装，到Redis的简单的API的使用，再到Redis的持久化的机制，今天这篇的博客就会介绍这些的东西。篇幅有点长，请大家耐心的观看。

2.Redis是什么？

是完全开源免费的，用c语言编写的，是一个单线程，高性能的（key/value）内存数据库，基于内存运行并支持持久化的nosql数据库。

3.Redis能干嘛？

主要是用来做缓存，但不仅仅只能做缓存，比如：redis的计数器生成分布式唯一主键，redis实现分布式锁，队列，会话缓存，点赞，统计网站访问量。

4.Redis如何安装？

环境

redis-5.0.12
Ubuntu 18.04

1. 先从对应网站下载对应的Redis的安装包，下载的地址：https://download.redis.io/releases/redis-5.0.12.tar.gz

2. 将对应的tar包上传到服务器的/opt目录下。

3. 执行tar -zxvf redis-5.0.12.tar.gz命令，解压对应的Redis。

4. 删除原来的tar包，执行 rm -rf redis-5.0.12.tar.gz

5. 重命名redis解压出来的目录，执行的命令：mv redis-5.0.12/ redis

6. 进入redis目录，执行的命令：cd redis

7. 编译，执行的命令：make,发现报错了，具体的如下：

   

   这个错误提醒我们我们没有gcc的环境，于是我们执行 sudo apt-get install gcc命令来安装gcc

8. 安装完gcc,我们需要执行命令： make distclean由于原来的make命令编译失败后不会回滚，所以我们这儿需要清除一下，然后继续执行命令：make,具体的如下：

   

9. 执行安装的命令：make install，具体的如下：

   

10. 这个时候应该在/usr/local/bin/,生成对应的Redis的安装的东西，具体的如下：

    

    这里解释下，这个可执行的脚本是干嘛的，具体的如下：

    redis-benchmark 性能测试
    redis-check-aof 修复aof文件
    redis-check-rdb 修复rdb文件
    redis-cli redis的客户端
    redis-sentinel 搭建集群的
    redis-server 启动Redis的服务的
    

5.Redis如何启动？

我们都知道启动Redis一般都会有一个配置文件，这个配置文件在什么地方呢？具体的路径在我们刚刚解压的路径，有个redis.conf的文件，由于我们是新手，所以我们需要将这个配置文件拷贝出来到/myredis/中，然后我们来讲解下我们对应的配置文件。我先讲一部分，主要是用到什么地方就讲什么。具体的如下：

# 绑定Ip   指定可以连接本实例Redis的ip  如果注释（删掉）则任意IP都可以连接
bind 127.0.0.1
#修改成 bind 192.168.181.6 这个配置的地址的是自己的服务器的内网地址

#禁止外网访问redis，如果启用了，即使注释掉了bind 127.0.0.1，再访问redisd时候还是无法连接的
#它启用的条件有两个，第一是没有使用bind，第二是没有设置访问密码。
protected-mode yes
#这儿不变

#指定Redis的端口
port 6379
#这儿不变

# 是否以守护进程启动
daemonize no
#修改成 daemonize yes

#设置日志的级别  debug、verbose、notice、warning，默认为verbose
loglevel notice
#这儿也是默认的日志级别

#日志文件的位置，当指定为空字符串时，为标准输出，如果redis已守护进程模式运行，那么日志将会输出到  /dev/null 。
logfile ""
#修改成 logfile "/myredis/redis.log"

具体我们只需要修改上个上面的几个配置项，修改完后，直接保存，然后运行/usr/local/bin/redis-server redis.conf,这个时候Redis服务就启动起来了。具体如下：

然后我们再试试本地的Redis的客户端工具能不能连接上

可以发现我们的本地的Redis客户端已经连接上，这个时候需要解释一下bind和protected-mode组合的方式

• 当bind 设置为0.0.0.0和protected-mode设置为yes的时候，外部的客户端是可以连接的
• 当bind项注释掉，protected-mode设置为yes的时候，外部的客户端是不可以连接的
• 总结：protected-mode它启用的条件有两个，第一是没有使用bind，第二是没有设置访问密码。

有了上面的总结，我们可以简单的做个试验，就是将bind项注释掉，然后给Redis设置一个密码，看看外部是否能访问，至于怎么给Redis设置密码呢？其实就是一个配置项，具体的如下：

# 设置Redis连接密码，如果配置了连接密码，客户端在连接Redis时需要通过AUTH <password>命令提供密码，默认关闭
requirepass foobared
#修改为 requirepass admin

修改对应的配置，然后重启Redis，然后重新连接Redis，看看能不能连接上，具体的如下：

可以发现也证实我们上面所说的了。我们还是将配置改回来。然后重启Redis，继续后面的知识点。

6.Redis常用的数据类型和常用的API

具体的命令可以参考：http://redisdoc.com/

1.string

string是redis最基本的类型，你可以理解成与Memcached一模一样的类型，一个key对应一个value。

string类型是二进制安全的。意思是redis的string可以包含任何数据。比如jpg图片或者序列化的对象 。

string类型是Redis最基本的数据类型，一个redis中字符串value最多可以是512M

常用的命令：

set  key  value   设置key  value

get  key  查看当前key的值

del  key  删除key

append key  value   如果key存在，则在指定的key末尾添加，如果key存在则类似set

strlen  key  返回此key的长度

以下几个命令只有在key值为数字的时候才能正常操作：

incr  key  为执定key的值加一

decr  key  为指定key的值减一

incrby key  数值  为指定key的值增加数值

decrby key  数值  为指定key的值减数值

其他的命令：

getrange  key  0(开始位置)  -1（结束位置）    获取指定区间范围内的值，类似between......and的关系 （0 -1）表示全部

setrange key 1（开始位置，从哪里开始设置） 具体值    设置（替换）指定区间范围内的值

setex 键 秒值 真实值    设置带过期时间的key，动态设置。

setnx  key   value    只有在 key 不存在时设置 key 的值。

mset   key1   value  key2   value    同时设置一个或多个 key-value 对。

mget   key1   key 2    获取所有(一个或多个)给定 key 的值。

msetnx   key1   value  key2   value   同时设置一个或多个 key-value 对，当且仅当所有给定 key 都不存在。

getset   key    value  将给定 key 的值设为 value ，并返回 key 的旧值(old value)。

2.list

它是一个字符串链表，left、right都可以插入添加；
如果键不存在，创建新的链表；
如果键已存在，新增内容；
如果值全移除，对应的键也就消失了。
链表的操作无论是头和尾效率都极高，但假如是对中间元素进行操作，效率就很惨淡了。

Redis 列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素导列表的头部（左边）或者尾部（右边）。
它的底层实际是个链表

常用的命令：

lpush  key  value1  value2  将一个或多个值加入到列表头部

rpush  key  value1  value2 将一个或多个值加入到列表底部

lrange key  start  end  获取列表指定范围的元素   （0 -1）表示全部

lpop key 移出并获取列表第一个元素

rpop key  移出并获取列表最后一个元素

lindex key index   通过索引获取列表中的元素 

llen 获取列表长度

lrem key   0（数量） 值，表示删除全部给定的值。零个就是全部值   从left往right删除指定数量个值等于指定值的元素，返回的值为实际删除的数量

ltrim key  start(从哪里开始截)  end（结束位置） 截取指定索引区间的元素，格式是ltrim list的key 起始索引 结束索引

3.set

Redis的Set是string类型的无序，不能重复的集合。

常用的命令：

sadd key value1 value 2 向集合中添加一个或多个成员

smembers  key  返回集合中所有成员

sismembers  key   member  判断member元素是否是集合key的成员

scard key  获取集合里面的元素个数

srem key value  删除集合中指定元素

srandmember key  数值     从set集合里面随机取出指定数值个元素   如果超过最大数量就全部取出，

spop key  随机移出并返回集合中某个元素

smove  key1  key2  value(key1中某个值)   作用是将key1中执定的值移除  加入到key2集合中

sdiff key1 key2  在第一个set里面而不在后面任何一个set里面的项(差集)

sinter key1 key2  在第一个set和第二个set中都有的 （交集）

sunion key1 key2  两个集合所有元素（并集）

4.hash

Redis hash 是一个键值对集合。
Redis hash是一个string类型的field和value的映射表，hash特别适合用于存储对象。

kv模式不变，但v是一个键值对

类似Java里面的Map<String,Object>

常用的命令：

hset  key  (key value)  向hash表中添加一个元素

hget key  key  向hash表中获取一个元素

hmset  key key1 value1 key2 value2 key3 value3 向集合中添加一个或多个元素

hmget key  key1 key2 key3  向集合中获取一个或多个元素

hgetall  key   获取在hash列表中指定key的所有字段和值

hdel  key  key1 key2 删除一个或多个hash字段

hlen key 获取hash表中字段数量

hexits key key  查看hash表中，指定key（字段）是否存在

hkeys  key 获取指定hash表中所有key（字段）

hvals key 获取指定hash表中所有value(值)

hincrdy key  key1  数量（整数）  执定hash表中某个字段加  数量  ，和incr一个意思

hincrdyfloat key key1  数量（浮点数，小数）  执定hash表中某个字段加  数量  ，和incr一个意思

hsetnx key key1 value1  与hset作用一样，区别是不存在赋值，存在了无效。

5.zset

Redis zset 和 set 一样也是string类型元素的集合,且不允许重复的成员。
不同的是每个元素都会关联一个double类型的分数。
redis正是通过分数来为集合中的成员进行从小到大的排序。zset的成员是唯一的,但分数(score)却可以重复。

常用的命令：

zadd  key  score 值   score 值   向集合中添加一个或多个成员

zrange key  0   -1  表示所有   返回指定集合中所有value

zrange key  0   -1  withscores  返回指定集合中所有value和score

zrangebyscore key 开始score 结束score    返回指定score间的值

zrem key score某个对应值（value），可以是多个值   删除元素

zcard key  获取集合中元素个数

zcount key   开始score 结束score       获取分数区间内元素个数

zrank key vlaue   获取value在zset中的下标位置(根据score排序)

zscore key value  按照值获得对应的分数

key

常用的指令：

keys *  

scan  0 match  *  count  1

exists key 判断某个key是否存在

move key db  当前库就没有了，到指定的库中去了

expire key  为给定的key设置过期时间

ttl key 查看还有多少时间过期   -1表示永不过期  -2表示已过期

type key  查看key是什么类型

7.Redis的持久化

什么是持久化呢？说白了，就是在指定的时间间隔内，将内存当中的数据集快照写入磁盘，它恢复时是将快照文件直接读到内存

什么意思呢？我们都知道，内存当中的数据，如果我们一断电，那么数据必然会丢失，但是玩过redis的同学应该都知道，我们一关机之后再启动的时候数据是还在的，所以它必然是在redis启动的时候重新去加载了持久化的文件

redis提供两种方式进行持久化，

一种是RDB持久化默认。

另外一种是AOF（append only file）持久化。

1.RDB

那么这个RDB的文件存在什么地方呢？

要回答这个问题，需要再次查看Redis的配置文件RDB相关的，具体的如下：

# 指定在多长时间内，有多少次更新操作，就将数据同步到数据文件，可以多个条件配合
# 这里表示900秒（15分钟）内有1个更改，300秒（5分钟）内有10个更改以及60秒内有10000个更改
# 如果想禁用RDB持久化的策略，只要不设置任何save指令，或者给save传入一个空字符串参数也可以
save 900 1
save 300 10
save 60  1

# 默认情况下，如果 redis 最后一次的后台保存失败，redis 将停止接受写操作，这样以一种强硬的方式让用户知道数据不能正确的持久化到磁盘， 
# 否则就会没人注意到灾难的发生。 如果后台保存进程重新启动工作了，redis 也将自动的允许写操作。
# 如果配置成no，表示你不在乎数据不一致或者有其他的手段发现和控制
stop-writes-on-bgsave-error yes

# 对于存储到磁盘中的快照(rdb)，可以设置是否进行压缩存储。如果是的话，redis会采用
# LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能
rdbcompression yes

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

#rdb文件的名字。
dbfilename dump.rdb

# dbfilename文件存放目录。必须是一个目录，aof文件也会保存到该目录下。
dir ./
# 修改为 dir /myredis/

从上面的配置文件我们可以得到，如果没有修改对应的文件，那么rdb文件就存储在启动命令的目录下，这个时候我们就让这个文件显示出来，但是上面的配置的rdb的触发机制有点难，我们先修改rdb文件的存储位置。然后重启Redis服务。所以这个rdb有什么另外的触发机制呢？当然有， shutdown时候会触发，于是我们尝试下，连接对应的Redis，执行一些命令，然后执行shutdown的操作，看看有没有rdb文件。

可以看到这个时候我们没有dump.rdb文件，这个时候用客户端连接下Redis服务器，然后随便执行几条命令，然后再执行下shutdown命令，这个时候我们再来看下有没有对应的dump.rdb文件，具体的如下：

可以发现我们没有执行shutdown命令的时候，dump.rdb文件是没有的，这个时候我们执行shutdown命令后，如下：

这个时候文件就有了。

那么RDB的原理是什么呢？

原理是redis会单独创建（fork）一个与当前进程一模一样的子进程来进行持久化，这个子进程的所有数据（变量。环境变量，程序程序计数器等）都和原进程一模一样，会先将数据写入到一个临时文件中，待持久化结束了，再用这个临时文件替换上次持久化好的文件，整个过程中，主进程不进行任何的io操作，这就确保了极高的性能

他什么时候fork子进程，或者什么时候触发rdb持久化机制？

shutdown时，如果没有开启aof，会触发配置文件中默认的快照配置，

执行命令save或者bgsave

save：是只管保存，其他不管，全部阻塞

bgsave： redis会在后台异步进行快照操作，同时可以响应客户端的请求

执行flushall命令 但是里面是空的，无意义

**既然有了上面的理论的知识了，那么我们有怎么知道它fork了一个新的进程呢？**那么我们现在提供一个方案，就是我们用Python写一个脚本，然后生成对应的500万条的数据，然后在Redis中使用bgsave的命令，然后再开启一个控制台，然后用ps -ef | grep redis命令看看有没有生成对应的新的进程。

具体的步骤如下：

1. 写出对应的Python脚本，具体的Python的脚本如下：

   import redis
   
   conn = redis.Redis(host='192.168.181.6', port=6379)
   
   values = [i for i in range(1, 5000001)]
   with conn.pipeline(transaction=False) as p:
       for value in values:
           p.set(value, value)
           if value % 1000 == 0:
               p.execute()
   
   

2. 这个时候删除我们的dump.rdb文件，执行的命令：rm -rf dump.rdb

3. 然后在客户端执行 bgsave命令。

4. 快速的打开一个控制台，执行ps -ef | grep redis。然后执行的情况的如下：

   

   可以发现Redis是开启一个新的进程来执行保存rdb文件。

**那么我们怎么证明Redis进程是单进程的呢？**由于我们的数据量够大，而执行save命令的时候没有开启新的进程，那么必然会阻塞其他的指令操作，这儿可以尝试一下，具体的步骤如下：

1. 开启两个Redis客户端，都连接上Redis的服务端。

2. 先不执行save操作，查看对应的执行的时间，具体的如下：

   

3. 然后一个客户端执行先save操作，另外一个客户端执行set操作，再看一个执行时间，具体的如下：

   

4. 总结：Redis是单线程的，在没有执行save操作的时候，set的操作直接执行的，而执行save操作的时候，set的操作没有直接执行，而是阻塞在哪，所以这儿可以得出Redis是单线程的。

既然这儿讲到了Redis是单线程的，那么我简单的画个图，讲下Redis的单线程吧，具体的如下：

上面的图大概的画了单机版的Redis的工作的流程，其中还有一个版块的AOF没有讲。以现在的机制，我们知道RDB的机制，可能会导致数据的丢失，那么还有Redis还有其他的数据持久化的机制吗？当然有，就是我们下面要要讲的AOF的机制。

2.AOF

AOF是什么？

原理是将Reids的操作日志以追加的方式写入文件，读操作是不记录的

这个持久化文件在哪里？

这个问题前面讲RDB机制的时候，已经讲了，和RDB的文件存储在一个地方。

触发机制（根据配置文件配置项）

no：表示等操作系统进行数据缓存同步到磁盘（快，持久化没保证）
always：同步持久化，每次发生数据变更时，立即记录到磁盘（慢，安全）
everysec：表示每秒同步一次（默认值,很快，但可能会丢失一秒以内的数据）

为此我们还是介绍一下和AOF相关的配置吧，具体的如下：

# 是否启用aof持久化方式 。否在每次更新操作后进行日志记录，Redis在默认情况下是异步的把数据写入磁盘，如果不开启，可能会在断电时导致一段时间内的数据丢失。
# 因为 redis本身同步数据文件是按上面save条件来同步的，所以有的数据会在一段时间内只存在于内存中。默认为no
appendonly no
# 修改为 appendonly yes

# 指定更新日志（aof）文件名，默认为appendonly.aof
appendfilename "appendonly.aof"

#指定更新日志条件，共有3个可选值： 
#  no：表示等操作系统进行数据缓存同步到磁盘（快，持久化没保证） 
#  always：同步持久化，每次发生数据变更时，立即记录到磁盘（慢，安全） 
#  everysec：表示每秒同步一次（默认值,很快，但可能会丢失一秒以内的数据）
# appendfsync always
appendfsync everysec
# appendfsync no

# 指定是否在后台aof文件rewrite期间调用fsync，默认为no，表示要调用fsync（无论后台是否有子进程在刷盘）。
# Redis在后台写RDB文件或重写AOF文件期间会存在大量磁盘IO，此时，在某些linux系统中，调用fsync可能会阻塞。
#如果应用系统无法忍受延迟，而可以容忍少量的数据丢失，则设置为yes。如果应用系统无法忍受数据丢失，则设置为no。
no-appendfsync-on-rewrite no

#当AOF文件增长到一定大小的时候Redis能够调用 BGREWRITEAOF 对日志文件进行重写 。当AOF文件大小的增长率大于该配置项时自动开启重写。
auto-aof-rewrite-percentage 100
#当AOF文件增长到一定大小的时候Redis能够调用 BGREWRITEAOF 对日志文件进行重写 。当AOF文件大小大于该配置项时自动开启重写
auto-aof-rewrite-min-size 64mb

#redis在启动时可以加载被截断的AOF文件，而不需要先执行redis-check-aof 工具。
aof-load-truncated yes

#是否开启混合持久化
aof-use-rdb-preamble yes

上面我们只需要修改appendonly yes即可，这样就开启了AOF的机制，至于其他的配置，我们接下来慢慢的讲，我们先将刚才那个dump.rdb复制一份，命名叫dumpold.rdb,然后开启AOF，然后重启Redis服务。

可以发现我们的appendonly.aof文件生成了，证明我们aof已经开启了，但是文件的大小是0，那么是不是可以证明原来的数据没有写到aof中去呢？我们不知道，我们先用一个客户端去连接Redis，然后执行一些命令，然后看看appendonly.aof会不会有数据。具体的如下：

可以发现appendonly.aof中数据了，但是很明显，是我们刚才的写的那条数据，我们可以用vim 打开这个appendonly.aof文件看看，具体的如下：

看到这个，如果大家看过我的博客《浅谈BIO到手写Redis客户端》，就知道这个是Redis的一种协议叫做Resp协议，这儿就不做过多的赘述了，那么我们开启AOF，原来的数据还在不在？我们执行一条dbsize的指令，具体的如下：

卧槽，我们五百万的数据没有了，消失了，怎么办？为什么会没有了？至于为什么消失，与执行逻辑逻辑有关，后面我会讲，那么我们怎么把数据搞回来呀！你如果是运维，就是生产事故了。这就出大事，先别慌，既然我们开启了aof数据没了，你可能心里会想，这个垃圾的aof，不开了，直接关了吧！于是你修改完配置文件，然后重启Redis，执行dbsize指令，具体的如下：

很不幸的就是刚才触发RDB的机制，导致dump.rdb文件已经被修改了，还好我备份dump.rdb文件，我们这个时候将原来dump.rdb文件给删除掉，然后将老的rdb文件复制回来，然后再执行前面的操作，切记这儿的操作是在关闭Redis的服务的时候做的，具体的如下：

可以发现我们的数据恢复了，但是我们在开启aof的时候，能把之前的数据也写入aof文件中去呢？当然有办法，就是在客户端的开启aof,具体的命令就是CONFIG SET appendonly yes，我们这个时候再来看下aof文件的大小，具体的如下：

我们发现appendonly.aof文件和dump.rdb的文件一样大，这个时候我们再来看下这个appendonly.aof文件中的内容，具体的如下：

可以发现一大堆看不懂的东西，不是我们看到的Resp协议的东西了，这是因为Redis4.0后的混合持久化机制。

redis4.0后混合持久化机制

如何开启混合持久化

4.0版本的混合持久化默认关闭的，通过aof-use-rdb-preamble配置参数控制，yes则表示开启，no表示禁用，5.0之后默认开启。

混合持久化是通过bgrewriteaof完成的，不同的是当开启混合持久化时，fork出的子进程先将共享的内存副本全量的以RDB方式写入aof文件，然后在将重写缓冲区的增量命令以AOF方式写入到文件，写入完成后通知主进程更新统计信息，并将新的含有RDB格式和AOF格式的AOF文件替换旧的的AOF文件。简单的说：新的AOF文件前半段是RDB格式的全量数据后半段是AOF格式的增量数据，

优点：混合持久化结合了RDB持久化 和 AOF 持久化的优点, 由于绝大部分都是RDB格式，加载速度快，同时结合AOF，增量的数据以AOF方式保存了，数据更少的丢失。

缺点：兼容性差，一旦开启了混合持久化，在4.0之前版本都不识别该aof文件，同时由于前部分是RDB格式，阅读性较差

这个时候我们只需要在配置文件中开启对应的aof就可以将之前的文件也同步过来了，我们可以试试，具体的如下：

可以发现我们的数据没有丢失了，所以这儿运维一定要小心，一定要小心，一定要小心。重要的事说三遍。

上面的配置项还有一个重写的机制我没有讲，那么重写机制又是什么呢？

AOF的重写机制

当AOF文件增长到一定大小的时候Redis能够调用 bgrewriteaof对日志文件进行重写 。当AOF文件大小的增长率大于该配置项时自动开启重写（这里指超过原大小的100%）。

auto-aof-rewrite-percentage 100

当AOF文件增长到一定大小的时候Redis能够调用 bgrewriteaof对日志文件进行重写 。当AOF文件大小大于该配置项时自动开启重写

auto-aof-rewrite-min-size 64mb

总结：也就是说当aof的文件达到了64MB的时候，这个时候AOF会进行重写，可以简单的理解为压缩，就是将在原来的数据的内容不变的情况下，尽最大的努力压缩AOF文件，假设压缩到40MB，这个时候第二次压缩的的时候就是80MB(40+40*100%(就是上面auto-aof-rewrite-percentage的配置项))，依次类推，每次增量都是一倍。

最后再画两张图分别介绍一下在rdb和aof同时开启的时候加载aof和rdb文件的情况和aof重写的机制。首先先看在rdb和aof同时开启的时候加载aof和rdb文件的情况，具体的如下：

这也就解释我们之前开启AOF的时候，我们的文件为什么会丢失的问题。接下来我们看看aof重写的机制重写机制的流程图，具体的如下：

3.总结

1.redis提供了rdb持久化方案，为什么还要aof？

优化数据丢失问题，rdb会丢失最后一次快照后的数据，aof丢失不会超过2秒的数据

2.如果aof和rdb同时存在，听谁的？

aof

3.rdb和aof优势劣势

rdb 适合大规模的数据恢复，对数据完整性和一致性不高，在一定间隔时间做一次备份，如果redis意外down机的话，就会丢失最后一次快照后的所有操作。

aof 根据配置项而定。

官方建议：两种持久化机制同时开启，如果两个同时开启 优先使用aof持久化机制

4.性能建议（这里只针对单机版redis持久化做性能建议）：

因为RDB文件只用作后备用途，只要15分钟备份一次就够了，只保留save 900 1这条规则。

如果开启 AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。
代价一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。
只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。
默认超过原大小100%大小时重写可以改到适当的数值。

8.写在最后

我这篇博客主要简单的介绍了下Redis的简单的API和Redis的一些持久化的机制。相信大家看了这篇博客，对Redis的持久化的面试应该能满分。