redis中的持久化数据
redis作为缓存数据库在一个系统中扮演着很重要的角色，缓存嘛 就是为了减轻系统的各种负担避免大量的请求发送的后台的数据库中导致数据库不可用，最后系统不可用。于是牵扯出一系列的问题：当缓存不可用了，大量的请求依然会发送到数据库中，或者缓存服务器宕机等导致缓存数据丢失等其他问题使得缓存不可用。要如何解决这样的问题?说白了就是解决redis的故障恢复问题。
好的，首先来说下缓存不可用。要解决这个问题，需要把缓存系统做成高可用的情况，比如一主两从 多住多从。要实现这样的redis集群对redis本身并不难，因为redis自身已经实现了较好的集群底层功能。那就是redis cluster这里不做赘述后面在讲redis cluster的部署及实现高可用之类的。下面回答第二个问题，缓存数据因为各种乱七八糟的原因导致数据丢失。当这样的问题是我们通常的关系型数据库会如何考虑呢？我们有日志文件和备份，对的redis同样也有。那就是redis的 RDB文件和 AOF文件，如果通过持久化将数据搞一份儿在磁盘上去，然后定期比如说同步和备份到一些云存储服务上去，那么就可以保证数据不丢失全部，还是可以恢复一部分数据回来的。随着云数据的发展个人觉得将这种容灾型的文件同步到云上会成为一个较好的选择，好了 不说这个继续说RDB和AOF
redis的AOF. RDB
RDB持久化机制，对redis中的数据执行周期性的持久化
AOF机制对每条写入命令作为日志，以append-only的模式写入一个日志文件中，在redis重启的时候，可以通过回放AOF日志中的写入指令来重新构建整个数据集
如果我们想要redis仅仅作为纯内存的缓存来用，那么可以禁止RDB和AOF所有的持久化机制
通过RDB或AOF，都可以将redis内存中的数据给持久化到磁盘上面来，然后可以将这些数据备份到别的地方去，比如说云服务器
如果redis挂了，服务器上的内存和磁盘上的数据都丢了，可以从云服务上拷贝回来之前的数据，放到指定的目录中，然后重新启动redis，redis就会自动根据持久化数据文件中的数据，去恢复内存中的数据，继续对外提供服务
如果同时使用RDB和AOF两种持久化机制，那么在redis重启的时候，会使用AOF来重新构建数据，因为AOF中的数据更加完整
AOF在配置中默认是这样的：
# 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
值得注意的是AOF默认并不打开的 在配置文件conf中添加
append-only=always
再有就是RDB文件：
下面是redis的cof文件中的注释，也很好理解 就是在配置的时间内 多少发生变化变进行一次快照的拍摄：
################################ 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 save 300 10 save 60 10000
在配置文件中还能修改文件存放的位置及文件后缀名如下
# 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 /var/redis/Rdb
比较两者的优劣：
首先明确一个点：RDB文件中存储的是冷数据 ，可以理解为快照文件，有点恐怖对不对，如果redis需要频繁的进行快照的更新那势必会在一定程度上影响整个机器的性能，事实上影响并不大，日志快照通过redis主进程fork出子进程由子进程进行与磁盘的文件IO操作，通常建议如果只是在缓存上使用redis，而不需要考虑缓存的可用的情况下关闭两种缓存。当然作为一个日志系统相比于redis主系统这点开销算不得什么。
- （1）RDB会生成多个数据文件，每个数据文件都代表了某一个时刻中redis的数据，这种多个数据文件的方式，非常适合做冷备，可以将这种完整的数据文件发送到一些远程的安全存储上去，比如说Amazon的S3云服务上去，在国内可以是阿里云的ODPS分布式存储上，以预定好的备份策略来定期备份redis中的数据
- （2）RDB对redis对外提供的读写服务，影响非常小，可以让redis保持高性能，因为redis主进程只需要fork一个子进程，让子进程执行磁盘IO操作来进行RDB持久化即可
- （3）相对于AOF持久化机制来说，直接基于RDB数据文件来重启和恢复redis进程，更加快速
鉴于存储快照不需要过于频繁，我们可能是几分钟记录一个缓存中的所有的数据，然后保存一份RDB文件
RDB持久化机制的缺点
- （1）如果想要在redis故障时，尽可能少的丢失数据，那么RDB没有AOF好。一般来说，RDB数据快照文件，都是每隔5分钟，或者更长时间生成一次，这个时候就得接受一旦redis进程宕机，那么会丢失最近5分钟的数据
- （2）RDB每次在fork子进程来执行RDB快照数据文件生成的时候，如果数据文件特别大，可能会导致对客户端提供的服务暂停数毫秒，或者甚至数秒
再来说说AOF的形成，这个有点牵扯到操作系统的一个函数 fsync 函数：调用 fsync 可以保证文件的修改时间也被更新。fsync 系统调用可以使您精确的强制每次写入都被更新到磁盘中。您也可以使用同步（synchronous）I/O 操作打开一个文件，这将引起所有写数据都立刻被提交到磁盘中。通过在 open 中指定 O_SYNC 标志启用同步I/O。 后台线程可能一秒fsync一次 ，然后把积累的IO一次写完，这样看起来写的很频繁，但是也不会造成IO的积累因为要知道 对于计算机而言 一秒已经够他做很多事情了。 AOF文件的缺点也是很明显的相比于RDB文件 它又多又大 毕竟记录的是操作。在并发访问极高的情况下不推荐使用AOF这个。这里说的是极高 redis做的好的话抗个几十万几百万只是小case。真的qps很大的话可以横向扩容鸭。
优
- （1）AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据
- （2）AOF日志文件以append-only模式写入，所以没有任何磁盘寻址的开销，写入性能非常高，而且文件不容易破损，即使文件尾部破损，也很容易修复
- （3）AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。因为在rewrite log的时候，会对其中的指导进行压缩，创建出一份需要恢复数据的最小日志出来。再创建新日志文件的时候，老的日志文件还是照常写入。当新的merge后的日志文件ready的时候，再交换新老日志文件即可。
- （4）AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据
劣
- （1）对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大
- （2）AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的
- （3）以前AOF发生过bug，就是通过AOF记录的日志，进行数据恢复的时候，没有恢复一模一样的数据出来。所以说，类似AOF这种较为复杂的基于命令日志/merge/回放的方式，比基于RDB每次持久化一份完整的数据快照文件的方式，更加脆弱一些，容易有bug。不过AOF就是为了避免rewrite过程导致的bug，因此每次rewrite并不是基于旧的指令日志进行merge的，而是基于当时内存中的数据进行指令的重新构建，这样健壮性会好很多。
那么最后还是牵扯到如何选择的问题了： 这其实很难说，没有特点的场景 不好说：这里给出鄙人的拙见：在确定真正需要RDB或者AOF来保证数据的可用情况下，综合使用AOF和RDB两种持久化机制，AOF来保证数据不丢失，作为数据恢复的第一选择; 用RDB做冷
备，在AOF文件都丢失或损坏不可用的时候，还可以使用RDB来进行快速的数据恢复。感觉有点多余，所以是拙见了。。。。
调用 fsync 可以保证文件的修改时间也被更新。fsync 系统调用可以使您精确的强制每次写入都被更新到磁盘中。您也可以使用同步（synchronous）I/O 操作打开一个文件，这将引起所有写数据都立刻被提交到磁盘中。通过在 open 中指定 O_SYNC 标志启用同步I/O。