通过前面文章的介绍，大家对于redis的基本操作应该比较了解了。本文主要介绍下redis持久化方式中的快照持久化
Redis持久化
所谓的持久化就是保持我们的数据不丢失，将数据通常保存在我们的硬盘中。在Redis中持久化的方式有两种，一种是快照持久化，一种是AOF持久化，各有各的优缺点，在项目中我们得根据实际的情况来选择具体的持久化方式。本文主要介绍快照持久化，下篇文章介绍AOF持久化。
快照持久化
也叫RDB持久化方式。就是通过拍摄快照的方式来实现持久化，将某个时间的内存数据存储在一个rdb文件中。在redis服务重新启动的时候会加载rdb文件中的数据。
配置快照持久化
redis中的快照持久化默认是开启的，在redis.conf配置文件中有相关的配置选项
################################ SNAPSHOTTING ################################ # # Save the DB on disk: # # 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. # # 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 completely by commenting out all "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 #900秒内至少有1个key被更改就执行快照 save 300 10 #300内描述至少有10个key被更改就执行快照 save 60 10000 #60秒内至少有10000个key被更改就执行快照 # 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 a hard way) that data is not persisting # on disk properly, otherwise chances are that no one will notice and some # disaster will happen. # # If the background saving process will start working again Redis will # automatically allow writes again. # # However if you have setup your proper monitoring of the Redis server # and persistence, you may want to disable this feature so that Redis will # continue to work as usual even if there are problems with disk, # permissions, and so forth. stop-writes-on-bgsave-error yes #拍摄快照失败是否继续执行写命令 # Compress string objects using LZF when dump .rdb databases? # For default that's set to 'yes' as it's almost always a win. # If you want to save some CPU in the saving child set it to 'no' but # the dataset will likely be bigger if you have compressible values or keys. rdbcompression yes #是否对快照文件进行压缩 # Since version 5 of RDB a CRC64 checksum is placed at the end of the file. # This makes the format more resistant to corruption but there is a performance # hit to pay (around 10%) when saving and loading RDB files, so you can disable it # for maximum performances. # # RDB files created with checksum disabled have a checksum of zero that will # tell the loading code to skip the check. rdbchecksum yes #是否进行数据校验 # The filename where to dump the DB dbfilename dump.rdb #快照文件存储的名称 # The working directory. # # The DB will be written inside this directory, with the filename specified # above using the 'dbfilename' configuration directive. # # The Append Only File will also be created inside this directory. # # Note that you must specify a directory here, not a file name. dir ./ #快照文件存储的位置
验证快照效果
1.进入安装目录，如果有dump.rdb文件就删除。
2.启动redis，然后添加几个数据，然后关闭redis并退出。如下
[root@hadoop-node01 redis-5.0.3]# src/redis-cli 127.0.0.1:6379> ping PONG 127.0.0.1:6379> set name aaa OK 127.0.0.1:6379> set age 18 OK 127.0.0.1:6379> incr age (integer) 19 127.0.0.1:6379> shutdown not connected> exit
3.在我们的安装目录下有生成了一个dump.rdb文件，这个就是我们的快照备份文件。
4.再次启动redis，进入发现原来的数据还在，这是因为redis启动的时候加载了备份文件中的数据。
[root@hadoop-node01 redis-5.0.3]# src/redis-server redis.conf 1211:C 13 Feb 2019 01:27:22.668 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo 1211:C 13 Feb 2019 01:27:22.668 # Redis version=5.0.3, bits=64, commit=00000000, modified=0, pid=1211, just started 1211:C 13 Feb 2019 01:27:22.668 # Configuration loaded [root@hadoop-node01 redis-5.0.3]# src/redis-cli 127.0.0.1:6379> ping PONG 127.0.0.1:6379> get name "aaa" 127.0.0.1:6379> get age "19" 127.0.0.1:6379> keys * 1) "name" 2) "age"
5.关闭退出
关闭退出后删除dump.rdb文件，启动后发现数据没有了
[root@hadoop-node01 redis-5.0.3]# src/redis-server redis.conf 1218:C 13 Feb 2019 01:29:01.336 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo 1218:C 13 Feb 2019 01:29:01.336 # Redis version=5.0.3, bits=64, commit=00000000, modified=0, pid=1218, just started 1218:C 13 Feb 2019 01:29:01.336 # Configuration loaded [root@hadoop-node01 redis-5.0.3]# src/redis-cli 127.0.0.1:6379> ping PONG 127.0.0.1:6379> keys * (empty list or set)
快照持久化原理
1.save命令
在redis运行中，我们可以显示的发送一条save命令来拍摄快照。save命令是阻塞命令，也就是当服务器接收了一条save命令之后就会开始拍摄快照，在此期间不会再去处理其他的请求，其他请求会被挂起直到备份结束
2.bgsave命令
bgsave命令也是立即拍摄快照，有别于save命令，bgsave并不是一条阻塞命令，而是fork一个子线程，然后这个子线程负责备份操作。而父进程继续处理客户端的请求，这样就不会造成阻塞了。
127.0.0.1:6379> ping PONG 127.0.0.1:6379> keys * (empty list or set) 127.0.0.1:6379> set name zhangsan OK 127.0.0.1:6379> set age 20 OK 127.0.0.1:6379> bgsave Background saving started
3.根据配置文件默认快照
save 900 1 #900秒内至少有1个key被更改就执行快照 save 300 10 #300内描述至少有10个key被更改就执行快照 save 60 10000 #60秒内至少有10000个key被更改就执行快照
4.shutdown命令
当我们只想shutdown命令的时候。服务器会自动发送一条save命令来完成快照操作。并在完成备份操作后关闭服务器。所以我们当我们的操作不满足前面三种情况的时候关闭服务器后，再次打开我们的数据也不会丢失。
5.sync命令
当在主从环境中，从节点要同步主节点的数据的时候会发送一条sync命令来开发一次复制。此时主节点会发送一条bgsave命令来fork一个新的线程来完成快照并在bgsave命令操作结束后将快照文件发送给从节点来完成主从节点的数据的同步。
优缺点
优点
RDB文件是一个很简洁的单文件，它保存了某个时间点的Redis数据，很适合用于做备份。你可以设定一个时间点对RDB文件进行归档，这样就能在需要的时候很轻易的把数据恢复到不同的版本。
RDB很适合用于灾备。单文件很方便就能传输到远程的服务器上。
RDB的性能很好，需要进行持久化时，主进程会fork一个子进程出来，然后把持久化的工作交给子进程，自己不会有相关的I/O操作。
比起AOF，在数据量比较大的情况下，RDB的启动速度更快。
缺点
RDB容易造成数据的丢失。假设每5分钟保存一次快照，如果Redis因为某些原因不能正常工作，那么从上次产生快照到Redis出现问题这段时间的数据就会丢失了。
RDB使用fork()产生子进程进行数据的持久化，如果数据比较大的话可能就会花费点时间，造成Redis停止服务几毫秒。如果数据量很大且CPU性能不是很好的时候，停止服务的时间甚至会到1秒。
如何禁用快照持久化
1.在redis.conf配置文件中注释掉所有的save配置
2.在最后一条save配置追加吃命令
save ""
~好了本文到此为止，下篇文章介绍AOF持久化
