Redis持久化以及集群方案略述

redis的数据全部在内存中，如果突然宕机，数据就会全部丢失，因此需要持久化来保证Redis的数据不会因故障而丢失，redis重启的时候，可以重新加载持久化文件来恢复数据；
Redis持久化的相关配置

默认情况下，只开启rdb持久化
aof
append only file
aof 日志存储的是Redis服务器的顺序指令序列，aof日志只记录对内存修改的指令

恢复
通过重放（replay）,aof日志中指令序列来恢复Redis当前实例的内存数据结构的状态
配置

策略

缺点：

随着时间的增加，aof日志会越来越长，如果redis重启，重放rof日志会非常耗时，导致redis长时间无法对外提供服务

aof rewrite
aof持久化策略会持久化所有修改命令，里面很多命令其实可以合并或者删除；
aof rewrite在aof的基础上，满足一定策略则fork进程，根据当前内存状态，转换成一系列的redis命令，序列化成一个新的aof文件中，序列化完毕后，再将操作期间增量的aof日志追加到新的aof文件中，追加完毕后替换aof文件，以达到aof文件瘦身的目的
注意：aof rewrite的前提是开启aof
流程图如下：


配置

策略

缺点
aof复写在aof的基础上实现了瘦身，但是aof复写的数据量仍然很大；加载会非常慢

rdb
基于aof或aof复写文件大的缺点，rdb是一种快照持久化；它通过fork主进程，在子进程中将内存当中的数据键值对按照存储方式持久化到rdb文件中，rdb存储的是经过压缩的二进制数据
流程如下

配置

策略

缺点
若采用rdb持久化，一旦redis宕机，redis将丢失一段时间的数据；
RDB需要经常fork子进程来保存数据集到硬盘上，当数据集较大时，fork的过程时非常耗时的，可能会导致Redis在一些毫秒级内不能响应客户端的请求，如果数据集巨大并且CPU性能不是很好的情况下，这种情况会持续一秒，AOF也需要fork,但是你可以调节重写日志文件的频率来提高数据集的耐久度。

混合持久化
从上面知道，rdb文件小且加载快但丢失多，aof文件大加载慢但丢失多；混合持久化是吸取rdb和rof两者优点的一种持久化方案；aof复写的时候实际持久化的内容是rdb,等持久化后，持久化期间的数据以aof的形式附加到文件尾部；
混合持久化，实际上是在aof rewrite的基础上进行的优化，所以需要开启aof rewrite
流程如下图

配置

Redis主从复制
主要是用来实现Redis数据的可靠性，防止主Redis所在磁盘损坏，造成数据永久丢失
主从之间采用异步复制的方式

命令

数据同步
全量数据同步

流程如下图

增量数据同步流程如下图：

服务器RUN ID
无论主库还是从库都有自己的RUN ID，RUN ID启动时自动产生，RUN ID由40个随机的十六进制字符组成
当从库对主库初次复制时，主库将自身的RUN ID传送给从库，从库会将RUN ID保存
当从库断线从连主库时，从库向主库发送之前保存的主库RUN ID
1.从库RUN ID和主库RUN ID一致时，说明从库断线前复制的就是该主库，主库尝试进行增量同步
2.若不一致，说明从库断线前复制的主库不是当前的主库，则主库将对从库进行全量同步操作
复制偏移量offset
主从都会维护一个复制偏移量
1.主库向从库发送N个字节的数据时，将自己的复制偏移量加N；
2.从库接收到主库发送的N个字节数据时，将自己的复制偏移量加上N；
通过比较主从偏移量得知主从之间的数据是否一致；偏移量相同则数据一致，偏移量不一致则数据不一致

环形缓冲区（复制积压缓冲区）
本质上是固定长度先进先出队列

当某些原因（网络抖动或从库宕机）从库与主库断开链接。避免断开链接后开始全量同步。在主库设置一个环形缓冲区；该缓冲区会在从库失联期间累计主库的写操作；当从库重连，会发送自身的复制偏移量到主库，主库会比较主从的复制偏移量；
1.若从库的offset还在复制挤压缓冲区中，则进行增量同步
2.否则，主库将对从库进行全量同步

Redis cluster 集群
Redis cluster将所有数据划分为16384（2的14次方）个槽位，每个redis负责其中一部分槽位。cluster集群是一种去中心化的集群方式；