跳到主要内容

Redis

一、概述​

1. 什么是Redis？​

Redis 是速度非常快的非关系型（NoSQL）内存键值数据库，可以存储键和五种不同类型的值之间的映射。与传统数据库不同的是，Redis 的数据是保存在内存中的（内存数据库，支持持久化），因此读写速度非常快，被广泛应用于分布式缓存方向。

键的类型只能为字符串，值支持五种数据类型：字符串、列表、集合、散列表、有序集合。

Redis 支持很多特性，例如将内存中的数据持久化到硬盘中，使用复制来扩展读性能，使用分片来扩展写性能。

https://cyc2018.xyz/%E6%95%B0%E6%8D%AE%E5%BA%93/Redis.html

2. Redis为什么这么快？​

  1. Redis 基于内存，内存的访问速度比磁盘快很多；

  2. Redis 基于 Reactor 模式设计开发了一套高效的事件处理模型，主要是单线程事件循环和 IO 多路复用（Redis 线程模式后面会详细介绍到）；

    1. 采用单线程，避免不必要的上下文切换可竞争条件，多线程还要考虑线程安全问题

    2. 使用IO多路复用模型，非阻塞IO

      解释IO多路复用模型：Redis是纯内存操作，执行速度非常快。它的性能瓶颈是网络延迟而不是执行速度，IO多路复用模型主要就是实现了高效的网络请求。

  3. Redis 内置了多种优化过后的数据类型/结构实现，性能非常高。

  4. Redis 通信协议实现简单且解析高效。

3. 为什么不直接用 Redis 当主数据库呢？​

主要是因为内存成本太高且 Redis 提供的数据持久化仍然有数据丢失的风险。

4. 为什么要用Redis?​

1、访问速度更快

传统数据库数据保存在磁盘，而 Redis 基于内存，内存的访问速度比磁盘快很多。引入 Redis 之后，我们可以把一些高频访问的数据放到 Redis 中，这样下次就可以直接从内存中读取，速度可以提升几十倍甚至上百倍。

2、高并发

一般像 MySQL 这类的数据库的 QPS 大概都在 4k 左右（4 核 8g） ，但是使用 Redis 缓存之后很容易达到 5w+，甚至能达到 10w+（就单机 Redis 的情况，Redis 集群的话会更高）。

QPS（Query Per Second）：服务器每秒可以执行的查询次数；

由此可见，直接操作缓存能够承受的数据库请求数量是远远大于直接访问数据库的，所以我们可以考虑把数据库中的部分数据转移到缓存中去，这样用户的一部分请求会直接到缓存这里而不用经过数据库。进而，我们也就提高了系统整体的并发。

3、功能全面

Redis 除了可以用作缓存之外，还可以用于分布式锁、限流、消息队列、延时队列等场景，功能强大！

5. 常见的缓存读写策略有哪些？​

https://javaguide.cn/database/redis/3-commonly-used-cache-read-and-write-strategies.html#read-write-through-pattern-%E8%AF%BB%E5%86%99%E7%A9%BF%E9%80%8F

二、Redis应用​

1. Redis除了做缓存，还能做什么？​

分布式锁：通过 Redis 来做分布式锁是一种比较常见的方式。通常情况下，我们都是基于 Redisson 来实现分布式锁。关于 Redis 实现分布式锁的详细介绍：分布式锁详解 。

限流：一般是通过 Redis + Lua 脚本的方式来实现限流。如果不想自己写 Lua 脚本的话，也可以直接利用 Redisson 中的 RRateLimiter 来实现分布式限流，其底层实现就是基于 Lua 代码+令牌桶算法。

消息队列：Redis 自带的 List 数据结构可以作为一个简单的队列使用。Redis 5.0 中增加的 Stream 类型的数据结构更加适合用来做消息队列。它比较类似于 Kafka，有主题和消费组的概念，支持消息持久化以及 ACK 机制。

延时队列：Redisson 内置了延时队列（基于 Sorted Set 实现的）。

分布式 Session ：利用 String 或者 Hash 数据类型保存 Session 数据，所有的服务器都可以访问。

复杂业务场景：通过 Redis 以及 Redis 扩展（比如 Redisson）提供的数据结构，我们可以很方便地完成很多复杂的业务场景比如通过 Bitmap 统计活跃用户、通过 Sorted Set 维护排行榜。

……

2. 如何基于Redis实现分布式锁？​

https://javaguide.cn/distributed-system/distributed-lock-implementations.html

三、Redis数据类型​

1. Redis常用的数据类型有哪些？​

Redis 中比较常见的数据类型有下面这些：

  • 5 种基础数据类型：String（字符串）、List（列表）、Set（集合）、Hash（散列）、Zset（有序集合）。
  • 3 种特殊数据类型：HyperLogLog（基数统计）、Bitmap （位图）、Geospatial (地理位置)。

除了上面提到的之外，还有一些其他的比如 Bloom filter（布隆过滤器）、Bitfield（位域）。

2. String的应用场景有哪些？​

String 是 Redis 中最简单同时也是最常用的一个数据类型。它是一种二进制安全的数据类型，可以用来存储任何类型的数据比如字符串、整数、浮点数、图片（图片的 base64 编码或者解码或者图片的路径）、序列化后的对象。

String 的常见应用场景如下：

  • 常规数据（比如 Session、Token、序列化后的对象、图片的路径）的缓存；
  • 计数比如用户单位时间的请求数（简单限流可以用到）、页面单位时间的访问数；
  • 分布式锁(利用 SETNX key value 命令可以实现一个最简易的分布式锁)；
  • ……

3. String 还是 Hash 存储对象数据更好呢？​

简单对比一下二者：

  • 对象存储方式：String 存储的是序列化后的对象数据，存放的是整个对象，操作简单直接。Hash 是对对象的每个字段单独存储，可以获取部分字段的信息，也可以修改或者添加部分字段，节省网络流量。如果对象中某些字段需要经常变动或者经常需要单独查询对象中的个别字段信息，Hash 就非常适合。
  • 内存消耗：Hash 通常比 String 更节省内存，特别是在字段较多且字段长度较短时。Redis 对小型 Hash 进行优化（如使用 ziplist 存储），进一步降低内存占用。
  • 复杂对象存储：String 在处理多层嵌套或复杂结构的对象时更方便，因为无需处理每个字段的独立存储和操作。
  • 性能：String 的操作通常具有 O(1) 的时间复杂度，因为它存储的是整个对象，操作简单直接，整体读写的性能较好。Hash 由于需要处理多个字段的增删改查操作，在字段较多且经常变动的情况下，可能会带来额外的性能开销。

总结：

  • 在绝大多数情况下，String 更适合存储对象数据，尤其是当对象结构简单且整体读写是主要操作时。
  • 如果你需要频繁操作对象的部分字段或节省内存，Hash 可能是更好的选择。

4. String 的底层实现是什么？​

Redis 是基于 C 语言编写的，但 Redis 的 String 类型的底层实现并不是 C 语言中的字符串（即以空字符 \0 结尾的字符数组），而是自己编写了 SDS（Simple Dynamic String，简单动态字符串） 来作为底层实现。

SDS 最早是 Redis 作者为日常 C 语言开发而设计的 C 字符串，后来被应用到了 Redis 上，并经过了大量的修改完善以适合高性能操作。

5. 购物车信息用 String 还是 Hash 存储更好呢?​

由于购物车中的商品频繁修改和变动，购物车信息建议使用 Hash 存储：

  • 用户 id 为 key
  • 商品 id 为 field，商品数量为 value

那用户购物车信息的维护具体应该怎么操作呢？

  • 用户添加商品就是往 Hash 里面增加新的 field 与 value；
  • 查询购物车信息就是遍历对应的 Hash；
  • 更改商品数量直接修改对应的 value 值（直接 set 或者做运算皆可）；
  • 删除商品就是删除 Hash 中对应的 field；
  • 清空购物车直接删除对应的 key 即可。

6. 使用 Redis 实现一个排行榜怎么做？​

Redis 中有一个叫做 Sorted Set （有序集合）的数据类型经常被用在各种排行榜的场景，比如直播间送礼物的排行榜、朋友圈的微信步数排行榜、王者荣耀中的段位排行榜、话题热度排行榜等等。

相关的一些 Redis 命令: ZRANGE (从小到大排序)、 ZREVRANGE （从大到小排序）、ZREVRANK (指定元素排名)。

7. Redis 的有序集合底层为什么要用跳表，而不用平衡树、红黑树或者 B+树？​

  • 平衡树 vs 跳表：平衡树的插入、删除和查询的时间复杂度和跳表一样都是 O(log n)。对于范围查询来说，平衡树也可以通过中序遍历的方式达到和跳表一样的效果。但是它的每一次插入或者删除操作都需要保证整颗树左右节点的绝对平衡，只要不平衡就要通过旋转操作来保持平衡，这个过程是比较耗时的。跳表诞生的初衷就是为了克服平衡树的一些缺点。跳表使用概率平衡而不是严格强制的平衡，因此，跳表中的插入和删除算法比平衡树的等效算法简单得多，速度也快得多。
  • 红黑树 vs 跳表：相比较于红黑树来说，跳表的实现也更简单一些，不需要通过旋转和染色（红黑变换）来保证黑平衡。并且，按照区间来查找数据这个操作，红黑树的效率没有跳表高。
  • B+树 vs 跳表：B+树更适合作为数据库和文件系统中常用的索引结构之一，它的核心思想是通过可能少的 IO 定位到尽可能多的索引来获得查询数据。对于 Redis 这种内存数据库来说，它对这些并不感冒，因为 Redis 作为内存数据库它不可能存储大量的数据，所以对于索引不需要通过 B+树这种方式进行维护，只需按照概率进行随机维护即可，节约内存。而且使用跳表实现 zset 时相较前者来说更简单一些，在进行插入时只需通过索引将数据插入到链表中合适的位置再随机维护一定高度的索引即可，也不需要像 B+树那样插入时发现失衡时还需要对节点分裂与合并。

8. Set 的应用场景是什么？​

Redis 中 Set 是一种无序集合，集合中的元素没有先后顺序但都唯一，有点类似于 Java 中的 HashSet 。

Set 的常见应用场景如下：

  • 存放的数据不能重复的场景：网站 UV 统计（数据量巨大的场景还是 HyperLogLog更适合一些）、文章点赞、动态点赞等等。
  • 需要获取多个数据源交集、并集和差集的场景：共同好友(交集)、共同粉丝(交集)、共同关注(交集)、好友推荐（差集）、音乐推荐（差集）、订阅号推荐（差集+交集） 等等。
  • 需要随机获取数据源中的元素的场景：抽奖系统、随机点名等等。

9. 使用 Set 实现抽奖系统怎么做？​

如果想要使用 Set 实现一个简单的抽奖系统的话，直接使用下面这几个命令就可以了：

  • SADD key member1 member2 ...：向指定集合添加一个或多个元素。
  • SPOP key count：随机移除并获取指定集合中一个或多个元素，适合不允许重复中奖的场景。
  • SRANDMEMBER key count : 随机获取指定集合中指定数量的元素，适合允许重复中奖的场景。

10. 使用 Bitmap 统计活跃用户怎么做？​

Bitmap 存储的是连续的二进制数字（0 和 1），通过 Bitmap, 只需要一个 bit 位来表示某个元素对应的值或者状态，key 就是对应元素本身 。我们知道 8 个 bit 可以组成一个 byte，所以 Bitmap 本身会极大的节省储存空间。

你可以将 Bitmap 看作是一个存储二进制数字（0 和 1）的数组，数组中每个元素的下标叫做 offset（偏移量）。

img

如果想要使用 Bitmap 统计活跃用户的话，可以使用日期（精确到天）作为 key，然后用户 ID 为 offset，如果当日活跃过就设置为 1。

11. 使用 HyperLogLog 统计页面 UV 怎么做？​

使用 HyperLogLog 统计页面 UV 主要需要用到下面这两个命令：

  • PFADD key element1 element2 ...：添加一个或多个元素到 HyperLogLog 中。
  • PFCOUNT key1 key2：获取一个或者多个 HyperLogLog 的唯一计数。

1、将访问指定页面的每个用户 ID 添加到 HyperLogLog 中。

PFADD PAGE_1:UV USER1 USER2 ...... USERn

2、统计指定页面的 UV。

PFCOUNT PAGE_1:UV

四、Redis 持久化机制​

Redis 是内存型数据库，为了保证数据在断电后不会丢失，需要将内存中的数据持久化到硬盘上。

RDB 持久化​

将某个时间点的所有数据都存放到硬盘上。

可以将快照复制到其它服务器从而创建具有相同数据的服务器副本。

如果系统发生故障，将会丢失最后一次创建快照之后的数据。

如果数据量很大，保存快照的时间会很长。

AOF 持久化​

将写命令添加到 AOF 文件（Append Only File）的末尾。

使用 AOF 持久化需要设置同步选项，从而确保写命令同步到磁盘文件上的时机。这是因为对文件进行写入并不会马上将内容同步到磁盘上，而是先存储到缓冲区，然后由操作系统决定什么时候同步到磁盘。有以下同步选项：

选项同步频率
always每个写命令都同步
everysec每秒同步一次
no让操作系统来决定何时同步
  • always 选项会严重减低服务器的性能；
  • everysec 选项比较合适，可以保证系统崩溃时只会丢失一秒左右的数据，并且 Redis 每秒执行一次同步对服务器性能几乎没有任何影响；
  • no 选项并不能给服务器性能带来多大的提升，而且也会增加系统崩溃时数据丢失的数量。

随着服务器写请求的增多，AOF 文件会越来越大。Redis 提供了一种将 AOF 重写的特性，能够去除 AOF 文件中的冗余写命令。

五、键的过期时间​

Redis 可以为每个键设置过期时间，当键过期时，会自动删除该键。

对于散列表这种容器，只能为整个键设置过期时间（整个散列表），而不能为键里面的单个元素设置过期时间。

六、数据淘汰策略​

可以设置内存最大使用量，当内存使用量超出时，会施行数据淘汰策略。

Redis 具体有 6 种淘汰策略：

策略描述
volatile-lru从已设置过期时间的数据集中挑选最近最少使用的数据淘汰
volatile-ttl从已设置过期时间的数据集中挑选将要过期的数据淘汰
volatile-random从已设置过期时间的数据集中任意选择数据淘汰
allkeys-lru从所有数据集中挑选最近最少使用的数据淘汰
allkeys-random从所有数据集中任意选择数据进行淘汰
noeviction禁止驱逐数据

作为内存数据库，出于对性能和内存消耗的考虑，Redis 的淘汰算法实际实现上并非针对所有 key，而是抽样一小部分并且从中选出被淘汰的 key。

使用 Redis 缓存数据时，为了提高缓存命中率，需要保证缓存数据都是热点数据。可以将内存最大使用量设置为热点数据占用的内存量，然后启用 allkeys-lru 淘汰策略，将最近最少使用的数据淘汰。

Redis 4.0 引入了 volatile-lfu 和 allkeys-lfu 淘汰策略，LFU 策略通过统计访问频率，将访问频率最少的键值对淘汰。

七、Redis缓存​

1. 缓存穿透​

  • 缓存穿透：查询一个不存在的数据，mysql查询不到数据也不会直接写入缓存，就会导致每次请求都查数据库。
  • 解决方案一：
    • 缓存空数据，查询返回的数据为空，仍把这个空结果进行缓存
    • 优点：简单
    • 缺点：消耗内存，可能会发生不一致的问题
  • 解决方案二：
    • 布隆过滤器
    • 优点：占用内存少，没有多余key
    • 缺点：实现复杂，存在误判

布隆过滤器​

bitmap **（位图）：**相当于是一个以（bit）位为单位的数组，数组中每个单元只能存储二进制数0或1

**布隆过滤器作用：**布隆过滤器可以用于检索一个元素是否在一个集合中。

  • 存储数据：id为1的数据，通过多个hash函数获取hash值，根据hash计算数组对应位置改为1
  • 查询数据：使用相同hash函数获取hash值，判断对应位置是否都为1

误判率：数组越小误判率就越大，数组越大误判率就越小，但是同时带来了更多的内存消耗。

2. 缓存击穿​

**缓存击穿：**给某一个key设置了过期时间，当key过期的时候，恰好这时间点对这个key有大量的并发请求过来，这些并发的请求可能会瞬间把DB压垮。

解决方案：

  • 互斥锁
    • 当缓存失效时，不立即取load db，先使用Redis的setnx设置一个互斥锁，当操作成功返回时再进行load db的操作并回设缓存，否则重试get缓存的方法
    • 特点：强一致性，性能低
  • 逻辑过期
    • 在设置key的时候，设置一个过期时间字段一块存入缓存中，不给当前key设置过期时间；当查询的时候，从Redis中取出数据后判断时间是否过期；如果过期，则开通另外一个线程进行数据同步，当前线程正常返回数据，这个数据不是最新的
    • 特点：高可用性，性能高，数据做不到强一致

3. 缓存雪崩​

缓存雪崩是指在同一时段大量的缓存key同时失效或者Redis服务宕机，导致大量请求到达数据库，带来巨大压力。

解决方案：

  • 给不同的Key的TTL添加随机值
  • 利用Redis集群提高服务的可用性
  • 给缓存业务添加降级限流策略
  • 给业务添加多级缓存

4. 双写一致性​

双写一致性：当修改了数据库的数据同时也要更新缓存的数据，缓存和数据库的数据要保持一致。

  • 读操作：缓存命中，直接返回；缓存不命中，查询数据库，写入缓存，设定超时时间
  • 写操作：延迟双删。删除缓存，修改数据库，延时 删除缓存

先删缓存还是先修改数据库？都有可能产生脏数据。

为什么要删两次缓存？降低脏数据出现的概率。

保证强一致：互斥锁