本文共 8359 字，大约阅读时间需要 27 分钟。

一：Redis持久化

1. redis持久化的意义？
      redis持久化的意义在于故障恢复。比如我们在生产环境中部署了redis,在redis中存储了一些较为重要的数据，
      把redis作为缓存数据库，如果我们没有对redis中的数据进行持久化的话，那么机器一旦出现灾难性的故障，
      就会丢失所有的数据。如果我们能够将数据持久化到磁盘上，并且定期同步一份备份数据到云服务上，就可以
      保证数据不会全部丢失，可以恢复大部分数据。
2. redis的RDB和AOF两种持久化机制介绍
    1)：RDB持久化机制
               RDB持久化机制，其实就是对redis中的数据进行周期性的持久化。
               比如：
                   现在是10点整，在redis中存在1000条数据，redis会生成一份RDB快照的文件存放到磁盘上，那么这个RDB文件中存有                     1000条数据。到10点零5分的时候，redis中存在1500条数据，这时候redis就会又生成一个RDB文件写到磁盘上，这个新的                 文件中存放1500条数据。
               总结：
                   RDB持久化机制就是在一定的间隔时间内生成一份redis内存中数据的完整快照。
      2)：AOF持久化机制
                AOF机制对每条写入命令作为日志，以append-only的模式写入一个日志文件中，在redis重启的时候，
               可以通过回放AOF日志中的写入指令来重新构建整个数据集。
               流程讲解：
                   当我们通过指令操作redis时，redis会每秒都将指令写入AOF文件中，当然redis中的数据是有一定限量的，
                   redis内存中的数据不可能一直无限增长，进而导致AOF文件无限增长。redis中内存的大小是一定的，到了
                   一定的时间,redis就会用缓存淘汰算法LRU，自动将一部分数据从缓存中给清除。当然AOF文件
                   是用来存放每条操作指令的，所以会一直不断的膨胀，当大到一定的时候,AOF会做rewriter操作，
                   AOF的rewriter操作，就会基于当时redis内存中的数据，来重新构造一个更小的AOF文件，然后将就得AOF文件删除。
                  如果我们想要redis仅仅作为纯内存的缓存来用，那么可以禁止RDB和AOF所有的持久化机制。
                 通过RDB或AOF，都可以将redis内存中的数据给持久化到磁盘上面来，然后可以将这些数据备份到别的地方去，
                比如说阿里云，云服务， 如果redis挂了，服务器上的内存和磁盘上的数据都丢了，可以从云服务上拷贝回来之前的数据，
                放到指定的目录中，然后重新启动redis，redis就会自动根据持久化数据文件中的数据，去恢复内存中的数据，
               继续对外提供服务如果同时使用RDB和AOF两种持久化机制，那么在redis重启的时候，会使用AOF来重新构建数据
           ，因为AOF中的数据更加完整，redis会每秒都将指令写入AOF文件中.
3. RDB持久化机制的优点
     a：RDB会生成多个数据文件，每个数据文件都代表了某一个时刻中redis的数据，这种多个数据文件的方式，
          非常适合做冷备，可以将这种完整的数据文件发送到一些远程的安全存储上去。            
          当然AOF也可以做冷备，只有一个文件，但是你可以，每隔一定时间，去copy一份这个文件出来。
     b：RDB对redis对外提供的读写服务，影响非常小，可以让redis保持高性能，因为redis主进程只需要fork一个子进程，
          让子进程执行磁盘IO操作来进行RDB持久化即可。
          RDB，每次写，都是直接写redis内存，只是在一定的时候，才会将数据写入磁盘中
          AOF，每次都是要写文件的，虽然可以快速写入os cache中，但是还是有一定的时间开销的,速度肯定比RDB略慢一些。
     c：相对于AOF持久化机制来说，直接基于RDB数据文件来重启和恢复redis进程，更加快速
           AOF，存放的指令日志，做数据恢复的时候，其实是要回放和执行所有的指令日志，来恢复出来内存中的所有数据的。
           RDB，就是一份数据文件，恢复的时候，直接加载到内存中即可    
     结合上述优点，RDB特别适合做冷备份，冷备    
4.  RDB持久化机制的缺点
     1）如果想要在redis故障时，尽可能少的丢失数据，那么RDB没有AOF好。一般来说，RDB数据快照文件，
          都是每隔5分钟，或者更长时间生成一次，这个时候就得接受一旦redis进程宕机，那么会丢失最近5分钟的数据。
          这个问题，也是rdb最大的缺点，就是不适合做第一优先的恢复方案，如果你依赖RDB做第一优先恢复方案，
          会导致数据丢失的比较多
   （2）RDB每次在fork子进程来执行RDB快照数据文件生成的时候，如果数据文件特别大，
           可能会导致对客户端提供的服务暂停数毫秒，或者甚至数秒。
          一般不要让RDB的间隔太长，否则每次生成的RDB文件太大了，对redis本身的性能可能会有影响的    
5.  AOF持久化机制的优点
     （1）AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，
              最多丢失1秒钟的数据每隔1秒，就执行一次fsync操作，保证os cache中的数据写入磁盘中，
              redis进程挂了，最多丢掉1秒钟的数据
   （2）AOF日志文件以append-only模式写入，所以没有任何磁盘寻址的开销，写入性能非常高，
             而且文件不容易破损，即使文件尾部破损，也很容易修复
   （3）AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。因为在rewrite log的时候，
            会对其中的指令进行压缩，创建出一份需要恢复数据的最小日志出来。
           再创建新日志文件的时候，老的日志文件还是照常写入。当新的merge后的日志文件ready的时候，再交换新老日志文件即可。
   （4）AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。
             比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，
             将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据
6. AOF持久化机制的缺点
     1）对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大
   （2）AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，
            当然，每秒一次fsync，性能也还是很高的
          如果你要保证一条数据都不丢，也是可以的，AOF的fsync设置成没写入一条数据，fsync一次，那就完蛋了，redis的QPS大降
   （3）以前AOF发生过bug，就是通过AOF记录的日志，进行数据恢复的时候，没有恢复一模一样的数据出来。
            所以说，类似AOF这种较为复杂的基于命令日志/merge/回放的方式, 比基于RDB每次持久化一份完整的数据快照文件的方式，           更加脆弱一些，容易有bug。不过AOF就是为了避免rewrite过程导致的bug，因此每次rewrite并不是基于旧的指令日志进行                  merge的，而是基于当时内存中的数据进行指令的重新构建，这样健壮性会好很多。
   （4）唯一的比较大的缺点，其实就是做数据恢复的时候，会比较慢，还有做冷备，定期的备份，不太方便，
           可能要自己手写复杂的脚本去做，做冷备不太合适

二：如何配置RDB持久化机制 

     redis.conf文件，也就是/etc/redis/6379.conf，去配置持久化

     save 60 1000      每隔60s，如果有超过1000个key发生了变更，那么就生成一个新的dump.rdb文件，就是当前redis内存中完整的数据快照，      这个操作也   被称之为snapshotting，快照也可以手动调用save或者bgsave命令，同步或异步执行rdb快照生成save可以设置多个，      就是多个snapshotting检查点，每到一个检查点，就会去check一下，是否有指定的key数量发生了变更，如果有，     就生成一个新的dump.rdb文件。

三：AOF持久化的配置

AOF持久化，默认是关闭的，默认是打开RDB持久化

appendonly yes，可以打开AOF持久化机制，在生产环境里面，一般来说AOF都是要打开的，除非你说随便丢个几分钟的数据也无所谓。

打开AOF持久化机制之后，redis每次接收到一条写命令，就会写入日志文件中，当然是先写入os cache的，然后每隔一定时间再fsync一下

而且即使AOF和RDB都开启了，redis重启的时候，也是优先通过AOF进行数据恢复的，因为aof数据比较完整。

可以配置AOF的fsync策略，有三种策略可以选择，一种是每次写入一条数据就执行一次fsync; 一种是每隔一秒执行一次fsync; 一种是不主动执行fsync。

always: 每次写入一条数据，立即将这个数据对应的写日志fsync到磁盘上去，性能非常非常差，吞吐量很低; 确保说redis里的数据一条都不丢，那就只能这样了。

mysql -> 内存策略，大量磁盘，QPS到多少，一两k。

QPS，每秒钟的请求数量 redis -> 内存，磁盘持久化，QPS到多少，单机，一般来说，上万QPS没问题

everysec: 每秒将os cache中的数据fsync到磁盘，这个最常用的，生产环境一般都这么配置，性能很高，QPS还是可以上万的

no: 仅仅redis负责将数据写入os cache就撒手不管了，然后后面os自己会时不时有自己的策略将数据刷入磁盘，不可控了

四：AOF rewrite

redis中的数据其实有限的，很多数据可能会自动过期，可能会被用户删除，可能会被redis用缓存清除的算法清理掉

redis中的数据会不断淘汰掉旧的，就一部分常用的数据会被自动保留在redis内存中

所以可能很多之前的已经被清理掉的数据，对应的写日志还停留在AOF中，AOF日志文件就一个，会不断的膨胀，到很大很大

所以AOF会自动在后台每隔一定时间做rewrite操作，比如日志里已经存放了针对100w数据的写日志了; redis内存只剩下10万; 基于内存中当前的10万数据构建一套最新的日志，到AOF中; 覆盖之前的老日志; 确保AOF日志文件不会过大，保持跟redis内存数据量一致

redis 2.4之前，还需要手动，开发一些脚本，crontab，通过BGREWRITEAOF命令去执行AOF rewrite，但是redis 2.4之后，会自动进行rewrite操作

在redis.conf中，可以配置rewrite策略

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64mb

比如说上一次AOF rewrite之后，是128mb

然后就会接着128mb继续写AOF的日志，如果发现增长的比例，超过了之前的100%，256mb，就可能会去触发一次rewrite

但是此时还要去跟min-size，64mb去比较，256mb > 64mb，才会去触发rewrite

五：AOF破损文件的修复

如果redis在append数据到AOF文件时，机器宕机了，可能会导致AOF文件破损

用redis-check-aof --fix命令来修复破损的AOF文件

六：企业级的持久化的配置策略

1. 在企业中，RDB的生成策略，用默认的也差不多，RDB是Redis默认的持久化配置策略，一般我们会将AOF和RDB都打开，
   RDB作为冷备是非常合适的，一旦生成文件就不会再修改，AOF主要是避免丢失大量的数据，每秒同步一次写入命令。         
2. RDB三个配置如下：
   a：save 900 1
           900秒，也就是15分钟只要有一个key发生变化，就生成一个rdb文件，正好合适。
   b：save 300 10
           300秒，也就是5分钟，只要有10个key发生变化，就生成一个rdb文件，刚好合适。
   c：save 60 10000
            60秒，也就是1分钟10000个key发生变化，生成一个rdb文件，这个我们就要根据当前应用系统
         的数据量来决定了，如果我们的数据量不大，我们可以修改为1000个，甚至是100个，这个需要看情况而定。
3. AOF配置，这个
    a：appendfsync always
          每次写入一条数据，立即将这个数据对应的写日志fsync到磁盘上去，性能非常非常差，吞吐量很低。一般企业中都不打开
    b：appendfsync everysec
           每秒将os cache中的数据fsync到磁盘，这个最常用的，生产环境一般都这么配置，性能很高。
    c：appendfsync no
            仅仅redis负责将数据写入os cache就撒手不管了，然后后面os自己会时不时有自己的策略将数据刷入磁盘，不可控了，
            一般企业中都不打开。

七：企业级的数据备份方案

1.   一般我们会写crontab定时调度脚本去做数据备份，一般分为3个层次，如下
    a：小时级别的
            每小时都copy一份rdb的备份，到一个目录中去，仅仅保留最近48小时的备份，旧的定时删除
    b：日级别的
            每天都保留一份当日小时级别的rdb的备份，到一个目录中去，仅仅保留最近1个月的备份，旧的定时删除
    c：云服务级别的
            每天晚上将当前服务器上所有的数据备份，发送一份到远程的云服务上去
2. 小时级别的备份脚本操作，脚本目录为/usr/local/redis/copy_shell，名称redis_rdb_copy_hourly.sh
    

   #!/bin/sh#获取日期到小时级别的时间cur_date=`date +%Y%m%d%k`#防止该时间级的文件夹已经存在，先删除再创建rm -rf /usr/local/redis/snapshotting/$cur_datemkdir /usr/local/redis/snapshotting/$cur_date#将redis当前的rdb文件备份过来cp /var/redis/6379/dump.rdb /usr/local/redis/snapshotting/$cur_date#删除两天前的备份数据文件夹del_date=`date -d -48hour +%Y%m%d%k`rm -rf /usr/local/redis/snapshotting/$del_date

    

    下面创建crontab：
     命令：crontab -e
     
    内容：
     #表示每月，每周，每天，每小时，0分执行这个脚本
     0 * * * * sh /usr/local/redis/copy_shell/redis_rdb_copy_daily.sh
    测试：我们在/usr/local/redis/snapshotting/目录下手动创建一个两天前的文件，再手动执行redis_rdb_copy_daily.sh脚本
    
    执行后结果：
    

3. 每天一次的和上面小时的类似，修改一下脚本即可。        

八：数据恢复方案

1. 如果是redis进程挂掉，那么重启redis进程即可，直接基于AOF日志文件恢复数据。
    fsync everysec策略，最多就丢一秒的数
2. 如果是redis进程所在机器挂掉，那么重启机器后，尝试重启redis进程，尝试直接基于AOF日志文件进行数据恢复。
   AOF没有破损，也是可以直接基于AOF恢复的，因为AOF append-only，顺序写入，如果AOF文件破损，
   那么用redis-check-aof fix命令修复AOF文件即可。 
3. 如果redis当前最新的AOF和RDB文件出现了丢失/损坏，那么可以尝试基于该机器上当前的某个最新的RDB数据副本
   进行数据恢复。当前最新的AOF和RDB文件都出现了丢失/损坏到无法恢复，一般不是机器的故障，可能人为的。 
   注意：当我们的redis数据是基于备份的RDB文件恢复的时候，我们必须要先将redis中的aof配置给关闭，否则它
              会基于aof文件去恢复数据，就算是我们将aof文件删除，redis还是会自动生成aof文件，然后基于这个新的aof
              文件去恢复数据，而不会去基于rdb文件恢复数据，因为当rdb和aof两种模式都打开的情况下redis优先aof恢复数据。
   正确的操作：
          停止redis，关闭aof，拷贝rdb备份，重启redis，确认数据恢复，直接在命令行热修改redis配置，打开aof，
          这个redis就会将内存中的数据对应的日志，写入aof文件中，此时aof和rdb两份数据文件的数据就同步了。
          redis config set热修改配置参数，可能配置文件中的实际的参数没有被持久化的修改，再次停止redis，
          手动修改配置文件，打开aof的命令，再次重启redis 。       

九：如果redis要支撑超过10万+的并发，那应该怎么做？

1.  单机的redis并发
    单机的redis几乎不太可能说QPS超过10万+，除非一些特殊情况，比如你的机器性能特别好，配置特别高，
    物理机，维护做的特别好，而且你的整体的操作不是太复杂。单机redis并发量一般在上万到几万。
2.  redis集群支撑高并发
    一般我们redis集群会使用主从架构去实现高并发，采用读写分离，读写分离，一般来说，对缓存，
    一般都是用来支撑读高并发的，写的请求是比较少的，可能写请求也就一秒钟几千，一两千 ，
   大量的请求都是读，一秒钟二十万次读 。主从架构一般是一主多从，主节点负责写数据，并且将数据
    同步复制到其它的从节点上，从节点都负责读操作，所有的读请求都走从节点。 而且我们可以水平
    扩容，要提高并发量，多加几台redis的从节点即可。 
    

十：主从架构的核心原理

1. 简介
     比如目前我们存在一个master node节点启动着，那么现在我们加一个slave node节点，当这个slave node
     节点第一次刚启动的时候它会发送一个Ping命令给master node，那么master node会将自己全量的数据都
     复制拷贝给这个slave node节点。如果后面slave node挂掉了，最后重新连接master node，那么master node
     仅仅会复制给slave部分缺少的数据。也就是说如果是slave node第一次连接master node，那么会触发一次
     full resynchronization(全量数据同步)。
     
2. full resynchronization(全量数据同步)
     full resynchronization的时候，master会启动一个后台线程，开始生成一份RDB快照文件，同时还会将从客户
     端收到的所有写命令缓存在内存中。RDB文件生成完毕之后，master会将这个RDB发送给slave，slave会先写
    入本地磁盘，然后再从本地磁盘加载到内存中。然后master会将内存中缓存的写命令发送给slave，slave也会同
    步这些数据。       
    slave node如果跟master node有网络故障，断开了连接，会自动重连。master如果发现有多个slave node都来重新连接，
    仅仅会启动一个rdb save操作，用一份数据服务所有slave node。
    注意：master node将rdb快照文件发送给salve node，如果rdb复制时间超过60秒（repl-timeout），
                那么slave node就会认为复制失败，可以适当调节大这个参数，对于千兆网卡的机器，一般每秒传输100MB，
                6G文件，很可能超过60s
3. 主从复制的断点续传
     从redis 2.8开始，就支持主从复制的断点续传，如果主从复制过程中，网络连接断掉了，那么可以接着上次复制的地方，
     继续复制下去，而不是从头开始复制一份。master node会在内存中常见一个backlog，master和slave都会保存一个
     replica offset还有一个master id，offset就是保存在backlog中的。如果master和slave网络连接断掉了，slave会让master
     从上次的replica offset开始继续复制。但是如果没有找到对应的offset，那么就会执行一次resynchronization。
4. 无磁盘化复制
     master在内存中直接创建rdb，然后发送给slave，不会在自己本地落地磁盘了。
5. 过期key处理
     slave不会过期key，只会等待master过期key。如果master过期了一个key，或者通过LRU淘汰了一个key，
     那么会模拟一条del命令发送给slave。