煮酒听雨

redis持久化机制

编辑时间：2020-10-28 编辑：忘尘阅读：163

####RDB
Redis DataBase 将某一个时刻的内存快照(Snapshot )，以二进制的方式写入磁盘

- 手动触发
 - `save`命令，使Redis 处于阻塞状态，直到RDB持久化完成，才会响应其他客户端发来的命令，所以在生产环境一定要慎用
 
 - `bgsave`命令，fork出一个子进程执行持久化，主进程只在fork过程中有短暂的阻塞，子进程创建之后，主进程就可以响应客户端请求了

- 自动触发
 - save m n :在m秒内,如果有n个键发生改变,则自动触发持久化,通过bgsave 执行，如果设置多个、只要满足其一就会触发,配置文件有默认配置(可以注释掉)
 
 - `flushall`: 用于清空所有的数据库，`flushdb `清空当前所在库数据(默认是0号数据库),会清空RDB文件,同时也会生成dump .rdb、内容为空
 
 - 主从同步:全量同步时会自动触发bgsave命令，生成rdb发送给从节点
 
 
#####优点:
1. 整个Redis 数据库将只包含一个文件dump.rdb，方便持久化

2. 容灾性好，方便备份

3. 性能最大化，fork子进程来完成写操作,让主进程继续处理命令，所以是IO最大化。使用单独子进程来进行持久化，主进程不会进行任何IO操作，保证了redis 的高性能
 
 
#####缺点:
1. 数据安全性低。RDB是间隔一段时间进行持久化，如果持久化之间redis发生故障,会发生数据丢失。所以这种方式更适合数据要求不严谨的时候

2. 由于RDB是通过fork子进程来协助完成数据持久化工作的，因此,如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒,甚至是1秒钟。会占用cpu
 
 
<br>
------------

####AOF
 Append Only File 以日志的形式记录服务器所处理的每一个`写`、`删除`操作,查询操作不会记录,以文本的方式记录,可以打开文件看到详细的操作记录,调操作系统命令进程刷盘
 
1.  所有的写命令会加到AOF缓冲中

2.  AOF缓冲区根据对应的策略向硬盘进行同步操作。

3.  随若AOF文件越来越大，需要定期对AOF文件进行写，达到压缩的目的。

4.  当Redis重启时，可以加载AOF文件进行数据恢复。

#####同步策略
- 每秒同步: 异步完成，效率非常高,一旦系统出现机现象，那么这一秒钟之内修改的数据将会丢失

- 每修改同步: 同步持久化，每次发生的数据变化都会被立即记录到磁盘中，最多丢一条

- 不同步: 由操作系统控制，可能丢失较多数据

在redis.conf文件中配置
```
appendonly yes

#相关配置
appendfilename "appendonly.aof"
# appendfsync always      #每次有一个写命令,就把命令存入aof文件里
appendfsync everysec      #每秒存入aof文件一次(建议选用)
# appendfsync no          #不同步到硬盘aof文件（让操作系统来决定何时进行同步）
```

#####优点:
1. 数据安全

3. 通过append 模式写文件，即使中途服务器机也不会破坏已经存在的内容，可以通过redis-check-aof工具解决数据一致性问题

5. AOF机制的rewrite模式，定期对AO文件进行重写，以达到压缩的目的
 
#####缺点:
1. AOF文件比RDB文件大，且恢复速度慢。

3. AOF数据集大的时候，比RDB启动效率低。

5. AOF运行效率没有RDB高

------------

####RDB与AOF比较：
- AOF文件比RDB更新频率高，优先使用AOF还原数据。如果两个都配了优先加载AOF（数据恢复机制）

- AOF比RDB更安全

- RDB性能比AOF好

##### 相关文章
https://my.oschina.net/davehe/blog/174662

来说两句吧