内容简介:数据写入redis时,保存在redis客户端的内存中,这是的数据称为瞬时数据,所谓持久化就是把内存中的数据保存在存储设备中。(入磁盘)aof: Redis 在执行完一个写命令后,都会将执行的写命令追回到 Redis 内部的缓冲区的末尾。这个过程是命令的追加过程。rbd: 固定的时间间隔将内存中的数据写入磁盘。默认的方式
什么是持久化
数据写入 redis 时,保存在redis客户端的内存中,这是的数据称为瞬时数据,所谓持久化就是把内存中的数据保存在存储设备中。(入磁盘)
持久化的两种方式
aof: Redis 在执行完一个写命令后,都会将执行的写命令追回到 Redis 内部的缓冲区的末尾。这个过程是命令的追加过程。
rbd: 固定的时间间隔将内存中的数据写入磁盘。默认的方式
Append Only File(aof)
以日志的形式记录redis的写操作。将redis执行过的所有写指令记录下来。只追加文件不可以改写文件、redis启动的时候回读取该文件重新构建数据。也就是说redis会将文件中的写操作从头到尾重新执行一遍
配置文件部分内容如下:
appendonly no # The name of the append only file (default: "appendonly.aof") appendfilename "appendonly.aof" # appendfsync always appendfsync everysec # appendfsync no
- always : 同步持久化,每次发生数据变化都会被立即记录到磁盘中(appendonlu.aof)。 能保证数据的完整性,但是性能相对较差
- Everysec : 出厂默认推荐,异步操作。每秒钟记录一次。 所以最多会只丢失最后一秒钟的数据
- No: 执行写操作之后由操作系统自动的去同步到磁盘。性能最好
Rewrite: aof采用文件追加方式,因此appendonly.aof文件会越来越大。所以新增了重新机制。当aof文件大小超过阈值,会fork一个新的进程将文件重写,遍历新进程中的内存数据。重写aof并不会读取旧的aof文件。而是将内存中的所有数据内容用命令的方式重写了一个新的aof文件。类似快照。
触发机制, redis.conf中:
auto-aof-rewrite-percentage 100 # aof文件增长比例,指当前aof文件比上次重写的增长比例大小。 auto-aof-rewrite-min-size 64mb # aof文件重写最小的文件大小
优点
AOF 持久化的方法提供了多种的同步频率,即使使用默认的同步频率每秒同步一次,Redis 最多也就丢失 1 秒的数据而已。
0 AOF 文件使用 Redis 命令追加的形式来构造,因此,即使 Redis 只能向 AOF 文件写入命令的片断,使用 redis-check-aof 工具也很容易修正 AOF 文件。
AOF 文件的格式可读性较强,这也为使用者提供了更灵活的处理方式。例如,如果我们不小心错用了 FLUSHALL 命令,在重写还没进行时,我们可以手工将最后的 FLUSHALL 命令去掉,然后再使用 AOF 来恢复数据。
同时开启时,会优先健在aof文件来恢复数据。 因为aof的数据完整性要比rdb的要好。
缺点
对于具有相同数据的的 Redis,AOF 文件通常会比 RDF 文件体积更大。
虽然 AOF 提供了多种同步的频率,默认情况下,每秒同步一次的频率也具有较高的性能。但在 Redis 的负载较高时,RDB 比 AOF 具好更好的性能保证。
RDB 使用快照的形式来持久化整个 Redis 数据,而 AOF 只是将每次执行的命令追加到 AOF 文件中,因此从理论上说,RDB 比 AOF 方式更健壮。官方文档也指出,AOF 的确也存在一些 BUG,这些 BUG 在 RDB 没有存在。
Redis Database(rbd)
redis会单独fork一个子进程,来进行持久化操作。会将内存中的数据暂时先写入一个临时文件中,当持久化过程结束后。再用这个临时文件替换之前持久化好的文件(dump.rbd )。 由于是单独创建的子进程,所以整个过程并不会影响主进程的IO操作。因此需要整个过程非常高效。如果对数据精度要求较高,rbd的方式并不适用。因为如果出现断电情况最后一个时间间隔内的数据可能会丢失。
所谓fork: 复制一个与当前进程一样的进程。所有数据都与原进程一直。 类似git的fork
redis.conf:
################################ SNAPSHOTTING ################################ # # Save the DB on disk: # # save <seconds> <changes> # 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 # save "" 如果要禁用rdb,不设置save或者给sava传个空字符串就ok # 出发rdb的条件 save 900 1 # 900秒改一次 save 300 10 # 300秒改10次 save 60 10000 # 60秒改1W次
当遇到特别重要的数据我们需要它立即进行持久化。可以通过save命令来完成
优势
适合大规模数据的回复 对数据完整性和一致性要求不高
劣势
由于会fork一份一样的进程。因此会占用翻倍的膨胀性
发生意外时,最后一份数据可能会丢失
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
构建高性能Web站点
郭欣 / 电子工业出版社 / 2012-6 / 75.00元
《构建高性能Web站点(修订版)》是畅销修订版,围绕如何构建高性能Web站点,从多个方面、多个角度进行了全面的阐述,几乎涵盖了Web站点性能优化的所有内容,包括数据的网络传输、服务器并发处理能力、动态网页缓存、动态网页静态化、应用层数据缓存、分布式缓存、Web服务器缓存、反向代理缓存、脚本解释速度、页面组件分离、浏览器本地缓存、浏览器并发请求、文件的分发、数据库I/O优化、数据库访问、数据库分布式......一起来看看 《构建高性能Web站点》 这本书的介绍吧!