redis持久化详解
来源:互联网 发布:大连知你创业基地 编辑:程序博客网 时间:2024/06/14 15:47
redis持久化详解
redis是一个支持持久化的内存型数据库,由于是在内存中,即使有主从,数据冗余备份,也难保数据丢失,
redis持久化就是解决这个问题。
redis持久化,是通过把内存里的数据同步到磁盘上来保证持久化。
redis有两种持久化方式
一种是快照,snapshotting,也是默认方式,还有一种是只追加文件,缩写aof(apppend-only-file)。
快照(snapshotting):将某一时刻的所有数据都写入硬盘。
只追加文件(AOF):在执行写命令时,将被执行的写命令复制到硬盘里。
snapshotting(RDB)机制
创建快照有两个命令BGSAVE,SAVE。
BGSAVE过程:
1redis通过fork产生子进程
2父进程继续处理client请求,子进程负责将快照写入硬盘
3子进程写完后,用临时文件代替原来快照文件,然后子进程退出
SAVE过程:
1redis服务器停止接受来自client请求
2在快照创建完成之前将不再响应其他命令。
SAVE和BGSAVE优缺点:
save缺点:快照操作完成之前不再响应其他命令。
save优点:在大数据量的情况下,比bgsave更快速稳定。
运用场景:SAVE一般用在机器没有足够内存执行BGSAVE或是接收到SHUTDOWN关机命令请求时用。
比如写个脚本,在凌晨5点访问量很小的时候,执行save快照操作。
bgsave缺点:在大数据量的情况下,BGSAVE的子进程由于要把内存里的数据写入到硬盘,子进程会耗费越来越多时间。
如果达到十几GB数据量的话,BGSAVE可能会导致系统长时间的停顿
bgsave优点:快照操作时不影响redis服务器继续接受请求,做出响应。
运用场景:非十几GB的大数据量情况下一般都适合用bgsave命令执行快照操作。
快照snapshotting配置选项
编辑redis.conf
save 60 1000 //多久执行一次bgsave自动快照操作,当满足 60秒之内有1000次写入即触发。
save 3600 1 //该条配置可以有多个,任意一个满足一次,执行一次。 一小时之内只要有一条写操作就执行快照操作
stop-writes-on-bgsave-error no //创建快照失败后是否继续写操作
rdbcompression yes //是否对快照文件压缩
dbfilename dump.rdb //快照写入文件的名称
dir ./ //快照文件的指定路径
snapshotting快照持久化运用场景
快照是将某一时间点在内存里的数据进行写入操作到硬盘。
也就是说在本次快照操作完成之后,下一次时间点快照操作到来之前的这段时间内发生系统崩溃,或是硬件问题,
这段时间内产生的数据将会丢失。所以快照适合对小数据丢失有一定容忍的应用和场景。
1购物车(查询简单|经常变更|数据量级不大|弱化事务|安全级别低)
2促销活动规则(存储) | 抢购 缓冲队列
3涉及到钱的问题都不会用,银行,付款,等等
3涉及到钱的问题都不会用,银行,付款,等等
append-only-file(AOF)机制
AOF持久化会将被执行的写命令追加到原来的AOF文件末尾,因此redis只要重新执行一遍AOF文件包含的所有写命令
即可恢复AOF文件所记录的数据集。
1redis产生fork子进程。
2父进程继续处理client请求,子进程把aof内容写入缓冲区。
3子进程写完退出,父进程接受退出消息,将缓冲区内容写入AOF文件。
AOF配置选项
编辑redis.conf
appendonly no //是否启用aof方式
appendfsync everysec|always|no //aof文件同步频率
//everysec 每秒执行同步一次,显示的将多个命令同步到硬盘,也是推荐的一个
//always每个redis写命令都要同步写入到硬盘,io操作频繁影响到redis速度。
// 但是数据最安全的一个。
//no让操作系统来决定何时该同步。
no-appendfsync-on-rewite no //再对aof进行压缩的时候是否执行同步操作
auto-aof-rewrite-percentage 50 //当aof文件大于80MB时并且AOF文件比上次重写之后体积大了50%
auto-aof-rewrite-min-size 80mb //redis将自动执行BGREWRITEAOF命令,
AOF缺陷--aof文件体积问题
表面上看,aof方式既可以把数据丢失降低到1秒(设置成appendfsync everysec),又可以极短时间完成持久化操作,无疑是最好的方式,但是
aof有文件过大的问题。随着redis不断运行,执行的写操作越来越多,aof文件不断追加命令,aof文件将越来越大,极端情况可以用完整个硬盘。
另一方面,如果系统崩溃了,在机器重启后需要执行aof文件来恢复丢失数据,aof文件过大,导致,执行时间会很长。
为了解决这个问题,就不得不说BGREWRITEAOF命令,该命令可以移除原有aof文件里冗余的写操作重写aof文件。
但是BGREWRITEAOF命令又出现了快照方式BGSAVE问题,执行BGREWRITEAOF,redis会创建子进程,子进程负责文件重写,
由此带来的子进程的性能和时间问题同样存在。
无论使用aof方式还是快照方式来实现持久化都是各有利弊,选用时要因地制宜。
如果有不同见解欢迎大家一起来讨论,共同进步@_@。
观点有参考Josiah L,carlson 所著redis in action。
无论使用aof方式还是快照方式来实现持久化都是各有利弊,选用时要因地制宜。
如果有不同见解欢迎大家一起来讨论,共同进步@_@。
观点有参考Josiah L,carlson 所著redis in action。
0 0
- redis持久化详解
- Redis持久化方案详解
- redis持久化原理详解
- redis持久化原理详解
- 《Redis的持久化》详解
- redis详解-(8)持久化
- redis 持久化机制AOF/RDB详解
- Redis教程(十):持久化详解
- Redis教程(十):持久化详解
- redis 安装配置及持久化详解
- redis持久化方式配置详解
- 【redis】redis 持久化
- 【redis】redis持久化
- redis---Redis持久化
- NoSQL之Redis高级命令详解--持久化机制
- redis持久化及主从复制详解(转)
- Redis中持久化的两种方法详解
- NoSQL之Redis高级命令详解--持久化机制
- 使用ssh中遇到的错误
- tensorflow--Not a JPEG file: starts with 0x89 0x50
- Lucene 查询索引库
- 反距离插值(Inverse Distance Weighted)
- 强大的ORM之Realm基础使用总结
- redis持久化详解
- hdu 1116 poj 1386 欧拉回路并查集
- 编写联系人list
- 组播MAC地址
- Spring 各个jar包的作用
- 关于H5唤醒APP的功能实现(千辛万苦啊!)
- List<Object>删除某一个Object
- 用pybrain构建BP神经网络
- Cannot find the declaration of element 'beans'. 的解决方法