Redis持久化详解与实战

Redis持久化方式

Redis是支持RDB和AOF两种持久化的机制，持久化的功能可以有效的避免当进程崩溃、退出时造成的数据损失。当进程退出后，我们下次启动的时候，利用之前持久化的文件马上就可以恢复原有的数据。我们先大致理解一下官方的介绍：

RDB持久化的方式，是在指定条件下，能对数据库进行快照存储。比如手动触发或者自动按照时间间隔。

AOF持久化是以记录命令为条件来完成的。

AOF打开的时候，对Redis的所有写操作全部按照redis的协议格式进行保存，把新的命令追加到文件末尾来完成aof文件的保存。前边也介绍过可以通过BGREWRITEAOF 这个命令完成aof文件的重写，不至于让aof文件过大，成为磁盘或者恢复时的负担。

Redis 还可以同时打开RDB和AOF持久化，重启的时候优先使用AOF文件，因为AOF文件更完整。

持久化模式对比图表

存储方式	优点	缺点	场景建议
RDB	1、文件紧凑,占用磁盘小 2、适用灾难恢复,可把文件备份至异地 3、恢复快,在大数据时恢复速度比AOF快	1、出现故障时、数据会少量丢失 2、保存RDB系统资源紧张时可能会影响访问	1、允许少量数据丢失,需要更好的性能下选择 比如存放每天的定期的数据,比如计算好的推荐数 据,由于几乎不更新使用这种模式更快的恢复,数 据上也不会有太大损失
AOF	1、数据安全性高,最多一秒数据损失 2、数据文件可修复,易恢复 3、可重新AOF,降低磁盘容量消耗 4、误操作命令可通过A0F文件重写恢复	1、A0F对比RDB同等数据更占用磁盘容量 2、使用fsync速度对比会变慢。 3、恢复是需要fork更大的内存 4、恢复时可能会因为文件内某个命令出 现bug恢复失败	1、对数据安全性有较高要求的时候。 比如我存放文章评论、点赞等信息。故障时减少数 据损失
RDB+AOF	1、同上两条 2、不会同时执行rdb快照和AOF重新避免高I/0 3、数据安全系数更好	1、磁盘消耗两份文件肯定更占用磁盘 2、CPU消耗,定期执行两种的持久化	用于数据安全性较高的数据,定期远程备份RDB。我 们对历史数据有恢复或者查询要求时,也建议选择 这种。可以更好的保证数据的完整性
MEM	1、速度快 2、速度很快 3、速度非常快	故障不可恢复 缓存雪崩概念	数据量小、纯缓存。集群缓存等。在使用过程中 无需保存数据,仅为提高用户感受提升访问速度

RDB快照详解

在通常的情况下，Redis的快照将会保存在dump.rdb的二进制文件中，文件在我们配置的datadir 的目录下可以找到。

我们可以对Redis进行设置，让redis在 “x秒内数据集至少Y个改动”这种条件下自动保存一次快照。比如设置为 save 20 500 这个配置20秒内 500个改动保存一次。本次保存至下次满足条件保存的数据，崩溃时会丢失。

多个策略并行 通过配置可以看到我们可以根据实际的应用场景，设置多个保存策略，当满足某一个策略时，都会保存数据集。

RDB工作方式

1.调用fork(),发起一个子进程。不影响父进程的正常工作。

2.父进程处理正常请求，子进对数据集进行保存。

3.子进程完成新的RDB文件，Redis将使用新的RDB文件替换并删除旧文件。此机制可不产生垃圾文件。上图可以看到执行bgsave操作时，产生一个临时的rdb文件，在重新完成后，将更新和替换原来的dump.rdb文件。

孤舟大师免费大奉送了

Python篇

为了让大家能更好的理解和演示，希望大家也能有同样的数据环境。比如bgsave的操作，如果数据量比较小的话，是不能捕捉到临时文件替换rdb文件的。所以希望大家可以使用简单的工具，创造出模拟数据。学习起来更直观和容易理解。

1.安装python

2.安装pip

3.编写脚本插入数据

这里风险脚本内容，安装python和python-redis大家开动脑筋，多多思考和用脑啊。哈哈

#!/usr/bin/python
# -*- coding:utf-8 -*-  
import redis
//连接redis
r = redis.Redis(host='127.0.0.1', port=6379, decode_responses=True)
//使用for循环，插入1-5000000条记录
for i in range(1,5000000):
    r.set('name%d' %i, 'yiyeguzhu%d' %i)

Append-only file，AOF 详解

 

通过字面意思也可以清晰看到 只对文件进行追加，真的简单易懂啊。下边我们来更加深入了解一下，这个追加文件，到底是怎么回事儿吧。

1.首先通过配置文件打开 AOF 功能，临时配置的希望加不要忘记哦，参考config set 命令。appendonly yes2.打开AOF功能之后，我们所有对数据的写操作，插入或者update、以及删除都会写入到AOF文件末尾。

3.AOF 的重写 以点赞数量为例，我们只需要对点赞的数量进行统计出最后的总数即可。我们每次点赞操作都会调用 INCR 来获取当前的值即可。但是AOF文件会记录到我们每一次调用的记录。这样会导致我们的AOF文件比较臃肿。因为前边的数据记录对于我们来讲没有意义。这个时候我们可以通过 BGREWRITEAOF 进行重写。

4.和RDB相同调用子进程来完成，不影响父进程处理其他请求。重新完成后，新的aof文件会替换旧文件。5.AOF持久化策略之fsync

只要数据有变化马上追加到文件内 对于大量写入的不适合，会严重影响性能

每秒执行一次文件写入 速度快，出现故障时仅丢失1秒数据，默认为每秒写入这种模式。

从不写入到磁盘，等待手动调用。这种性能好，安全性不高。

 

# appendfsync always   #数据变化马上fsync
appendfsync everysec   #每秒同步一次
# appendfsync no       #从不进行fsync

6.AOF文件查看

大家可以通过策略制定每秒把数据变化同步到数据文件中，这个追加保存是按照redis内部协议完成的。但是大家可以通过以上的python脚本，模拟写入操作，然后观察一下AOF文件内容的变化。

题外篇

终于写完了，知识很重要、如何运用知识更重要。好比《侠客行》 里的石破天一样，单纯的有一身好的内力是不够的。还是需要通过实战和高手指导，融汇贯通。

由于经常修改配置，需要重启redis，深感不便啊。简单写了个重启的脚本，大家参考一下。功能过于简单，不做讲解。

 

#!/bin/bash
stop() {
  kill -9 `ps aux | grep redis-server | grep 6379 | grep -v grep | awk '{print $2}'`
}
start() {
 ./bin/redis-server ./conf/redis.conf
}
case "$1" in
      "start")
          start
          echo "redis server start"
             ;;
       "stop")
          stop
          echo "redis server stop"
             ;;
        "restart")
           stop
           start
           echo "redis server restart"
             ;;
          *)
           echo "input stop/start/restart"
             ;;
esac

 

@版权声明：51CTO独家出品，未经允许不能转载，否则追究法律责任