Redis的持久化机制

Redis的持久化机制

第一章 Reids单线程为什么这么快？
第二章 Redis的持久化机制

---

---

前言

想必大家都知道，Redis是基于内存进行的读写操作，这也是它快的一个原因，但是正因为它是在内存中进行操作，数据的安全性得不到保障，如果服务器某天宕机了的化那我们数据将会面临丢失的风险。那么Redis是怎么解决这一问题的呢，答案就是持久化。接下来我将会给各位讲解reids的持久化的实现以及不同实现方法它们各自的优缺点。

---

一、Redis持久化的实现机制

Redis 的持久化主要是有两种一种是RDB(快照)，另一种事AOF(日志)

二、RDB

RDB 全称 Redis DataBase(快照) 它会将某一时刻的内存快照（Snapshot）,以二进制的形式写入磁盘
举个例子：
当前redis中有2个key,当前时间是下午1点40分redis使用RDB进行持久化就会把这2个key做成一份文件保存到磁盘中

RDB的手动触发

• Save命令：使用Save命令时Redis的主进程将处于阻塞状态，直到RDB持久化完成，才会响应客户端的发来的命令（生产环境中慎用）

• bgSave命令：使用bgseave命令时Redis会fork出一个子线程进行持久化，主进程只在fork过程中会短暂阻塞，fork时reids的父子进程会有一个数据共享区域，类似于Github的分支。当Reids创建完成这个分支后，主进程就可以响应客户端发来的命令了。
  (fork是操作系统提供的一种父子进程机制)

   那么此时有靓仔要问了，你创建子线程写数据怎么保证数据的准确性呢？
   答：fork子进程利用了操作系统的写实拷贝机制也称COW(copy OR write),通过写实拷贝。
   举个例子：
   下午一点四十时Redis开始了bgsave命令，下午一点四十一时来了个写入命令，
   那么Redis将会把和fork出的子进程和自己的数据共享区域copy一份,然后去修改copy文件中的数据。等子进程保存完了再把数据写回去。
   此时就保证了子进程拷贝的数据的数据全是下午一点四十之前的数据了。
  

RDB的自动触发

• save m n：在m秒内，如果有n个键发生改变，则自动触发持久化，通过bgSave执行，如果设置多个，只要满足其中一个就会触发，配置文件中默认配置了（可以注释掉）

   举个例子：
   比如我们设置了10秒内监控5个键，然后我们又设置了一个200秒内监控100个键
   此时两个命令只要满足其中一个就会触发，redis先会统计10秒内到达了5个先触发一次，200秒到达了100个又触发一次。
   如果10秒内监控的5个键中只有4个法师了改变，而200秒内监控的100个键都发生了改变此时也会触发一次
  

• flushall：用于清空Redis所有的数据库，flushdb清空当前Redis所在的库（默认是0号数据库），会清空RDB文件，同时也会生成一个空的dump.rdb文件。（慎用）

• 主从同步：全量同步时会触发bgSave命令，生成rdb文件发送给从节点

RDB的优缺点

优点

1. 整个Redis数据库只有一个dump.rdb文件，方便持久化。可以拷贝出来。
2. 容灾性好，方便备份。
3. 性能最大化，fok子进程来完成写操作，让主进程继续处理命令，所以是IO最大化。使用单独子进程来进行
   持久化，主进程不会进行任何IO操作，保证了redis的高性能。
4. 相对于数据集大时，比AOF的启动效率高。

缺点

1. 数据安全性低。RDB是间隔一段时间进行持久化，如果持久化之间redis发生故障，会发生数据丢失。所以这
   种方式更适合数据要求不严谨的时候)
2. 由于RDB是通过fok子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务
   器停止服务几百毫秒，甚至是1秒钟。会占用cpu

三、AOF

AOF 全称 Append Only File 以日志的形式记录服务器锁处理的每一个写、删命令，查询命令不会记录，以文本的形式记录，可以打开文件看到详细的操作记录，调用操作系统命令进程刷盘

AOF 的操作流程

• 所有的写命令会追加到AOF缓冲中。
• AOF缓冲区根据对应的策略向硬盘进行同步操作。
  （ 注意这里的“策略”，并不是所有的命令都会往log文件里去写，这里使用到了一个缓冲区的概念，它会将命令暂时存入内存缓冲区中，然后根据一定的策略把一些命令写入日志文件中）
• 随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的。
  （ 如何理解这里的重写达到压缩的目的。比如现在有三个List 分别存储的是A,B,C.这三条数据，当我们定期重写时就会发现其实这三条数据用一个List存储也可以。重写后就只有一个List里面分别 存储的A,B,C,此时压缩的目的就达到了）
• 当Redis里启时，可以加载AOF文件进行数居恢复。

同步策略

• 每秒同步：故名思意就是每过一秒就将AOF缓冲区的数据写入log文件中去，异步完成，效率非常高，一旦系统出现宕机现象，那么这一秒之内的修改的数据将会丢失。
• 每修改同步：也就是每写一条就同步一条，此时的同步技术是调用的系统的fsync, 同步持久化，每次发生数据变化都会被立即记录到磁盘中，系统出现宕机，最多丢失一条。
• 不同步：由系统操作自己控制，可能会丢失多数据。
  （注意这里的不同步并不是说不进行持久化，只是说我们不去干预Redis的持久化，怎么持久化由它自己决定）

AOF的优缺点

优点

1. 数据相对安全
2. 通过append模式写文件，即使中途出现服务器宕机也不会破坏已经存在的内容，可以通过reids-check-aof工具解决数据一致性问题
3. AOF机制的rewrite模式，定期队AOF文件进行重写，以达到压缩的目的

缺点

1. AOF文件比RDB文件大，且恢复速度慢。
2. 数据集大的时候，比RDB启动效率低。
3. 运行效率没有RDB高。

四、总结

AOF文件比RDB更新频率高，优先使用AOF还原数据。
AOF比RDB更安全，文件也更大
RDB性能比AOF好
如果两个都配置了优先加载AOF