Redis(3).持久化操作

一、Redis配置文件解析

INCLUDES 包含

• 作用：类似于Struct2 配置文件，可以通过 INCLUDES来包含其它配置文件，redis.conf 可以作为总闸。
  
  

GENERAL 通用

• Daemonize：是否作为守护线程运行，如果开启则开机自启
• Pidfile： 进程管道pid文件
• Port：redis运行的端口
• Tcp-backlog：backlog其实是一个连接队列，用来避免慢客户端连接问题。
  
• Timeout：在多长的空闲时间后会关闭连接，默认值为0，表示不关闭
• Bind： 绑定的ip地址
• Tcp-Keepalive：用于定时检测连接是否正常，单位为秒，如果设置为0，则不会进行Keepalive检测，建议设置为60
• Loglevel：日志级别，redis默认有4种日志级别 debug、verbose、notice、warning，日志级别由低到高主键上升。
  
• logfile：日志保存的路径；默认为标准输出，如果Redis设置为守护进程方式运行，而这里又配置为标准输出，则日志会发送给 /dev/null
• sys-log-enabled： 是否允许记录系统日志
• databases：redis含有的数据库，使用select xxx 来切换数据库

SECURITY

命令行语句：
config get dir   //获取当前的工作目录
conifg  get requirepass   //获取登录密码
config  set  requirepass    //设置登录密码
auth   密码           //使用密码登录 

配置文件中：
requirepass  xxxxx    //设置登录密码

LIMITS 限制

• Maxclients：同一时间最大的用户连接数量，默认1
• Maxmemory：最大的缓存空间
• Maxmemory-samples ：设置样本数量，LRU算法和最小TTL算法都不是精确的算法，而是估算值。redis默认会检查这么多个key并选择其中LRU的那个。
• Maxmemory-policy：清除缓存策略(当数据库存储的数据过多时)
  

Volatile-lru ：最近最少算法移除key，只对设置了过期时间的键
Allkeys-lru ：最近最少使用算法移除key
Volatile-lfu ：使用频率最少算法移除key，只对设置了过期时间的键
Allkeys-lfu ：使用频率最少使用算法移除key
Volatile-random ：在过期集合中随机移除key，只对设置了过期时间的
Allkeys-random ：随机移除的key
Volatile-ttl ：移除最近将要过期的(TTL最小的)
Noeviction：永不移除（实际不会使用）

常用配置redis.conf 说明：

二、Redis持久化— RDB方式

2.1 RDB(Redis DataBase):

• 概念：在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是Snapshot快照，他恢复时是将快照文件直接读入到内存里。

• 执行特点：Redis会单独创建(fork) 一个子进程来进行持久化，会先将数据写入到一个临时文件中(dump.rdb)，等到持久化操作结束后再用这个临时文件去替换上次持久化好的文件。整个过程中主进程是不进行任何IO操作的，这就确保了极高的性能，如果需要进行大规模的数据恢复，且对于数据的完整性要求不高，那么RDB方式要比AOF方式更加的高效，缺点是最后一次持久化后的数据可能会丢失。

• Fork：作用是复制一个与当前进程一样的进程。新进程的所有数据等和原进程一样，但是是一个全新的进程，并作为原进程的子进程。

• dump.rdb的恢复策略：

1. 在操作满足对应持久化触发条件或者关闭Redis服务时，都会将内存数据写入磁盘(dump.rdb文件)，最后替换上一次的持久化好的文件。 注意当关闭redis时会最后进行一次RDB持久化操作
2. 最好的策略是主机和备份机分为2台机器，这样可以保障数据的安全，采用冷拷贝后重新使用的方式[cp dump.rdb dump_new rdb]
3. save和bgsave都是主动对数据进行备份。 Save时只管保存，其它不管，全部阻塞；BGSAVE时Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。可以通过lastsave命令获取最后一次成功执行快照的时间。
4. Redis适合于大规模数据的恢复，对于数据一致性要求不高；
5. Fork的时候，内存中数据被克隆了一份，大致2被的膨胀性需要考虑；

2.2 配置文件解读 (SNAPSHOTTING) 快照：

• dir：指定本地数据库的存放目录

• save //触发持久化的条件
  
  

• Stop-writes-on-bgsave-error：出现异常后立刻停止存储数据。如果配置成no，表示你不在乎数据不一致或者有其它的手段发现和控制。

• rdbcompression xxx ：对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果的话，redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭次功能。

• rdbchecksum：在存储快照后，还可以让redis使用CRC64算法来进行数据校验。

• dbfilename： RDB持久化后生成的持久化文件名

• rdb文件异常恢复操作： Redis-check-rdb --fix rdb文件名

• dir：指定本地数据库存放的目录

2.3 save指令、bgsave指令、save配置：

• save指令工作原理：
  
  当同时有多个客户端向服务器发送请求时，由于Redis是单线程的，因此不同指令到达Redis内部是有一个执行顺序的，假设如下。
  
  save指令的执行会阻塞当前的Redis服务器，直到当前RDB过程完成为止，有可能会造成长时间阻塞，线上环境不建议使用。

  
  

• bgsave指令工作原理：
  
  对于客户端发送的请求，服务器端不直接进行处理，而是通过Linux的fork函数来生成一个子进程来创建rdb文件同时返回消息。
  bgsave命令是针对save阻塞问题做的优化。Redis内部所涉及到的RDB操作都采用bgsave方式，save命令可以放弃使用。

  
  

• save配置：
  
  save配置后台其实走的还是 bgsave指令的方式。

• 三种方式对比比较：
  

2.4 RDB总结：

（1）RDB优点：

• RDB是一个紧凑压缩的二进制文件，存储效率较高；
• RDB内部存储的是redis在某个时间点的数据快照(全部数据)，非常适合用于数据备份，全量复制等场景；
• RDB恢复数据的速度比AOF快很多；
• 应用：服务器中每X小时执行bgsave备份，并将RDB 文件拷贝到远程机器中，用于灾难恢复；

  （2）RDB缺点：

• RDB方式无论是执行指令还是利用配置，无法做到实时持久化，具有较大可能性丢失数据；
• bgsave指令每次运行要执行fork操作创建子进程，要牺牲掉一些性能；
• Redis的众多版本中未进行RDB文件格式的版本统一，有可能出现各版本服务之间数据格式无法兼容现象；

三、Redis持久化— AOF方式

鉴于RDB方式的弊端如下：

• 存储数据量较大，效率较低：基于快照思想，每次读写都是全部数据，当数据量巨大时，效率非常低；
• 大数据量下IO性能较低；
• 基于fork创建子进程，内存产生额外消耗；
• 宕机带来的数据丢失风险；

解决思路：

• 不写全部数据，仅记录部分数据；
• 改记录数据为记录操作过程；
• 对所有操作均进行记录，排除丢失数据的风险；

  3.1 AOF(Append Only File):

• 概念：以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件内容将所有写指令从前到后执行一次来完成数据的恢复操作。
• 执行特点：

1. 当AOF和RDB两种持久化方式都存在时优先执行AOF持久化方式，恢复数据也是一样的。
2. AOF会记录所有的写操作，这也包括FLUSHDB、FLUSHALL等操作。
3. redis-check-aof --fix xxxx.aof 命令会对xxxx.aof文件进行修复操作。
4. AOF和RDB两种持久化操作可以同时执行，没有问题。

• Fork：作用是复制一个与当前进程一样的进程。新进程的所有数据等和原进程一样，但是是一个全新的进程，并作为原进程的子进程。
• AOF 写数据的三种策略：
  

3.2 配置文件解读 (APPEND ONLY MODE) ：

• appendonly ： 是否开启AOF持久化
• appendfilename ： 持久化后的文件名
• Appendsync ：持久化的频率，包括 Always：同步持久化，每次发生数据变更会立刻被记录到磁盘上，性能较差但是数据完整性较好；Everysec：出厂默认推荐，异步操作，每秒记录，如果一秒宕机有数据丢失。no：不同步，性能最好，但是持久化没有保证。
  
• AOF异常恢复命令： Redis-check-aof --fix aof文件名
• Rewrite：命令：redis-cli -h ip -p port bgrewriteaof AOF采用文件追加方式，文件会越来越大为了避免此种情况，新增了重写机制，在当前的快照保存工作结束后，fork一个子进程，将AOF文件进行重写，合并set命令等操作到一个临时文件，达到缩小文件大小的目的。重写结束后后将临时文件替换为新的AOF文件（重写过程中如果有新的redis操作命令，会提交到缓存中，重写结束后追加到AOF文件内）。
• Rewrite触发机制：Redis会记录上一次重写的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。
  
• auto-aof-rewrite-pericentage xxx：当目前的AOF文件大小超过上一次重写文件大小的百分之几时进行重写，如果没有重启过，则以启动时的AOF文件大小为依据
• auto-aof-rewrite-min-size ：允许重写的最小AOF文件大小
• No-appendsync-on-rewrite ：重写时是否可以运用 Appendsync，用默认no即可。保证数据的完整性。

3.3 AOF重写：

• AOF重写的作用及介绍：
  

• AOF重写的规则：
  

• AOF的重写方式：
  手动重写 ———————— bgrewriteaof
  自动重写 ———————— auto-aof-rewrite-min-size size
auto-aof-rewrite-percentage percentage

• AOF手动重写原理：

  当输入bgrewriteaof指令时会直接触发AOF重写
  

• AOF自动重写原理：

  自动重写需要满足两个触发条件之一
  

• AOF重写流程：
  
  

1. always是直接fork一个子进程进行aof文件的写入；
2. everysec 在 always的基础上使用了aof缓存区，使用fork出一个子进程将数据缓存到aof缓存区然后对于满足条件的数据写入到aof文件；
3. everysec开启重写操作后会同时将数据缓存到 aof缓存区和aof重写缓存区，如果此时执行了 bgrewriteaof则会从该重写缓存区中拿数据然后fork出子进程进行重写。
4. 如果是通过配置激活aof重写，那么bgrewriteaof指令的执行是通过配置的方式触发而不是手动触发的。

3.4 AOF总结：

四、AOF与RDB性能建议：

参考：https://blog.csdn.net/weixin_42683679/article/details/81092985