redis持久化--rdb

    在运行的过程中，redis是以数据结构的形式将数据维持在内存中的，为了让这些数据在redis重启之后仍然可以使用，这时候就需要持久化。就是我们把数据存储在redis关闭后不会丢失的设备中了，通常是硬盘。

    Redis的持久化有2种方式，快照和日志。

    这一节我们介绍的是rdb的工作原理：每个N分钟或者N次写操作后，从内存dump数据形成rdb文件，也是二进制文件。这是一种快照的方式。rdb方式是redis默认的一种方式。当我们在断点或者重启redis之后，那么就会帮助我们回复数据。但是当我们的redis数据库持续写入的时候，我们是fork出了一个子进程，在子进程中循环所有的数据，将数据写成为一个RDB文件。

生成rdb方式1

使用rdb的配置：

时长和修改的频率，相互的弥补。/

save 900 1      // 900内,有1条写入,则产生快照

save 300 1000   // 如果300秒内有1000次写入,则产生快照

save 60 10000  // 如果60秒内有10000次写入,则产生快照

(这3个选项都屏蔽,则rdb禁用，因为找不到导出规则了，所以停止了。)

时间满了之后，就会导出。

 

stop-writes-on-bgsave-error yes  // 后台备份进程出错时,主进程停不停止写入，停止也如

rdbcompression yes    // 导出的rdb文件是否压缩

Rdbchecksum   yes // 导入rbd恢复时数据时,要不要检验rdb的完整性

dbfilename dump.rdb  //导出来的rdb文件名

 

dir ./ //rdb的放置路径

缺陷：

    每次做一个快照是在有足够的积累之后是N分钟或者N次操作之后，那么这样，当在两个保存点之间断电的时候会丢失1-N分钟或者1--N次的数据的数据。这个问题我们可以使用AOF的方式来弥补。

优势：

rdb是从内存中导出的一个二进制的内存块，这个文件在回复的时候也是很快的。

注意：

  当我们使用6379的rdb文件将数据恢复到另外一个6380的redis进程中的时候，我们在赋值6379的rdb到6380那么如果6379的redis进程运行的时候，rdb处于打开状态，此时复制文件，占用同样的句柄。所以这样看是复制了两份文件，但是占用了同一个句柄，这样复制的rdb6380是没有复制过来数据。,无法恢复数据。

方式2：

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

解决方案：如果我们有主从复制的话，使用从服务器来分担这种大量的IO操作。