关于redis:Redis持久化基础篇系列三

Redis 的数据机构、CAP+BASE 实践咱们在后面曾经理解过了，当初咱们来理解下 Redis 的长久化和事务。

前言

在理论数据库选型过程中，为了灾备，可长久化根本是数据库的必要选项；Redis 尽管是基于内存的，然而为了防止过程异常中断后数据的失落，也提供了两种长久化计划，将内存中的数据写入磁盘，尽量减少数据的失落。

Redis 的长久化

Redis 提供了两种长久化形式：RDB 和 AOF。

RDB 长久化形式：可能在指定的工夫距离能对 Redis 的数据进行快照存储，造成一个 dump.rdb 文件；是 Redis 默认 采纳的长久化形式。
AOF 长久化形式：记录每次对服务器写的操作，当服务器重启的时候会从新执行这些命令来复原原始的数据。

如果你只心愿你的数据在服务器运行的时候存在, 你也能够不应用任何长久化形式。
你也能够 同时开启两种长久化 形式，在这种状况下，当 Redis 重启的时候会 优先载入 AOF 文件来复原原始的数据，因为在通常状况下AOF 文件保留的数据集要比 RDB 文件保留的数据集要残缺。

RDB(Redis DataBase)

RDB 长久化形式：可能在指定的工夫距离能对 Redis 的数据进行快照存储，造成一个 dump.rdb 文件。

RDB 快照的实现过程：
（1）Redis 会独自创立 (fork) 一个子过程来进行长久化，会先将以后内存中的数据写入到磁盘的一个临时文件中。
（2）主过程是不进行任何 IO 操作，会持续接管并解决客户端发来的命令。
（3）当子过程写入完所有数据后会用该临时文件替换旧的 RDB 文件，这样，一次 RDB 快照操作就实现了。

整个过程中，主过程是不进行任何 IO 操作的，这就确保了极高的性能。如果须要进行大规模数据的复原，且对于数据恢复的完整性不是十分敏感，那 RDB 形式要比 AOF 形式更加的高效。的毛病是

redis.conf 的配置文件中，对于 SNAPSHOTTING 模块的全是 RDB 的相干配置。官网给出的配置文件中有这几种：
save 900 1：若 900S(15min)内数据库改变了一次，则触发快照条件。
save 300 10：若 300S(5min)内数据库改变了十次，则触发快照条件。
save 60 10000：若 60S(1min)内数据库改变了一万次，则触发快照条件。
若不想应用长久化形式，能够配置成save ""。

总的来说，有以下四种触发快照条件 ：
（1）达到配置文件中定义的规定
（2）手动执行save 或bgsave命令
（3）执行flushall 命令
（4）执行主从复制操作的时候

save：执行 save 命令时 Redis 只管保留，其余不论，Redis 进入阻塞状态。
bgsave：Redis 会在后盾异步进行快照操作，快照的同时还能够响应客户端申请。能够通过 lastsave 命令获取最初一次胜利执行快照的工夫。
执行 flushall 命令，也会产生 dump.rdb 文件，但外面是空的，毫无意义。

注意事项：

• Redis 在进行快照的过程中 不会批改 原 RDB 文件，只有快照完结后才会将旧的文件 替换 成新的，也就是说任何时候 RDB 文件都是残缺的。
• 这就使得咱们能够通过定时备份 RDB 文件来实现 Redis 数据库的备份，RDB 文件是通过压缩的二进制文件，占用的空间会小于内存中的数据，更加利于传输。

RDB 长久化形式复原数据：
将 RDB 产生的备份文件 (dump.rdb) 挪动到 Redis 装置目录并启动 Redis 服务即可。

RDB 的长处：
（1）RDB 是一个十分紧凑的文件，它保留了某个工夫点得数据集，十分实用于数据集的备份。
（2）RDB 是一个紧凑的繁多文件，很不便传送到另一个远端数据中心（可能加密），十分实用于劫难复原。
（3）RDB 在保留 RDB 文件时父过程惟一须要做的就是 fork 出一个子过程，接下来的工作全副由子过程来做，父过程不须要再做其余 IO 操作，所以 RDB 长久化形式能够最大化 redis 的性能。
（4）与 AOF 相比，在复原大的数据集的时候，RDB 形式会更快一些。

RDB 的毛病：

（1）RDB 最初一次长久化后的数据可能失落。
（2）如果你心愿在 Redis 意外进行工作（例如电源中断）的状况下失落的数据起码的话，那么 RDB 不适宜你。
（3）RDB 须要常常 fork 子过程来保留数据集到硬盘上，当数据集比拟大的时候，fork 的过程是十分耗时的，可能会导致 Redis 在一些毫秒级内不能响应客户端的申请。如果数据集微小并且 CPU 性能不是很好的状况下，这种状况会继续 1 秒，AOF 也须要 fork，然而你能够调节重写日志文件的频率来进步数据集的耐久度。

AOF(Appendonly File)

AOF 长久化形式 用日志的模式记录每次对服务器写的操作，当服务重启的时候会从新执行这些命令来复原原始的数据，AOF 的命令以 Redis 协定追加保留每次写的操作到文件开端。Redis 还能对 AOF 文件进行后盾重写，使得 AOF 文件的体积不至于过大。

redis.conf 的配置文件中，对于 APPEND ONLY MODE 模块的全是 AOF 的相干配置。官网给出的配置文件中 默认是不开启 的：
appendonly no：想要开启 AOF 长久化形式，批改成 yes 即可。

appendfsync always：同步长久化，每次产生数据变更会立刻记录到磁盘，性能较差但数据完整性比拟好。
appendfsync everysec：默认配置，异步操作，每秒记录数据变更；如果产生宕机最多失落一秒的数据。
appendfsync no：从不被动同步。

AOF 长久化形式复原数据：
AOF 会产生文件(appendonly.aof)，Redis 启动时会从新执行这些命令来复原原始的数据。

AOF 重写

因为 AOF 的运作形式是一直地将命令追加到文件的开端，所以随着写入命令的一直减少，AOF 文件的体积也会变得越来越大。
举个例子，如果你对一个计数器调用了 100 次 INCR key，那么仅仅是为了保留这个计数器的以后值，AOF 文件就须要应用 100 条记录（entry）。
然而在实际上，只应用一条 SET key value [EX seconds] [PX milliseconds] [NX|XX]命令曾经足以保留计数器的以后值了，其余 99 条记录实际上都是多余的。

所以 Redis 反对这样一个性能：在不中断服务的状况下在后盾重建 AOF 文件。那么在什么状况下会重写 AOF 文件呢：

# Redis 会记住自从上一次重写后 AOF 文件的大小（如果自 Redis 启动后还没重写过，则记住启动时应用的 AOF 文件的大小）。# 如果以后的文件大小比起记住的那个大小超过指定的百分比，则会触发重写。# 同时须要设置一个文件大小最小值，只有大于这个值文件才会重写，以防文件很小，然而曾经达到百分比的状况。auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

AOF 文件重写的过程：

（1）Redis 执行 fork()，创立一个子过程，当初同时领有父过程和子过程。
（2）子过程开始将新 AOF 文件的内容写入到临时文件。
（3）对于所有新执行的写入命令，父过程一边将它们累积到一个内存缓存中，一边将这些改变追加到现有 AOF 文件的开端：这样即便在重写的中途产生停机，现有的 AOF 文件也还是平安的。
（4）当子过程实现重写工作时，它给父过程发送一个信号，父过程在接管到信号之后，将内存缓存中的所有数据追加到新 AOF 文件的开端。
（5）当初 Redis 原子地用新文件替换旧文件，之后所有命令都会间接追加到新 AOF 文件的开端。

AOF 重写总结:

（1）Redis 能够在 AOF 文件体积变得过大时，主动地在后盾对 AOF 进行重写 ， 重写后的新 AOF 文件蕴含了复原以后数据集所需的 最小命令汇合。
（2）整个重写操作是相对平安的，因为 Redis 在创立新 AOF 文件的过程中，会持续将命令追加到现有的 AOF 文件外面，即便重写过程中产生停机，现有的 AOF 文件也不会失落。而一旦新 AOF 文件创建结束，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。
（3）AOF 文件有序地保留了对数据库执行的所有写入操作，这些写入操作以 Redis 协定的格局保留，因而 AOF 文件的内容非常容易被人读懂，对文件进行剖析（parse）也很轻松。

两种长久化形式的比照（取自官网）

（1）一般来说，如果想达到足以媲美 PostgreSQL 的数据安全性，你应该同时应用两种长久化性能。
（2）如果你十分关怀你的数据，但依然能够接受数分钟以内的数据失落，那么你能够只应用 RDB 长久化。
（3）有很多用户都只应用 AOF 长久化，但咱们并不举荐这种形式：因为定时生成 RDB 快照（snapshot）十分便于进行数据库备份，并且 RDB 复原数据集的速度也要比 AOF 复原的速度要快，除此之外，应用 RDB 还能够防止 AOF 引擎的 bug。

Redis 事务

Redis 的事务能够一次执行多个命令，实质是一组命令的汇合。一个事务中的所有命令都会序列化，按程序地串行化执行而不会被其余命令插入，不许加塞。

以下摘自官网的解释：
（1）事务是一个独自的隔离操作：事务中的所有命令都会序列化、按程序地执行。事务在执行的过程中，不会被其余客户端发送来的命令申请所打断。
（2）事务是一个原子操作：事务中的命令要么全副被执行，要么全副都不执行。(留神，这里只是说执行的这个动作，即便事务中有某条 / 某些命令执行时失败了，事务队列中的其余命令依然会继续执行 —— Redis 不会进行执行事务中的命令。)

事务的开启：
MULTI：输出该命令开启事务。

命令的入队：
将多个命令入队到事务中，接到这些命令并不会立刻执行，而是放到期待执行的事务队列外面

事务的执行：
EXEC：执行所有事务块内的命令。按程序执行事务队列外面的命令，并返回执行后果。

对于事务的常见命令：
DISCARD：勾销事务，放弃执行事务块内的所有命令。
EXEC：执行所有事务块内的命令。
MULTI：标记一个事务块的开始。
UNWATCH：勾销 WATCH 命令对所有 key 的监督。
WATCH key [key ...]：监督一个(或多个) key，如果在事务执行之前这个(或这些) key 被其余命令所改变，那么事务将被打断。

通常事务要配合 watch 和 unwatch 命令应用。这里的事务都是基于单机模式下的事务阐明，对于集群的话事务的后果和操作有所不同。