Redis学习(3)—— 持久化机制
什么叫持久化？
用一句话可以将持久化概括为：将数据（如内存中的对象）保存到可永久保存的存储设备中。持久化的主要应用是将内存中的对象存储在数据库中，或者存储在磁盘文件中、 XML 数据文件中等等。
从应用层与系统层理解持久化
同时，也可以从应用层和系统层这两个层面来理解持久化：
应用层：如果关闭( Close )你的应用然后重新启动则先前的数据依然存在。
系统层：如果关闭( Shutdown )你的系统（电脑）然后重新启动则先前的数据依然存在。
Redis 为什么要持久化？
Redis 中的数据类型都支持 push/pop、add/remove 及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。在此基础上，Redis 支持各种不同方式的排序。与 Memcached 一样，为了保证效率，数据都是缓存在内存中。
对，数据都是缓存在内存中的，当你重启系统或者关闭系统后，缓存在内存中的数据都会消失殆尽，再也找不回来了。所以，为了让数据能够长期保存，就要将 Redis 放在缓存中的数据做持久化存储。
Redis 怎么实现持久化？
在设计之初，Redis 就已经考虑到了这个问题。官方提供了多种不同级别的数据持久化的方式：
1、RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储。
2、AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大。
3、如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式。
4、你也可以同时开启两种持久化方式, 在这种情况下, 当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。
RDB持久化机制优点
· 一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是非常完美的。比如，你可能打算每个小时归档一次最近24小时的数据，同时还要每天归档一次最近30天的数据。通过这样的备份策略，一旦系统出现灾难性故障，我们可以非常容易的进行恢复。
· 对于灾难恢复而言，RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上
· 性能最大化。对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork（分叉）出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。
相比于AOF机制，如果数据集很大，RDB的启动效率会更高
特点:只会将最终的数据持久化到本地。
RDB持久化机制缺点
· 如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。
· 由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟
RDB持久化机制的配置
在redis.windows.conf配置文件中有如下配置：
```confSNAPSHOTTING
Save the DB on disk:
save
Will save the DB if both the given number of seconds and the given
number of write operations against the DB occurred.
In the example below the behaviour will be to save:
after 900 sec (15 min) if at least 1 key changed
after 300 sec (5 min) if at least 10 keys changed
after 60 sec if at least 10000 keys changed
Note: you can disable saving at all commenting all the "save" lines.
It is also possible to remove all the previously configured save
points by adding a save directive with a single empty string argument
like in the following example:
save ""save 900 1 save 300 10 save 60 10000 ```
其中，上面配置的是RDB方式数据持久化时机：
| 关键字 | 时间(秒) | key修改数量 | 解释 | | ------ | -------- | ----------- | ----------------------------------------------------- | | save | 900 | 1 | 每900秒(15分钟)至少有1个key发生变化，则dump内存快照 | | save | 300 | 10 | 每300秒(5分钟)至少有10个key发生变化，则dump内存快照 | | save | 60 | 10000 | 每60秒(1分钟)至少有10000个key发生变化，则dump内存快照 |
AOF持久化机制优点
· 该机制可以带来更高的数据安全性，即数据持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。事实上，每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。可以预见，这种方式在效率上是最低的。至于无同步，无需多言，我想大家都能正确的理解它。
· 由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。
· 如果日志过大，Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。
· AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，我们也可以通过该文件完成数据的重建
AOF持久化机制缺点
· 对于相同数量的数据集而言，AOF文件通常要大于RDB文件
· 根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。
AOF持久化机制配置
开启AOF持久化
```conf
APPEND ONLY MODE
By default Redis asynchronously dumps the dataset on disk. This mode is
good enough in many applications, but an issue with the Redis process or
a power outage may result into a few minutes of writes lost (depending on
the configured save points).
The Append Only File is an alternative persistence mode that provides
much better durability. For instance using the default data fsync policy
(see later in the config file) Redis can lose just one second of writes in a
dramatic event like a server power outage, or a single write if something
wrong with the Redis process itself happens, but the operating system is
still running correctly.
AOF and RDB persistence can be enabled at the same time without problems.
If the AOF is enabled on startup Redis will load the AOF, that is the file
with the better durability guarantees.
Please check http://redis.io/topics/persistence for more information.appendonly no ```
将appendonly修改为yes，开启aof持久化机制，默认会在目录下产生一个appendonly.aof文件
AOF持久化时机
```
appendfsync always
appendfsync everysec
appendfsync no
```
上述配置为aof持久化的时机，解释如下：
| 关键字 | 持久化时机 | 解释 | | ----------- | ---------- | ------------------------------ | | appendfsync | always | 每执行一次更新命令，持久化一次 | | appendfsync | everysec | 每秒钟持久化一次 | | appendfsync | no | 不持久化 |
参考：https://blog.csdn.net/bible_reader/article/details/84138665