redis(三) 持久化机制

以后会每天更新 更新内容大多是分布式博客。

感觉不错的加我java群  群号是：369784068

1.redis持久化机制
    1.1 rdb持久化
          在指定的时间间隔内将内存中的数据集快照写入磁盘
 redis.conf文件中如下配置是rdb持久化
     save 900 1
              save 300 10
              save 60 10000    rdb 保存的dump.rdb文件


     rdb优势：只包含一个文件
                     灾难恢复是好的选择（单独的文件拷贝到别的存储)
     只fork出子进程，子进程完成持久化避免服务进程执行IO，能够达到性能最大化
     与aof相比，数据集大，启动效率高。
              rdb劣势:
                   数据可能丢失
   数据集较大,fork子进程可能会导致服务器停止几百毫秒，甚至1秒
    1.2 aof持久化
         以日志的形式来记录每个写操作，redis启动之初会读取该文件重新构建数据
 保证数据的完整性
   redis.conf文件中
     appendonly yes    (默认是no改成yes就打开了aof持久化）
           appendonly.aof文件
            aof优势:
          3种同步策略  每秒同步、每修改同步、不同步
           appendfsync always   同步持久化 每次发生数据变更会被立即记录到磁盘  性能较差
                   # appendfsync everysec    异步操作，每秒记录   如果一秒内宕机，有数据丢失
                   # appendfsync no   从不同步
  带来更高的数据安全


                   对日志文件的操作是append模式的，写入过程中即使宕机，也不会破坏日志文件
  已经存在的内容，如果写一半出现宕机，redis在下次启动之前，做一个redis-check-aof工作即可，使得数据一致


  rewrite机制。


  aof日志文件清晰、易懂
   aof劣势:相同数据集的数据而言aof文件要远大于rdb文件
               aof运行效率要慢于rdb,每秒同步策略效率较好，不同步效率和rdb相同


   1.3 无持久化
   1.4 同时使用rdb和aof方式


         如果只打开rdb,启动时通过rdb重建数据
如果只打开aof,启动时通过aof重建数据
如果既打开了rdb又打开了aof,通过aof重建数据
redis-cli -a pwd bgsave
redis-cli -a pwd bgrewriteaof
通过命令显示启动rdb记录       aof记录




2.redis 复制流程
    2.1 slaveof指令可以配置方式也可以是命令方式，slave端有定时器触发事件连接master,
     发送sync命令,阻塞等待master发送其内存快照（新版不用阻塞)
     2.2master端收到sync命令,判断是否有子进程做内存快照，有等待其完成，没有立即
     开始内存快照，快照完成后，将该文件发送给slave端
     2.3slave接收到内存快照，保存到本地.接收完，清空内存，重新读取发来的
         内存快照，重新建立整个内存数据
     2.4此时master如果有修改更新，暂时先发送到缓存队列，等slave快照完成后，依次
         再发给slave.
3.复制缺陷
      无增量复制概念，每次重新连接都要取master全部内存快照，并清空数据，重新内存数据


      redis集群需要主从复制，最好事先配置好所有的从库，避免中途再去增加从库


      redis持久化机制还不是特别成熟  Cache/Store


 4.在实际应用中redis复制机制、影响效率
     解决方案:自己完成增量同步的工作
             首先写redis 的aof文件,并对这个文件按文件的大小进行自动分割回滚。
    同时关闭redis的rewrite命令，然后会在业务低峰时间进行内存快照存储，
    并把当前的AOF文件位置一起写入到快照文件中，这样我们可以是快照文件
    和aof文件的位置保持一致性。这样我们就得到了系统某一时刻的内存快照，
    并且同时你也知道了这一时刻对应的AOF文件的位置，当从库发送同步命令
    的时候，首先会把快照文件发送给从库，然后从库会去取出快照文件存储
    的AOF文件位置，并将该位置发给主库，主库随后发送该位置之后的所有命令，
    以后的复制就都是这个位置之后的增量信息了。


    也有一些中间件，专门来解决这个问题。Twitter专门开发了一个用于复制
    和分区的中间件gizzard(主动复制避开redis复制缺陷)