Redis持久化

Redis持久化

RDB持久化

​ Redis 可以通过创建快照(RDB)来获得存储在内存里面的数据在 某个时间点 上的副本,它是经过压缩的二进制文件，用于主从数据传递和数据备份。

​ Redis有两种方式创建RDB快照：

​ save：主线程进行

​ bgsave：主线程fork一个子进程创建快照，不会阻塞主线程执行其他命令，但是创建快照的过程会对cpu造成较大压力。

​ 触发的条件就是当多少秒内有多少个key发生变化就会触发bgsave命令创建快照，这也为什么说是内存数据在某个时间点的副本的原因，副本的原因是因为主进程fork子进程会复制页表对内存数据进行读操作，此时共享内存就会进行read-only状态，如果此时主进程接收到了写请求，那么就会触发操作系统的异常中断，会拷贝一份修改数据的那个数据页然后重新指向它，此时子进程的共享内存的数据还是修改之前的。

​

AOF持久化

​ Redis只要在执行写操作的命令时会将该命令追加到aof文件中去。

AOF工作流程

​ 具体流程就是当Redis执行写操作的命令时，会将该命令追加(append)到aof缓冲区中，然后再将缓冲区的数据写入(write)到内核缓冲区中，此步骤还不是真正写入到磁盘中，然后根据aof的持久化策略，调用fsync函数强制将内核缓冲区的数据写入到磁盘aof文件中，只要全部写完线程才不被阻塞，这就是aof的基本流程。

aof持久化方式

​ 有三种持久化方式：

1. 只要执行wirte就会后台线程执行fsync，此持久化方式会严重降低redis性能。
2. 后台线程每隔1s执行fsync，默认开启，最多损失1s内的数据。
3. 由操作系统管理调度

aof重写机制

​ 当指定大小的aof文件写满后，redis会重写生成一个aof文件进行重写操作，重写操作会开启一个独立的线程进行，在重写操作期间，redis会维护一个aof重写缓冲区用来记录重写操作期间redis主线程执行其他的写操作指令，重写操作执行完后就会追加到新aof文件末尾。

​ 重写后的aof文件在与旧aof文件数据库保存的信息一样但是体积更小。

Redis主从同步

1. ​ 首先从节点会请求主节点数据同步操作
2. ​ 主节点判断从节点是否第一次同步，通过Replication id去判断，如果是第一次则主节点和从节点的id不相同，则会进行全量同步。
3. ​ 如果是第一次同步则将主节点的数据版本信息返回给从节点，从节点保存
4. ​ 主节点执行bgsave命令生成RDB，并且记录RDB期间的所有命令到repl_baklog中
5. ​ 主节点执行完后发送RDB文件，从节点清空本地数据加载RDB文件
6. ​ 主节点发送repl_baklog，从节点进行接收

​ 上面是全量同步的过程，全量同步需要将整个RDB文件通过网络传输给slave，网络开销较大。

​ 所以一般都是增量同步，就是将master和slave存在的数据的差异进行同步，而这个数据的差异是通过offset实现的，master节点会发送repl_baklog中offset之后的执行的命令给slave节点。但是如果出现了网络阻塞导致从节点的数据没有及时同步而被覆盖则会进行从增量同步退化到全量同步。

Redis哨兵集群

​ 主从同步的缺陷在于当主节点发生故障时需要人为复杂的干预，我们要要从slave节点中选择一个主节点，并且要修改每个从节点对应主节点的地址等等一系列繁琐的操作，所以就出现了哨兵集群来帮我们实现监控和故障转移等一系列繁琐操作。

Redis分片集群

​ 主从复制和Redis Sentinel这两种方案本质都是通过增加主库(master)的副本(slave)数量的方式来提高Rdis服务的整体可用性和读吞吐量，都不支持横向扩展来缓解写压力以及解决缓存数据量过大的问题。

​ 简单来说，Redis切片集群就是部署多台Redis主节点(master),这些节点之间平等，并没有主从之说，同时对外提供读/写服务。缓存的数据库相对均匀地分布在这些Rdis实例上，客户端的请求通过路由规则转发到目标master上。

​ 那么问题来了，如何实现路由转发到指定的master中呢？

​ 首先会根据对应的key使用crc16函数再对16384(2的14次方)进行取模运算得到对应的哈希槽，然后再根据哈希槽和节点的映射关系即可找到目标节点。

​ 哈希槽分区机制的优点在于解耦了数据和节点的关系，提升了集群的横向扩展和容错率。