redis实现快照的过程
1：redis使用fork函数复制一份当前进程的副本(子进程)
2：父进程继续接收并处理客户端发来的命令，而子进程开始将内存中的数据写入硬盘中的临时文件
3：当子进程写入完所有数据后会用该临时文件替换旧的RDB文件，至此，一次快照操作完成。
注意：redis在进行快照的过程中不会修改RDB文件，只有快照结束后才会将旧的文件替换成新的，也就是说任何时候RDB文件都是完整的。
这就使得我们可以通过定时备份RDB文件来实现redis数据库的备份
RDB文件是经过压缩的二进制文件，占用的空间会小于内存中的数据，更加利于传输。
手动执行save或者bgsave命令让redis执行快照。 两个命令的区别在于，save是由主进程进行快照操作，会阻塞其它请求。bgsave是由redis执行fork函数复制出一个子进程来进行快照操作。 文件修复：redis-check-dump rdb的优缺点 优点：由于存储的有数据快照文件，恢复数据很方便。 缺点：会丢失最后一次快照以后更改的所有数据。 如果要禁用rdb，可以在redis.conf中注释save900 1，save300 10, save60 10000,添加save "" #save900 1 #save300 10 # save60 10000 save "" 第二种方式 AOF aof方式的持久化是通过日志文件的方式。默认情况下redis没有开启aof，可以通过参数appendonly参数开启。 appendonly yes aof文件的保存位置和rdb文件的位置相同，都是 dir参数设置的，默认的文件名是appendonly.aof，可以通过appendfilename参数修改 appendfilenameappendonly.aof redis写命令同步的时机 appendfsyncalways 每次都会执行 appendfsynceverysec 默认 每秒执行一次同步操作（推荐，默认） appendfsyncno不主动进行同步，由操作系统来做，30秒一次 aof日志文件重写 auto-aof-rewrite-percentage100(当目前aof文件大小超过上一次重写时的aof文件大小的百分之多少时会再次进行重写，如果之前没有重写，则以启动时的aof文件大小为依据) auto-aof-rewrite-min-size64mb 手动执行bgrewriteaof进行重写 重写的过程只和内存中的数据有关，和之前的aof文件无关。 所谓的 “ 重写 ” 其实是一个有歧义的词语， 实际上， AOF 重写并不需要对原有的 AOF文件进行任何写入和读取， 它针对的是数据库中键的当前值。 文件修复：redis-check-aof 动态切换redis持久方式，从 RDB 切换到 AOF（支持Redis2.2及以上） CONFIGSET appendonly yes CONFIGSET save ""（可选） 注意：当redis启动时，如果rdb持久化和aof持久化都打开了，那么程序会优先使用aof方式来恢复数据集，因为aof方式所保存的数据通常是最完整的。 注意：如果想把正在运行的redis数据库，从 RDB切换到AOF，建议先使用动态切换方式，再修改配置文件，重启数据库。(不能自己修改配置文件，重启数据库，否则数据库中数据就为空了。) 当两种方式都开启的话，redis在启动时候会优先使用AOF恢复内存中的数据 rdb切换到AOF： 需要动态切换，在客户端执行命令：config set appendonly yes 执行这个命令后，在redis配置的路径下生产aof文件，里面有当前内存中的数据。 然后关掉客户端 redis-cli shutdown， 关掉redis server .因为我们是在客户端设置的参数，所以参数是临时参数，我们需要在redis的配置文件中修改 appendonly yes 配置使用AOF持久化方式，然后启动redis server，redis就使用AOF方式持久化 AOF文件不要随便删除，如果运行的时候删除AOF文件，退出redis的时候没有保存，在重启redis的时候，redis发现没有AOF文件，所以新建了另一个AOF文件，这样内存中 大数据就丢失了 AOF文件内容分析： *2 $6 SELECT $1 0 第一行*2，表示有两个参数，$6表示第一个参数有6个字符，SELECT是第一个参数，$1表示第二个参数有1个字符，0是第二个字符，那么命令就是select 0 ,redis默认有15个数据库，默认选择0号数据库 *3 $3 set $1 a $1 2 上面一串就表示命令set a 2