小记redis持久化的机制

　　刚学redis，就经常看到两种持久化机制在眼头晃，RDB和AOF,然而当时学的还知道这两东西是啥玩意，过段时间又忘了，中文记忆这两种概念总感觉有些别扭。今心血来潮翻看redis的配置文件，豁然开朗，仿佛打开了一片新世界，现小结如下。

　　RDB机制：

 save <seconds> <changes>

   Will save the DB if both the given number of seconds and the given
   number of write operations against the DB occurred.

这句话就是说我们一旦对数据库进行写入的操作，那么redis数据库就会对这个操作进行持久化

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

然后，reids持久化默认遵循这样一种策略进行持久化，如果1-9个键发生变化了，15分钟后reids才会进行持久化；

如果不少于10个键发生了变化，5min后数据库才会进行持久化；如果不少于10000个键发生了变化，那么1min后数据库才会持久化。基于这种策略，我们称之为快照，在指定的时间间隔内生成数据集的时间点快照（point-in-time snapshot）。快照这个概念初听很懵，经此分析，瞬间感觉这概念跃然纸上，像按下快门记录下这瞬间的信息一样。

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

既然有默认的机制，同时redis也允许我们自己设置这个持久化间隔时间，格式：save+间隔时间+最少键变化个数。

By default Redis will stop accepting writes if RDB snapshots are enabled
# (at least one save point) and the latest background save failed.
# This will make the user aware (in an hard way) that data is not persisting
# on disk properly, otherwise chances are that no one will notice and some
# distater will happen.

#If the background saving process will start working again Redis will
  # automatically allow writes again.

如果redis基于这种持久化策略,在快照生效后，位于这个节点后的后台持久化操作将不能执行。这意味着我们的redis持久化数据会存在着不准确性。只有当后台程序重新启动后，redsi才会自动进行写入的操作。这句话意思就是说，假设存在这样的一个场景：

如果redis已经在节点一进行了一次快照持久化，恰巧我们后面又进行了一次后台写入操作，紧接着我们关闭了redis,那么我们最后一次的数据是否持久化到了disk上了？

首先，从节点二到redis关闭的这段时间内，是否产生了节点快照，这取决于时间间隔是否满足持久化策略，因此这将会导致我们存储数据的不准确性。