redis persistent - yaokun123/php-wiki GitHub Wiki

redis持久化

一、持久化简介

Redis 的数据全部存储在内存中，如果突然宕机，数据就会全部丢失，因此必须有一套机制来保证 Redis 的数据不会因为故障而丢失，这种机制就是 Redis 的持久化机制，它会将内存中的数据库状态保存到磁盘中。

持久化发生了什么 | 从内存到磁盘

我们来稍微考虑一下 Redis 作为一个 "内存数据库" 要做的关于持久化的事情。通常来说，从客户端发起请求开始，到服务器真实地写入磁盘，需要发生如下几件事情：

详细版的文字描述大概就是下面这样：

1、客户端向数据库发送写命令(数据在客户端的内存中)
2、数据库接收到客户端的写请求(数据在服务器的内存中)
3、数据库调用系统 API 将数据写入磁盘 (数据在内核缓冲区中)
4、操作系统将写缓冲区传输到磁盘控控制器(数据在磁盘缓存中)
5、操作系统的磁盘控制器将数据写入实际的物理媒介中 (数据在磁盘中)

注意: 上面的过程其实是极度精简的，在实际的操作系统中，缓存和缓冲区会比这多得多...

如何尽可能保证持久化的安全

如果我们故障仅仅涉及到软件层面 (该进程被管理员终止或程序崩溃) 并且没有接触到内核，那么在上述步骤 3 成功返回之后，我们就认为成功了。即使进程崩溃，操作系统仍然会帮助我们把数据正确地写入磁盘。

如果我们考虑停电/ 火灾等更具灾难性的事情，那么只有在完成了第 5 步之后，才是安全的。

所以我们可以总结得出数据安全最重要的阶段是：步骤三、四、五，即：

数据库软件调用写操作将用户空间的缓冲区转移到内核缓冲区的频率是多少？
内核多久从缓冲区取数据刷新到磁盘控制器？
磁盘控制器多久把数据写入物理媒介一次？

注意：如果真的发生灾难性的事件，任何一步都可能被意外打断丢失，所以只能尽可能地保证数据的安全，这对于所有数据库来说都是一样的。

我们从第三步开始。Linux 系统提供了清晰、易用的用于操作文件的 POSIX file API，20 多年过去，仍然还有很多人对于这一套 API 的设计津津乐道，我想其中一个原因就是因为你光从 API 的命名就能够很清晰地知道这一套 API 的用途：

int open(const char *path, int oflag, .../*,mode_t mode */);
int close (int filedes);int remove( const char *fname );
ssize_t write(int fildes, const void *buf, size_t nbyte);
ssize_t read(int fildes, void *buf, size_t nbyte);

所以，我们有很好的可用的 API 来完成第三步，但是对于成功返回之前，我们对系统调用花费的时间没有太多的控制权。

然后我们来说说第四步。我们知道，除了早期对电脑特别了解那帮人 (操作系统就这帮人搞的)，实际的物理硬件都不是我们能够直接操作的，都是通过操作系统调用来达到目的的。为了防止过慢的 I/O 操作拖慢整个系统的运行，操作系统层面做了很多的努力，譬如说上述第四步提到的写缓冲区，并不是所有的写操作都会被立即写入磁盘，而是要先经过一个缓冲区，默认情况下，Linux 将在 30 秒后实际提交写入。

但是很明显，30 秒并不是 Redis 能够承受的，这意味着，如果发生故障，那么最近 30 秒内写入的所有数据都可能会丢失。幸好 PROSIX API 提供了另一个解决方案：fsync，该命令会强制内核将缓冲区写入磁盘，但这是一个非常消耗性能的操作，每次调用都会阻塞等待直到设备报告 IO 完成，所以一般在生产环境的服务器中，Redis 通常是每隔 1s 左右执行一次 fsync 操作。

到目前为止，我们了解到了如何控制第三步和第四步，但是对于第五步，我们完全无法控制。也许一些内核实现将试图告诉驱动实际提交物理介质上的数据，或者控制器可能会为了提高速度而重新排序写操作，不会尽快将数据真正写到磁盘上，而是会等待几个多毫秒。这完全是我们无法控制的。

二、Redis 中的两种持久化方式

2.1 方式一：快照rdb

Redis 快照是最简单的 Redis 持久性模式。当满足特定条件时，它将生成数据集的时间点快照，例如，如果先前的快照是在2分钟前创建的，并且现在已经至少有 100 次新写入，则将创建一个新的快照。此条件可以由用户配置 Redis 实例来控制，也可以在运行时修改而无需重新启动服务器。快照作为包含整个数据集的单个 .rdb 文件生成。

1、手动save(同步)
手动向redis客户端发送save命令。redis会同步dump rdb文件，此过程会阻塞其他命令。
缺点：由于是同步的命令，所以当数据量比较大的时候会造成阻塞。
文件策略：如果存在老的rdb文件，新的替换老的。
复杂度：o(n)
>redis save

2、手动bgsave(异步)
手动向redis客户端发送bgsave命令。redis会异步dump rdb文件，此过程不会阻塞其他命令。
redis主进程会fork()一个子进程用来执行dump操作，主进程依然可以处理其他客户端的请求。
当rdb文件生成成功之后，子进程会告诉主进程。
缺点：fork会消耗额外的内存。
文件策略：如果存在老的rdb文件，新的替换老的。
复杂度：o(n)
>redis bgsave

3、rdb自动的工作原理
（1）每隔N分钟或N次写入之后
（2）从内存dump数据形成rdb文件
（3）压缩
（4）放在备份目录
注：N分钟或N次／压缩／目录 部分可以通过参数来配置

4、rdb快照相关参数
save 900 1 #刷新快照到硬盘中，必须满足两者要求才会触发，即900秒之后至少一个关键字发生变化
save 300 10 #必须是300秒之后至少10个关键字发生变化
save 60 10000 #必须是60秒之后至少有10000个关键字发生变化

stop-writes-on-bgsave-error yes #后台存储错误,客户端停止写
rdbcompression yes #使用LZF压缩rdb文件
rdbchecksum yes #存储和加载rdb文件时校验
dbfilename dump.rdb #设置rdb文件名(dump-${port}.rdb)
dir ./ #设置工作目录，rdb文件会写入该目录(bigdiskpath)

5、在我们没有执行save、bgsave也没有配置自动dump的策略，那么为什么依然会生成rdb文件呢？ 这时候可以考虑一下几点：
（1）、全量复制（比如在主从模式下的复制）
（2）、debug reload
（3）、shutdown

但我们知道，Redis 是一个单线程的程序，这意味着，我们不仅仅要响应用户的请求，还需要进行内存快照。而后者要求 Redis 必须进行 IO 操作，这会严重拖累服务器的性能。

还有一个重要的问题是，我们在持久化的同时，内存数据结构还可能在变化，比如一个大型的 hash 字典正在持久化，结果一个请求过来把它删除了，可是这才刚持久化结束，咋办？

使用系统多进程 COW(Copy On Write) 机制 | fork 函数

操作系统多进程 COW(Copy On Write) 机制拯救了我们。Redis 在持久化时会调用 glibc 的函数 fork 产生一个子进程，简单理解也就是基于当前进程复制了一个进程，主进程和子进程会共享内存里面的代码块和数据段：

这里多说一点，为什么 fork 成功调用后会有两个返回值呢？因为子进程在复制时复制了父进程的堆栈段，所以两个进程都停留在了 fork 函数中 (都在同一个地方往下继续"同时"执行)，等待返回，所以一次在父进程中返回子进程的 pid，另一次在子进程中返回零，系统资源不够时返回负数。 (伪代码如下)

pid = os.fork()
if pid > 0:
  handle_client_request()  # 父进程继续处理客户端请求
if pid == 0:
  handle_snapshot_write()  # 子进程处理快照写磁盘
if pid < 0:  
  # fork error

所以快照持久化可以完全交给子进程来处理，父进程则继续处理客户端请求。子进程做数据持久化，它不会修改现有的内存数据结构，它只是对数据结构进行遍历读取，然后序列化写到磁盘中。但是父进程不一样，它必须持续服务客户端请求，然后对内存数据结构进行不间断的修改。

这个时候就会使用操作系统的 COW 机制来进行数据段页面的分离。数据段是由很多操作系统的页面组合而成，当父进程对其中一个页面的数据进行修改时，会将被共享的页面复制一份分离出来，然后对这个复制的页面进行修改。这时子进程相应的页面是没有变化的，还是进程产生时那一瞬间的数据。

子进程因为数据没有变化，它能看到的内存里的数据在进程产生的一瞬间就凝固了，再也不会改变，这也是为什么 Redis 的持久化叫「快照」的原因。接下来子进程就可以非常安心的遍历数据了进行序列化写磁盘了。

2.2、方式二：AOF

快照不是很持久。如果运行 Redis 的计算机停止运行，电源线出现故障或者您 kill -9 的实例意外发生，则写入 Redis 的最新数据将丢失。尽管这对于某些应用程序可能不是什么大问题，但有些使用案例具有充分的耐用性，在这些情况下，快照并不是可行的选择。

aof的配置:
appendfsync always #每一个命令，都立即同步到aof安全，速度慢
appendfsync everysec #折衷方案，每秒写一次
appendfsync no #写入工作交给操作系统，由操作系统判断缓冲区大小统一写到aof同步频率低，速度快

aof重写策略：
1、bgrewriteaof命令
2、aof重写配置
auto-aof-rewrite-percentage 100 #aof文件大小比起上次重写时的大小，增长率100%时重写
auto-aof-rewrite-min-size 64mb #aof文件，至少超过64M重写

appendonly yes #是否打开aof日志功能，默认是no，如果需要改为yes即可
no-appendfsync-on-rewrite yes #正在导出rdb快照的过程中，要不要停止同步aof

问题：
1、在dump rdb过程中，aof如果停止同步，会不会丢失数据？
答：不会，所有的操作换存在内存的队列里，dump rdb完成后统一操作

2、aof重写是指什么?
答：aof重写是指把内存中的数据，逆化成命令，写入到.aof日志里，以解决aof日志过大的问题

3、如果rdb文件和aof文件都存在，优先用谁来恢复数据？
答：aof

4、rdb和aof是否可以同时使用？
答：可以的，而且推荐这么使用

5、恢复时，rdb和aof哪个快？
rdb快，因为其是数据的内存映射，直接载入到内存中，而aof是命令，需要逐条执行

AOF(Append Only File - 仅追加文件) 它的工作方式非常简单：每次执行修改内存中数据集的写操作时，都会记录该操作。假设 AOF 日志记录了自 Redis 实例创建以来所有的修改性指令序列，那么就可以通过对一个空的 Redis 实例顺序执行所有的指令，也就是「重放」，来恢复 Redis 当前实例的内存数据结构的状态。

为了展示 AOF 在实际中的工作方式，我们来做一个简单的实验：

./redis-server --appendonly yes  # 设置一个新实例为 AOF 模式

然后我们执行一些写操作：

redis 127.0.0.1:6379> set key1 Hello
OK
redis 127.0.0.1:6379> append key1 " World!"
(integer) 12
redis 127.0.0.1:6379> del key1
(integer) 1
redis 127.0.0.1:6379> del non_existing_key
(integer) 0

前三个操作实际上修改了数据集，第四个操作没有修改，因为没有指定名称的键。这是 AOF 日志保存的文本：

$ cat appendonly.aof 
*2
$6
SELECT
$1
0
*3
$3
set
$4
key1
$5
Hello
*3
$6
append
$4
key1
$7
 World!
*2
$3
del
$4
key1

如您所见，最后的那一条 DEL 指令不见了，因为它没有对数据集进行任何修改。

就是这么简单。当 Redis 收到客户端修改指令后，会先进行参数校验、逻辑处理，如果没问题，就立即将该指令文本存储到 AOF 日志中，也就是说，先执行指令再将日志存盘。这一点不同于 MySQL、LevelDB、HBase 等存储引擎，如果我们先存储日志再做逻辑处理，这样就可以保证即使宕机了，我们仍然可以通过之前保存的日志恢复到之前的数据状态，但是 Redis 为什么没有这么做呢？

我甚至觉得没有什么特别的原因。仅仅是因为，由于AOF文件会比较大，为了避免写入无效指令（错误指令），必须先做指令检查？
如何检查，只能先执行了。因为语法级别检查并不能保证指令的有效性，比如删除一个不存在的key。
而MySQL这种是因为它本身就维护了所有的表的信息，所以可以语法检查后过滤掉大部分无效指令直接记录日志，然后再执行。

AOF 重写

Redis 在长期运行的过程中，AOF 的日志会越变越长。如果实例宕机重启，重放整个 AOF 日志会非常耗时，导致长时间 Redis 无法对外提供服务。所以需要对 AOF 日志 "瘦身"。

Redis 提供了 bgrewriteaof 指令用于对 AOF 日志进行瘦身。其原理就是开辟一个子进程对内存进行遍历转换成一系列 Redis 的操作指令，序列化到一个新的 AOF 日志文件中。序列化完毕后再将操作期间发生的增量 AOF 日志追加到这个新的 AOF 日志文件中，追加完毕后就立即替代旧的 AOF 日志文件了，瘦身工作就完成了。

fsync

就像我们上方第四步描述的那样，我们需要借助 glibc 提供的 fsync(int fd) 函数来讲指定的文件内容强制从内核缓存刷到磁盘。但 "强制开车" 仍然是一个很消耗资源的一个过程，需要 "节制"！通常来说，生产环境的服务器，Redis 每隔 1s 左右执行一次 fsync 操作就可以了。

Redis 同样也提供了另外两种策略，一个是永不 fsync，来让操作系统来决定合适同步磁盘，很不安全，另一个是来一个指令就 fsync 一次，非常慢。但是在生产环境基本不会使用，了解一下即可。

2.3、Redis 4.0 混合持久化

重启 Redis 时，我们很少使用 rdb 来恢复内存状态，因为会丢失大量数据。我们通常使用 AOF 日志重放，但是重放 AOF 日志性能相对 rdb 来说要慢很多，这样在 Redis 实例很大的情况下，启动需要花费很长的时间。

Redis 4.0 为了解决这个问题，带来了一个新的持久化选项——混合持久化。将 rdb 文件的内容和增量的 AOF 日志文件存在一起。这里的 AOF 日志不再是全量的日志，而是自持久化开始到持久化结束的这段时间发生的增量 AOF 日志，通常这部分 AOF 日志很小：

于是在 Redis 重启的时候，可以先加载 rdb 的内容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，重启效率因此大幅得到提升。