Redis高可用的原因 (一) -- 数据持久化

1. 什么是高可用

高可用 , 就是通过采取各种策略 , 尽量减少不能提供服务的时间 .

2. 如果保持Redis的高可用

Redis的高可用有四个方面的原因 :

1.1 数据持久化

在Redis中 , 使用多种方式进行数据持久化 , 其中包括了 RDB和AOF 两种方式 . 通过将Redis中数据或者命令保存在磁盘中 , 当发生服务器宕机需要重启时 , 可以从磁盘中读取数据重新加载 .

2.2 主从复制

Redis支持主从模式 . 在Redis集群中 , 选择一个节点作为master主节点 , 其余节点为slave节点 . 客户端只能对master节点进行写操作 , 对slave节点进行读操作 , 从而实现了读写分离 . 这个主从模式不仅实现了读写分离 , 提高了效率 , 更可以实现数据冗余 , 保证了高可用

2.3 哨兵机制

sentinel (哨兵) 机制的作用就是监控 , 故障恢复 , 以及通知 . sentinel通过心跳机制监控master主节点的存活状态 , 当master节点发生故障宕机时 , sentinel就会从slave节点中选择一个新节点作为新的master节点 , 然后通知其他节点 . 当故障节点重启后 , 也会以新节点作为主节点

2.4 Cluster集群

Redis Cluster是一种分布式系统 , 将数据分布在多个节点上 , 每个节点持有部分数据 , 并且可以容忍部分节点的故障 , 当节点发生故障时 , 集群自动重新分配数据 . 确保服务的可用性和扩展性 .

3. 数据持久化

Redis数据持久化的方式最常见的有RDB 和 AOF

3.1 RDB

RDB : Redis database backup (Redis数据库备份) , 又称Redis数据快照 . 该策略是将Redis中的全部数据写到一个RDB文件中然后保存到磁盘上 , 当重启Redis后 , 就会从磁盘中读取RDB文件 , 从而实现了数据持久化

3.2 触发RDB的时机

1. 执行save命令 : 该命令是主进程执行的 , 因此在执行该命令时 , 会阻塞其他命令 , 一般不使用
2. 执行bgsave命令 : 执行该命令时 , 主进程会fork一个子进程 , 由子进程完成数据记录
3. Redis停机 : 当Redis停机时 , 会自动执行save命令 , 将Redis的数据保存到磁盘上
4. 满足一定条件时 , Redis会自动执行bgsave命令 , 将Redis的数据保存到磁盘上 (通过配置文件配置)

3.3 配置文件修改RDB配置

• save “” 禁用RDB
• save 900 1 在900秒内 , 有一个key被修改 , 则执行bgsave (触发时机4)
• rdbcompression yes 是否压缩rdb文件
• dbfilename filename.rdb 手动修改RDB文件名
• dir ./ 配置在当前目录下读取RDB文件

3.4 bgsave命令的执行过程

1. 当执行bgsave命令时 , 主进程会fork( 创建 )一个子进程 (该步骤是主进程执行的 , 因此会阻塞其他命令)
2. 创建出子进程后 , 子进程会将Redis中的数据记录到新的RDB文件中
3. 记录结束之后 , 就用新的RDB文件替代旧的RDB文件.

3.5 当fork子进程后 , 如果主进程执行了写命令怎么办 ?

当子进程在记录数据时 , 如果主进程执行了写命令 , 那么可能会造成脏数据问题 , 因此 , Redis使用了写时复制(Copy - on - write) 机制解决了该问题 .
写时复制 : 当主进程写数据时 , 会复制要修改的数据 , 修改副本 , 而不直接修改共享数据 , 当修改完毕之后 , 才会将新数据赋值给共享数据

• 主进程执行读操作 , 访问共享内存 (read-only)
• 主进程执行写操作 , 访问数据副本
  

3.6 RDB的缺点

• RDB执行时间间隔较长 , 两次RDB之间写入数据有丢失风险
• fork子进程 , 压缩 , 写出RDB文件都比较耗时

4.1 AOF

AOF append only file (仅追加文件) , 写时追加 , 当Redis执行写操作时 , 就会将命令追加到aof文件中 , 因此aof文件又叫日志命令文件

4.2 AOF的开启

在Redis中 , 默认使用的是RDB数据持久化 , 因此AOF是默认关闭的 , 要开启AOF , 可以通过修改Redis.conf配置文件

4.3 AOF命令记录的频率

aof命令记录的频率可以通过修改redis.conf文件来配置

1. always : 每执行一条写命令就立即记录到aof文件中
   该策略的可靠性高 , 几乎不丢数据 , 但是对性能的影响大
2. everyseec : 写命令执行完后放入aof缓冲区 , 然后每隔1秒就将缓冲区的数据写道aof文件中 , 默认使用该策略
   性能适中 , 最多丢失1秒钟的数据
3. no 写命令执行完后放入aof缓冲区 , 由操作系统决定什么时候将数据写入aof文件中
   性能最好 , 但是可靠性比较差 , 可能丢失大量数据

4.4 AOF的bgrewriteaof

由于AOF 记录每一条写命令 , 因此AOF文件的大小比RDB文件大 , 而且如果对同一个key的多次修改 , RDB只会记录最后的key和值 , 但是AOF会记录所有修改的命令 , 但是实际上只有最后一次的修改是有效的 , 因此可以通过执行bgrewriteaof命令 , 重写AOF文件 , 会将多余的修改命令合并 , 保留有效的命令
例如 :
set key 1 set key 2 set key 3 , 执行完bgrewriteaof命令后 , 只会保存set key 3 .

bgrewriteaof命令的触发时机 : 当文件的大小超过设置的阈值时会触发bgrewriteaof命令 , 阈值可以在配置文件中配置