redis的持久化和缓存机制

摘自 https://blog.csdn.net/tr1912/article/details/70197085?foxhandler=RssReadRenderProcessHandlerredis

1、redis的适用环境sql


        首先做为一个nosql的key—value组成的数据库,它们能存储的数据结构必须是简单的,由于有关系的数据即便存储进去以后查询也是很困难的,而且对于海量的数据存储仍是关系型数据库比较合适。数据库

        举一个把通常数据库数据存储到key-value中的例子:缓存

student数据结构

学号app

姓名nosql

年龄函数

班级性能

001.net

小明

18

2

key

value

student:001:姓名

小明

student:001:年龄

18

student:001:班级

2


听从规则为        key  表名:主键值:列名
                            value  列值

 

若是加上表关系的话还要复杂好几倍的。

        那么什么样的数据适合存储在非关系型数据库中的呢?

        一、关系不是很密切的的数据,好比用户信息,班级信息,评论数量等等。

        二、量比较大的数据,如访问记录等

        三、访问比较频繁的数据,如用户信息,访问数量,最新微博等

 

2、持久化


        那么这么多,这么重要的数据都存储在内存中,若是忽然断电,岂不是很糟糕,因而就有了数据的持久化机制,这个其实就是把内存中的数据存储到硬盘中,方便数据的持续存在,也能够减小断电形成的损失。

        那么咱们怎么持久化数据呢?多长时间进行一次持久化呢?

redis 支持两种持久化方式,一种是 Snapshotting(快照)也是默认方式,另外一种是 Append-only file(缩写 aof)的方式。下面分别介绍:

     一)、Snapshotting

         快照是默认的持久化方式。这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb。能够经过配置设置自动作快照持久化的方式。咱们能够配置 redis在 n 秒内若是超过 m 个 key 被修改就自动作快照,下面是默认的快照保存配置:

save 900 1 #900 秒内若是超过 1 个 key 被修改,则发起快照保存
save 300 10 #300 秒内容如超过 10 个 key 被修改,则发起快照保存
save 60 10000

下面介绍详细的快照保存过程:

        1.redis 调用 fork,如今有了子进程和父进程。

        2. 父进程继续处理 client 请求,子进程负责将内存内容写入到临时文件。因为 os 的实时复制机制( copy on write)父子进程会共享相同的物理页面,当父进程处理写请求时 os 会为父进程要修改的页面建立副本,而不是写共享的页面。因此子进程地址空间内的数据是 fork时刻整个数据库的一个快照。

        3.当子进程将快照写入临时文件完毕后,用临时文件替换原来的快照文件,而后子进程退出。client 也可使用 save 或者 bgsave 命令通知 redis 作一次快照持久化。 save 操做是在主线程中保存快照的,因为 redis 是用一个主线程来处理全部 client 的请求,这种方式会阻塞全部client 请求。因此不推荐使用。另外一点须要注意的是,每次快照持久化都是将内存数据完整写入到磁盘一次,并非增量的只同步变动数据。若是数据量大的话,并且写操做比较多,必然会引发大量的磁盘 io 操做,可能会严重影响性能。

 

       二)、AOF方式

        因为快照方式是在必定间隔时间作一次的,因此若是 redis 意外 down 掉的话,就会丢失最后一次快照后的全部修改。若是应用要求不能丢失任何修改的话,能够采用 aof 持久化方式。下面介绍 Append-only file:aof 比快照方式有更好的持久化性,是因为在使用 aof 持久化方式时,redis 会将每个收到的写命令都经过 write 函数追加到文件中(默认是 appendonly.aof)。当 redis 重启时会经过从新执行文件中保存的写命令来在内存中重建整个数据库的内容。固然因为 os 会在内核中缓存 write 作的修改,因此可能不是当即写到磁盘上。这样 aof 方式的持久化也仍是有可能会丢失部分修改。不过咱们能够经过配置文件告诉 redis 咱们想要经过 fsync 函数强制 os 写入到磁盘的时机。有三种方式以下(默认是:每秒 fsync 一次)

 

appendonly yes //启用 aof 持久化方式# appendfsync always //收到写命令就当即写入磁盘,最慢,可是保证彻底的持久化appendfsync everysec //每秒钟写入磁盘一次,在性能和持久化方面作了很好的折中# appendfsync no //彻底依赖 os,性能最好,持久化没保证        aof 的方式也同时带来了另外一个问题。持久化文件会变的愈来愈大。例如咱们调用 incr test命令 100 次,文件中必须保存所有的 100 条命令,其实有 99 条都是多余的。由于要恢复数据库的状态其实文件中保存一条 set test 100 就够了。为了压缩 aof 的持久化文件。 redis 提供了 bgrewriteaof 命令。收到此命令 redis 将使用与快照相似的方式将内存中的数据以命令的方式保存到临时文件中,最后替换原来的文件。--------------------- 做者:王啸tr1912 来源:CSDN 原文:https://blog.csdn.net/tr1912/article/details/70197085 版权声明:本文为博主原创文章,转载请附上博文连接!

相关文章
相关标签/搜索