简介 redis 持久化 RDB

http://redis.io/topics/persistence
http://www.cnblogs.com/daoluanxiaozi/p/3625285.html

redis支持四种持久化方式，一是 Snapshotting（快照）也是默认方式；二是Append-only file（缩写aof）的方式；三是虚拟内存方式；四是diskstore方式。redis 提供两种持久化方式：RDB 和 AOF。redis 允许两者结合，也允许两者同时关闭。

• RDB 可以定时备份内存中的数据集。服务器启动的时候，可以从 RDB 文件中回复数据集。
• AOF 可以记录服务器的所有写操作。在服务器重新启动的时候，会把所有的写操作重新执行一遍，从而实现数据备份。当写操作集过大（比原有的数据集还大），redis 会重写写操作集。

快照保存过程：

1. redis调用fork,现在有了子进程和父进程。
2. 父进程继续处理client请求，子进程负责将内存内容写入到临时文件。由于os的写时复制机制（copy on write)父子进程会共享相同的物理页面，当父进程处理写请求时os会为父进程要修改的页面创建副本，而不是写共享的页面。所以子进程的地址空间内的数据是fork时刻整个数据库的一个快照。
3. 当子进程将快照写入临时文件完毕后，用临时文件替换原来的快照文件，然后子进程退出（fork一个进程入内在也被复制了，即内存会是原来的两倍）。

client 也可以使用save或者bgsave命令通知redis做一次快照持久化。save操作是在主线程中保存快照的，由于redis是用一个主线程来处理所有 client的请求，这种方式会阻塞所有client请求。所以不推荐使用。另一点需要注意的是，每次快照持久化都是将内存数据完整写入到磁盘一次，并不是增量的只同步脏数据。如果数据量大的话，而且写操作比较多，必然会引起大量的磁盘io操作，可能会严重影响性能。

redis 支持两种方式进行 RDB：当前进程执行和后台执行（BGSAVE）。RDB BGSAVE 策略是 fork 出一个子进程，把内存中的数据集整个 dump 到硬盘上。两个场景举例：

1. redis 服务器初始化过程中，设定了定时事件，每隔一段时间就会触发持久化操作；进入定时事件处理程序中，就会 fork 产生子进程执行持久化操作。
2. redis 服务器预设了 save 指令，客户端可要求服务器进程中断服务，执行持久化操作。

如果采用 BGSAVE 策略，且内存中的数据集很大，fork() 会因为要为子进程产生一份虚拟空间表而花费较长的时间；如果此时客户端请求数量非常大的话，会导致较多的写时拷贝操作；在 RDB 持久化操作过程中，每一个数据都会导致 write() 系统调用，CPU 资源很紧张。因此，如果在一台物理机上部署多个 redis，应该避免同时持久化操作。那如何知道 BGSAVE 占用了多少内存？子进程在结束之前，读取了自身私有脏数据 Private_Dirty 的大小，这样做是为了让用户看到 redis 的持久化进程所占用了有多少的空间。在父进程 fork 产生子进程过后，父子进程虽然有不同的虚拟空间，但物理空间上是共存的，直至父进程或者子进程修改内存数据为止，所以脏数据 Private_Dirty 可以近似的认为是子进程，即持久化进程占用的空间。

RDB 的文件组织方式为：数据集序号1：操作码：数据1：结束码：校验和----数据集序号2：操作码：数据2：结束码：校验和......
其中，数据的组织方式为：过期时间：数据类型：键：值，即 TVL（type，length，value)。RDB 持久化的结果是一个非常紧凑的文件，几乎每一位都是有用的信息。