1.持久化简介

1.1 什么是持久化

利用永久性存储介质将数据进行保存，在特定的时间将保存的数据进行恢复的工作机制称为持久化

1.2 为什么要进行持久化

防止数据的意外丢失，确保数据安全性

1.3 持久化过程保存什么

RDB

  • 快照复制

    将当前数据状态进行保存，快照形式，存储数据结果，存储格式简单，关注点在数据

AOF

  • 记录操作

    将数据的操作过程进行保存，日志形式，存储操作过程，存储格式复杂，关注点在数据的操作过程

2. RDB

2.1 RDB启动方式—— save指令

  • 命令
1
save

  • 作用

    手动执行一次保存操作

2.2 RDB启动方式 —— save指令相关配置

  • dbfilename dump.rdb

    说明：设置本地数据库文件名，默认值为 dump.rdb

    经验：通常设置为dump-端口号.rdb

  • dir

    说明：设置存储.rdb文件的路径

    经验：通常设置成存储空间较大的目录中，目录名称data

  • rdbcompression yes

    说明：设置存储至本地数据库时是否压缩数据，默认为 yes，采用 LZF 压缩

    经验：通常默认为开启状态，如果设置为no，可以节省 CPU 运行时间，但会使存储的文件变大（巨大）

  • rdbchecksum yes

    说明：设置是否进行RDB文件格式校验，该校验过程在写文件和读文件过程均进行

    经验：通常默认为开启状态，如果设置为no，可以节约读写性过程约10%时间消耗，但是存储一定的数据损坏风险

Redis RDB执行顺序

注意：save指令的执行会阻塞当前Redis服务器，直到当前RDB过程完成为止，有可能会造成长时间阻塞，线上环境不建议使用

2.3 RDB启动方式 —— bgsave指令

  • 命令
1
bgsave

  • 作用

    手动启动后台保存操作，但不是立即执行

2.4 RDB启动方式 —— bgsave指令工作原理

Reids bgsave指令工作原理

注意： bgsave命令是针对save阻塞问题做的优化。Redis内部所有涉及到RDB操作都采用bgsave的方式，save命令可以放弃使用

2.5 RDB启动方式 —— bgsave指令相关配置

  • dbfilename dump.rdb

  • dir

  • rdbcompression yes

  • rdbchecksum yes

  • stop-writes-on-bgsave-error yes

    说明：后台存储过程中如果出现错误现象，是否停止保存操作

    经验：通常默认为开启状态

2.6 RDB启动方式 ——save配置

  • 配置

    save second changes

  • 作用 满足限定时间范围内key的变化数量达到指定数量即进行持久化

  • 参数 second：监控时间范围 changes：监控key的变化量

  • 位置 在conf文件中进行配置

  • 范例

    save 900 1

    save 300 10

    save 60 10000

2.6 RDB启动方式 ——save配置原理

Redis save配置原理

注意： save配置要根据实际业务情况进行设置，频度过高或过低都会出现性能问题，结果可能是灾难性的 save配置中对于second与changes设置通常具有互补对应关系，尽量不要设置成包含性关系 save配置启动后执行的是bgsave操作

2.7 RDB三种启动方式对比

方式 save指令 bgssave指令
读写 同步 异步
阻塞客户端指令 是 否
额外内存消耗 否 是
启动新进程 否 是

2.8 RDB特殊启动形式

  • 全量复制

    在主从复制中详细讲解

  • 服务器运行过程中重启

    debug reload

  • 关闭服务器时指定保存数据

    shutdown save

默认情况下执行shutdown命令时，自动执行 bgsave(如果没有开启AOF持久化功能)

2.9 RDB的优缺点

RDB优点

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

RDB缺点

数据大时效率低 数据丢失风险 大数据下IO性能低

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

3. AOF

3.1 AOF概念

  • AOF(append only file)持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令达到恢复数据的目的
    与RDB相比可以简单描述为改记录数据为记录数据产生的过程
  • AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式

AOF写数据过程

AOF写数据过程

3.2 AOF写数据三种策略(appendfsync)

  • always(每次）

    每次写入操作均同步到AOF文件中，数据零误差，性能较低

  • everysec（每秒）

    每秒将缓冲区中的指令同步到AOF文件中，数据准确性较高，性能较高
    在系统突然宕机的情况下丢失1秒内的数据

  • no（系统控制）

    由操作系统控制每次同步到AOF文件的周期，整体过程不可控

3.3 AOF的相关配置

  • appendonly yes|no

    是否开启AOF持久化功能，默认为不开启状态

  • appendfsync always|everysec|no

    AOF写数据策略

  • appendfilename filename

    AOF持久化文件名，默认文件名未appendonly.aof，建议配置为appendonly-端口号.aof

  • dir

    AOF持久化文件保存路径，与RDB持久化文件保持一致即可

3.4 AOF的重写

功能由来

随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积
AOF文件重写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程
简单说就是将对同一个数据的若干个条命令执行结 果转化成最终结果数据对应的指令进行记录

AOF重写作用

  • 降低磁盘占用量，提高磁盘利用率
  • 提高持久化效率，降低持久化写时间，提高IO性能
  • 降低数据恢复用时，提高数据恢复效率

AOF重写规则

  • 进程内已超时的数据不再写入文件

  • 忽略无效指令，重写时使用进程内数据直接生成，这样新的AOF文件只保留最终数据的写入命令

  • 如del key1、 hdel key2、srem key3、set key4 111、set key4 222等

  • 对同一数据的多条写命令合并为一条命令

    如lpush list1 a、lpush list1 b、 lpush list1 c 可以转化为：lpush list1 a b c

    为防止数据量过大造成客户端缓冲区溢出，对list、set、hash、zset等类型，每条指令最多写入64个元素

3.5 AOF重写方式

  • 手动重写

    bgrewriteaof

  • 自动重写

    auto-aof-rewrite-min-size size

    auto-aof-rewrite-percentage percentage

  • 自动重写触发比对参数

    aof_current_size aof当前大小

    aof_base_size aof基础大小

  • 自动重写触发条件

aof当前大小 > auto-aof-rewrite-min-size

(aof当前大小-aof基础大小)/aof基础大小 >= auto-aof-rewrite-percentage

3.6 AOF工作流程

AOF工作流程

AOF重写操作流程

AOF重写工作流程

4. RDB与AOF区别

4.1 持久化方式区别

持久化方式 RDB AOF
占用存储空间 小（数据级：压缩） 大（指令级：重写）
存储速度 慢 快
恢复速度 快 慢
数据安全性 会丢失数据 依据策略决定
资源消耗 高/重量级 低/轻量级
启动优先级 低 高

4.2 RDB与AOF的选择

对数据非常敏感，建议使用默认的AOF持久化方案

  • AOF持久化策略使用everysecond，每秒钟fsync一次
    该策略redis仍可以保持很好的处理性能，当出现问题时，最多丢失0-1秒内的数据
  • 注意：由于AOF文件存储体积较大，且恢复速度较慢

数据呈现阶段有效性，建议使用RDB持久化方案

  • 数据可以良好的做到阶段内无丢失（该阶段是开发者或运维人员手工维护的），且恢复速度较快，阶段点数据恢复通常采用RDB方案
  • 注意：利用RDB实现紧凑的数据持久化会使Redis降的很低

4.3 综合比对

  • RDB与AOF的选择实际上是在做一种权衡，每种都有利有弊
  • 如不能承受数分钟以内的数据丢失，对业务数据非常敏感，选用AOF
  • 如能承受数分钟以内的数据丢失，且追求大数据集的恢复速度，选用RDB
  • 灾难恢复选用RDB
  • 双保险策略，同时开启 RDB 和 AOF，重启后，Redis优先使用 AOF 来恢复数据，降低丢失数据的量

5. Redis事务

5.1 什么是事务

redis事务就是一个命令执行的队列，将一系列预定义命令包装成一个整体（一个队列）
当执行时，一次性 按照添加顺序依次执行，中间不会被打断或者干扰
一个队列中，一次性、顺序性、排他性的执行一系列命令

5.2 事务的基本操作

开启事务 : multi
作用 : 设定事务的开启位置，此指令执行后，后续的所有指令均加入到事务中

执行事务: exec
作用:设定事务的结束位置，同时执行事务。与multi成对出现，成对使用

注意：加入事务的命令暂时进入到任务队列中，并没有立即执行，只有执行exec命令才开始执行

5.3 事务的工作流程

Redis 事务工作流程

5.4 事务的注意事项

命令格式输入错误

如果定义的事务中所包含的命令存在语法错误，整体事务中所有命令均不会执行。包括那些语法正确的命令。

命令执行出现错误

能够正确运行的命令会执行，运行错误的命令不会被执行

注意：已经执行完毕的命令对应的数据不会自动回滚，需要程序员自己在代码中实现回滚。

5.5 手动进行事务回滚

记录操作过程中被影响的数据之前的状态

  • 单数据：string
  • 多数据：hash、list、set、zset

设置指令恢复所有的被修改的项

  • 单数据：直接set（注意周边属性，例如时效）
  • 多数据：修改对应值或整体克隆复制

6. 锁

使用场景

  • 多个客户端有可能同时操作同一组数据，并且该数据一旦被操作修改后，将不适用于继续操作
  • 在操作之前锁定要操作的数据，一旦发生变化，终止当前操作

6.1 锁

对 key 添加监视锁，在执行exec前如果key发生了变化，终止事务执行

  • watch key1 [key2……]

取消对所有 key 的监视

  • unwatch

6.2 分布式锁

虽然redis是单线程的，但是多个客户端对同一数据同时进行操作时，如何避免不被同时修改

  • 使用 setnx 设置一个公共锁

setnx lock-key value

利用setnx命令的返回值特征，有值则返回设置失败，无值则返回设置成功

  • 对于返回设置成功的，拥有控制权，进行下一步的具体业务操作

  • 对于返回设置失败的，不具有控制权，排队或等待

    操作完毕通过del操作释放锁

注意：上述解决方案是一种设计概念，依赖规范保障，具有风险性

6.3 分布式锁改良

  • 由于锁操作由用户控制加锁解锁，必定会存在加锁后未解锁的风险
  • 需要解锁操作不能仅依赖用户控制，系统级别要给出对应的保底处理方案

使用 expire 为锁key添加时间限定，到时不释放，放弃锁

expire lock-key second
pexpire lock-key milliseconds

由于操作通常都是微秒或毫秒级，因此该锁定时间不宜设置过大。具体时间需要业务测试后确认。

  • 例如：持有锁的操作最长执行时间127ms，最短执行时间7ms。
  • 测试百万次最长执行时间对应命令的最大耗时，测试百万次网络延迟平均耗时
  • 锁时间设定推荐：最大耗时*120%+平均网络延迟*110%
  • 如果业务最大耗时<<网络平均延迟，通常为2个数量级，取其中单个耗时较长即可