redis的数据备份dump.rdb和AOF

redis的数据备份有两种方式，一种是dump.rdb文件，一种是AOF。如果没有开启AOF,也可以用 monitor 加 grep命令全部重定向到文件的办法把全部的数据生成txt，再用脚本倒回到本地的服务器。

快照备份dump.rdb

关于dump.rdb的相关配置在redis的配置文件redis.conf中的SNAPSHOTTING一节。
其中的关键配置有以下几项。

1. 快照存储频率
   
   save <soconds> <changes> 格式意思为多少秒做多少操作会写入快照中。例如一个客户端只做了一个操作，那么这个操作不会立即写入快照，而是等到900秒之后才会写入。客户端也可以执行save或者bgsave来强制快照操作，二者的区别是save会阻塞一切操作，而bgsave是在后台异步进行快照操作，依然能响应客户端的请求。
   lastsave可以查看最近一次快照存储的时间。
2. 快照存储失败时是否禁止客户端的写操作
   
   当打开了redis的快照功能，如果最近一次的快照存储失败，则服务端会禁止客户端的写操作。这是为了让用户知悉此时数据并没有持久化到磁盘，防止意外情况的发生。存储成功后会自动允许写操作。
3. 是否压缩rdb文件
   
   redis采用LZF压缩，若想节约CPU可以选择关闭，若想节约磁盘空间则应该选择开启。
4. rdb文件名称及所在目录
   
   需要注意，默认配置文件中dump.rdb生成的目录为./，是指运行redis-server时的目录，而不是redis.conf所在的目录。

AOF

AOF(Append Only File)与dump.rdb文件不同的地方在于AOF会把redis-cli所作的所有操作都会记录下来。

appendonly yes —开启AOF
appendfilename “appendonly.aof” —AOF日志文件名
# appendfsync always —这三种模式选择一种，意为redis调用fsync告诉操作系统向盘中写数据
appendfsync everysec —三种模式的安全级别由高到低，默认为everysec
# appendfsync no
no-appendfsync-on-rewrite no —应用系统无法忍受延迟，而可以容忍少量的数据丢失，则设置为yes。如果应用系统无法忍受数据丢失，则设置为no
auto-aof-rewrite-percentage 100 —当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时，自动启动新的日志重写过程
auto-aof-rewrite-min-size 64mb —当前AOF文件启动新的日志重写过程的最小值，避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写

1. 什么是rewrite？
   随着操作记录的增长，AOF也将随之增大，因此就有了AOF重写的机制，即rewrite，什么叫AOF rewrite，举个例子，假设有个key:value是carCount:1，对carCount设置了3次值，分别为set carCount=2，set carCount=3，set carCount=4，那么最后carCount的值为4，如果不对AOF进行重写，那么将会有3条针对carCount的操作记录，为了减小AOF的大小，redis server会定期对AOF进行重写，重写之后，刚刚针对carCount的操作将会合并成1条，即set carCount=4（只保留最终的操作结果，省略了中间的过程）
2. fsync与rewrite写同一个文件，二者是否冲突？
   会。所以设置参数no-appendfsync-on-rewrite 为yes，防止rewrite的同时有fsync操作，fsync把数据写在缓冲区，有可能会造成数据丢失，但防止了延迟。如果此项参数设置为no，则rewrite和fsync会竞争，此时操作可能会延迟，但数据更安全。

监控命令monitor

redis-cli -a passwd -h ip -p port monitor |grep "lpush listname" > redis_monitor.log

用redis-cli的monitor搭配grep命令，可以筛选出想要的redis客户的特定操作，例如上图中的语句可以筛选出所有push到listname中的语句。但是生成的日志redis_monitor.log并不能导入到redis中，需要写脚本另行处理。