002-Redis持久化、主从、哨兵架构分析

持久化

RDB 快照

触发规则

文件名称和目录

手动触发

save //阻塞保存
bgsave //不阻塞异步保存，fork子进程

AOF

append-only file
记录所有修改命令写入文件

触发策略

appendfsync always #每次同步，性能消耗较大
appendfsync no #从不同步，操作系统决定是否同步

AOF优化

避免文件行数过大会重写命令
如对一个key n次执行自增+1操作
会最后优化为 key 自增 + n

触发策略

文件大小增加了100%
文件大小增加了64M
底层执行 > bgrewritedaof

怎么选择

AOF 恢复内存数据速度较慢，但是安全，只会丢失少量数据
RDB 恢复内存数据速度块，占用磁盘小，但是根据触发策略可知有可能丢失分钟级数据

所以在两个都开启的情况下，Redis优先选择AOF恢复
并且redis提供了混合持久化功能

混合持久化

前提：必须先开启AOF

重写的时候吧内容重写为二进制压缩格式（RDB file）
新的内容还是AOF格式
都存到AOF文件中

主从架构

基础设置

从节点复制配置

复制原理

全量复制

1. 从节点启动建立长连接
2. psync同步数据
   a. 从节点发起
   b. 主节点执行bgsave生成最新快照（这个快照和上边的持久化不是一回事）
   c. 发送 快照数据给从节点
   d. 从节点接收到之后清空数据并加载接收到的快照
   e. 生成快照后的数据变化存入repl buffer
   f. 发送备份数据给从节点
   g. 执行备份数据
   h. 主节点新的写命令，全部发送给从节点一份保持一致（命令重放）

增量复制

发送psync的时候传输offset
主节点在repl backlog buffer（FIFO 1M）中查询是否存在offset位置命令
如果有则从offset位置开始同步
如果没有则走全量同步流程

架构问题

主从复制风暴

多个从节点同时从主节点复制
解决方案：阶梯式分布，从节点复制从节点数据

哨兵模式

修改 sentinel.conf文件
sentinel monitor mymaster ip point quorum(多少哨兵认为主节点失效时才算真的失效，推荐值:哨兵总数/2+1)

哨兵模式客户端连接连接的是哨兵而不是redis实例
哨兵会选取出出主节点

结构图

重新选举

选举后追加写入 sentinel.conf文件