Redis持久化介绍

Redis是一个基于BSD开源许可的内存数据结构存储系统,因为redis具备卓越的高并发读写特性,其主要用于用做数据库、缓存和消息代理。redis具备内置的复制、lua、lru、事务和不一样级别的磁盘持久性,并经过哨兵机制和集群自动分区功能提供高可用性。本文主要介绍包含RDB(Redis DataBase)持久化、AOF(Append Only File)持久化、RDB和AOF混合持久化等持久化策略。redis

 

Redis如下几种持久性选项范围:数据库

  • RDB持久性按指定的时间间隔执行数据集的时间点快照。
  • AOF持久性会记录服务器接收的每一个写入操做,这些操做将在服务器启动时再次播放,以重建原始数据集。使用与Redis协议自己相同的格式记录命令,而且采用仅追加方式。当日志太大时,Redis能够在后台重写日志。
  • 能够在同一实例中同时合并AOF和RDB。在这种状况下,当Redis从新启动时,AOF文件将用于重建原始数据集,由于它能够保证是最完整的。
  • 若是但愿只用做缓存服务器,对数据的持久性无要求,也能够彻底禁用持久性。

 

下面着重介绍RDB和AOF持久化的特色和应用场景。缓存

 

RDB持久化

 

RDB持久化的优势

RDB 是 Redis 默认的持久化方案。在指定的时间间隔内,写操做达到指定的次数,则会将内存中的数据写入到磁盘RDB文件中。因为RDB文件是一个很是紧凑的文件,比较容易备份,因此RDB对于灾难恢复很是有用。RDB最大限度地提升了Redis的性能,由于Redis父进程的持久化操做是经过分叉子进程实现,而父进程不会执行磁盘I / O等操做。与AOF相比,RDB容许大型数据集更快地重启。安全

 

RDB持久化的缺点

RDB持久化的写入方式决定了该持久化策略并不能彻底保证数据的安全性。RDB须要常用fork()才能使用子进程将其持久化在磁盘上。若是数据集很大,Fork()可能很耗时,而且若是数据集很大且CPU性能不佳,则可能致使Redis中止为客户端服务几毫秒甚至一秒钟。该过程若是出现宕机,则可能形成数据丢失。服务器

 

RDB持久化配置

打开 redis.conf 文件,定位到 SNAPSHOTTING 对应内容数据结构

save <seconds> <changes>并发

# save ""app

save 900 1运维

save 300 10高并发

save 60 10000

dbfilename dump.rdb

dir ./

rdbcompression yes

 

save <指定时间间隔> <执行指定次数更新操做>,知足条件就将内存中的数据同步到硬盘中。官方出厂配置默认是 900秒内有1个更改,300秒内有10个更改以及60秒内有10000个更改,则将内存中的数据快照写入磁盘。关闭RDB,则把上面配置注释便可。

 

  • dbfilename指定本地数据库文件名,默认文件名为 dump.rdb,文件格式.rdb结尾。
  • dir指定数据库存放目录为当前目录
  • rdbcompression开启数据压缩,默认为yes,Redis采用LZF压缩方式。

 

RDB的触发与恢复

触发RDB快照的方式有save策略触发,flush命令(清空数据库全部数据),shutdown(关闭redis)命令,三种方式都是调用redis的bgsave机制实现快照触发。

 

RDB文件恢复数据的方式是将dump.rdb 文件拷贝到redis的安装目录的bin目录下,重启redis服务便可。

 

AOF持久化

 

AOF持久化的优点

AOF能够弥补RDB的不足(数据的不一致性),它采用日志的形式来记录每一个写操做,并追加到文件中。Redis 重启的会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工做。

 

使用AOF Redis更加持久,提供不一样的fsync策略:彻底没有fsync,每秒fsync,每一个查询fsync。使用默认策略fsync时,每秒的写入性能仍然很好(fsync是使用后台线程执行的,而且在没有进行fsync的状况下,主线程将尽力执行写入操做。)

 

AOF日志是仅追加的日志,所以即使是断电故障,也不会出现磁盘寻道或损坏问题。即便因为某种缘由(磁盘已满或其余)致使日志错误,也可使用redis-check-aof工具=轻松修复。

 

AOF持久化的缺点

对于同一数据集,AOF文件一般大于等效的RDB文件。在特定的fsync策略下,AOF比RDB的效率低。一般,在将fsync设置为每秒的状况下,性能仍然很高,而且在禁用fsync的状况下,即便在高负载下,它也应与RDB同样快。即便在巨大的写负载的状况下,RDB仍然可以提供有关最大延迟的更多保证。可是若是fsync策略为aways,则随着集群负载增大,AOF记录的内容愈来愈大多,文件会愈来愈大,数据恢复也会愈来愈慢。

 

AOF持久化配置

打开 redis.conf 文件,定位到APPEND ONLY MODE 对应内容

appendonly yes

appendfilename "appendonly.aof"

appendfsync everysec

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64mb

 

说明:

  • appendonly 配置redis 默认关闭,开启须要手动把no改成yes
  • appendfilename指定本地数据库文件名,默认值为 appendonly.aof
  • appendfsync everysec指定更新日志条件为每秒更新,共三种策略(aways,everyse,no)
  • auto-aof-rewrite-min-size配置重写触发机制,当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。

 

AOF触发与恢复

AOF主要根据配置文件策略触发,能够是每次执行触发,能够是每秒触发,能够不一样步。

 

AOF的恢复主要是将appendonly.aof 文件拷贝到redis的安装目录的bin目录下,重启redis服务便可。但在实际开发中,可能由于某些缘由致使appendonly.aof 文件异常,从而致使数据还原失败,能够经过命令redis-check-aof --fix appendonly.aof 进行修复

 

AOF的工做原理是将写操做追加到文件中,文件的冗余内容会愈来愈多。因此Redis 新增了重写机制,经过auto-aof-rewrite-min-size控制。当AOF文件的大小超过所设定的阈值时,Redis就会对AOF文件的内容压缩。

做者:张文博

其余讨论

4大步骤节省30%浪费,优化企业上云成本从了解云开始!

运维思考 | 你知道CMDB与监控是什么关系吗?

【干货】4种Oracle DBaaS部署模式,你在使用哪种?

如何改善监控问题,试试打造企业统一监控平台体系!

云计算 | 数据在云上安全吗?DDoS攻击怎么办?

相关文章
相关标签/搜索