主从同步数据选择的方法-----数据耐久化操纵 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 呼吁生存，再次规复时再次执行呼吁
Linux公社的RSS地点：https://www.linuxidc.com/rssFeed.aspx