redis持久化

Redis由于支持非常丰富的内存数据结构类型，如何把这些复杂的内存组织方式持久化到磁盘上是一个难题，所以Redis的持久化方式与传统数据库的方式有比较多的差别。
Redis主要支持下面两种持久化方式，分别是：

定时快照方式(RDB)
基于语句追加文件的方式(AOF)

Redis还可以同时使用AOF持久化和RDB持久化。 在这种情况下， 当Redis重启时， 它会优先使用AOF文件来还原数据集， 因为AOF文件保存的数据集通常比RDB文件所保存的数据集更完整。

定时快照方式(snapshot，RDB快照)

该持久化方式实际是在Redis内部一个定时器事件，每隔固定时间去检查当前数据发生的改变次数与时间是否满足配置的持久化触发的条件，如果满足则 通过操作系统fork调用来创建出一个子进程，这个子进程默认会与父进程共享相同的地址空间，这时就可以通过子进程来遍历整个内存来进行存储操作，而主进程则仍然可以提供服务，当有写入时由操作系统按照内存页(page)为单位来进行copy-on-write保证父子进程之间不会互相影响。

该持久化的主要缺点是定时快照只是代表一段时间内的内存映像，所以系统重启会丢失上次快照与重启之间所有的数据。

在默认情况下，Redis将数据库快照保存在名字为dump.rdb的二进制文件中。
可以在.conf文件中修改

#   save ""
save 60 1000

# The filename where to dump the DB
dbfilename "dump.rdb"

你也可以通过调用SAVE或者BGSAVE ， 手动让Redis进行数据集保存操作。

redis> SAVE
OK

redis> BGSAVE
Background saving started

Redis恢复数据

只要覆盖一下dump.rdb，再重启下redis就可以了。

基于语句追加方式(AOF)

aof方式实际类似mysql的基于语句的binlog方式，即每条会使Redis内存数据发生改变的命令都会追加到一个log文件中，也就是说这个log文件就是Redis的持久化数据。

aof的方式的主要缺点是追加log文件可能导致体积过大，当系统重启恢复数据时如果是aof的方式则加载数据会非常慢，几十G的数据可能需要几小 时才能加载完，当然这个耗时并不是因为磁盘文件读取速度慢，而是由于读取的所有命令都要在内存中执行一遍。另外由于每条命令都要写log,所以使用aof的方式，Redis的读写性能也会有所下降。

AOF重写和RDB创建快照一样，都巧妙地利用了写时复制机制。 打开只需要写入conf文件

appendonly yes

RDB 和 AOF，应该用哪一个

一般来说， 如果想达到足以媲美PostgreSQL的数据安全性， 你应该同时使用两种持久化功能。

如果你非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失， 那么你可以只使用RDB持久化。

有很多用户都只使用AOF持久化， 但我们并不推荐这种方式： 因为定时生成RDB 快照（snapshot）非常便于进行数据库备份， 并且RDB恢复数据集的速度也要比AOF恢复的速度要快， 除此之外， 使用RDB还可以避免之前提到的AOF程序的bug。

实验阶段

虚拟内存方式

虚拟内存方式是Redis来进行用户空间的数据换入换出的一个策略，此种方式在实现的效果上比较差，主要问题是代码复杂，重启慢，复制慢等等，目前已经被作者放弃。

diskstore方式：

diskstore方式是作者放弃了虚拟内存方式后选择的一种新的实现方式，也就是传统的B-tree的方式，目前仍在实验阶段，后续是否可用我们可以拭目以待。

---

Qué bonito es ver la lluvia y no mojarse.