对redis一直情有独钟，所以总觉得手里又把锤子，看哪里都是钉子的感觉。这篇是读Redis入门指南这本书中持久化的相关内容。
rdb触发机制
1. redis.conf配置文件中定义的
2. 用户执行了SAVE或者BGSAVE
SAVE会阻塞进程直至完成，而BGSAVE会在后台异步执行
3. 执行了FLUSHALL命令
如果redis.conf中没有定义任何快照计划，执行FLUSHALL时不会触发快照动作。反之定义了1个或以上都会触发快照动作。
4. 执行复制(replication)时
只要是执行了replication，不管如何都会进行快照动作### 总结
1. Redis在进行快照的过程中不会修改RDB文件，只有快照结束后才会将旧的文件替换成新的，也就是说任何时候 RDB 文件都是完整的。这使得我们可以通过定时备份 RDB 文件来实现 Redis 数据库备份。
2. 在不同的版本之间rdb文件恢复时候会提示版本不兼容。从高版本中导出的rdb文件有时候(**我测试3.2.6导出的可以在3.2.0上恢复,但是3.2.6和3.0.7无法恢复。所以应该是跨比较大的版本的时候**)是无法在低版本上进行恢复的。所以rdb文件一般都是从低版本导出到大于等于自身的高版本中恢复。(**AOF文件可以跨版本**)
Dec 19 02:28:00 ip-10-23-179-92 redis[13656]: Can't handle RDB format version 7
Dec 19 02:28:00 ip-10-23-179-92 redis[13656]: Fatal error loading the DB: Invalid argument. Exiting.
3. 如果配置文件同时开启了rdb和aof持久化操作，那么这个时候redis会使用aof文件进行恢复，如果aof文件不存在貌似也不会使用rdb恢复。所以我测试时关掉了`appendonly no`选项后恢复成功。## AOF
### 实现
auto-aof-rewrite-percentage 100 【当AOF文件超过上一次重写的AOF文件大小时进行重写操作】
auto-aof-rewrite-min-size 64mb 【限制允许重写的最小AOF文件大小】
BGREWRITEAOF命令也将会重新AOF文件### 同步硬盘数据
> 虽然每次执行更改数据库内容的操作时，AOF都会将命令记录在AOF文件中，但是事实上，由于操作系统的缓存机制，数据并没有真正地写入硬盘，而是进入了系统的硬盘缓存。在默认情况下系统每30秒会执行一次同步操作，以便将硬盘缓存中的内容真正地写入硬盘，在这30秒的过程中如果系统异常退出则会导致硬盘缓存中的数据丢失。
在 Redis 中我们可以通过 appendfsync 参数设置同步的时机：
```bash
# appendfsync always
appendfsync everysec #每秒同步一次，而不是系统默认的30秒执行一次同步操作(这也是redis的默认选项)
# appendfsync no
```
## Redis主从配置
> 从服务器开启`redis-server --port 7001 --slaveof 101.193.72.85 6379 --masterauth ooxx`
> 当一个从数据库启动时，会向主数据库发送SYNC命令，主数据库收到命令后会开始在后台保存快照（即RDB持久化过程），并将保存快照期间接收到的命令缓存起来。当快照完成后，Redis会将快照文件和缓存的命令发给从数据库，从数据库收到数据后，会载入快照文件并执行缓存的命令。以上过程称为复制初始化。复制初始化之结束后，主数据库每收到写命令时就会将命令同步给从数据库，从而保证主从数据库数据一致，这一过程称为复制同步阶段。
## 结构图
从数据库不仅可以接收主数据库的数据，同时也可以作为主数据库存在，形成类似图的结构，如下图：
