主从同步数据选择的方式-----数据持久化操作  redis在正常关闭时触发rdb操作

rdb持久化是指在客户端输入save和bgsave或者达到配置文件自动保存快照条件时，将redis在内存的数

生成快照保存在dump.rdb文件中

save 会阻塞redis主进程，直到rdb文件创建完毕

bgsave命令的原理

1.redis主进程fork一个和组进程完全一样的子进程进行持久化,验证方法，执行bgsave后另一个终端ps -ef | grep redis

2.子进程将内存中的数据写入到一个临时RDB文件中，主进程不进行IO操作，确保主进程极高的性能，这个就是解释为什么要fork子进程(redis单线程)

3.当子进程完成rdb文件时，redis会使用新的rdb文件替代旧的文件，之后删除旧的文件

在备份数据时，当进程的内存空间为G时，无法正常的分配内存，可以修改系统参数

/etc/sysctl.conf

vm.overcommit_memory=1

退出执行sysctl -p

0:请求分配的虚拟内存和系统当前空闲内存+swap内存进行比较

1:直接放行

2:比较进程已经占用的内存+请求分配的内存与系统的空闲内存+swap内存

flushall，清空redis内存中的数据，此时就会异常宕机，再次重启redis时，会再次读取rdb文件，相当于flushall的操作无意义，所以会触发rdb机制。


生产上一般的选择，redis4.0以后才提供rdb和aof重新，当两个持久化方式都存在时优先使用aof

append-only file(AOF)--数据实时追加的方式把操作及记录保存在磁盘中，会影响redis使用的效率

为了压缩AOF的持久化文件，Redis提供了bgrewriteaof命令。

收到此命令后Redis将使用与快照类似的方式将内存中的数据以二进制的数据方式保存到临时文件中，其他的aof日志还是以命令字符串的方式保存，

这样会较少aof文件的大小

最后替换原来的文件，以此来实现控制AOF文件的增长


appendonlya.aof文件重写，就是把一些命令相互抵消，或者命令整合达到aof文件瘦身的效果。

重写会fork一个和主进程完全一样的子进程，基于内存中的数据，以rdb文件存储格式替换旧的aof文件

appendonly no（默认关闭状态）

开启的话在/usr/local/redis/bin目录下生成appendonly.aof文件


no-appendfsync-on-rewrite yes #在日志重写时，命令只是将其放在缓冲区里。

auto-aof-rewrite-percentage 100 #当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时，自动启动新的日志重写过程。

auto-aof-rewrite-min-size 5GB,最少 #当前AOF文件启动新的日志重写过程的最小值，避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写



为什么出现aof持久化

rdb触发机制： shutdown；save 时间可能较长； bgsave;  如果没有这些人工的操作，宕机时丢失数据较多

aof触发机制: 指定更新日志条件

appendfsync   no：表示等操作系统进行数据缓存同步到磁盘(效率快，持久化没保证)，不建议

  always: 同步持久化，每次发生数据变化时，立即记录到磁盘(效率慢，安全)

  everysec：表示每秒同步一次(m默认值，很快，但可能会丢失一秒的数据)

没有子进程，开启aof会有一个缓冲区1M，主进程把数据缓存在缓存区在存储在aof文件中

rdb 基于内存中的数据持久化的，  二进制文件，较少

aof基于命令字符串文件较大，把set 命令保存，再次恢复时再次执行命令