Redis二三事一套超详细的Redis学习教程（步骤图片+实操）---第二集

Posted 温文艾尔

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Redis二三事一套超详细的Redis学习教程（步骤图片+实操）---第二集相关的知识，希望对你有一定的参考价值。

⭐️写在前面

文章目录

⭐️1 Redis持久化

什么是持久化？

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

为什么要进行持久化？

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

持久化几种实现方式

  • 将当前数据状态进行保存，以快照形式，存储数据结果，存储格式简单，关注点在数据
  • 将操作流程记录下来，像日志，撤销操作等

而在Redis中两种方式都用到了

⭐️1.1 RDB

⭐️1.1.1 save

命令

  • save

    • 作用 ：手动执行一次保存操作

  • dbfilename dump.rdb

    • 说明：设置本地数据库文件名，默认值为dump.rdb
    • 经验：通常设置为dump-端口号.rbd

  • dir

    • 说明：设置存储rdb文件的路径
    • 经验：通常设置为存储空间较大的目录中，目录名称为data

  • rbdcompression yes

    • 说明：设置存储至本地数据库时是否压缩数据，默认为yes,采用LZF压缩
    • 经验：通常默认为开启状态，如果设置为no，可以节省CPU运行时间，但会使存储的文件变大（巨大）

  • rdbchecksum yes

    • 说明：设置是否进行RDB文件格式校验，该校验过程在写文件和读文件过程均进行
    • 经验：通常默认为开启状态，如果设置为no，可以节约读写性过程约10%时间消耗，但是存储一定的数据损坏风险


我们查看data文件中是否生成了dump-6379.rdb文件


👋生成成功
当前我们的数据成功的保存，那么怎么样才能让他恢复呢？

首先找出服务进程并’杀掉’'它


现在再次启动服务，如果我们设置的name 123还在，则证明持久化成功

我们成功获取到了name，证明持久化成功！

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

那么当数据量过大时，单线程执行方式造成效率过低如何处理？

我们可以将其放在后台操作

⭐️1.1.2 bgsave

  • 命令
    • bgsave
  • 作用
    • 手动启动后台保存操作，但不是立即执行

当我们执行bgsave指令时，它会发送指令给redis，redis也会返回一条消息，并在返回消息时调用fork函数生成子进程，利用子进程去创建rdb文件，子进程做完之后会返回一条消息告诉redis完成任务了

流程图解：

我们可以通过查看日志文件来了解流程

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

bgsave配置

  • stop-writes-on-bgsave-error yes
    • 说明：后台存储过程中如果出现错误现象，是否停止保存操作
    • 通常默认为开启状态

我们会遇到这样的问题：

反复执行保存指令，忘记执行了怎么办？不知道数据产生了多少变化，何时保存？

我们可以通过配置解决上述问题

配置

  • save second changes
  • 作用
    • 满足限定时间范围内key的变化数量达到指定数量即执行持久化
  • 参数
    • second :监控时间范围
    • changes：监控key的变化量
  • 位置
    • 在conf文件中进行配置
  • 范例
    • save 900 1
    • save 300 10
    • save 60 10000
配置完成后，只要在规定seconds内key的变化次数达到changes，redis就会自动执行bgsave指令,如果规定时间内
key的变化没有达到changes，则会重新计时

演示：

我们进入conf文件进行配置

启动redis，先添加1个key观察,rdb文件是否出现


文件并没有出现，说明bgsave指令没有被执行

在10s内添加2个key试一试


rdb文件出现，说明bgsave指令已被执行

⭐️原理分析

在我们进行配置以后，每一个指令之后的都对应着一个结果，而结果如果对save产生影响就必须满足以下两个条件

  • 对数据产生了影响（get key这种不对数据产生影响的就会被忽略）

  • 对数据真正产生了影响（例如原来age=18，执行set age=19之后又执行set age=18，age的值并没有发生变化，故指令被忽略）

注意：

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

⭐️1.1.3 RDB几种启动方式对比

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

RDB特殊启动方式

  • 服务器运行过程中重启
    • debug reload
  • 关闭服务器时指定保存数据
    • shutdown save

RDB优点

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

RDB缺点

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

⭐️1.2 AOF

上面我们讲的RDB基于快照思想，每次读写都是全部数据，当数据量巨大时，效率非常低，并且基于fork创建的子进程也会产生额外消耗，并且需要达到一定条件才可进行保存，一旦遇到宕机，数据就存在丢失的风险

解决思路

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

⭐️1.2.1 AOF概念

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

⭐️1.2.2 AOF写数据的过程

当我们发送指令给服务器，服务器接收到指令并没有马上记录，而是将指令放到AOF写命令刷新缓存区，缓冲区满，将直接把命令同步到AOF文件中

至于一次写过去多少条，多久写一次，我们通过配置策略来解决

⭐️1.2.3 AOF写数据三种策略（appendfsync）

  • always（每次）
    • 每次写入操作均同步到AOF文件中，数据零误差，性能较低
  • everysec（每秒）
    • 每秒将缓冲区中的指令同步到AOF文件中，数据准确性较高，性能较高
    • 在系统突然宕机的情况下丢失1秒内的数据
  • no（系统控制）
    • 由操作系统控制每次同步到AOF文件的周期，整体过程不可控

⭐️1.2.4 配置

  • 配置
    • appendonly yes|no
    • 作用
    • 是否开启AOF持久化功能，默认为不开启状态
  • 配置
    • appendfsync always|everysec|no
    • 作用
    • AOF数据策略
  • 配置
    • appendfilename filename
    • 作用
    • AOF持久化文件名，默认文件名为appendonly.aof，建议配置为appendonly-端口号.aof
  • 配置
    • dir
    • 作用
    • AOF持久化文件保存路径，与RBD持久化文件保持一致

⭐️1.2.5 演示


配置完成后重启redis服务


可以看到AOF持久化文件已经生成


我们尝试存储一些数据并观察文件的变化

进入持久化文件

我们发现我们每一步有效操作的步骤都被记录在文件中

⭐️1.2.6 AOF写数据遇到的问题

我们执行以上指令会发现，set name zs 和 set name ls 在写数据时实际上是不用执行的incr num也可以合并为1条指令，AOF提供这样的功能

⭐️1.2.7 AOF重写

随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积，AOF文件重写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程。

简单说就是将对同一个数据的若干个命令执行结果转化成最终结果数据对应的指令进行记录

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个元素

⭐️1.2.7.1 AOF重写方式

  • 手动重写
    • bgrewriteaof
  • 自动重写
    • auto-aof-rewrite-min-size size
    • auto-aof-rewrite-percentage percentage

未指定重写之前

AOF将操作都记录了下来


手动重写：

查看aof文件

我们看到只有set name 456在其中，set name 123 set name 235等无效操作没有被记录

⭐️1.3 RDB与AOF区别

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

⭐️1.4 RDB与AOF的选择之惑


⭐️2 事务

一般来说，事务是必须满足4个条件（ACID）：：

原子性（**A**tomicity，或称不可分割性）、一致性（**C**onsistency）、隔离性（**I**solation，又称
独立性）、持久性（**D**urability）。

- **原子性：**一个事务（transaction）中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。
- **一致性：**在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设规则，这包含资料的精确度、串联性以及后续数据库可以自发性地完成预定的工作。
- **隔离性：**数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括读未提交（Read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（Serializable）。
- **持久性：**事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

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

⭐️2.1 事物的基本操作

  • 开启事务
    • multi
    • 作用
    • 设定事务的开启位置，此指令执行后，后续的所有指令均加入到事务中
  • 执行事务
    • exec
    • 作用
    • 设定事务的结束位置，同时执行事务。与multi成对出现，成对使用
  • 取消事务
    • discard
    • 作用
    • 终止当前事务的定义，发生在multi之后，exec之前

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

⭐️2.2 事务的工作流程

假定我们有一个set指令，服务器接收到之后会先做判断，判断set指令是否处于事务状态

  • 不在事务状态：识别指令，如果是普通指令就直接执行并返回执行结果，如果是事务指令（MULTI），会直接创建事务队列，然后返回“OK”结果
  • 在事务状态：识别指令，如果是普通指令，就将该指令加入队列，如果是事务指令（EXEC）则会直接执行事务，事务队列中的指令会挨个执行，执行完毕后返回执行结果并销毁事务队列，如果是事务指令（DISCARD），则会直接销毁事务队列，返回结果

事务执行流程图解

⭐️2.3 事务操作的注意事项

1.如果定义事务的过程中，命令格式输入错误怎么办？
  • 语法错误
    • 指命令书写格式有误
  • 处理结果
    • 如果定义的事物中所包含的命令存在语法错误，整体事务中所有命令均不会执行。包括那些语法正确的命令

2.如果定义事务的过程中，命令执行出现错误怎么办？
  • 运行错误
    • 指命令格式正确，但是无法正确的执行，例如对list进行incr操作
  • 处理结果
    • 能够正确运行的命令会执行，运行错误的命令不会被执行

注意：已经执行完毕的命令对应的数据不会自动实现回滚，有些操作具有连贯性的，当我们其中一行指令执行错误,
后面指令的结果会受到影响，这就比较难受了，需要程序员自己在代码中实现回滚，因为这种原因，redis的事务在
企业级开发中用的较少一些

⭐️2.4 锁

业务场景1

天猫双11热卖过程中，对已经售空的货物追加补货，4个业务员都有权限进行补货。补货的操作可能是一系列的操作，牵扯到多个连续操作，如何保障不会重复操作？

业务分析1
  • 多个客户端有可能同时操作同一组数据，并且该数据一旦被操作修改后，将不适用于继续操作
  • 在操作之前锁定要操作的数据，一旦发生变化，终止当前操作
解决方案1
  • 对key添加监视锁，在执行exec前如果key发生了变化，终止事务进行
    • watch key1 [key2…]
  • 取消对所有key的监视
    • unwatch

在执行exec之前，我们让另一个客户端修改name的值，发现执行exec之后结果为nil，事务队列中的所有指令都被取消，可以看出，watch指令监控的东西一旦发生改变，事务将不再执行，除非在开启事务之前unwatch，取消监控

业务场景2

天猫双11热卖过程中，对已经售空的货物追加补货，且补货完成。客户购买热情高涨，3秒内将所有商品购买完毕。本次补货已经将库存全部清空，如何避免最后一件商品不被多人同时购买？【超卖问题】

业务分析2
  • 使用watch监控一个key有没有改变已经不能解决问题，此处要监控的是具体数据
  • 虽然redis是单线程的，但是多个客户端对同一数据同时进行操作时，如何避免不被同时修改？
解决方案2
  • 使用setnx设置一个公共锁
    • setnx lock-key value
    • 作用
    • 利用setnx命令的返回值特征，有值则返回设置失败，无值则返回设置成功
      • 对于返回设置成功的，拥有控制权，进行下一步的具体业务操作
      • 对于返回设置失败的，不具有控制权，排队或等待
  • 操作完毕通过del操作释放锁
上述解决方案是一种设计概念，依赖规范保障，具有风险性（锁必须一致，如果设置锁为lock-num那么之后是用的
锁都应该是lock-num）

操作演示：


我们对num加锁，对其进行操作，如果此时另一个用户也想获取锁就会失败


⭐️2.4.2 死锁问题

业务场景1

依赖分布式锁的机制，某个用户操作时对应的客户端宕机，但是它已经获得了锁，其他客户端需要它释放锁才能继续工作，如何解决？

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

我们采取的方案就是给锁加一个时效

解决方案1
  • 使用expire为锁key添加时间限定，到时不释放，放弃锁
    • expire lock-key second （设置秒）
    • pexpire lock-key milliseconds （设置毫秒）

演示：


此时另一客户不断获取锁，终于在设定的20s之后获取到了锁


⭐️3 删除策略

⭐️3.1 过期数据

Redis是一种内存级数据库，所有数据均存放在内存中，内存中的数据可以通过TTL指令获取其状态
  • XX：具有时效性的数据
  • -1：永久有效的数据
  • -2：已经过期的数据或被删除的数据或为定义的数据

时效性数据的存储结构

redis会开放出一个空间名叫expires，它是哈希结构的，存放的数据左边是16进制的地址，而右边就是过期时间，一个地址和一个过期时间相对应

数据删除策略的目标：

在内存占用与CPU占用之间寻找一种平衡，顾此失彼都会造成整体redis性能的下降，甚至引发服务器宕机或内存泄露

⭐️3.2 数据删除策略

⭐️3.2.1 定时删除

⭐️3.2.2 惰性删除

  • 数据到达过期时间，不作处理，等下次访问该数据时再做处理（get name）
    • 如果未过期，返回数据
    • 如果过期，删除数据，返回不存在，内部会触发expirelfNeeded()函数，在任何获取数据的操作之前内部都将执行这个操作，expirelfNeeded()便是检查数据是否过期的
  • 优点、节约CPU性能，发现必须删除的时候才删除
  • 缺点：内存压力很大，出现长期占用内存的数据
总结：以空间换时间

⭐️3.2.3 定期删除

通过对比我们发现，无论是定时删除还是惰性删除都显得太过极端，有没有一种折中方案呢？

在redis的16个数据库中每一个数据库中都会存在一个expires,里面存放所有的过期数据地址和过期时间

定期删除的策略是这样的：

当redis启动服务完成初始化的时候，它会去读取server.hz的值，这个值默认为10

- redis每秒执行server.hz次serverCron()进行定时轮询，serverCron会去调用databasesCron()方法，对

  redis的每个库进行轮询，访问expires的信息，对他们执行activeExpireCycle()进行数据检查
  
- activeExpireCycle()方法对每个expires[*]逐一进行检测，每次执行250ms/server.hz次
- activeExpireCycle()的执行策略是对每个expires[*]检测时，随机挑选W个key检测，如果key超时，就直接
  删除key，如果一轮中超时的key的数量>Wx25%，则循环该过程，如果<Wx25%,则检查下一个数据库的expires,16
  个数据库循环进行
  
- 简单地说我们可以理解为抽奖，一直对16个数据库进行轮询，删除过期数据，对于某一个数据库如果过期数据>
- 抽出总量的1/4则继续抽奖，否则就去下一个数据库继续抽奖

- W取值=ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP属性值
- 参数current_db用于记录activeExpireCycle进入哪一个expires[*]执行

总结：

定期删除

  • 周期性轮询redis库中的时效性数据，采用随机抽取的策略，利用过期数据占比的方式控制删除频度
  • 特点1：CPU性能占用设置有峰值，检测频度可自定义设置
  • 特点2：内存压力不是很大，长期占用内存的冷数据会被持续清理

⭐️3.2.4 三种策略的对比

策略内存CPU总结
定时删除节约内存，无占用不分时段占用CPU资源，频度高拿时间换空间
惰性删除内存占用严重延时执行，CPU利用率高拿空间换时间
定期删除内存定期随机清理每秒花费固定的CPU资源维护内存随机抽查，重点抽查
redis内部惰性删除和定期删除都会用

⭐️3.3 逐出算法

上面三种策略针对的是已经过期的数据的处理方式，那如果我们所有数据都没有过期，且有新数据进入redis，内存
不足怎么办？

这个时候就要用到逐出算法

  • Redis使用内存存储数据，在执行每一个命令前，会调用freeMemoryIfNeeded()检测内存是否充足。如果内存不满足新加入的数据的最低存储要求，redis要临时删除一些数据为当前指令清理存储空间。清理数据的策略称为逐出算法
  • 注意：逐出数据的过程不是100%能够清理出足够的可使用的内存空间，如果不成功则反复执行。当对所有数据尝试完毕后，如果不能达到内存清理的要求，将出现错误信息

⭐️3.3.1 影响数据逐出的相关配置

  • 最大可使用内存
    • maxmemory
    • 占用物理内存的比例，默认值为0，表示不限制。生产环境中根据需求设定，通常设置在50%以上
  • 每次选取待删除数据的个数
    • maxmemory-samples
    • 选取数据时并不会全库扫描，导致严重的性能消耗，降低读写性能。因此采用随机获取数据的方式作为待检测删除数据
  • 删除策略
    • maxmemory-policy
    • 达到最大内存后的，对被挑选出来的数据进行删除的策略
检测易失数据（可能会过期的数据集server.db[i].expires）

- volatile-lru：挑选很久未使用的数据淘汰
- volatile-lfu：挑选使用次数最少的数据淘汰
- volatile-ttl：挑选将要过期的数据淘汰
- volatile-random：任意选择数据淘汰


- 检测全库数据（所有数据集server.db[i].dict）
  - allkeys-lru：挑选很久未使用的数据淘汰
  - allkeys-lfu：挑选使用次数最少的数据进行删除
  - allkeys-random：任意选择数据淘汰
- 放弃数据驱逐（造成内存泄露）
  - no-enviction（驱逐）：禁止驱逐数据（redis4.0中默认策略），会引发错误OOM（Out of Memory）

在配置文件中进行配置

maxmemory-policy volatile-lru

也可使用INFO命令输出监控信息，查询缓存hit和miss的次数，根据业务需求调优Redis配置

以上是关于Redis二三事一套超详细的Redis学习教程（步骤图片+实操）---第二集的主要内容，如果未能解决你的问题，请参考以下文章

Redis二三事一把LOL的时间让你了解Redis的主从复制机制（超详细步骤图解）

Redis二三事一文了解Redis的哨兵机制（超详细步骤图解）

Redis二三事一把LOL的时间让你了解Redis的主从复制机制（超详细步骤图解）

OpenStack二三事

Jetty源码学习-编译Jetty源码二三事

寒假二三事