/
?
2、手动在Redis中保存
?
127.0.0.1:6379> SET key 1
OK
127.0.0.1:6379> SAVE
OK
?
下目录下面有没有修改：
-rw-r--r-- 1 root root 27 Oct 14 13:35 dump_6379.rdb 当前时间创建
在设置个key看下：
127.0.0.1:6379> SET key 2
OK
127.0.0.1:6379> SAVE
OK
?
-rw-r--r-- 1 root root 27 Oct 14 13:37 dump_6379.rdb
?
127.0.0.1:6379> BGSAVE
Background saving started
?
SAVE和BGSAVE有什么区别：SAVE 是阻塞的当你直接执行SAVE的时候他就不干活了，BGSAVE是在后台执行。forker一个子进程来进行SAVE！
?
SAVE的使用场景仅限于：当Redis需要迁移的时候，Redis没有数据写入并且可以停的时候使用！
?
测试添加一个：key然后停掉看看！不保存：
目前的key是：
127.0.0.1:6379> KEYS *
1) "key"
2) "key2"
3) "key3"
?
127.0.0.1:6379> SET key4 4
OK
?
杀掉，重启之后发现设置的key丢失了。
#所以当redis异常挂掉之后，没有SAVE收据！
?
3、启用了AOF后
?
给这个文件追加，把所有的命令都写到一个文件里面，你执行一个我写一个。
恢复的话在执行一遍不就行了吗！非常简单 （但是恢复相对RDB模式回慢他相当于重新把AOF库里的记录重新往内存中写一边）
?
可以RDB和AOF同时使用！优点都占用了！但是也的根据业务来定！
?
开启方法：修改配置文件
appendonly yes ?#改为yes
appendfilename "appendonly.aof" ?#文件名
?
?
工作原理：
forker 一个子进程写到临时文件，写完之后就给父进程发一个信号，开始写到写完的这个过程还会有子进程给父进程发信号。先保存在内存里
但是他有个好的功能，重写，他会定时对aof进行重新，这样文件就会非常小！
?
测试：（他会根据Redis可识别的方式写入文件，不过大概人也能看懂）
16:50 [root@192.168.7.107]$ cat appendonly.aof
*2
$6
SELECT
$1
0
*3
$3
SET
$4
kye1