2.6_9 Redis持久化（rdb、aof）

相关链接

• Excel目录
• redis官网
• redis中文网

---

1. Redis持久化

  Redis 是内存数据库，如果不将内存中的数据保存到磁盘，那么一旦服务器进程退出，服务器中的数据也会消失。所以Redis提供了持久化的功能。

扩展：
  1) Redis持久化一般只用rdb方式（可以将rdb视作主从切换中的备机），aof方式基本不用
  2) 如果只做缓存，只需要在程序运行时数据存在，是不需要持久化的。
  3) 同时开启两种持久化，redis重启的时候会优先载入AOF文件来恢复原始数据，因为在通常情况下，AOF文件保存的数据集要比RDB更完整
  4) 开启AOF时也不要关闭RBD，因为RDB更适合做数据库备份和快速重启（AOF在不断变化不好备份），而且aof文件可能会有潜在BUG，导致数据丢失。
  5) 性能建议
   5.1 RDB文件只用作后备，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留 save 900 1 这条规则
   5.2 如果开启AOF，好处是最差的情况下也只会丢失不超过1秒的数据，启动脚本简单，只load自己的aof就可以了。代价是来带了持续的IO，和 AOF rewrite 过程中产生的新数据写到新文件造成的阻塞问题。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上，默认超过原大小100%大小重写可以改到适当的数值。
   5.3 如果关闭AOF，紧靠 Master-Slave Repllcation 实现高可用性也可以，能节省一大笔IO，也减少了 rewrite时带来的系统波动。代价是如果 Master/Slave 同时宕机，会丢失十几分钟的数据，启动脚本也要比较两个 Master/Slave 中的 RDB文件，载入较新的那个文件，微博目前采用的就是此种模式。

---

1.1 RDB (Redis Database)

1.8 SNAPSHOTTING 快照⭐️ => Redis.conf 配置文件
 
1) save：持久化（在规定的时间内，执行了多少次操作，则会持久化到文件.rdb .aof），redis是内存数据库，如果没有持久化，那么数据断电即丢失。规则解释：

# 三个条件，触发任意一个条件都会执行一次持久化动作

# 如果900秒内，至少有1个 key 进行了修改，就进行持久化操作
save 900 1
# 如果300秒内，至少有10个 key 进行了修改，就进行持久化操作
save 300 10
# 如果60秒内，至少有10000个 key 进行了修改，就进行持久化操作
save 60 10000

2) stop-writes-on-bgsave-error：持久化如果出现错误，是否还需要继续工作。默认 yes。一般情况下也都是yes。>
3) rdbcompression：是否压缩rdb持久化文件，需要消耗一些CPU资源。默认 yes。如果对资源要求较高，可以关闭此配置，用空间换时间。
4) rdbchecksum：是否校验rbd文件，开启后会自动修复错误的rdb文件。默认 yes。
5) dbfilename：持久化(rdb方式)的文件名。默认 dump.rdb。
6) dir：rdb文件的保存目录。默认 ./。

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

  Reids会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，在用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的。这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加高效。RDB的缺点是最后一次持久化后（到下一次持久化触发之前）的数据可能丢失。Redis默认就是RDB模式，一般情况下不需要修改这个配置。

优点：
  1) RDB比AOF更高效。
  2) 适合大规模的数据恢复。(重启服务就会读取dump.rdb文件，恢复数据)

缺点：
  1) 需要一定的时间间隔操作。
  2) 如果最后一次持久化过程中宕机，那么数据会丢失。
  3) fork（分叉）进程的时候，会占用一定的内存空间。

rdb快照触发机制：生成dump.rdb文件
  1) 执行save命令。
  2) 执行flushall命令。
  3) save规则满足任一条件。（save n m => 在n秒内m个key进行了修改，就会触发rdb操作）
  4) 退出redis时。

恢复rdb文件：
  1) 将rdb文件放在redis启动目录，重启redis-server服务。
  生产环境需要定期对 rdb 文件进行备份。
    

---

1.2 AOF (Append Only File)

1.17 APPEND ONLY MODE 设置AOF⭐️ => Redis.conf 配置文件
 
1) appendonly：是否开启aof持久化，默认使用rdb持久化，不开启aof。在大部分情况下rdb完全够用了。默认 on。
2) appendfilename：持久化(aof方式)的文件名。默认 appendonly.aof。
3) appendfsync：是否每次都需要同步(sync)。默认everysec。
  always：每次修改值都会执行一次 sync。
  everysec：每秒执行一次 sync（如果这1秒内宕机了，可能会丢失这1秒的数据）。默认级别
  no：不执行 sync，这个时候操作系统自己同步数据，速度最快。
4) auto-aof-rewrite-percentage：当前写入日志文件的大小超过上一次rewrite之后的基准（文件大小的百分之多少）时触发rewrite。默认100。把它设置为0可以禁用自动触发功能。可以通过config set来动态修改。
5) auto_aofrewrite_min_size：当前aof文件大于多少后才触发。避免在aof较小的时候进行无谓的重写行为。默认大小为64mb。
可以通过config set来动态修改。

  AOF：将所有命令都记录下来（相当于执行历史history），恢复时将这个文件的内容全部执行一遍，由于只是一个append到文件操作，所以写到硬盘上的操作往往非常快。

  以日志的形式来记录每个写操作，将Redis执行过的所有指令记录下来（读操作不记录），只需追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据。换言之，redis启动时会根据日志文件的内容将写指令从前到后全部执行一遍，已完成数据的恢复工作。默认aof不生效，需要手动开启（修改redis.conf配置文件） 。

  Redis aof机制包括了两件事，rewrite和AOF。rewrite类似于普通数据库管理系统日志恢复点，当AOF文件随着写命令的运行膨胀时，当文件大小触碰到临界时，rewrite会被运行。

  rewrite会像replication一样，fork出一个子进程，创建一个临时文件，遍历数据库，将每个key、value对输出到临时文件。输出格式就是Redis的命令，但是为了减小文件大小，会将多个key、value对集合起来用一条命令表达。在rewrite期间的写操作会保存在内存的rewrite buffer中，rewrite成功后这些操作也会复制到临时文件中，在最后临时文件会代替AOF文件。

  以上在AOF打开的情况下，如果AOF是关闭的，那么rewrite操作可以通过bgrewriteaof命令来进行。

---

Redis AOF流程：
  1) Redis Server启动，如果AOF机制打开那么初始化AOF状态，并且如果存在AOF文件，读取AOF文件。
  2) 随着Redis不断接受命令，每个写命令都被添加到AOF文件，AOF文件膨胀到需要rewrite时又或者接收到客户端的bgrewriteaof命令。
  3) fork出一个子进程进行rewrite，而父进程继续接受命令，现在的写操作命令都会被额外添加到一个aof_rewrite_buf_blocks缓冲中。
  4) 当子进程rewrite结束后，父进程收到子进程退出信号，把aof_rewrite_buf_blocks的缓冲添加到rewrite后的文件中，然后切换AOF的文件fd。rewrite任务完成，继续第二个步骤。

aof文件修复：redis-check-aof，在redis根目录下，可以自动修复aof文件。（如果aof文件有错误，会导致redis-server启动失败 Connect refused）redis-check-aof --fix appendonly.aof

---

优点：
  1) appendfsync always会每一次修改都同步，文件的完整性会更好。

缺点：
  1) 数据文件大小：aof>rdb，修复速度慢。
  2) 读取方式：aof从磁盘读取，运行效率慢。

aof快照触发机制：生成appendonly.aof文件
  1) appendfsync always 每次都改都会 sync，消耗性能。
  2) appendfsync everysec 每秒执行一次 sync，可能会丢失这1s内的数据。
  3) appendfsync no 不执行sync，这个时候系统自己同步数据，速度最快，但可能会丢失部分数据。

恢复aof文件：
  1) 将aof文件放在redis启动目录，重启redis-server服务。

---

1.3 RDB + AOF场景测试

场景：
  1) 开启aof模式，rbd设置为save 60 5，set命令连续执行5次，未触发生成dump.rdb文件。flushall 和 save依然会触发。
  2) 开启aof模式，删掉dump.rdb，重启redis-server，数据不丢失。
  3) 开启aof模式，删掉appendonly.aof，客户端输入save生成dump.rdb文件，重启redis-server，数据全部丢失。修改配置文件(改为rdb模式)，试图从dump.rdb恢复数据，数据恢复。
  4) 服务器开启(此时是rdb模式，且有dump.rdb文件)，修改配置文件(改为aof模式)，重启服务，现有数据丢失。再修改配置文件(改为rdb模式)，试图从dump.rdb恢复数据，数据丢失

结论：
  1) aof开启后，默认采用aof模式保存数据，save 自动触发方式不会发生，但flushall和save依然生效。且切换rbd后，依然可以从save生成的rdb文件恢复数据。
  2) rdb切换aof时，请确保redis中没有重要数据，因为数据会丢失。（除非先备份dump.rdb文件）
  3) aof模式下删除dump.rdb文件不影响数据的完整性（数据从.aof文件加载）
  4) rdb模式下不会有aof文件（数据从.rdb文件加载）

---

2. 持久化测试

首先确保修改redis.conf文件后确实生效了（最好把端口号改了）可以查看=> Redis.conf 配置文件 3. mac修改配置文件不生效

查看redis.conf文件目录：config get dir

---

2.1 rdb测试

 
Step1. 修改rdb配置文件 save 60 5（60秒内修改5次就会触发rdb操作），:wq保存。

Step2. 删除已有的rdb文件

Step3. 测试第一种触发条件，save命令

执行save命令

查看dump文件，已经出现

Step4. 测试第二种触发条件，flushALL命令

首先删除dump.rdb文件 => rm -rf dump.rdb（略）。然后在客户端(redis-cli)执行flushall命令


查看dump文件，再次出现

Step5. 测试第三种触发条件，save条件（这里设置的是60秒内5次修改key）

首先删除dump.rdb文件 => rm -rf dump.rdb（略）。然后在客户端(redis-cli)执行5次set k1 v1命令。（实际上每执行一次我都查询一下是否是生成了dump.rdb文件，执行第三次的时候就已经发现rdb文件生成了）

查看dump文件，第四次出现（第一次是删除后查询的，后面3次是每次执行set命令查询一次）

具体为什么不是执行到第5次才生产dump.rdb文件，我也不清楚。测试完记得将 save 60 5 改回默认配置。

---

2.2 aof测试

---

  默认aof不生效，需要手动开启（修改redis.conf配置文件）。

# appendonly no
appendonly yes

  重启redis即可生效。

groupiesm@GroupiesMdeMacBook-Pro redis-6.2.6 % ls appendonly.aof dump.rdb
appendonly.aof dump.rdb

  aof文件是一个可读文件，会一直append所有操作到该文件中。

---

22/03/10

M