Redis持久化，主从与哨兵

持久化

redis默认开启的持久化策略是RDB。如果两个都开启了，重启时默认用AOF。一般来说AOF数据更全。

RDB

在redis.conf中配置多个策略 ，其中一个条件被触发，就将内存中的全部数据写入dump.rdb二进制文件。也可以在客户端使用save或bgsave命令进行内存快照。RDB每次快照会覆盖原有数据。

save 900 1   # 900秒内有一次修改
save 300 10 # 300秒内有10次修改
save 60 1000  #60秒内有1000次修改

save是主线程执行的命令，会造成阻塞，默认使用bgsave进行异步保存。

缺点

数据丢失。做一个持久化会把内存中所有的数据快照，频繁快照影响性能，且配置的触发保存的条件也不能频繁执行，如果配置半分钟保存一次，宕机后，最后半分钟数据因未保存而丢失。

什么是写时复制COW？

Copy-On-write，在生成快照的同时，可以正常处理写命令。

主线程fork生成bgsave子进程，可以共享主线程的所有内存数据。
bgsave子进程将主线程的内存数据写入RDB的同时，如果主线程在修改数据，这个数据会被复制一份，由bgsave子进程把该副本写入RDB文件，主线程依然可以直接修改原来的数据。

AOF

Append Only File 追加保存指令。
在redis.conf文件中开启aof功能。 将修改的每一条指令，追加到appendonly.aof文件中。恢复服务时，重新将文件中的指令逐条执行。

appendonly yes

持久化策略

1. 每秒执行一次 【默认采用，兼顾速度和安全性】
2. 每执行一条命令 影响性能
3. 将数据交给操作系统处理

appendfsync always  #每当有新命令追加到AOF文件时就执行一次fsync，非常慢，但也很安全
appendfsync everysec #每秒fsync一次，足够快，并且在故障时只会丢失1秒的数据
appendfsync no #从不fsync，将数据交给操作系统来处理。更快，也更不安全

缺点

如果redis长时间运行，那么aof文件会很大。恢复数据时，要重新将aof的命令全部执行，恢复慢。【文件大，恢复慢】
宕机时，也会丢失一秒数据。

AOF重写

对于INCR readcount 累加操作，如果在AOF中记录每一次INCR命令，在恢复数据时，会要重新执行N遍。如果记录一个最终的累加值，恢复数据时只需要一次读取。

auto-aof-rewrite-min-size 64mb //aof文件达到64MB才会自动重写，文件太小恢复速度本来就很快，重写意义不大
auto-aof-rewrite-percentage 100  //aof文件自上一次重启后文件大小增长100%则再次触发重写

也可以在客户端执行命令手动重写 bgrewriteaof
注：AOF重写时，redis会fork出一个子进程去做，不会对redis正常命令处理有太多影响。

RDB与AOF对比

混合持久化

Redis4.0后，结合了RDB和AOF优点，新增了混合持久化方式。它其实就是在AOF的基础上进行了优化。 必须先开启AOF，可以关闭RDB。

aof-use-rdb-preamble yes

工作原理

AOF重写时，会将这一刻之前的内存做RDB快照处理，并将RDB快照内容和增量的AOF修改内存数据的命令存放在一起，重写完成才会将文件名改为appendonly.aof覆盖原文件。
Redis重启时，可以先加载RDB的内容，然后再重放增量AOF日志，就可以完全替代之前的AOF全量文件重放，效率大幅提升。

Redis数据备份策略

1. 写crontab定时调度脚本，每小时都copy一份rdb或aof的备份到一个目录中去，仅仅保留最近48小时的备份
2. 每天保留一份当日的数据备份到一个目录中去，可以保留最近一个月的备份
3. 每次copy备份的时候，都把太旧的备份删掉，避免占用空间。
4. 多机器备份，以防机器损坏。每天晚上，将当前机器上的备份复制一份到其他机器上。

主从架构

只有主节点提供写服务。从节点备份，也可以提供读操作，缓解主节点压力

搭建主从的配置信息

首先复制一份redis.config文件

Redis主从工作原理

master配置了slave之后，不管这个slave是不是第一次连接上master，它都会发送一个PSYNC命令给master请求复制数据。

master收到PSYNC命令后，会在后台进行数据持久化，通过bgsave命令生成最新的rdb快照文件。
持久化期间master会继续接收客户端的请求，并把这些修改请求命令缓存在内存中。当持久化完成后，master会把之前缓存在内存中的命令发送给slave。

当master与slave的连接中断时，slave能够自动重连master。 如果maser收到多个slave并发连接请求，它只会进行一次持久化，再把这一份持久化数据发送给多个并发连接的slave。

全量复制

repl backlog buffer 增量日志缓冲区默认是1MB

replica-backlog-size 1mb

部分复制

主从复制风暴

多个从节点同时复制主节点导致主节点压力过大。采用阶梯式节点复制。
优化措施：部分从节点与主节点同步完成后，让其他的从节点去复制已完成同步的从节点。

哨兵架构

单纯的主从架构，从节点只是用来备份或读操作，主节点宕机后，不能自动进行主节点的选举。

哨兵是用来监听主从节点的状态的，客户端不再直接连主从节点，而是连接哨兵节点。主从节点宕机后，哨兵能选举出新的主节点。

因为哨兵知道所有的主从节点信息，所以哨兵会把主节点信息返回给客户端。客户端第一次连接哨兵成功之后，拿到了主节点信息，第二次之后直接访问主节点。 选举完成后，哨兵会把新的主节点信息推送给客户端。

哨兵本身也是redis实例。

管道 Pipeline

redis执行命令的时间很短，但从客户端发到服务端的时间比执行命令的时间更长，所以可以用管道，客户端一次性发送N条命令，节省N-1次命令发送的网络传输的开销

管道没有事务原子性，第一条执行失败后，会继续执行剩下的命令。全部执行完成后返回一个结果集