Redis持久化
什么是持久化
将数据从掉电易失的内存存放到能够永久存储的设备上
Redis为什么需要持久化

• 基于内存的
• 缓存数据库
• 内存数据库
• 消息队列
  Redis持久化方式
• RDB(Redis DB) 产生dump.rdb文件 类似于 hdfs：fsimage（产生镜像快照）
  在默认情况下，Redis将数据库快照保存在名字为dump.rdb的二进制文件中
• AOF(AppendOnlyFile) 类似于 hdfs : edit logs日志命令文件
  恢复把命令再执行一遍。默认是关闭的。默认RDB形式。

Redis持久化-RDB
方式：产生一个RDB
-1.阻塞方式
客户端执行save命令。好处是对数据完整性有一个保护。可以保持前后数据一致。但是体验不好

• 2.非阻塞方式（复杂度高：主要在于数据不完整）
  bgsave
  bgsave是一个异步命令

  
  图片1.png
  图片2.png
  

  新的rdb文件会覆盖旧的rdb文件
  策略

• 自动：按照配置文件中的条件满足就执行BGSAVE
  save 60 1000，Redis要满足在60秒内至少有1000个键被改动，会自动保存一次
  本质上就是bgsave
• 手动
  客户端发起SAVE,BGSAVE命令
  RDB优缺点
  优点
  完全备份，不同时间的数据集备份可以做到多版本恢复（会覆盖 手动写脚本扫描目录拿走不同阶段备份，异地备份）
  紧凑的单一文件，方便网络传输，适合灾难恢复
  恢复大数据集速度较AOF快
  缺点
  会丢失最近写入、修改的而未能持久化的数据
  fork过程非常耗时，会造成毫秒级不能响应客户端请求

AOF写入机制

• AOF方式不能保证绝对不丢失数据。默认关闭，一旦开启，则rdb不作为恢复的选择。
• 目前常见的操作系统中，执行系统调用write函数，将一些内容写入到某个文件里面时，为了提高效率，系统通常不会直接将内容写入硬盘里面，而是先将内容放入一个内存缓冲区（buffer）里面，等到缓冲区被填满，或者用户执行fsync调用和fdatasync调用时才将储存在缓冲区里的内容真正的写入到硬盘里，未写入磁盘之前，数据可能会丢失

写入磁盘的策略
appendfsync选项，这个选项的值可以是always、everysec或者no
Always：服务器每写入一个命令，就调用一次fdatasync，将缓冲区里面的命令写入到硬盘。这种模式下，服务器出现故障，也不会丢失任何已经成功执行的命令数据
Everysec（默认）：服务器每一秒重调用一次fdatasync，将缓冲区里面的命令写入到硬盘。这种模式下，服务器出现故障，最多只丢失一秒钟内的执行的命令数据
No：服务器不主动调用fdatasync，由操作系统决定何时将缓冲区里面的命令写入到硬盘。这种模式下，服务器遭遇意外停机时，丢失命令的数量是不确定的
运行速度：always的速度慢，everysec和no都很快

AOF重写机制

• AOF文件过大
• 合并重复的操作，AOF会使用尽可能少的命令来记录

重写过程
fork一个子进程负责重写AOF文件
子进程会创建一个临时文件写入AOF信息
父进程会开辟一个内存缓冲区接收新的写命令
子进程重写完成后，父进程会获得一个信号，将父进程接收到的新的写操作由子进程写入到临时文件中
新文件替代旧文件
注：如果写入操作的时候出现故障导致命令写半截，可以使用redis-check-aof工具修复

AOF重写触发的条件
手动：客户端向服务器发送BGREWRITEAOF命令

自动：配置文件中的选项，自动执行BGREWRITEAOF命令

• auto-aof-rewrite-min-size <size>，触发AOF重写所需的最小体积：只要在AOF文件的体积大于等于size时，才会考虑是否需要进行AOF重写，这个选项用于避免对体积过小的AOF文件进行重写
• auto-aof-rewrite-percentage <percent>，指定触发重写所需的AOF文件体积百分比：当AOF文件的体积大于auto-aof-rewrite-min-size指定的体积，并且超过上一次重写之后的AOF文件体积的percent %时，就会触发AOF重写。（如果服务器刚刚启动不久，还没有进行过AOF重写，那么使用服务器启动时载入的AOF文件的体积来作为基准值）。将这个值设置为0表示关闭自动AOF重写

优点

• 写入机制，默认fysnc每秒执行，性能很好不阻塞服务，最多丢失一秒的数据
• 重写机制，优化AOF文件
• 如果误操作了（FLUSHALL等），只要AOF未被重写，停止服务移除AOF文件尾部FLUSHALL命令，重启Redis，可以将数据集恢复到 FLUSHALL 执行之前的状态
  缺点
• 相同数据集，AOF文件体积较RDB大了很多
• 恢复数据库速度叫RDB慢（文本，命令重演）

Redis集群存储（承载）数据的方式
Redis集群 一变多
单机/单点: 单机
单点故障/瓶颈：多个节点负载：面向数据：

• 一变多（一致性<弱一致，最终一致性>）》可用性-
• 最终一致性：一部分角色确认 》 网络分区（脑裂）》过半机制

了解无主模型

镜像：数据容量不变
切片（shard切片）：横向扩展
Cap原则
CAP原则又称CAP定理，指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。

出现了以上的问题，所以集群产生了

集群分类

• 主从复制 Replication：镜像：增删改（主<退化到单节点>）查询负载到从节点
  高可用 Sentinel
• 分布式 twemproxy：切片
  集群 Cluster

Redis主从复制 Replication

• 一个Redis服务可以有多个该服务的复制品，这个Redis服务称为Master，其他复制品称为Slaves
• 只要网络连接正常，Master会一直将自己的数据更新同步给Slaves，保持主从同步
• 只有Master可以执行写命令，Slaves只能执行读命令
• 从服务器执行客户端发送的读命令，比如GET、LRANGE、SMEMMBERS、HGET、ZRANGE等等
• 客户端可以连接Slaves执行读请求，来降低Master的读压力。
• 相对于无主模型，更加简单. 主单点返回确认即可。Redis采用异步主从同步数据，有瑕疵。另外主单点，使用哨兵解决单点故障。

Redis的哨兵机制
主从复制问题

• 一个Master可以有多个Slaves
• Slave下线，只是读请求的处理性能下降
• Master下线，写请求无法执行
• 其中一台Slave使用SLAVEOF no one命令成为Master，其它Slaves执行SLAVEOF命令指向这个新的Master，从它这里同步数据

以上过程是手动的，能够实现自动，这就需要Sentinel哨兵，实现故障转移Failover操作

主从复制创建�
每个redis实例默认自己是主，需要手动变更

• redis-server --slaveof <master-ip> <master-port>，配置当前服务称为某Redis服务的Slave

redis-server --port 6380 --slaveof 127.0.0.1 6379

• SLAVEOF host port命令，将当前服务器状态从Master修改为别的服务器的Slave
  redis > SLAVEOF 192.168.1.1 6379，将服务器转换为Slave
  redis > SLAVEOF NO ONE ，将服务器重新恢复到Master，不会丢弃已同步数据
• 配置方式：启动时，服务器读取配置文件，并自动成为指定服务器的从服务器
  slaveof <masterip> <masterport>
  slaveof 127.0.0.1 6379
  监控 Monitoring
• Sentinel（哨兵）会不断检查Master和Slaves是否正常
• 每一个Sentinel可以监控任意多个Master和该Master下的Slaves
• 监控同一个Master的Sentinel会自动连接，组成一个分布式的Sentinel网络，互相通信并交换彼此关于被监视服务器的信息

注:哨兵是无主模型。但是哨兵会有一个投票机制，多票决定把服务器替换下去。