Redis持久化策略(看这篇,你肯定会有所获)

RDB：Redis DataBase ， 记录快照

        RDB是redis 默认的持久化方案 RDB 是当满足一定条件时, 就会将redis内存中的数据写入磁盘,并生成一个快照文件dumprdb 文件Redis 重启会通过加载dumprdb文件恢复数据

        一定条件分为以下几种情况: 1自动触发  2 手动触发 下面分开说明下:

a)redisconf 中 SNAPSHOTTING 其中定义了触发把数据保存到磁盘的触发频率

        如果不需要rdb 方案, 注释save 或者配置成空字符串" "

        save 900 1 #900秒内至少有一个key被修改(包括添加)

        save 300 10 #400秒内至少10个key被修改

        save 10000 #60秒内至少有10000个key 被修改

        这三条配置不冲突, 只要满足一条就触发

        rdb 文件位置和目录 (默认在安装根目录下) 

        #文件路径

        dir /

        #文件名称

        dbfilename dumprdb

        #是否以LZY压缩rdb 文件

        rdbcompression yes 

        #开启数据校验

        rdbchecksum yes

b) shutdown触发 ,保证服务器正常关闭

c) flushall , rdb文件是空的, 会生成一个空的文件,所以这种情况也没有什么意义但需要知道,这种情况下

会触发生成rdb文件

Redis 提供了两条命令: save 和 bgsave

a) save 命令

        save 在生成快照的时候会阻塞当前Redis 服务器,Redis不能处理其他命令如果内存数据较多,会造成

b)bgsave 命令

        执行bgsave命令时,   Redis会在后台进行异步快照 *** 作,快照同时还可以响应客户端请求

具体 *** 作

        具体 *** 作:Redis进程会执行fork *** 作创建子进程(copy-on-write),RDB 持久化过程由子进程负载,完成后自动结束它不会记录fork之后产生的记录阻塞只发送在fork阶段,一般时间较短

一优势

    1RDB是一个非常紧凑的文件,它保存了Redis在某个时间点上的数据集这种文件非常适合进行备份和

灾难恢复

    2生成RDB文件的时候,redis主进程会fork()一个子进程来处理所有保存的工作,主进程不需要进行任何

IO *** 作

    3RDB在恢复大数据集时的速度比AOF的恢复速度要快

二劣势

    1)RDB 没办法做到实时持久化/妙级持久化因为bgsave每次运行都要执行fork创建子进程,频繁执行成本过高    

    2)在一定间隔时间做一次备份,所以如果Redis 以为down掉的话,就会丢失最后一次快照之后所有修改

(数据有丢失)

AOF：<Append Only File> ， 记录日志

Redis 默认不开启AOF采用日志的形式来记录每个写 *** 作,并追加到文件中开启后,执行更改Redis    命令时,就会把命令写入到AOF文件中

Redis 重启时会根据日志文件的内容把写指令从前往后执行一次以完成数据的恢复工作

#开关

appendonly no

#文件名

appendfilename "appendonlyaof"

        由于 *** 作系统缓存机制,AOF数据并没有真正地写入硬盘,而是进入了系统的硬盘缓存什么时候

把缓冲区的内容写入到AOF文件中 由下面参数决定

appendfsync :  值: no  \ always \everysec 

        no: 表示不执行fync, 由 *** 作系统保证数据同步到磁盘,速度最快,但是不安全

        always:表示每次写入都执行fync,以保证数据同步到磁盘,效率很低

        everysec:表示每秒执行以fync ,可能会导致丢失1s数据通常选择everysec,兼顾效率和安全性

    因为AOF文件只有一个, 随着redis 不断进行,AOF 的文件会越来越大,文件越大, 文件占用服务器内存

以及AOF恢复要求时间越长

    为了解决这个问题,可以使用bgwriteaof来重写那什么时候重写 又是怎样重写

    一 什么时候重写

    #重写触发机制

    auto-aof-rewrite-percentage 100 默认值是100 当前aof 文件大小超过 上一次重写的aof文件大小百分之多少进行重写,即当aof文件增长到一定大小时,Redis能够调用bgwriteaof对日志文件进行重写当前aof文件大小是上次日志重写得到aof文件大小的二倍时, 自动启动新的日志重写过程

    auto-aof-rewrite-min-size 默认是64M设置允许重写的最小aof文件大小,避免达到了约定百分比 但尺寸

仍然很小的情况还要重写

   二 怎样重写

    并不是对原文件进行重新整理,而是直接读取服务器上现有的键值对,然后用一条命令去代替之间记录这

个键值对的多条命令,生成一个新的文件后去替换原来的 AOF文件

    看下面这两个参数:

        no-appendfsync-on-rewrite

        aof-load-truncated

   AOF 数据恢复

        重启Redis之后就会进行AOF文件恢复

   AOF 的优势和劣势

优点:

1AOF 持久化的方法提供了多种的同步频率,即使使用默认的同步频率每秒同步一次,Redis最多也就丢失

1秒的数据

缺点:

1对于具有相同数据的Redis, AOF文件通常比RDF文件体积更大(RDB存的是数据快照)

2虽然AOF提供了多种同步的频率,默认的情况下,没秒同步一次的频率也具有较高的性能在高并发的情况下,RDB比AOF具有更好的性能

        如果可以忍一小段时间数据的丢失,毫无疑问使用RDB 是最好的,定时生成RDB快照非常便于进行数据备份,而且RDB恢复数据集的速度也要比AOF恢复速度要快

        否则就要使用AOF重写但是一般情况下建议不要单独使用某一种持久化机制,而是两种一起用

本文内容来自咕泡学院-青山老师,感谢青山老师!!

1、安装编译工具

yum install wget make gcc gcc-c++ zlib-devel openssl openssl-devel pcre-devel kernel keyutils patch perl

2、安装tcl组件包（安装Redis需要tcl支持）

下载： tcl861-srctargz

上传tcl861-srctargz到/usr/local/src目录

cd /usr/local/src #进入软件包存放目录

tar zxvf tcl861-srctargz #解压

cd tcl861 #进入安装目录

cd unix

/configure --prefix=/usr --without-tzdata --mandir=/usr/share/man $([ $(uname -m) = x86_64 ] && echo --enable-64bit) #配置

make #编译

sed -e "s@^(TCL_SRC_DIR=')@1/usr/include'@" -e "/TCL_B/s@='(-L)unix@='1/usr/lib@" -i tclConfigsh

make install #安装

make install-private-headers

ln -v -sf tclsh86 /usr/bin/tclsh

chmod -v 755 /usr/lib/libtcl86so

3、安装Redis

下载：>

根据下面步骤创建适应业务需求的云数据库Redis版实例。

使用下列方法中任意一种打开购买页：

打开云数据库Redis版产品首页，单击立即购买。

说明 如果尚未登录阿里云账号，单击立即购买后需要先使用阿里云账号和密码登录。

登录Redis管理控制台，单击右上角的创建实例。

设置以下参数。

选择密码设置方式。

立即设置：在下方的输入密码区域设置密码。

稍后设置：创建实例后再修改密码。

设置实例名称、购买数量，如果创建包年包月实例，还需设置时长。

在确认订单页，阅读《云数据库KVStore版服务协议》，确认接受后在服务协议前的选框中单击勾选。

单击去开通。

因为这方面内容较多，这里也写不开那么多内容，所以你可以留言或到我的博客上搜索相关内容，老魏有写过教程，还不止一篇，都挺详细的内容，可以帮助你入门。

不应该。因为redis开快照的话会让硬件受损，所以为了更长久的使用，不应该开快照。快照指照相馆的一种冲洗过程短的照片如：证件快照，基于硬件编程技术的一种，针对内存进行的快速读取技术，常用于硬件开发。

以上就是关于Redis持久化策略(看这篇,你肯定会有所获)全部的内容，包括:Redis持久化策略(看这篇,你肯定会有所获)、redis-4.0.1.tar.gz怎么安装、阿里云数据库redis怎么配置等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！