实习-Redis知识点

学习笔记 评论

Redis 数据类型

  • 五种基础数据类型：
    • String:底层使用C语言构建的简单动态字符串
    • Hash:数组 + 链表,用于对象数据
    • List:基于双向链表,用于时间(最新)数据
    • Set:intset或者hashtable, 用于找共同好友、共同喜好等
    • ZSet(有序集合),ziplist或者skiplist,用于排行榜、有权值排序的等
  • 三种特殊数据类型：HyperLogLog(基数统计)、Geo(地理位置)、Bitmap(位图)

问题:String和Hash存储对象数据的区别？

  • String 存储的是序列化后的对象数据，存放的是整个对象。Hash 是对对象的每个字段单独存储，可以获取部分字段的信息，也可以修改或者添加部分字段，节省网络流量。如果对象中某些字段需要经常变动或- String 存储相对来说更加节省内存，缓存相同数量的对象数据，String 消耗的内存约是 Hash 的一半。并且，存储具有多层嵌套的对象时也方便很多。如果系统对性能和资源消耗非常敏感的话，String 就非常适合。

三种常用的缓存读写策略

Cache Aside Pattern(旁路缓存模式)

Cache Aside Pattern 比较适合读请求比较多的场景。

Cache Aside Pattern 中服务端需要同时维系 db 和 cache，并且是以 db 的结果为准。

写

  • 先更新db
  • 然后直接删除cache

读

  • 从cache中读取数据,读取到就直接返回
  • 读取不到就从db中读取,然后写入cache,并返回

缺点:

  1. 首次请求时，cache中没有数据，会导致大量的请求落到db上
  2. 写操作比较频繁会频繁删除cache,影响缓存命中率

Read/Write Through Pattern(读写穿透模式)

Read/Write Through Pattern 中服务端把 cache 视为主要数据存储，从中读取数据并将数据写入其中。cache 服务负责将此数据读取和写入 db，从而减轻了应用程序的职责。

写

  • 先查 cache，cache 中不存在，直接更新 db。
  • cache 中存在，则先更新 cache，然后 cache 服务自己更新 db（同步更新 cache 和 db）。

读

  • 从 cache 中读取数据，读取到就直接返回 。
  • 读取不到的话，先从 db 加载，写入到 cache 后返回响应。

Write Behind Pattern(异步缓存写入模式)

Read/Write Through 是同步更新 cache 和 db，而 Write Behind 则是只更新缓存，不直接更新 db，而是改为异步批量的方式来更新 db。

这种方式对数据一致性带来了更大的挑战，比如 cache 数据可能还没异步更新 db 的话，cache 服务可能就就挂掉了。

Write Behind Pattern 下 db 的写性能非常高，非常适合一些数据经常变化又对数据一致性要求没那么高的场景

Redis 持久化机制

RDB持久化(snapshotting)


在指定时间间隔后，将内存中的数据集快照写入数据库 ；在恢复时候，直接读取快照文件，进行数据的恢复 ；

优点

  1. 适合大规模的数据恢复
  2. 对数据的完整性要求不高

缺点:

  1. 需要一定的时间间隔进行操作，如果redis意外宕机了，这个最后一次修改的数据就没有了。
  2. fork进程的时候，会占用一定的内容空间。

过程

  1. Redis 调用forks。同时拥有父进程和子进程。
  2. 子进程将数据集写入到一个临时 RDB 文件中。
  3. 当子进程完成对新 RDB 文件的写入时，Redis 用新 RDB 文件替换原来的 RDB 文件，并删除旧的 RDB 文件。

触发机制

  1. save的规则满足的情况下，会自动触发rdb原则
  2. 执行flushall命令，也会触发我们的rdb原则
  3. 退出redis，也会自动产生rdb文件
命令 save bgsave
是否阻塞 是 否
IO类型 同步 异步
复杂度 O(n) O(n)
优点 不会消耗额外的内存 不会阻塞主线程
缺点 会阻塞主线程 会fork子进程消耗额外的内存

AOF持久化(append-only file)


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

流程

  1. 命令追加（append）：所有的写命令会追加到 AOF 缓冲区中。
  2. 文件写入（write）：将 AOF 缓冲区的数据写入到 AOF 文件中。这一步需要调用write函数（系统调用），write将数据写入到了系统内核缓冲区之后直接返回了（延迟写）。注意！！！此时并没有同步到磁盘。
  3. 文件同步（fsync）：AOF 缓冲区根据对应的持久化方式（ fsync 策略）向硬盘做同步操作。这一步需要调用 fsync 函数（系统调用）， fsync 针对单个文件操作，对其进行强制硬盘同步，fsync 将阻塞直到写入磁盘完成后返回，保证了数据持久化。
  4. 文件重写（rewrite）：随着 AOF 文件越来越大，需要定期对 AOF 文件进行重写，达到压缩的目的。
  5. 重启加载（load）：当 Redis 重启时，可以加载 AOF 文件进行数据恢复。

AOF持久化方式

  1. appendfsync always每一次修改都会同步，文件的完整性会更加好
  2. appendfsync everysec没秒同步一次，可能会丢失一秒的数据
  3. appendfsync no主线程调用 write 执行写操作后立即返回，让操作系统决定何时进行同步

缺点:
1 相对于数据文件来说，aof远远大于rdb，修复速度比rdb慢！
2 Aof运行效率也要比rdb慢，所以我们redis默认的配置就是rdb持久化

问题:为什么是在执行完命令之后记录日志?

  • 避免额外的检查开销，AOF 记录日志不会对命令进行语法检查；
  • 在命令执行完之后再记录，不会阻塞当前的命令执行。

这样也带来了风险：

  • 如果刚执行完命令 Redis 就宕机会导致对应的修改丢失；
  • 可能会阻塞后续其他命令的执行（AOF 记录日志是在 Redis 主线程中进行的）

两种方式对比

RDB 比 AOF 优秀的地方：

  • RDB 文件存储的内容是经过压缩的二进制数据， 保存着某个时间点的数据集，文件很小，适合做数据的备份，灾难恢复。AOF 文件存储的是每一次写命令，类似于 MySQL 的 binlog 日志，通常会比 RDB 文件大很多。当 AOF 变得太大时，Redis 能够在后台自动重写 AOF。新的 AOF 文件和原有的 AOF 文件所保存的数据库状态一样，但体积更小。不过， Redis 7.0 版本之前，如果在重写期间有写入命令，AOF 可能会使用大量内存，重写期间到达的所有写入命令都会写入磁盘两次。
  • 使用 RDB 文件恢复数据，直接解析还原数据即可，不需要一条一条地执行命令，速度非常快。而 AOF 则需要依次执行每个写命令，速度非常慢。也就是说，与 AOF 相比，恢复大数据集的时候，RDB 速度更快。

AOF 比 RDB 优秀的地方：

  • RDB 的数据安全性不如 AOF，没有办法实时或者秒级持久化数据。生成 RDB 文件的过程是比较繁重的， 虽然 BGSAVE 子进程写入 RDB 文件的工作不会阻塞主线程，但会对机器的 CPU 资源和内存资源产生影响，严重的情况下甚至会直接把 Redis 服务干宕机。AOF 支持秒级数据丢失（取决 fsync 策略，如果是 everysec，最多丢失 1 秒的数据），仅仅是追加命令到 AOF 文件，操作轻量。
  • RDB 文件是以特定的二进制格式保存的，并且在 Redis 版本演进中有多个版本的 RDB，所以存在老版本的 Redis 服务不兼容新版本的 RDB 格式的问题。
  • AOF 以一种易于理解和解析的格式包含所有操作的日志。你可以轻松地导出 AOF 文件进行分析，你也可以直接操作 AOF 文件来解决一些问题。比如，如果执行FLUSHALL命令意外地刷新了所有内容后，只要 AOF 文件没有被重写，删除最新命令并重启即可恢复之前的状态。

Redis 线程模式

Redis 基于 Reactor 模式设计开发了一套高效的事件处理模型，这套事件处理模型对应的是 Redis 中的文件事件处理器（file event handler）。由于文件事件处理器（file event handler）是单线程方式运行的，所以我们一般都说 Redis 是单线程模型。

  • 文件事件处理器使用 I/O 多路复用（multiplexing）程序来同时监听多个套接字，并根据套接字目前执行的任务来为套接字关联不同的事件处理器。
  • 当被监听的套接字准备好执行连接应答（accept）、读取（read）、写入（write）、关 闭（close）等操作时，与操作相对应的文件事件就会产生，这时文件事件处理器就会调用套接字之前关联好的事件处理器来处理这些事件。
  • 虽然文件事件处理器以单线程方式运行，但通过使用 I/O 多路复用程序来监听多个套接字，文件事件处理器既实现了高性能的网络通信模型，又可以很好地与 Redis 服务器中其他同样以单线程方式运行的模块进行对接，这保持了 Redis 内部单线程设计的简单性。

问题:Redis 为什么是单线程的？

  • Redis 采用单线程模型，主要是因为 Redis 的瓶颈主要在于网络带宽和读写速度，而不是 CPU 的计算能力。
  • 单线程模型可以避免多线程的频繁上下文切换，减少线程间的竞争，避免了加锁解锁的开销，简化了开发和维护。

Redis 内存管理

问题:Redis 如何判断数据是否过期？
Redis 通过一个叫做过期字典（可以看作是 hash 表）来保存数据过期的时间。过期字典的键指向 Redis 数据库中的某个 key(键)，过期字典的值是一个 long long 类型的整数，这个整数保存了 key 所指向的数据库键的过期时间（毫秒精度的 UNIX 时间戳）。

问题:过期的数据删除策略有哪些？

  1. 惰性删除:当访问一个 key 时，Redis 会检查这个 key 是否过期，如果过期了就删除。这种策略可能会导致过期 key 堆积，占用大量内存。
  2. 定期删除:每隔一段时间，Redis 会随机抽取一些 key，检查其是否过期，如果过期了就删除。Redis 底层会通过限制删除操作执行的时长和频率来减少删除操作对 CPU 时间的影响。

问题:Redis 内存淘汰策略有哪些？

  1. volatile-lru:从已设置过期时间的数据集中挑选最近最少使用的数据淘汰。
  2. volatile-ttl:从已设置过期时间的数据集中挑选将要过期的数据淘汰。
  3. volatile-random:从已设置过期时间的数据集中随机挑选数据淘汰。
  4. allkeys-lru:从数据集中挑选最近最少使用的数据淘汰。
  5. allkeys-random:从数据集中随机挑选数据淘汰。
  6. no-enviction:禁止驱逐数据。当内存不足以容纳新写入数据时，新写入操作会报错
  7. volatile-lru:从已设置过期时间的数据集中挑选最不经常使用的数据淘汰。
  8. allkeys-lru:从数据集中挑选最不经常使用的数据淘汰。

Redis 事务

Redis 事务提供了一种将多个命令请求打包的功能。然后，再按顺序执行打包的所有命令，并且不会被中途打断。

  1. 开始事务:使用 MULTI 命令来开启一个事务。
  2. 命令入队:将所有需要执行的命令放入队列中。
  3. 执行事务:使用 EXEC 命令来执行事务中的所有命令。
  4. 取消事务:使用 DISCARD 命令来取消事务。
  5. 当调用 EXEC 命令执行事务时，如果一个被 WATCH 命令监视的 Key 被 其他客户端/Session 修改的话，整个事务都不会被执行。
  6. 被 WATCH 监视的 Key 被修改的操作发生在事务内部，这个事务是可以被执行成功
  7. Redis 事务其实是不满足原子性的，Redis 事务是不支持回滚，Redis 事务的持久性也是没办法保证

Redis 性能优化

1.使用批量操作减少网络传输

2.大量 key 集中过期问题

  1. 给 key 设置随机过期时间。
  2. 开启 lazy-free（惰性删除/延迟释放），指的是让 Redis 采用异步方式延迟释放 key 使用的内存，将该操作交给单独的子线程处理，避免阻塞主线程。

3.BigKey(大key)

如果一个 key 对应的 value 所占用的内存比较大，那这个 key 就可以看作是 bigkey。

  • String 类型的 value 超过 1MB
  • 复合类型（List、Hash、Set、Sorted Set 等）的 value 包含的元素超过 5000 个
  • 客户端超时阻塞：由于 Redis 执行命令是单线程处理，然后在操作大 key 时会比较耗时，那么就会阻塞 Redis，从客户端这一视角看，就是很久很久都没有响应。
  • 网络阻塞：每次获取大 key 产生的网络流量较大，如果一个 key 的大小是 1 MB，每秒访问量为 1000，那么每秒会产生 1000MB 的流量，这对于普通千兆网卡的服务器来说是灾难性的。
  • 工作线程阻塞：如果使用 del 删除大 key 时，会阻塞工作线程，这样就没办法处理后续的命令。
  1. 使用 redis-cli -p 6379 --bigkeys查找,会对 Redis 的性能有一点影响。并且，这种方式只能找出每种数据结构 top 1 bigkey
  2. 使用 SCAN查找

bigkey 的常见处理以及优化办法如下（这些方法可以配合起来使用）：

  • 分割 bigkey：将一个 bigkey 分割为多个小 key。例如，将一个含有上万字段数量的 Hash 按照一定策略（比如二次哈希）拆分为多个 Hash。
  • 手动清理：Redis 4.0+ 可以使用 UNLINK 命令来异步删除一个或多个指定的 key。Redis 4.0 以下可以考虑使用 SCAN 命令结合 DEL 命令来分批次删除。
  • 采用合适的数据结构：例如，文件二进制数据不使用 String 保存、使用 HyperLogLog 统计页面 UV、Bitmap 保存状态信息（0/1）。
  • 开启 lazy-free（惰性删除/延迟释放） ：lazy-free 特性是 Redis 4.0 开始引入的，指的是让 Redis 采用异步方式延迟释放 key 使用的内存，将该操作交给单独的子线程处理，避免阻塞主线程。

4.HotKey(热点 key)

如果一个 key 的访问次数比较多且明显多于其他 key 的话，那这个 key 就可以看作是 hotkey（热 Key）处理 hotkey 会占用大量的 CPU 和带宽，可能会影响 Redis 实例对其他请求的正常处理。此外，如果突然访问 hotkey 的请求超出了 Redis 的处理能力，Redis 就会直接宕机。这种情况下，大量请求将落到后面的数据库上，可能会导致数据库崩溃。

  1. 使用 redis-cli -p 6379 --hotkeys查找
  2. 使用 MONITOR命令查找,该命令对 Redis 性能的影响比较大，因此禁止长时间开启 MONITOR

hotkey 的常见处理以及优化办法如下（这些方法可以配合起来使用）：

  • 读写分离：主节点处理写请求，从节点处理读请求。
  • 使用 Redis Cluster：将热点数据分散存储在多个 Redis 节点上。
  • 二级缓存：hotkey 采用二级缓存的方式进行处理，将 hotkey 存放一份到 JVM 本地内存中（可以用 Caffeine）。

5.慢查询命令

  1. 发送命令
  2. 命令排队
  3. 命令执行
  4. 返回结果
    Redis 慢查询统计的是命令执行这一步骤的耗时，慢查询命令也就是那些命令执行时间较长的命令。
    Redis 中的大部分命令都是 O(1)时间复杂度，但也有少部分 O(n) 时间复杂度的命令，例如：
  • KEYS *：会返回所有符合规则的 key。
  • HGETALL：会返回一个 Hash 中所有的键值对。
  • LRANGE：会返回 List 中指定范围内的元素。
  • SMEMBERS：返回 Set 中的所有元素。
  • SINTER/SUNION/SDIFF：计算多个 Set 的交集/并集/差集。

6.内存碎片

将内存碎片简单地理解为那些不可用的空闲内存。操作系统为你分配了 32 字节的连续内存空间，而你存储数据实际只需要使用 24 字节内存空间，那这多余出来的 8 字节内存空间如果后续没办法再被分配存储其他数据的话，就可以被称为内存碎片

  1. Redis 存储数据的时候向操作系统申请的内存空间可能会大于数据实际需要的存储空间。
  2. 频繁修改 Redis 中的数据也会产生内存碎片。当 Redis 中的某个数据删除时，Redis 通常不会轻易释放内存给操作系统。

mem_fragmentation_ratio （内存碎片率）= used_memory_rss (操作系统实际分配给 Redis 的物理内存空间大小)/ used_memory(Redis 内存分配器为了存储数据实际申请使用的内存空间大小)

生产问题

缓存穿透

缓存穿透就是大量请求的 key 是不合理的，根本不存在于缓存中，也不存在于数据库中 。这就导致这些请求直接到了数据库上，根本没有经过缓存这一层，对数据库造成了巨大的压力，可能直接就被这么多请求弄宕机了。

  1. 缓存无效数据：如果缓存和数据库都查不到某个 key 的数据就写一个到 Redis 中去并设置过期时间
  2. 布隆过滤器: 布隆过滤器是一个非常神奇的数据结构，通过它我们可以非常方便地判断一个给定数据是否存在于海量数据中。我们可以把它看作由二进制向量（或者说位数组）和一系列随机映射函数（哈希函数）两部分组成的数据结构。相比于我们平时常用的 List、Map、Set 等数据结构，它占用空间更少并且效率更高，但是缺点是其返回的结果是概率性的，而不是非常准确的。理论情况下添加到集合中的元素越多，误报的可能性就越大。并且，存放在布隆过滤器的数据不容易删除。
  3. 接口限流: 根据用户或者 IP 对接口进行限流，

缓存击穿

缓存击穿中，请求的 key 对应的是 热点数据 ，该数据 存在于数据库中，但不存在于缓存中（通常是因为缓存中的那份数据已经过期） 。这就可能会导致瞬时大量的请求直接打到了数据库上，对数据库造成了巨大的压力，可能直接就被这么多请求弄宕机了。

  1. 设置热点数据永不过期或者过期时间比较长。
  2. 针对热点数据提前预热，将其存入缓存中并设置合理的过期时间比如秒杀场景下的数据在秒杀结束之前不过期。
  3. 请求数据库写数据到缓存之前，先获取互斥锁，保证只有一个请求会落到数据库上，减少数据库的压力。

缓存雪崩

缓存在同一时间大面积的失效，导致大量的请求都直接落到了数据库上，对数据库造成了巨大的压力。缓存服务宕机也会导致缓存雪崩现象，导致所有的请求都落到了数据库上。

针对 Redis 服务不可用的情况：

  1. 采用 Redis 集群，避免单机出现问题整个缓存服务都没办法使用。
  2. 限流，避免同时处理大量的请求。
  3. 多级缓存，例如本地缓存+Redis 缓存的组合，当 Redis 缓存出现问题时，还可以从本地缓存中获取到部分数据。

如何保证缓存和数据库数据的一致性

更新 DB，然后直接删除 cache 。

如果更新数据库成功，而删除缓存这一步失败的情况的话，简单说两个解决方案：

  1. 缓存失效时间变短（不推荐，治标不治本）：我们让缓存数据的过期时间变短，这样的话缓存就会从数据库中加载数据。另外，这种解决办法对于先操作缓存后操作数据库的场景不适用。
  2. 增加 cache 更新重试机制（常用）：如果 cache 服务当前不可用导致缓存删除失败的话，我们就隔一段时间进行重试，重试次数可以自己定。如果多次重试还是失败的话，我们可以把当前更新失败的 key 存入队列中，等缓存服务可用之后，再将缓存中对应的 key 删除即可。

GladdduckKB Master

我写的个人简介。