您的位置:首页 > 数据库 > Redis

redis 持久化

2018-04-23 17:56 197 查看

一、mysql和redis对比

内存(兔子):高效、运行速度快,断电后数据会丢失

硬盘(乌龟):读写速度慢于内存,数据断电后依旧存在

持久化:把数据 保存在硬盘上

  • 关系型数据库mysql持久化

  1.      任何增删改查语句,都是在硬盘上做的操作
  2.      断电以后,硬盘上的数据依旧存在
  3.       mysql要求的是安全,一方面有事务,一方面把数据保存在硬盘上

  • 非关系型数据库redis:

  1.     默认情况下,所有的增删改,数据都是在内存中进行操作
  2.     断电以后,内存中的数据是不存在的
  3.    断电以后,redis的部分数据会丢失,丢失的数据是保存在内存中的数据

但是我们关闭redis,在去打开,我们之前存的key value依旧存在,也就是  

Redis存在持久化操作。

二、Redis的两种持久化策略

1.RDB:  RDB是redis的默认持久化机制


图中的.rdb文件就是数据的持久化文件

RDB相当于照快照。保存的是一种状态

如果源数据有20G,那么照快照后可能只有几kb

20G---→几kb

【优点】

          1)快照保存数据速度极快,数据还原速度极快

          2)适用于灾难备份

        假设机房中有一台redis服务器,机房失火了,那么你赶紧拿起u盘去备份rdb文件,因为这个文件很小,备份速度很快。这个rdb数据可以很快恢复

【缺点】:

     1)符合要求就会照快照

  •     服务器正常关闭时照快照
  •     key满足一定条件照快照

        也就是RDB可能随时随地都会启动,这可能会占用你的一部分系统资源(突然的占用)。虽然生成的rdb文件不大,但是照快照的一瞬间需要将20g的资源复制压缩,备份,运算,最后生成---→.rdb文件,生成后才会把复制的20g资源释放

    2)小内存机子不适用

如果你的内存只有4g,你的数据有3个g,RDB进行复制备份时,内存不够了,那就很容易宕机,宕机后服务器关掉,这样关闭是非正常关闭,现在数据全在内存中,这样关闭后硬盘上啥数据都没有,3g数据就凭空消失了 .....

    所以RDB机制适用于内存比较充裕的计算机

【知识点】RDB何时进行照快照?

          1.服务器正常关闭时照快照 ./bin/redis-cli shutdown 

    (但是不能一直依赖于服务器关闭去照快照,因为正常生产上服务器是很少关闭的)

          2.key满足一定条件照快照 (此时需要去看Redis.conf文件,在此文件中:/save 900 1进行查找)


只有key满足这三个条件之一,才会照快照        


    1)例如 现在12点--12点15,有1个key发生变化(发生变化指的是key的添加,修改或删除),在12点15就照一次快照

         例如  现在12点--12点15,没有任何key发生变化,就不会照快照

   2)例如  现在12点--12点05,有11个key发生变化,12点05就会照一次快照

               现在12点--12点05,有9个key发生变化,那么12点05就不会照快照

                但是在12点15时会照快照

   3)12点-12点01,有15000个key发生变化,12点01会照一次快照

     12点-12点01,有1000个key发生变化,12点01不会照快照,12点05会进行照快照


    tips:  这个配置是计算出来最优的结果,建议不要随意更改

2.AOF: 使用日志功能保存数据操作 适用于内存比较小的计算机

默认:aof机制是关闭的,redis中提供了3种同步策略,每秒同步、每修改同步和不同步

  •     每秒同步(默认):每秒进行一次aof保存数据                                                             安全性低,比较节省系统资源
  •     每修改同步:只要有key变化语句,就进行AOF保存数据(key的变化指key的添加修改删除)   比较安全,但是极为浪费效率。
  •     不同步:不进行任何持久化操作                                                                        不安全

    

AOF操作只会保存导致key变化的语句

如下四句话中,不会保存第二句



AOF的逻辑是: 正是这些语句导致key变化,我把这些语句都记下来,将来服务器启动的时候,我再把这些语句重新执行一遍,就得到一样的数据了

如何开启AOF?

【开启AOF】在 Redis.conf中找到 aof

:/aof


将此处改为yes,AOF便开启了


上图画的为日志文件名

接着下拉,可以看到默认appendfsync everysec没有备注掉,所以每秒同步是默认的AOF机制


实际应用建议appendfsnc always 没修改同步

修改后将配置文件保存 :wq

然后需要重新加载配置文件

所以重启相关服务器 先关闭 ./bin/redis-cli shutdown

重启后ll看一下文件,文件里有dump.rdb

为了测试AOF机制,我们将.rdb文件删除  rm -rf dump.rdb

 

然后开启redis

./bin/redis-server ./redis.conf

进入客户端

./bin/redis-cli 


可以看到因为把rdb文件删了,所以数据库里没有数据。我们执行了几个set语句

然后将服务停掉 ./bin/redis-cli shutdown

ll 可以看到


多了.aof文件

cat appendonly.aof

内容如下


默认 select 0

然后 set username zhangsan 

然后 set password 123

【AOF配置】

  always  每次有数据修改时都会写入AOF文件

  everysec(默认) 每秒钟同步一次,该策略为AOF的缺省策略

   no  从不同步。高效但是数据不会持久化

 

【AOF优点】

    持续性占用极少量的内存资源,

只要开启AOF后,就会有一个专门的AOF日志程序运行,这个日志程序只会占用几kb的内存资源。它会持续的运行,而且只是记一个语句到硬盘上

【缺点】:

    1)aof生成的日志文件特别大,不适用于灾难恢复。(因为日志文件大,拷贝和恢复都需要更多时间)

    2)恢复效率远低于RDB

    拿set username 为例

    比如 set username hheh

            set username haha

           set username zhangsan

           set username lisi

    最终的结果为lisi,但是却要记录上面的三个语句,这样就使日志文件较大



阅读更多
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: