2021.04.06 redis相关

1.redis持久化

1>持久化流程

 a) 客户端向服务器写数据
 b) 服务器再把数据写到内存中
 c) 服务端再调write这个系统调用，写入磁盘（内存缓冲区）
 d) 操作系统再把数据从内存缓存区写入磁盘控制器（磁盘缓存区）
 e）磁盘控制器把数据写入物理磁盘中

2>两种策略RDB和AOF

   <1>RDB（redis data base）是采用快照的方式将数据持久化，指定的时间间隔内，将内存中数据集快照写入磁盘中二进制文件中，默认文件格式为dump.rdb
   **主要有三种方法**
   a)save的方法，当调用save方法时，客户端将不能向服务器中写数据，redis采用RDB方式将数据以数据集快照方式写入，直到写入完成
   ![](http://img1.sycdn.imooc.com//606c708b0001471306400356.jpg)
   b) bgsave的方式，redis服务器fork()一个子进程，专门将数据以RDB的方式写入，阻塞只发生在for()阶段
   ![](http://img1.sycdn.imooc.com//606c71230001471306400356.jpg)
   c)自动化方式，可以在redis.conf配置文件中定义
   例如save m n 如果在m秒钟有n修改，则自动调用bgsave
   stop-writes-on-bgsave-error 默认为yes在redis发生问题时，不能再向redis写入数据
   ![](http://img1.sycdn.imooc.com//606c721e0001f4da06400277.jpg)
   **优缺点：**
      优点：rdb文件文件紧凑，全量，适合备份和容灾，恢复速度比AOF快
        生成rdb文件时候，会fork()子进程，主进程不需要做IO操作
      缺点：在持久化过程中，发生改变无法被记录，导致恢复数据缺失

      <2> AOF
        redis每次写操作，都将文件写入AOF文件中，但是为了防止AOF文件过大，有重写机制，利用bgrewriteaof，先将文件写入一个临时文件中，再fork()一个子进程来重写AOF
        三种方式
        每次修改同步always:每次修改都会写AOF文件，
        everyecs:异步操作
        no:从不同步
        **优缺点**
      
        优点

（1）AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据。（2）AOF日志文件没有任何磁盘寻址的开销，写入性能非常高，文件不容易破损。

（3）AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。

（4）AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据

缺点

（1）对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大

（2）AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的

（3）以前AOF发生过bug，就是通过AOF记录的日志，进行数据恢复的时候，没有恢复一模一样的数据出来