redis笔记（四）redis持久化

redis持久化

• Redis持久化机制：redis是一个支持持久化的内存数据库，也就是说redis需要经常将内存中的数据同步到磁盘来保证持久化，持久化可以避免因进程退出而造成数据丢失

• RDB持久化方式

  1. RDB持久化把当前进程数据生成快照（.rdb）文件保存到硬盘的过程，有手动触发和自动触发。手动触发有save和bgsave量命令
  2. save命令：阻塞当前Redis，直到RDB持久化过程完成为止，若内存实例比较大会造成长时间阻塞，线上环境不建议用它。
  3. bgsave命令：redis进程进行fork操作创建子进程，由子线程完成持久化，阻塞时间很短（微秒级），是save的优化，在执行redis-cli shudown关闭redis服务时，如果没有
     开启AOF持久化，自动执行bgsave

• RDB文件的操作

  1. 命令：config set dir /usr/local //设置rdb文件保存路径
  2. 备份：bgsave //将dump.rdb文件保存到/usr/local下
  3. 恢复：将dump.rdb放到文件安装目录与redis.conf同级目录，重启redis即可
  4. 优缺点：
     1>优点：
     a, 压缩后的二进制文件适用于备份、全量复制，用于灾难恢复
     b, 加载RDB恢复数据远快于AOF方式
     2>缺点：
     a, 无法做到实时持久化，每次都要创建子进程，频繁操作成本过高
     b, 保存后的二级制文件，存在老版本不兼容新版本rdb文件的问题

• AOF持久化

  1. 针对RDB不适合实时持久化，redis提供了AOF持久化方式来解决

  2. 开启：redis.conf设置-----appendonly yes (默认不开启，为no)

  3. 默认文件名：appendfilename "appendonly.aof"

  4. aof 持久化流程
     1> 所有的写入命令（set,hset等）会append追加到aof_buf缓冲区中
     2> AOF缓冲区向硬盘做sync同步
     3> 随着AOF文件越来越大，需要定期对AOF文件rewrite重写，达到压缩
     4> 当redis服务重启，可load加载AOF文件进行恢复命令写入（append）,文件同步（sync）,文件重写（BGREWRITEAOF），重启加载（load）

  5. AOF配置详解
     1> appendonly yes //启用aof持久化方式
     2> appendfsync always //每收到写命令就立即强制写入磁盘，最慢的，但保证了完全的持久化，不推荐使用
     3> appendfsync everysec //每秒强制写入磁盘一次，性能和持久化方面做了折中，推荐
     4> apendfsync no //完全依赖OS,性能最好，持久化没保证（操作系统自身的同步）
     5> no-apendfsync-on-rewrite yes //正在导出rdb快照的过程中，要不要停止同步aof
     6> auto-aof-rewrite-percentage 100 //aof文件比起上次重写时的大小，增长率100%时重写
     7> auto-aof-rewrite-min-size 64mb //aof文件，至少超过64MB时重写

  6. aof如何恢复？
     1> 设置 appendonly yes
     2> 将appendonly.aof 放到dir参数指定的目录
     3> 启动redis，Redis会自动加载appendonly.aof文件

  7. redis重启时加载AOF和RDB的顺序
     1> 当AOF和RDB文件同时存在时，优先加载
     2> 当关闭了AOF，加载RDB
     3> 加载AOF/RDB成功,redis启动成功
     4> AOF/RDB存在错误，启动失败，打印错误信息

• redis主从复制（在同一台服务器上，以6379为主，6380为从举例）

  1. 方式一：新增redis6380.conf，并再redis6380.conf文件中加入slaveof 192.168.19.22 6379 ,在6379启动完成后再启动6380，即可完成主从复制配置
  2. 方式二：启动6379端口后，启动6380端口的redis, redis-server redis6380.conf --slaveof 192.168.19.22 6379。不需要在redis6380.conf配置文件做任何修改
  3. 查看状态：info replication
  4. 断开主从复制：在slave（6380客户端）节点客户端里执行 ： slaveof no one
  5. 断开后再变成主从复制：在slave（6380客户端）节点客户端里执行 ： slaveof 192.168.19.22 6379
  6. 数据较重要的节点，主从复制时使用密码验证：requirepass
  7. 从节点建议用只读模式slave-read-only=yes，否则若从节点修改数据，从节点中修改的数据不会同步到主节点，主从数据会不一致
  8. 注意事项传输延迟：主从一般部署在不同机器上，复制时存在网络延时问题，redis提供repl-disable-tcp-nodelay参数决定是否关闭TCP_NODELAY,默认关闭
     1> 参数关闭时：无论大小都会及时发布到从节点，占带宽，适用于主从网络好的场景
     2> 参数开启时：主节点合并所有数据成TCP包节省带宽，默认为40毫秒发一次，取决于内核，主从的同步延迟40毫秒，适用于网络环境复杂或带宽紧张如跨机房

• Redis主从拓扑

  1. 一主一从：用于主节点故障转移从节点，当主节点的"写"命令并发高且需要持久化，可以只在从节点上开启AOF(主节点不需要)
  2. 一主多从：针对“读”较多的场景，“读”由多个从节点来分担，但节点越多，主节点同步到从节点的次数也越多，影响带宽，也加重主节点的稳定
  3. 树状主从：一主多从的缺点（主节点推送次数多压力大）可用些方案解决，主节点只推送一次数据导从节点1，再由从节点2推送到11，减轻主节点推送的压力

• 主从复制原理（配置主从后）

  1. 保存主节点信息
  2. 主从建立socket连接
  3. 发送Ping命令
  4. 权限验证
  5. 同步数据集
  6. 命令持续复制

• 数据同步：redis2.8版本以上使用psync命令完成同步，过程分“全量”和“部分”复制

  1. 全量复制：一般用于初次复制场景（第一次建立slave后全量）
  2. 部分复制：网络出现问题，从节点再次连主时，主节点补发缺少的数据，每次数据增加同步
  3. 心跳：主从有长连接心跳，主节点默认每10s向从节点发Ping命令，repl-ping-slave-period控制发送频率