Redis持久化机制与位图api
持久化机制
将我们的内存数据 通过数据持久化写入磁盘中实现持化、
Redis官方提供了两种不同的持久化方法来将内存的数据存储到硬盘里面分别是:
- RDB持久化，快照(Snapshot)【默认】
- AOF (Append Only File) 只追加日志文件【默认不开启】
1.快照(snapshot)（关机慢开机快）
redis默认开启持久化，将某一时刻的所有数据写入磁盘中，保存文件是以rdb形式结尾，所以也叫RDB持久化
快照生成方式
客户端方式：BGSAVE 和SAVE命令
服务器配置自动触发
客户端方式：BGSAVE 我们客户端通过BGSAVE来创建一个快照当接收到了客户端的命令时，redis会调用fork来创建一个子进程，子进程负责将快照写入磁盘中，而父进程需要继续处理命令请求
{fork是用来创建子进程}
SAVE:
客户端通过使用SAVE命令来创建一个快照，接收到SAVE命令的redis服务区在快照创建完成前不在响应命令
redis处于阻塞状态,无法对外界服务
3.服务器配置方式之满足配置自动触发
- 如果用户在redis.conf中设置了save配置选项,redis会在save选项条件满足之后自动触发一次BGSAVE命令,如果设置多个save配置选项,当任意一个save配置选项条件满足,redis也会触发一次BGSAVE命令
1.修改生成快照名称- dbfilename wangjun-dump.rdb
2.修改生成位置- dir ./
AOF 只追加日志文件
这种方式可以将所有客户端执行的**写命令**（数据发生改变）记录到日志文件中,AOF持久化会将被执行的写命令写到AOF的文件末尾,以此来记录数据发生的变化,因此只要redis从头到尾执行一次AOF文件所包含的所有写命令,就可以恢复AOF文件的记录的数据集.
文件记录着每次的写命令操作。将AOF中的写文件从头到尾只写一遍，这样就能恢复数据集
.开启AOF持久化
在redis的默认配置中AOF持久化机制是没有开启的，需要在配置中开启
1.开启AOF持久化
- a.修改 appendonly yes 开启持久化
- b.修改 appendfilename "appendonly.aof" 指定生成文件名称(可以)
1.修改日志同步频率
- 修改appendfsync everysec|always|no 指定
日志追加频率
# 1.always 【谨慎使用】
- 说明: 每个redis写命令都要同步写入硬盘,严重降低redis速度
- 解释: 如果用户使用了always选项,那么每个redis写命令都会被写入硬盘,从而将发生系统崩溃时出现的数据丢失减到最少;遗憾的是,因为这种同步策略需要对硬盘进行大量的写入操作,所以redis处理命令的速度会受到硬盘性能的限制;
- 注意: 转盘式硬盘在这种频率下200左右个命令/s ; 固态硬盘(SSD) 几百万个命令/s;
- 警告: 使用SSD用户请谨慎使用always选项,这种模式不断写入少量数据的做法有可能会引发严重的`写入放大`问题,导致将固态硬盘的寿命从原来的几年降低为几个月。
# 2.everysec 【推荐默认】
- 说明: 每秒执行一次同步显式的将多个写命令同步到磁盘
- 解释： 为了兼顾数据安全和写入性能,用户可以考虑使用everysec选项,让redis每秒一次的频率对AOF文件进行同步;redis每秒同步一次AOF文件时性能和不使用任何持久化特性时的性能相差无几,而通过每秒同步一次AOF文件,redis可以保证,即使系统崩溃,用户最多丢失一秒之内产生的数据。
# 3.no 【不推荐】
- 说明: 由操作系统决定何时同步
- 解释：最后使用no选项,将完全由操作系统决定什么时候同步AOF日志文件,这个选项不会对redis性能带来影响但是系统崩溃时,会丢失不定数量的数据,甚至丢失全部数据，另外如果用户硬盘处理写入操作不够快的话,当缓冲区被等待写入硬盘数据填满时,redis会处于阻塞状态,并导致redis的处理命令请求的速度变慢。
AOF文件的重写（面试必问）
为了减小AOF文件的体积，加快启动速度，并且保证数据不丢失
触发重写方式
# 1.客户端方式触发重写
- 执行BGREWRITEAOF命令 不会阻塞redis的服务
# 2.服务器配置方式自动触发
- 配置redis.conf中的auto-aof-rewrite-percentage选项 参加下图↓↓↓
- 如果设置auto-aof-rewrite-percentage值为100和auto-aof-rewrite-min-size 64mb,并且启用的AOF持久化时,那么当AOF文件体积大于64M,并且AOF文件的体积比上一次重写之后体积大了至少一倍(100%)时,会自动触发,如果重写过于频繁,用户可以考虑将auto-aof-rewrite-percentage设置为更大
**注意：重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件,替换原有的文件这点和快照有点类似。**
# 重写流程
- 1. redis调用fork ，现在有父子两个进程 子进程根据内存中的数据库快照，往临时文件中写入重建数据库状态的命令
- 2. 父进程继续处理client请求，除了把写命令写入到原来的aof文件中。同时把收到的写命令缓存起来。这样就能保证如果子进程重写失败的话并不会出问题。
- 3. 当子进程把快照内容写入已命令方式写到临时文件中后，子进程发信号通知父进程。然后父进程把缓存的写命令也写入到临时文件。
- 4. 现在父进程可以使用临时文件替换老的aof文件，并重命名，后面收到的写命令也开始往新的aof文件中追加。
