Redis面试题

1.在项目中如何利用 Redis 实现分布式 Session？Redis 的主要优势是什么？

Redis 是一个开源的、基于内存的 K/V 存储中间件。由于基于内存，其读写性能非常高，很适用于缓存。此外，Redis 支持多种数据结构、各类编程语言的客户端、支持持久数据，其生态也非常广泛。

本项目中，我使用 Redis 分布式 Session 来代替 Tomcat 本地的 Session 存储，能够在分布式多机场景下保证获取登录用户信息的一致性。用 Redis 实现分布式 Session 的优点是非常简单方便，只需要引入 Redis 和 spring-session-data-redis 依赖，然后在配置文件中指定 Redis 的地址和 session 的 store-type 为 redis，即可自动生效，不用自己额外编码。

2.在 Redis 中，使用 Hash 代替 String 存储用户信息的好处是什么？Hash 与 String 存储方式有何区别？

Redis 的 Hash 结构采用 key / value 键值对的形式存储数据，使用 Redis 的 Hash 来存储用户信息后，能够很方便地对用户每个属性进行独立的更新和查询操作，而不是更新和返回整个 JSON 字符串，性能会更高。

举个例子，你想要获取用户的昵称（就 4 个字符串），但是用户的简介有 100 KB 的大小。如果用 Hash 结构，可以只获取昵称，网络传输的内容大小就很小；而如果用 String 结构整体存储，网络传输数据时会把所有的用户信息都返回出来，增加传输开销。

此外，相比于直接在 Spring Boot 中使用 String 类型存储用户信息，使用 Hash 结构不用额外存储序列化对象信息，可以一定程度上节省内存。

9.使用 Redis 缓存时可能出现的常见问题有哪些？你是如何解决这些问题的？

建议先列举使用缓存可能出现的常见问题，然后再挑其中一点举例。

使用 Redis 缓存可能的常见问题：

1）缓存击穿： 缓存击穿指的是某个热门的缓存键在过期后，同时有大量并发请求到达，导致所有请求都穿透缓存直接访问数据库，造成数据库压力激增。解决方法包括：

• 使用互斥锁来保护缓存访问，只允许一个线程重新生成缓存。
• 针对缓存失效时的并发请求使用分布式锁，确保只有一个线程重新生成缓存。

2）缓存雪崩： 缓存雪崩指的是大量缓存键在相同时间失效，导致大量请求落到数据库上，造成数据库压力激增。解决方法包括：

• 为缓存键设置不同的失效时间，使失效时间分散。
• 使用热点数据预热，提前加载热门数据到缓存。

3）缓存过期问题： 缓存中的数据过期后可能会导致数据不一致或数据不可用。解决方法包括：

• 设置合理的缓存失效时间，避免缓存数据长时间不更新。
• 使用缓存的时候检查数据是否过期，如果过期则重新生成缓存。

4）缓存内存问题： 如果缓存数据量很大，可能会导致内存占用过多。解决方法包括：

• 设置合理的内存限制，避免缓存数据过多。
• 使用LRU（Least Recently Used）策略或淘汰算法来淘汰不常用的缓存数据。

5）缓存数据一致性问题： 缓存数据和数据库数据不一致。解决方法包括：

• 使用缓存更新策略，当数据库数据发生变化时，及时更新缓存。
• 使用双写策略，即同时更新数据库和缓存，确保数据一致性。

6）缓存安全问题： 某些敏感数据可能不应该被缓存，如果被缓存可能引发安全问题。解决方法包括：

• 避免缓存敏感数据。
• 使用加密或其他安全措施来保护缓存数据。

7）缓存监控和调优问题： 缓存需要监控和调优，以确保性能和稳定性。解决方法包括：

• 使用监控工具来监测缓存的命中率、内存占用等性能指标。
• 定期调整缓存配置，优化性能。

在本项目中，我通过给不同的缓存设置不同的随机过期时间（N + n）来解决缓存雪崩问题。

129.Redis 是什么？Redis 的特点和常见应用场景有哪些？

Redis（Remote Dictionary Server）是一个开源的高性能键值存储系统，也被称为数据结构服务器。它支持多种类型的数据结构，如字符串、哈希、列表、集合、有序集合等，并提供了丰富的操作这些数据结构的命令。

Redis的特点包括：

• 高性能：Redis使用内存来存储数据，并且数据存储在单一的进程中，因此速度非常快。

• 多样的数据类型：Redis 支持多种数据结构，包括字符串、哈希、列表、集合、有序集合等。

• 持久化：Redis 支持多种持久化方式，包括 RDB 快照和 AOF 日志。

• 分布式：Redis 支持分布式部署，可以将数据分布在多个节点上。

• 简单易用：Redis 提供了丰富的命令，使得操作数据非常方便。 Redis 的常见应用场景包括：

• 缓存：Redis 可以作为缓存使用，加速数据读取和响应速度。

• 消息队列：Redis 提供了列表和发布/订阅功能，可以用来实现消息队列。

• 计数器：Redis 的计数器功能非常高效，可以用来实现页面访问量、点击量等的计数。

• 排行榜：Redis 的有序集合功能可以用来实现排行榜。

• 分布式锁：Redis 可以用来实现分布式锁，保证多个进程之间的互斥访问。

• 实时数据分析：Redis 可以作为实时数据分析的缓存层，加速数据分析速度。

总之，Redis 具有高性能、多样的数据类型、分布式、简单易用等特点，可以应用于各种场景，特别适合用来解决读写频繁的问题。

131.Redis 基础类型中的 String 底层实现是什么？

Redis 中的 String 类型底层实现是一个简单动态字符串（SDS，Simple Dynamic String）。

它有如下特点：

1. 动态扩展：SDS 支持动态扩展，不需要手动管理内存。当字符串长度增加时，SDS 会自动扩展以适应新的长度。
2. 常数时间获取长度：SDS 会缓存字符串的长度，获取长度的时间复杂度为 O(1)。
3. 二进制安全：SDS 可以存储二进制数据，不会因为遇到 \0 字符而截断。
4. 防止缓冲区溢出：SDS 通过空间预分配和惰性空间释放技术，减少了内存分配的频率并防止缓冲区溢出。
5. 预分配空间：当增加字符串长度时，SDS 会预分配额外的空间，以减少频繁的内存分配操作。
6. 惰性释放：当字符串缩短时，SDS 不会立即释放多余的内存，而是通过 free 字段记录未使用的空间。

SDS 的结构定义：

1
2
3
4
5

struct sdshdr {
    int len;      // 记录已使用的字符串长度
    int free;     // 记录未使用的预分配空间长度
    char buf[];   // 字符数组，用于保存字符串
};

• len：表示当前字符串的长度。
• free：表示分配的但未使用的空间长度。
• buf：实际存储字符串的字符数组。

扩展：小整数的特殊优化

为了提高效率，Redis 对小整数有特殊的处理。如果一个 string 值可以被解析为整数并且在一定范围内（64 位带符号整数范围），那么 Redis 会将这个 string 以整数形式存储。

这样在对整数进行操作时，可以直接使用整数值而不是进行字符串解析和转换。

扩展：字符串编码

Redis 的 string 类型可以采用以下三种不同的编码方式，具体取决于字符串的内容和长度：

1. RAW：直接使用 SDS 实现的字符串。当字符串长度超过 32 字节时，使用 RAW 编码。
2. EMBSTR：嵌入式字符串编码，适用于长度不超过 44 字节的小字符串。EMBSTR 将 SDS 头和字符数组分配在连续的内存块中，提高了内存分配和释放的效率。
3. INT：整数编码，适用于可以表示为 64 位带符号整数的字符串。

注意：

• 字符串长度为 32 字节到 44 字节之间：在这个范围内，Redis 会优先使用 EMBSTR 编码来优化内存使用。但如果有某些特殊的条件（如内存分配的碎片、存储优化等其他因素），Redis 可能会选择 RAW 编码，即使字符串长度在 32 到 44 字节之间。

132.如何使用 Redis 实现一个排行榜？

使用 Redis 可以很方便地实现一个排行榜，以下是一种实现方法：

使用**有序集合（Sorted Set）**来存储排行榜数据，以用户得分作为分数(score)，用户 ID 作为成员(member)。

当用户得分改变时，使用 Redis 的 ZADD 命令将用户的分数更新到有序集合中。

获取排行榜数据时，使用 Redis 的 ZREVRANGE 命令按分数倒序获取有序集合中的成员。

可以使用 Redis 的 ZSCORE 命令获取某个用户的分数，或使用 ZREVRANK 命令获取某个用户的排名。

以下是一个简单的 Node.js 实现：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74

const redis = require('redis');
const client = redis.createClient();

// 将用户得分更新到排行榜中
function updateScore(userId, score) {
  client.zadd('leaderboard', score, userId, (err, res) => {
    if (err) {
      console.error('Error updating score:', err);
    }
  });
}

// 获取排行榜数据
function getLeaderboard() {
  return new Promise((resolve, reject) => {
    client.zrevrange('leaderboard', 0, -1, 'WITHSCORES', (err, res) => {
      if (err) {
        reject(err);
      } else {
        const leaderboard = [];
        for (let i = 0; i < res.length; i += 2) {
          leaderboard.push({
            userId: res[i],
            score: parseInt(res[i + 1])
          });
        }
        resolve(leaderboard);
      }
    });
  });
}

// 获取某个用户的分数
function getScore(userId) {
  return new Promise((resolve, reject) => {
    client.zscore('leaderboard', userId, (err, res) => {
      if (err) {
        reject(err);
      } else {
        resolve(parseInt(res));
      }
    });
  });
}

// 获取某个用户的排名
function getRank(userId) {
  return new Promise((resolve, reject) => {
    client.zrevrank('leaderboard', userId, (err, res) => {
      if (err) {
        reject(err);
      } else {
        resolve(res === null ? null : res + 1);
      }
    });
  });
}

// 示例代码
updateScore('user1', 100);
updateScore('user2', 200);
updateScore('user3', 300);

getLeaderboard().then((leaderboard) => {
  console.log('Leaderboard:', leaderboard);
});

getScore('user1').then((score) => {
  console.log('User1 score:', score);
});

getRank('user1').then((rank) => {
  console.log('User1 rank:', rank);
});

在实际应用中，还可以根据需要进行排行榜数据的缓存和更新策略等优化。

133.Redis 的持久化机制有哪些？它们的优缺点和应用场景是什么？

Redis 的持久化机制主要分为 RDB 和 AOF 两种。

RDB 持久化机制

RDB 持久化机制是指将 Redis 在内存中的数据以快照的形式写入磁盘中，可以手动或自动执行快照操作，将数据集的状态保存到一个 RDB 文件中。

RDB 机制的优点在于：

• RDB 机制适合在数据集比较大时进行备份操作，因为它可以生成一个非常紧凑、经过压缩的数据文件，对于备份、恢复、迁移数据都很方便。

RDB 机制在 Redis 重启时比 AOF 机制更快地将 Redis 恢复到内存中。

RDB 机制的缺点在于：

• RDB 机制可能会出现数据丢失，因为数据是周期性地进行备份，一旦 Redis 出现问题并且上一次备份之后还没有进行过数据变更，那么这部分数据将会丢失。
• RDB 机制会造成一定的 IO 压力，当数据集比较大时，进行备份操作可能会阻塞 Redis 服务器进程。

AOF 持久化机制

AOF 持久化机制是指将 Redis 在内存中的操作命令以追加的形式写入到磁盘中的 AOF 文件，AOF 文件记录了 Redis 在内存中的操作过程，只要在 Redis 重启后重新执行 AOF 文件中的操作命令即可将数据恢复到内存中。

AOF 机制的优点在于：

• AOF 机制比 RDB 机制更加可靠，因为 AOF 文件记录了 Redis 执行的所有操作命令，可以确保数据不丢失。
• AOF 机制在恢复大数据集时更加稳健，因为 AOF 文件记录了数据的操作过程，可以确保每一次操作都被正确地执行。

AOF 机制的缺点在于：

• AOF 机制生成的 AOF 文件比 RDB 文件更大，当数据集比较大时，AOF 文件会比 RDB 文件占用更多的磁盘空间。
• AOF 机制对于数据恢复的时间比 RDB 机制更加耗时，因为要重新执行 AOF 文件中的所有操作命令。

综上所述，RDB 适合用于数据集较大、备份、恢复数据和迁移数据等场景，AOF 适合用于数据可靠性要求高、数据恢复稳健等场景。

134.如何用 Redis 实现分布式 Session？

在分布式系统中，通常会将 Session 存储在 Redis 中来实现分布式 Session，这样就可以在多台服务器之间共享 Session 数据。

实现分布式 Session 的方式有多种，其中一种常用的方式是使用 Redis 的数据结构 Hash。具体实现步骤如下：

1. 在用户登录成功后，将 Session 数据存储在 Redis 中。
2. 将 Redis 中的 Session 数据的 Key 设置为一个全局唯一的 ID，一般使用类似于“session:token”这样的格式，其中 token 是一个随机生成的字符串，用来标识这个 Session 数据。
3. 在客户端返回响应的同时，将 Session ID（即 token）以 Cookie 的形式返回给客户端。客户端在后续的请求中都会携带这个 Cookie。
4. 在后续的请求中，服务器会从客户端传递过来的 Cookie 中获取 Session ID，然后根据这个 ID 从 Redis 中获取对应的 Session 数据。如果 Redis 中没有找到对应的 Session 数据，那么就表示这个请求无法通过认证。

• 在用户退出登录或 Session 失效时，需要将 Redis 中的对应 Session 数据删除。

可以使用 Redis 的 EXPIRE 命令来设置 Session 数据的过期时间，这样可以自动删除已经过期的 Session 数据。

同时，还需要注意保护 Redis 中的 Session 数据不被恶意攻击者窃取，一般可以通过设置 Session 数据的前缀和使用随机的 Session ID 等方式来提高安全性。

鱼皮的补充：这题可以结合 spring-session-data-redis 的实现去说

135.Redis 的内存淘汰机制是什么？有哪些内存淘汰策略？

Redis 是一种基于内存的键值数据库，由于内存有限，当 Redis 占用的内存达到上限时，就需要进行内存淘汰，以腾出一些内存空间。

Redis 中的内存淘汰机制包括：

1. 定期删除：Redis 可以设置一个定时器，定期扫描键空间中的键，并删除已经过期的键。
2. 惰性删除：当一个键过期时，Redis 不会立即删除该键，而是等到该键被访问时再删除。
3. 内存淘汰策略：当 Redis 内存占用达到上限时，会根据内存淘汰策略来选择一些键进行删除，以腾出更多的内存空间。

Redis 中的内存淘汰策略包括：

1. noeviction：禁止删除键，即不做任何操作。
2. allkeys-lru：从所有的键中选择最近最少使用的键进行删除。
3. allkeys-random：从所有的键中随机选择一些键进行删除。
4. volatile-lru：从已设置过期时间的键中选择最近最少使用的键进行删除。
5. volatile-random：从已设置过期时间的键中随机选择一些键进行删除。
6. volatile-ttl：从已设置过期时间的键中选择剩余时间最短的键进行删除。

其中，noeviction 策略是最简单的策略，但可能会导致 Redis 内存占满，并导致 Redis 无法正常工作。其他策略则会根据不同的算法进行键的选择和删除，以尽可能地保留重要的键。

总之，Redis 中的内存淘汰机制是保证 Redis 正常运行的重要机制之一，内存淘汰策略则根据不同的场景选择合适的策略来删除不必要的键，以腾出更多的内存空间。

137.Redis 中有哪些数据类型？基础数据结构有几种？有哪些高级数据结构？

回答重点

Redis 支持多种数据类型，不同的数据类型可以满足不同的需求。下面是 Redis 中常用的数据类型：

String（字符串）

• Redis 中最基本的数据类型，可以存储任何形式的数据，例如整数、浮点数、二进制数据等。

Hash（哈希）

• Redis 中的一种键值对类型，可以存储多个键值对，每个键值对又是一个键值对结构。

List（列表）

• Redis 中的一个有序列表类型，可以存储多个元素，每个元素都有一个索引，支持多种列表操作，例如插入、删除、查找等。

Set（集合）

• Redis 中的一种无序集合类型，可以存储多个元素，每个元素都是唯一的，支持多种集合操作，例如交集、并集、差集等。

Sorted Set（有序集合）

• Redis 中的一种有序集合类型，可以存储多个元素，每个元素都有一个分值，支持根据分值进行排序和查询等操作。

Redis 的基础数据结构有三种：字符串、列表和哈希，其他的数据类型都是基于这三种数据结构进行扩展和衍生的。例如，Redis 的 Set 数据类型就是基于字符串实现的。

知识扩展

除了基础数据结构之外，Redis 还提供了多种高级数据结构，例如：

• HyperLogLog：一种基数估计算法，用于估计一个数据集合的基数。
• GeoHash：一种地理位置编码算法，可以对地理位置信息进行编码和查询。
• Pub/Sub：一种消息队列机制，可以实现消息的订阅和发布。
• Bitmaps：一种位图数据结构，可以进行高效的位运算，用于统计用户在线时长、网站访问量等。
• Lua 脚本：Redis 中可以使用 Lua 脚本进行扩展和定制，可以实现一些复杂的业务逻辑和算法。

139.如何使用 Redis 实现分布式锁？

使用 Redis 实现分布式锁的基本思路是使用 Redis 的原子性操作来确保在多个客户端之间只有一个客户端可以成功获取锁。以下是使用 Redis 实现分布式锁的步骤：

1. 获取锁：客户端尝试获取锁，可以使用 Redis 的 SET 命令结合NX和EX选项来实现。SET 命令用于设置一个键值对，NX 选项表示只有在键不存在时才设置，EX 选项表示设置一个过期时间（单位为秒）。 示例：SET lock_key unique_value NX EX 30。这个命令表示如果 lock_key 不存在，就设置它的值为 unique_value，并设置 30 秒的过期时间。如果设置成功，表示获取锁成功；如果设置失败，表示锁已被其他客户端持有，需要等待或重试。
2. 持有锁：在持有锁的客户端执行临界区代码。在此期间，其他客户端无法获取锁。
3. 释放锁：在临界区代码执行完毕后，需要释放锁以供其他客户端使用。为了避免误解锁的情况（例如，由于执行时间过长导致锁过期，然后被其他客户端获取），在释放锁时需要检查锁的值是否与获取锁时设置的值相同。这可以通过 Redis 的 EVAL 命令来实现，使用 Lua 脚本进行原子性操作。 示例：EVAL “if redis.call(‘get’, KEYS[1]) == ARGV[1] then return redis.call(‘del’, KEYS[1]) else return 0 end” 1 lock_key unique_value。这个命令表示检查lock_key的值是否为unique_value，如果是，则删除 lock_key 以释放锁；否则不执行任何操作。 通过以上步骤，可以实现一个基本的 Redis 分布式锁。在实际应用中，还需要考虑一些其他因素，例如获取锁的重试策略、锁的续期等。

题解更倾向于以原生命令的方式去实现，其实还有很多现成的第三方库，比如 Redisson。这里要关注分布式锁可能出现的各种异常情况。

140.如何使用 Redis 的 HyperLogLog 统计页面 UV？

在 Redis 中，HyperLogLog 是一种基数估算算法，可以用于快速计算一个集合中的不同元素数量的近似值。

在使用 HyperLogLog 统计页面 UV 时，我们可以将每个访问者的 IP 地址作为一个元素加入到 HyperLogLog 中，然后通过计算 HyperLogLog 中元素数量的近似值来估计页面的唯一访问者数量。

以下是一个示例代码：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

import redis

# 连接 Redis 服务器
r = redis.Redis(host='localhost', port=6379)

# 记录访问者 IP 地址
ip_address = '192.168.0.1'

# 将 IP 地址加入到 HyperLogLog 中
r.pfadd('page_views', ip_address)

# 获取 HyperLogLog 中元素数量的近似值
uv = r.pfcount('page_views')

# 输出页面 UV
print('页面 UV：', uv)

在上面的示例代码中，我们使用 Redis 的 pfadd() 方法将每个访问者的 IP 地址加入到名为 page_views 的 HyperLogLog 中。然后，我们使用 pfcount() 方法获取 page_views 中元素数量的近似值。

要注意 HyperLogLog 是一种基数估算算法，其结果是一个近似值，并不是精确值。

扩展 HyperLogLog 的特性

1）内存高效：

• 无论集合中有多少元素，HyperLogLog 结构的大小固定为 12 KB 左右。这种内存效率使得它非常适合用于处理大数据集的基数估计。

2）概率估计：

• HyperLogLog 并不存储实际的元素，而是通过散列函数（hash function）将元素映射到一个位图中，从而进行基数估计。
• 由于使用了概率算法，结果并不是精确的，但在大多数情况下具有很高的准确度。

它适用于需要快速计算基数但对准确度要求不高的场景，例如网络流量分析、独立访问用户计数等。

扩展 HyperLogLog 的内部原理（了解即可）

HyperLogLog 的工作原理主要如下：

1）哈希函数：

使用哈希函数将输入元素映射为一个大的二进制数。例如，将一个字符串通过哈希函数转换为一个 64 位的二进制数。

2）前导零计数：

计算哈希值中最左边的连续零的数量。这个数量越大，意味着元素的分布范围越大。

3）存储最大值：

使用一个位图（buckets）来存储不同哈希值的前导零计数的最大值。位图的大小通常是 2^14（16,384 个桶）。

4）基数估计：

根据位图中的最大值和桶的数量，使用 HyperLogLog 算法公式来估计集合的基数。

扩展 HyperLogLog 准确度（了解即可）

HyperLogLog 的标准误差公式是 1.04/sqrt(m），m 是桶的个数，因为 Redis 中用了 16384 个桶。

所以，HyperLogLog 的标准误差是 0.81%。

315.Redis 分布式 Session 实现用户登录的原理是什么？

实现步骤如下：

1. 用户登录过程：用户登录成功后，在后端生成一个唯一的 Session 标识（通常是一个SessionID），用于标识该用户的登录状态。
2. 用户信息存储：用户信息包括用户 id、昵称、角色等，封装到一个 Java 对象中，然后将其存储到 Redis。
3. 生成 SessionID：生成一个唯一的 SessionID，通常是一个随机字符串，用于关联用户和 Session信息。
4. Session 信息存储到 Redis：存储时使用 SessionID 作为键，将用户信息序列化为字符串或其他适当的格式作为值，存储的时效性通常由 Session 的过期时间决定。
5. SessionID 返回给前端：将生成的 SessionID 返回给前端，通常通过 HTTP 的 Cookie 或其他方式返回（这一步由框架帮你做了）
6. 后续请求：用户的后续请求会携带 SessionID，后端通过 SessionID 从 Redis 中获取用户信息，以便进行用户身份验证。
7. Session 过期管理：一定要设置 Session 的过期时间，确保 Session 在用户不活动的一段时间后自动失效，以释放资源并提高安全性。

397.Redis 中的三种高效缓存读写策略是什么？

引言：在某一天面试的时候，小 x 被问到 Redis 三种缓存读写的策略，他懵了，原因是简历上明明是写着熟悉 Redis，因此面试官可以随意向任何一个方向进行开火，大家要注意从小点切入，除非自己是完全能够掌握这门技术的，本文将带你去了解三种常用的缓存读写策略的优缺点和使用场景。

题目

Redis 三种高效缓存读写策略你了解吗？

推荐解析

旁路缓存模式(Cache Aside Pattern)

旁路缓存是最常见的缓存读写模式，适用于读多写少的使用经常。服务端以数据库比如 MySQL 为主，Redis 为辅，进行存储。

写操作流程

1）先更新数据库

2）删除 Redis 中的缓存

读操作流程

1）尝试从缓存中读取数据，读取到数据就直接返回

2）缓存中读取不到，从数据库中读取数据

3）读取完毕后，将数据放入缓存

缓存不一致可能的场景（先删后更）

假如先删除缓存，再更新数据库，大概率会造成缓存不一致。线程 1 把 Redis 中 x 数据删除，此时线程 2 发现缓存中没有数据，从数据库读取，而线程以此时又把数据库中的 x 数据更新，因此线程 2 读取到的就是旧数据，造成了缓存不一致的情况。

缓存不一致发生概率小

被推荐的作法，就是上文讲过的，先更新数据库，再删除缓存。

可能不一致的场景如下

1）缓存中 X（数据） 不存在（数据库 X = 1）

2）线程 1 读取数据库，得到旧值（X = 1）

3）线程 2 更新数据库（X = 2)

4）线程 2 删除缓存

5）线程 1 将旧值写入缓存（X = 1）

6）最终 X 的值在缓存中是 1（旧值），在数据库中是 2（新值），也发生不一致。

此场景需要满足：1）缓存失效 2） 读写请求同步对一个数据进行并发操作 3）更新数据库+删除缓存的时间大于读取和写入缓存的时间，也就是说写操作时间大于度操作时间，因为缓存这块可以不计入，理论发生概率是很小的。

旁路缓存优缺点

优点

1）提高数据访问速度

2）减少主存访问

3）提高并发性

缺点

1）存在缓存数据库不一致情况

2）首次请求数据一定不在缓存（可以缓存预热结合定时任务）

3）写操作频繁会导致缓存被频繁删除，影响缓存命中率。（可以加分布式锁，保证更新数据库同时更新缓存。或者直接设置一个较短的过期时间）

旁路缓存示例代码

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69

import java.util.HashMap;
import java.util.Map;

public class CacheAsideExample {
    // 模拟缓存
    private static Map<String, String> cache = new HashMap<>();

    // 模拟数据库或数据源
    private static Map<String, String> dataSource = new HashMap<>();

    // 从缓存中获取数据
    public static String getDataFromCache(String key) {
        return cache.get(key);
    }

    // 从数据源中获取数据
    public static String getDataFromDataSource(String key) {
        return dataSource.get(key);
    }

    // 将数据存入缓存
    public static void putDataIntoCache(String key, String value) {
        cache.put(key, value);
    }

    // 删除缓存中的数据
    public static void deleteDataFromCache(String key) {
        cache.remove(key);
    }

    // 从数据源中加载数据，并存入缓存
    public static String loadData(String key) {
        String data = getDataFromDataSource(key);
        if (data != null) {
            putDataIntoCache(key, data);
        }
        return data;
    }

    public static void main(String[] args) {
        // 设置数据源
        dataSource.put("key1", "value1");
        dataSource.put("key2", "value2");

        // 从缓存中获取数据，如果不存在则从数据源中加载
        String data1 = getDataFromCache("key1");
        if (data1 == null) {
            data1 = loadData("key1");
        }
        System.out.println("Data1: " + data1);

        // 从缓存中获取数据，如果不存在则从数据源中加载
        String data2 = getDataFromCache("key2");
        if (data2 == null) {
            data2 = loadData("key2");
        }
        System.out.println("Data2: " + data2);

        // 删除缓存中的数据
        deleteDataFromCache("key1");

        // 从缓存中获取数据，如果不存在则从数据源中加载
        String data3 = getDataFromCache("key1");
        if (data3 == null) {
            data3 = loadData("key1");
        }
        System.out.println("Data3: " + data3);
    }
}

读写穿透(Read/Write Through Pattern)

读写穿透策略将 Redis/Memcached 视为数据存储的主要地方，也就是说将缓存充当原本的数据库，利用 Cache 服务负责将数据读取并写入数据库(MySQL、Oracle等)。

写操作流程

1）先查询缓存，缓存不存在，更新数据库

2）缓存存在，先更新缓存，利用 Cache 服务同步更新数据库。

读操作流程

1）从缓存读取数据，读取到返回

2）缓存读取不到，从数据库加载后写入缓存并返回。

和旁路缓存相反，读写穿透，主缓存从数据库。

异步缓存写入(Write Behind Pattern)

只更新缓存，不利用 Cache 服务更新数据库，可以利用消息队列，先存放要消费的信息，然后可以异步批量的更新数据库，一般不使用，但数据库的缓冲池机制是这种策略的一个实现，

适用场景：数据经常变化，一致性要求不高（可以延时同步），比如 PV、UV、点赞量。

其他补充

鱼聪明 AI 的回答：

鱼聪明 AI 地址：https://www.yucongming.com/

1）旁路缓存（Cache Aside）

1.1）优点

• 简单易实现，适用于小规模系统。
• 缓存数据不会过期，不会出现缓存雪崩。

1.2）缺点

• 数据一致性问题，需要应用程序主动更新缓存。
• 缓存数据可能过期，导致缓存击穿。

1.3）使用场景

• 适用于读多写少的场景。
• 数据更新频率不高，对数据实时性要求不高的场景。

2）读写穿透（Cache Through）

2.1）优点

• 数据一致性较好，不会出现数据不一致的情况。
• 缓存数据不会过期，不会出现缓存雪崩。

2.2）缺点

• 需要保证数据源的可靠性和性能。
• 对于大规模系统，可能增加数据源的压力。

2.3）使用场景

• 适用于数据源更新频率高，对数据实时性要求高的场景。
• 数据源具有较好的性能和可靠性。

3）异步缓存写入（Write Behind）

3.1）优点

• 减少对数据源的频繁写入，提高性能。
• 可以缓解瞬时写入压力，提高系统稳定性。

3.2）缺点

• 数据一致性可能受影响，存在一定的数据丢失风险。
• 需要额外的机制来处理数据更新失败的情况。

3.3）使用场景

• 适用于写入频率高，对数据实时性要求不高的场景。
• 对数据丢失一定容忍度的场景。

在实际应用中，根据系统的特点和需求，可以选择合适的缓存读写策略来提高系统性能和稳定性。

欢迎交流

在阅读完本篇文章后，你应该对 Redis 的三种缓存读写策略有了一定了解，一般采用第一个策略进行读写，其他两种策略了解即可，在文末有三个问题将会检验本章的学习，欢迎在评论区发表意见。

1）旁路缓存策略中，如何解决缓存数据过期和缓存击穿的问题？

2）读写穿透策略中，如何确保数据源的可靠性和性能，以及如何处理数据源故障的情况？

3）在实际应用中，如何选择合适的缓存读写策略，考虑到系统的特点和需求？

398.Redis 的五种基本数据类型及其优化技巧是什么？

引言：最近小 X 去面试，面试问了这样一个问题，Redis 的基本数据类型和它们的底层原理介绍一下，可以结合你的项目进行讲解。小 X 不知道这道题该从哪里下手，因为大多数同学只知道 5 种基本数据类型的名称，用过 2、3 种已经是不错的了，而对于底层原理基本一窍不通，本文就会详细地去讲解各种数据类型的一个优化手段以及各自的使用场景和版本迭代情况。

题目

探索 Redis 5 种基本数据类型，轻松掌握优化技巧!

推荐解析

5 种基本数据类型概览

1）String 字符串

2）List 列表

3）Set 集合

4）Hash 散列

5）Zset 有序集合

String 字符串

适用场景：缓存、计数器、分布式锁，图片等等。

底层原理：使用 SDS （简单动态字符串）。对比 C 语言的原生字符串，Redis 可以安全保存二进制数据（比如音频、图片、视频），并且可以 O(1) 获取字符串长度。可以动态扩容，动态增加内存，避免静态数组大小限制。杜绝缓冲区溢出问题，SDS 会检查内存是否足够。减少修改字符串的内存重分配，惰性空间释放+空间预分配策略。

Redis 3.2 以前

1
2
3
4
5
6
7

struct sdshdr {
    // 已经适用的长度
    unsigned int len;
    // 剩余长度
    unsigned int free;
    char buf[];
};

Redis 3.2 以后（为了避免 int 浪费空间)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

/* Note: sdshdr5 is never used, we just access the flags byte directly.
 * However is here to document the layout of type 5 SDS strings. */
struct __attribute__ ((__packed__)) sdshdr5 {
    unsigned char flags; /* 3 lsb of type, and 5 msb of string length */
    char buf[];
};
struct __attribute__ ((__packed__)) sdshdr8 {
    uint8_t len; /* used */
    uint8_t alloc; /* excluding the header and null terminator */
    unsigned char flags; /* 3 lsb of type, 5 unused bits */
    char buf[];
};
struct __attribute__ ((__packed__)) sdshdr16 {
    uint16_t len; /* used */
    uint16_t alloc; /* excluding the header and null terminator */
    unsigned char flags; /* 3 lsb of type, 5 unused bits */
    char buf[];
};
struct __attribute__ ((__packed__)) sdshdr32 {
    uint32_t len; /* used */
    uint32_t alloc; /* excluding the header and null terminator */
    unsigned char flags; /* 3 lsb of type, 5 unused bits */
    char buf[];
};
struct __attribute__ ((__packed__)) sdshdr64 {
    uint64_t len; /* used */
    uint64_t alloc; /* excluding the header and null terminator */
    unsigned char flags; /* 3 lsb of type, 5 unused bits */
    char buf[];
};

List 列表

适用场景：队列、栈、消息队列。

举个例子，实现用户最近浏览记录等功能，可以使用 List 来存储用户的浏览记录，并通过 lpush/ltrim 操作来实现最近浏览记录的管理。

Redis 的 List 采用双向链表支持反向查找和遍历。

Redis 3.2 以前 List 底层采用 LinkedList（双向链表）和 ZipList（压缩列表），Redis 3.2 后引入了 LinkedList 和 ZipList 的结合 QuickList。

Set 集合

适用场景：求交集，并集，适用与好友列表、投票、社交网络、网页 UV(单个IP 访问量，数据量大用 hyperLogLog)、抽奖系统、随机点名等等。

Set 特点无序，不重复。

举个例子，在社交网络平台中，用户可以添加好友、删除好友，查看好友列表等操作。这种场景下，可以使用 Redis 的 Set 集合来存储用户的好友列表。通过使用 Redis 的 Set 集合来存储用户的好友关系，可以实现快速的添加、删除好友操作，并且支持高效的好友列表查询和好友关系分析。同时，Redis 的 Set 集合还支持去重功能，保证每个用户的好友列表中不会出现重复的好友。

Set 底层实现是由哈希表或者整数集合实现的。

1）如果集合的元素都是整数，并且元素个数小于 512 （默认值，可以自定义设置)，Redis 会使用**整数集合(intSet)**作为 Set 类型的底层数据结构，主要目的为了减少内存空间消耗。

2）如果集合元素不满足上述条件，Redis 使用哈希表作为 Set 类型的底层数据结构。

注意事项：大数据量下作交集、差集、并集会导致 Redis 实例阻塞，防范大 Key 问题。

如果是集群模式，建议防止主库在大数据库执行大 Key 被阻塞，选择一个从库完成聚合统计，或者把数据返回客户端，由客户端来完成聚合。

Hash 哈希

哈希由键值对组成，支持添加、删除、查找、求交集、求并集等操作。

适用场景：存储对象的多个属性信息，存储用户信息，购物车等场景。

举个例子，假设我们需要存储每个用户的姓名、年龄和邮箱地址，可以使用 Hash 数据结构来存储这些信息。在 Redis 中，可以使用一个 Hash 对象来表示每个用户的信息，其中 Hash 的键是用户的唯一标识，如用户ID，键值对则存储用户的各个字段信息。

例如

用户ID为 1 的用户信息：姓名：Alice 年龄：25 邮箱地址：alice@example.com

1
2
3

HSET user:1 name Alice
HSET user:1 age 25
HSET user:1 email alice@example.com

Hash 底层实现由压缩列表(ZipList 或者哈希表 Dict)实现。

当哈希类型元素小于 512 个，并且所有元素的值大小（小于64个字节），Redis 使用压缩列表作为底层数据结构。

如果不满足上述条件，采用哈希表作为底层数据结构。

Zset 有序集合

Zset 有序集合相比于 Set 多了一个排序属性 Score 分值，对于有序集合 Zset 来说，每个元素有两个值组成，一个是元素值，一个是排序值（分值）。

使用场景

1）排行榜：可以将用户的分数作为 Zset 中的分数，用户的 ID 作为成员，这样可以根据用户的分数来对用户进行排名。

2）带权重的任务调度：可以将任务的执行时间作为 Zset 中的分数，任务的 ID 作为成员，这样可以按照任务的执行时间对任务进行排序并调度执行。

3）范围查询：可以根据分数的范围来获取一定范围内的成员，如获取分数在某个区间的用户或任务。

举个例子：假设有一个学生社团组织，需要记录学生参加社团活动的积分，并根据积分对学生进行排名。可以使用 Zset 数据结构来存储学生的积分信息，学生的学号作为成员，积分作为分数。

1
2
3

ZADD studentscore 80 1001
ZADD studentscore 75 1002
ZADD studentscore 90 1003

获取学生积分排名

1

ZREVRANGE studentscore 0 -1 WITHSCORES

Zset 类型底层实现由压缩列表(ZipList)或者跳表(SkipList)

如果有序集合的元素小于 128 个，并且每个元素的值小于 64 字节，采用压缩列表作为 Zset 类型的底层数据结构。

如果不满足上述条件，采用跳表（加快查询效率）作为 Zset 类型的底层数据结构。

总结

1）String（字符串）：最简单的数据类型，常用于存储文本、数字等简单数据，适用于缓存、计数器、状态标记等场景。

2）List（列表）：有序的字符串元素集合，支持头部和尾部的插入、删除操作，适用于消息队列、最新消息列表等场景。

3）Set（集合）：不重复的字符串元素集合，支持交集、并集、差集等操作，适用于去重、共同好友、排重等场景。

4）Hash（哈希）：键值对集合，适用于存储对象属性、用户信息、配置信息等场景。

5）Zset（有序集合）：每个元素都关联一个分数，支持按分数排序，适用于排行榜、带权重的任务调度、范围查询等场景。

其他补充

1. 字符串 (String)

• 概述：字符串是Redis中最简单的数据类型，可以存储文本或二进制数据，最大支持512MB。
• 底层原理：Redis内部使用简单的字节数组来存储字符串数据。由于其简单性，字符串在Redis中的操作都非常高效。
• 使用场景：适用于缓存数据、计数器、存储短小的文本等场景。

2. 列表 (List)

• 概述：列表是一个有序的字符串集合，可以包含重复的元素。
• 底层原理：Redis的列表底层使用双向链表实现，支持在两端插入和删除元素，因此在读写两端的操作效率较高。
• 使用场景：适用于实现消息队列、发布订阅系统、实现简单的日志系统等场景。

3. 集合 (Set)

• 概述：集合是一组唯一的字符串集合，不允许重复元素。
• 底层原理：Redis的集合底层使用哈希表实现，因此添加、删除、查找元素的时间复杂度都是O(1)。
• 使用场景：适用于实现好友关系、标签系统、数据去重等场景。

4. 哈希表 (Hash)

• 概述：哈希表是一种键值对的集合，类似于Java中的Map，其中的值也是一个键值对。
• 底层原理：Redis的哈希表底层使用哈希表实现，每个哈希表可以存储多个键值对，对于小哈希表，Redis会使用压缩列表来存储键值对。
• 使用场景：适用于存储对象的属性、缓存对象等场景。

5. 有序集合 (Sorted Set)

• 概述：有序集合是一种有序的字符串集合，每个元素都会关联一个分数，通过分数进行排序。
• 底层原理：Redis的有序集合底层使用跳跃表和哈希表实现，其中跳跃表用于保持元素的有序性，哈希表用于维护元素与分数之间的映射关系。
• 使用场景：适用于实现排行榜、范围查询等场景。

底层原理总结

• Redis的基本数据类型都是在内存中存储的，因此具有高效的读写性能。
• Redis通过使用不同的数据结构来实现不同的数据类型，以满足不同的需求。

使用场景总结

• 字符串适用于存储简单的键值对数据、计数器等。
• 列表适用于实现简单的消息队列、发布订阅系统等。
• 集合适用于实现好友关系、数据去重等。
• 哈希表适用于存储对象的属性、缓存对象等。
• 有序集合适用于实现排行榜、范围查询等。

总的来说，Redis提供了丰富的数据类型和高效的底层实现，能够满足各种不同的应用场景需求。

401.Redis 中的跳表是什么？你了解多少？

引言：你知道 Redis 的 Zset 为什么要用跳表，而不用红黑树或者 B+ 树呢？这是一个经常会被问到的问题，和数据库为什么要设计成 B+ 树，而不是红黑树和平衡树有异曲同工之妙，本文将用带大家展示跳表在 Redis 中的运用。

推荐解析

Zset 的两种底层实现

首先我们需要知道跳表并不是 Zset 的唯一实现，它是可选项，当满足条件时候，就会使用跳表进行效率的提升。

1）Zset 键值对数量少于 128 个

2）每个元素的长度小于 64 字节

如果同时满足上面的两个条件，此时就会采用 ZipList，如果不满足就会采用 SkipList。

普通链表 VS 跳表

1）结构

1.1）有序链表：由一个个节点组成，每个节点包含数据和指向下一个节点的指针。

1.2）跳表：由多层级组成，每一层都是一个有序链表，每一层的节点指向下一层的节点。

2）时间复杂度

2.1）有序链表：插入、删除和查找的平均时间复杂度为O(n)，其中n是链表的长度。

2.2）跳表：插入、删除和查找的平均时间复杂度为O(log n)，其中n是元素的个数。

3）空间复杂度

3.1）有序链表：空间复杂度为O(n)，其中n是链表的长度。

3.2）跳表：空间复杂度为O(n log n)，其中n是元素的个数。

4）插入和删除操作

4.1）有序链表：插入和删除操作需要遍历链表找到插入或删除位置，时间复杂度较高。

4.2）跳表：通过建立多层级索引，插入和删除操作只需更新索引节点，时间复杂度较低。

5）查找操作

5.1）有序链表：查找操作需要遍历整个链表，时间复杂度较高。

5.2）跳表：通过多层级索引，可以快速跳跃到目标位置，查找操作时间复杂度较低。

理想清理，每一层的索引是下一层元素个数的二分之一。

一级索引：16 二级索引：8 三级索引：4 四级索引：2

递推公式可得：H = log2^n-1

理论上 Redis 的一个类型可以放大约 40 亿个实例，2^32-1个。因此索引高度不能超过 32。

每次创建一个新跳跃表节点的时候，程序都会根据幂次定律（zslRandomLevel,越大的数出现的概率越小）随机生成一个介于1和32之间的值作为level数组的大小，这个大小就是层的“高度”。 节点层高确定之后便不会在修改。

1
2
3
4
5
6
7

#define ZSKIPLIST_P 0.25      /* Skiplist P = 1/4 */
int zslRandomLevel(void) {
    int level = 1;
    while ((random()&0xFFFF) < (ZSKIPLIST_P * 0xFFFF))
        level += 1;
    return (level<ZSKIPLIST_MAXLEVEL) ? level : ZSKIPLIST_MAXLEVEL;
}

根据概率论，计算期望，当 p =0.25，期望层高为 1/(1-0.25)=1.33。

红黑树 VS 跳表

1）结构：红黑树是一种二叉搜索树，而跳表是一种多层级的有序链表。

2）平衡性：红黑树通过颜色和规则来保持平衡，而跳表通过多层级索引来提高查询效率。

3）动态性：红黑树和跳表都支持高效的动态操作，包括插入、删除和查找。

4）空间复杂度：红黑树和跳表的空间复杂度都为O(n)，但是跳表的额外索引层级会增加一些额外的空间开销。

主要原因：跳表实现比较简单，并且对于区间查找的效率比较高，红黑树的高度不好控制。

B+ 树 VS 跳表

B+树

1）可以是多叉树（区别二叉树），每个节点可包含多个子节点，减少树的高度，查询效率较高。

2）叶子节点存放真正的 Value，非叶子节点存放多个 Key。

3）平衡性强，高度差控制的不大。

4）因为叶子节点是有一条链表相连的，因此范围查询的效率很高。

主要原因：因为 B+ 树是给数据库用的，数据库存放的数据量比较大，而缓存不需要存储大量数据，跳表不需要节点分裂和合并。跳表会更节省内存，更容易实现和进行 Debug。

跳表插入过程

1）首先定义了一个函数 zslRandomLevel()，用于生成随机的插入元素层高，该函数会根据概率 ZSKIPLIST_P 来确定插入元素的层高，同时限制最大层高为 ZSKIPLIST_MAXLEVEL 。

2）在 zslInsert() 函数中，首先声明了需要更新的节点数组 update[] 和 rank[] ，以及变量 i 和 level 。然后从跳表的头节点开始向下遍历，找到插入元素的位置，并记录每层的跨越节点数量 rank[] 。

3）在获取到插入元素的位置后，判断插入元素的随机层高是否大于当前跳表的层高，如果是则需要补全需要更新的节点，并更新跳表的层高。

4）接着创建新节点 x，并根据随机层高分层插入节点，同时更新同层前一节点的步长信息。最后更新新增节点未涉及层节点的步长信息，以及更新跳表的相关信息。

5）最后将插入节点的前后指针指向正确的节点，并增加跳表的长度。最终返回插入的节点 x 。整个过程保证了插入操作的正确性和效率。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

int zslRandomLevel(void) { 
    int level = 1;
    // (random()&0xFFFF) < (ZSKIPLIST_P * 0xFFFF) 概率为1/4
    while ((random()&0xFFFF) < (ZSKIPLIST_P * 0xFFFF))
        level += 1;
    return (level<ZSKIPLIST_MAXLEVEL) ? level : ZSKIPLIST_MAXLEVEL;
}

zskiplistNode *zslInsert(zskiplist *zsl, double score, sds ele) {
    // update存放需要更新的节点
    zskiplistNode *update[ZSKIPLIST_MAXLEVEL], *x;
    unsigned int rank[ZSKIPLIST_MAXLEVEL];
    int i, level;

    serverAssert(!isnan(score));
    x = zsl->header;
    for (i = zsl->level-1; i >= 0; i--) {
        /* store rank that is crossed to reach the insert position */
        rank[i] = i == (zsl->level-1) ? 0 : rank[i+1];
        while (x->level[i].forward &&
                (x->level[i].forward->score < score ||
                    (x->level[i].forward->score == score &&
                    sdscmp(x->level[i].forward->ele,ele) < 0)))
        {
            rank[i] += x->level[i].span;
            x = x->level[i].forward;
        }
        update[i] = x;
    }
    level = zslRandomLevel();
    if (level > zsl->level) {
        for (i = zsl->level; i < level; i++) {
            rank[i] = 0;
            update[i] = zsl->header;
            update[i]->level[i].span = zsl->length;
        }
        zsl->level = level;
    }
    x = zslCreateNode(level,score,ele);
    for (i = 0; i < level; i++) {
        x->level[i].forward = update[i]->level[i].forward;
        update[i]->level[i].forward = x;

        /* update span covered by update[i] as x is inserted here */
        x->level[i].span = update[i]->level[i].span - (rank[0] - rank[i]);
        update[i]->level[i].span = (rank[0] - rank[i]) + 1;
    }
    /* increment span for untouched levels */
    for (i = level; i < zsl->level; i++) {
        update[i]->level[i].span++;
    }

    x->backward = (update[0] == zsl->header) ? NULL : update[0];
    if (x->level[0].forward)
        x->level[0].forward->backward = x;
    else
        zsl->tail = x;
    zsl->length++;
    return x;
}

其他补充

1. 压缩列表：当有序集合元素数量较少时，Redis会使用压缩列表进行存储。压缩列表是一种紧凑的线性结构，可以节省内存空间。每个元素在压缩列表中占用连续的内存空间，元素之间没有额外的指针等开销。
2. 跳表：当有序集合元素数量较多时，Redis会使用跳表进行存储。跳表是一种有序的数据结构，可以快速地进行查找、插入和删除操作。跳表通过在每个级别添加索引节点来加速查找元素的过程，使得查找的时间复杂度可以达到O(log n)。

实战场景：假设我们需要存储一个社交平台的用户关注列表，其中每个用户关注的人数不定，但是需要按照关注人数的多少进行排序。这时可以使用有序集合来存储用户ID和对应的关注人数，通过有序集合的排序功能可以快速地获取关注人数最多的用户。

跳表的优点：

1. 查询效率高：跳表通过添加索引节点来加速查找元素的过程，使得查询的时间复杂度可以达到O(log n)，效率比较高。
2. 支持范围查找：由于跳表是有序的数据结构，所以可以支持范围查找，例如查找某个范围内的元素。
3. 空间利用率高：跳表通过添加索引节点来加速查找，相比于普通链表来说，空间利用率更高，内存占用更少。

总的来说，跳表在有序集合这种需要快速查找、有序存储的场景下具有明显的优势。

CSDN 某同学的回答

跳表（skiplist）是一种有序的数据结构，它可以通过维护指向每个节点中其他节点的多个指针来快速访问节点。简单来说，跳表是通过向双向链接列添加多个索引而形成的。

与双向链接列表相比，它支持快速搜索、更新和删除，因此适用于需求灵活的场景。

对于双向链表，即使存储在链接列表中的数据是有序的，如果我们想在其中找到某个数据，它也只能从头到尾遍历链接列表，反之亦然。这样搜索效率将非常低，时间复杂度将非常高，达到O（n）。 跳表在搜索某个数据时，首先在索引中找到一个较大的范围，然后再放到原始链接列表中进行精确搜索。因为在添加一层索引后，搜索节点的次数减少了，因此搜索效率大大提高，是典型的空间换时间。

当链表长度相对较大时，索引构建效率将显著提高。第一级链表不是单向链表，而是有序的双向链表。为了以相反的顺序获得范围中的元素。

634.Redis通常应用于哪些场景？

回答重点

1）缓存：Redis 最常用的场景是作为缓存层，以减少数据库的负载，提高数据读取速度。例如，常用的用户会话数据和页面渲染结果可以存储在 Redis 中。

2）实时系统：Redis 支持快速的数据写入和读取，非常适合用于实时分析，如网站点击统计、实时排行榜等。

3）消息队列：利用 Redis 的 List 和 Pub/Sub 功能，可以实现轻量级的消息队列，适用于任务处理和异步消息传递。

4）分布式锁：Redis 可以用作分布式锁的实现，确保在分布式系统中资源的安全访问，避免竟态条件。

5）计数器：Redis 的原子性操作非常适合用作计数器。例如，可以使用 Redis 来统计页面访问量、点赞数、评论数等。通过 INCR 命令可以轻松实现高效的计数。

扩展知识

Redis 的用途有很多，这里再介绍下回答重点提到的几个常见的场景，更多场景需要结合项目去进行拓展。

1.Redis 缓存

因为 Redis 是基于内存的，其读写速度比 MySQL 基于磁盘的方式要快很多，所以其作为热点数据的缓存是非常合适的。使用 Redis 缓存可以极大地提高应用的响应速度和吞吐量

举一个例子，如下图所示，用户访问 Web 服务的时候，可以先查询缓存，如果缓存未命中的话，去查询数据库（这里建议去查询数据库的时候加铁，防止多个请求同时打到数据库，导致数据库查询效率不高），如果数据库中有对应的数据，则写入 Redis 缓存中，并返回给用户，如果数据库没有对应的数据的话，可以写入 null 值到缓存中，应对缓存穿透问题。

2.分布式锁

本地锁（synchronized、lock）在很多时候已经满足不了我们的需求，特别是现在大部分企业都使用了微服务框架，不同实例之间的锁需要依赖外部系统进行一致性锁定，因此就需要用上分布式锁。Redis 就是很好的一个外部系统，它基于缓存使得加锁非常高效，天然的过期机制可以很好地避免死锁的发生，且配合 redission 这种封装好的类库，使用起来也非常简便：

3.计数器

Redis 由于其单线程执行命令的特性，实现计数器非常方便，不会有锁的竞争。像文章的点赞数量就可以使用 Redis 实现。

再如一些海量数据的统计，例如大网站的访问统计、日活月活等，适合使用 Redis 提供的高级数据结构 HyperLogLog。

它基于基数估算算法实现。优点就是所需的内存不会随着集合的大小而改变，因此很适合大规模数据集统计的场景，不过它的统计值是不精确的，有一定的误差，但是在海量数据场景，这些误差一般是可以接受的。

4.消息队列

在一些简单场景，也可以利用 Redis 来实现消息队列功能。例如使用列表的 lpush 实现消息的发布，rpop 实现消息的消费。也可以使用Redis 5.0 之后引入的 stream 这个数据结构来实现消息功能。但是要注意，用 Redis 来实现消息队列肯定比不上正常的消息队列中间件，例如无法保证消息的持久性，即使有 aof 和 rdb 也无法保证消息一定不会丢。

在大型系统或正常的业务场景下，如果要使用消息队列还是得用 RocketMQ、Kafka等，不推荐使用 Redis 来实现。

5.实时系统的构建

由于 Redis 高性能的特性，其经常被用于构建实时系统，比如抽奖、秒杀等，最常见的还有排行榜的实现，其可以使用 Redis 的 Zset 数据结构，根据用户的分数、时间等参数构建一个实时的排行榜。

主要就列举这些了，更多的场景可以结合你的项目去拓展，比如登录鉴权、限流、会话等，都是可以的。

635.Redis 为什么这么快？

回答重点

主要有 3 个方面的原因，分别是存储方式、优秀的线程模型以及 IO 模型、高效的数据结构。

• Redis 将数据存储在内存中，提供快速的读写速度，相比于传统的磁盘数据库，内存访问速度快得多。
• Redis 使用单线程事件驱动模型结合 I/O 多路复用，避免了多线程上下文切换和竞争条件，提高了并发处理效率。
• Redis 提供多种高效的数据结构（如字符串、哈希、列表、集合等），这些结构经过优化，能够快速完成各种操作

扩展知识

存储方式

Redis 的存储是基于内存的，直接访问内存的速度是远远大于访问磁盘的速度的。

一般情况下，计算机访问一次 SSD 磁盘的时间大概是 50 ~ 150 微秒，如果是传统硬盘的话，需要的时间会更长，可能需要 1 ~ 10 毫秒，而你访问一次内存，其需要的时间大概是 120 纳秒。由此可见，其访问的速度差了快一千倍左右。

除了一些场景，比如说持久化，Redis 很少需要与磁盘进行交互，大多数时候 Redis 的读写是基于内存的，因此其效率较高。

优秀的线程模型以及 IO 模型

Redis 使用单个主线程来执行命令，不需要进行线程切换，避免了上下文切换带来的性能开销，大大提高了 Redis 的运行效率和响应速度。

Redis 采用了 I/O 多路复用技术，实现了单个线程同时处理多个客户端连接的能力，从而提高 Redis 的并发能力。

不过 Redis 并不是一直都是单线程的，自 4.0 开始，Redis 就引入了 Unlink 这类命令，用于异步执行删除等操作，还有在 6.0 之后，Redis 为了进一步提升 I/O 的性能，引入了多线程的机制，利用多线程的机制并发处理网络请求，从而减少 Redis 由于网络 I/O 等待造成的影响。

高效的数据结构

Redis 本身提供了丰富的数据结构，比如字符串、哈希、Zset 等，这些数据结构大多操作的时间复杂度都为 O(1)。

备注：答案中的图来自 ByteByteGo：https://blog.bytebytego.com/p/why-is-redis-so-fast

五种 I/O 模型

• 1460. 说说你知道的几种 I/O 模型

Select、Poll、Epoll

• 722. Select、Poll、Epoll 之间有什么区别？

Redis 中常见的数据类型（数据结构）

• 637. Redis 中常见的数据类型有哪些？

• 5206. Redis 源码中有哪些巧妙的设计，举几个典型的例子？

636.为什么 Redis 设计为单线程？6.0 版本为何引入多线程？

回答重点

单线程设计原因：

1. Redis 的操作是基于内存的，其大多数操作的性能瓶颈主要不是 CPU 导致的
2. 使用单线程模型，代码简便的同时也减少了线程上下文切换带来的性能开销
3. Redis 在单线程的情况下，使用 I/O 多路复用模型就可以提高 Redis 的 I/O 利用率了

6.0 版本引入多线程的原因：

1. 随着数据规模的增长、请求量的增多，Redis 的执行瓶颈主要在于⽹络 I/O。引入多线程处理可以提高网络 I/O处理速度。

扩展知识

我们所说的 Redis 单线程，主要指的是 Redis 网络 I/O 和键值对读写这些操作是由一个线程完成的。（持久化、集群等机制其实是有后台线程执行的）

不过 Redis 并不是一直都单线程的，在 4.0 之后就开始引入了多线程指令，6.0 之后便正式引入了多线程的机制，不过 这里的多线程其只是针对网络请求过程使用多线程，其对于数据读写命令的处理依旧是单线程的。

为什么 Redis 前期不使用多线程的方式，等到 6.0 却又引入呢？

主要是因为我们对 Redis 的性能有了更高的要求，因为随着业务愈加复杂，公司需要的 QPS 就越高了，为了提升 QPS ，最直接的做法就是搭建 Redis 的集群，即提高 Redis 的机器数，但是这种做法的资源消耗是巨大的。

而 Redis 单线程执行命令的性能瓶颈在网络 I/O ，虽然它采用了多路复用技术，但 I/O 多路复用模型本质还是同步I/O。

从上面这个图中我们可以看到，I/O 多路复用在处理网络请求的时候，其调用 select（或是 epoll 等）后，如果来数据了，那么将数据从内核拷贝到用户空间这一步是同步的（关于 I/O 场景，阻塞、同步等名词意义请看扩展知识），即用户线程需要等待数据拷贝完成（在 redis 场景就是无法处理命令了），如果并发量很高的话，这个过程可能会成为瓶颈。

综上所示，我们可以发现，多路复用+单线程的设计并不能很好地解决网络 I/O 瓶颈的问题，这个时候就可以考虑利用 CPU 的多核优势，即利用多线程处理网络请求的方式来提高效率，然后对于读写命令， Redis 依旧采用单线程命令。

Redis 引入多线程之后，有没有带来什么线程安全问题呢？

没有，因为 Redis 6.0 只有针对网络请求模块采用的是多线程，对于读写命令部分还是采用单线程，所以所谓的线程安全问题就不存在了。

Redis 6.0 的多线程默认是禁⽤的，只使⽤主线程，因为大部分公司并发量实际上还是用不上这个。

如果要开启需要配置 io-threads-do-reads参数为 yes。

I/O 模型

五种 I/O 模型

同步、异步、阻塞、非阻塞的I/O的区别？

637.Redis中常见的数据类型有哪些?

回答重点

Redis 常见的数据结构主要有五种，这五种类型分别为：String（字符串）、List（列表）、Hash、Set（集合）、Zset（有序集合，也叫sorted set）。

String

字符串是 Redis 中最基本的数据类型，可以存储任何类型的数据，包括文本、数字和二进制数据。它的最大长度为 512MB。

使用场景：

• 缓存：存储临时数据，如用户会话、页面缓存。
• 计数器：用于统计访问量、点赞数等，通过原子操作增加或减少。

Hash

哈希是一个键值对集合，适合存储对象的属性。Redis内部使用哈希表实现，适合小规模数据。

使用场景：

• 商品详情：存储商品的各个属性，方便快速检索。

List

列表是有序的字符串集合，支持从两端推入和弹出元素，底层实现为双向链表。

使用场景：

• 消息队列：用于简单任务调度、消息传递等场景，通过LPUSH 和 RPOP 操作实现生产者消费者模式。
• 历史记录：存储用户操作的历史记录，便于快速访问。

Set

集合是无序且不重复的字符串集合，使用哈希表实现，支持快速查找和去重操作。

使用场景：

• 标签系统：存储用户的兴趣标签，避免重复。
• 唯一用户集合：记录访问过某个页面的唯一用户，方便进行分析。

Sorted Set

有序集合类似于集合，但每个元素都有一个分数（score），用于排序。底层使用跳表实现，支持快速的范围查询。

使用场景：

• 排行榜：存储用户分数，实现实时排行榜。
• 任务调度：根据任务的优先级进行排序，方便调度执行。

扩展知识：四种高级数据类型

随着 Redis 版本的更新，后面又增加 BitMap（2.2 版新增）、HyperLogLog（2.8 版新增）、GEO（3.2 版新增）、Stream（5.0 版新增）。

BitMap

BitMap 是一种以位为单位存储数据的高效方式，适合用来表示布尔值（如存在性、状态等）。每个 bit 可以表示一个状态（0或 1），使用空间少且操作快速。 使用示例：假设要统计每天用户的在线状态，可以用 Bitmap 记录每个用户是否在线：

1
2

SETBIT user:online:2024-09-27 12345 1  #用户 ID 12345 在 2024-09-27 在线
GETBIT user:online:2024-09-27 12345    #获取用户 ID 12345 在该日期的在线状态

HyperLogLog

HyperLogLog 是一种概率性数据结构，主要用于估算基数（不同元素的数量），内存占用固定，适合处理大规模数据的去重和计数。

使用示例：假设要估算访问网站的独立用户数量：

1
2

PFADD unique:visitors userl user2 user3  # 添加用户 ID
PFCOUNT unique:visitors                  # 估算独立用户数量

GEO

GEO 是 Redis 提供的一种用于存储地理位置信息的数据结构，可以存储经纬度信息并支持空间查询，例如计算距离和获取范围内的坐标。

使用示例：假设要存储城市的位置并查找距离某个城市在一定范围内的其他城市：

1
2
3
4

GEOADD cities 13.361389 38.115556 "Palermo"  #添加城市
GEOADD cities 15.087269 37.502669 "Catania"  #添加城市
GEODIST cities "Palermo" "Catania" "km"      #计算两个城市之间的距离
GEORADIUs cities 15.0 37.5 100 km            #查找指定范围内的城市

Stream

Stream 是 Redis 提供的一种日志数据结构，适合于存储时间序列数据或消息流。支持高效的消息生产和消费模式，具有持久性和序列化特性

使用示例：假设要存储传感器数据流，可以使用 Stream 进行数据插入和消费

1
2
3

XADD sensor:data * temperature 22.5 humidity60 # 向 Stream 添加传感器数据
XRANGE sensor:data - +                         # 获取 stream 中的所有数据
XREAD COUNT 10 STREAMs sensor:data $           # 读取新的传感器数据

Redis9 种常见的基本数据类型应用场景汇总

• String：缓存对象、计数器、分布式锁、分布式 session 等
• List：阻塞队列、消息队列（但是有两个问题：1.生产者需要自行实现全局唯一ID；2.不能以消费组形式消费数据）等
• Hash：缓存对象、购物车等
• Set：集合聚合计算（并集、交集、差集）的场景，如点赞、共同关注、收藏等
• Zset：最典型的就是排行榜，这个也是面试中经常问到的点
• BitMap（2.2 版新增）：主要有0和1两种状态，可以用于签到统计、用户登录态判断等
• HyperLogLog（2.8 版新增）：海量数据基数统计的场景，有一定的误差，可以根据场景选择使用，常用于网页 PV、UV 的统计
• GEO（3.2 版新增）：存储地理位置信息的场景，比如说百度地图、高德地图、附近的人等
• Stream（5.0 版新增）：这个主要就是消息队列了，可以实现一个简单的消息，其相比 list 多了两个特性，分别是自动生成全局唯一消息ID以及支持以消费组形式消费数据（同一个消息可被分发给多个单消费者和消费者组），相比 pub/sub 它是可以被持久化。

638.Redis中跳表的实现原理是什么?

回答重点

跳表主要是通过 多层链表来实现，底层链表保存所有元素，而每一层链表都是下一层的子集。

• 插入时：首先从最高层开始查找插入位置，然后随机决定新节点的层数，最后在相应的每一层中插入节点并更新指针。
• 删除时：同样从最高层开始查找要删除的节点，并在各层中更新指针，以保持跳表的结构。
• 查找时：从最高层开始，逐层向下，直到找到目标元素或确定元素不存在。查找效率高，时间复杂度为 O(logn)。

扩展知识

跳表原理详细解析

跳表，一句话概括：就是一个多层索引的链表，每一层索引的元素在最底层的链表中可以找到的元素。如下图所示，这就是一个简单的跳表实现了，每个颜色代表一层，绿色的就是链表的最底层了。

接下来我们通过查询和添加元素来了解其功能流程：

1）查询元素：这里我们与传统的链表进行对比，来了解跳表查询的高效。

假设我们要查找 50 这个元素，如果通过传统链表的话（看最底层绿色的查询路线），需要查找 4 次，查找的时间复杂度为 O（n）。

但如果使用跳表的话，其只需要从最上面的 10 开始，首先跳到 40，发现目标元素比 40 大，然后对比后一个元素比 70 小，于是就到下一层进行查找，然后 40 的下一个 50 刚好符合目标，就直接返回就可以了，这个过程的跳转次数是 3 次，即 10 -> 40（顶层）-> 40（第二层）-> 50（第二层），其流程如下图所示：

跳表的平均时间查询复杂度是 O（logn），最差的时间复杂度是 O（n）。

2）插入元素：我们插入一条 score 为 48 的数据

• 先需要定位到第一个比 score 大的数据。如图所示，一下子就可以定位到 50 了，这里和查询的过程（上文所示）是一样的。
• 在定位到对应节点之后，具体是在当前节点的前驱数据还是增加一个层级这个是随机的，这里假设设置为 2 层。
• 定位层级后，再将每一层的链表节点进行补齐，就是在 40 与 50 之间插入一个新的链表节点 48，插入过程与链表插入是一样的。 最终实现的效果如下图所示：

Redis 中的跳表实现解析

Redis 的跳表相对于普通的跳表多了一个回退指针，且 score 可以重复。

我们先来看一下 Redis 中关于跳表实现的源码：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

typedef struct zskiplistNode {
    //set 对象的元素值
    robj *ele;
    //元素权重值
    double score;
    //后退指针
    struct zskiplistNode *backward;

    //节点的 level 数组，保存每层上的前向指针和跨度
    struct zskiplistLevel {
        struct zskiplistNode *forward;
        unsigned long span;
    } level[];
} zskiplistNode;

这里我们分析一下每个字段的含义：

• ele：这里用到了 Redis 字符串底层的一个实现 sds，其主要作用是用来存储数据。
• score：节点的分数，double 即浮点型数据。
• backward：我们可以看到其是 zskiplistNode 结构体指针类型，即代表着向前一个跳表节点
• level：这个就是 zskiplistNode 的结构体数组了，数组的索引代表着层级索引，这里注意与 hashtable 中的结构进行区分，那个使用的是联合体，一个是 forward，其代表下一个跳转的跳表节点，注意一个点，其是跳转到同一层，span 主要作用代表距离下一个节点的步数。

到这里分析就差不多了，为了方便大家理解，这里放一个相关的图，下图的红色箭头就代表回退指针。

Redis 跳表的实现大致如下图所示：

补充插入的随机层级

新插入的节点位于哪一层在 Redis 中是采用随机的概率函数来决定的。

（以下源码来自 redis7.0）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

#define ZSKIPLIST_MAXLEVEL 32 /* Should be enough for 2^64 elements */
#define ZSKIPLIST_P 0.25      /* Skiplist p = 1/4 */

/* Returns a random level for the new skiplist node we are going to create.
 * The return value of this function is between 1 and ZSKIPLIST_MAXLEVEL
 * (both inclusive), with a power-law-like distribution where higher
 * levels are less likely to be returned. */
int zslRandomLevel(void) {
    static const int threshold = ZSKIPLIST_P*ZSKIPLIST_MAXLEVEL;
    int level = 1;
    while (random() < threshold) {
        level += 1;
        return (level<ZSKIPLIST_MAXLEVEL) ? level : ZSKIPLIST_MAXLEVEL;
    }
    return level;
}

通过调用 zslRandomLevel 方法来决定新插入的节点所在的层数（level），可以看到 level 从 1 开始，通过 while 循环，当产生的随机数小于 RAND_MAX 的最大值的 0.25 倍时 level + 1，即有 25% 的概率累加 level，反之退出循环。

• 节点被分配到第 1 层的概率为 0.75
• 节点被分配到第 2 层的概率为 0.25
• 节点被分配到第 3 层的概率为 0.25 * 0.25

以此类推，节点被分配到第 n 层的概率为 0.25^(n-1)。

所以跳表每一个节点能否新增一层的概率是 25%（最多的层数在 Redis 5.0 中是 64 层，Redis 7.0 中是 32 层）。

为什么 Redis 跳表实现多了一个回退指针（前驱指针）

回退指针主要是为了提高跳表的操作效率和灵活性。

假如删除节点时，通过前驱指针可以在一次遍历中找到并记录所有关联的前驱节点，无需在变更时再次查找前驱节点。这种设计避免了重复查找过程，简化了操作逻辑，大幅提高了删除的执行效率。

尤其是在频繁插入和删除的场景中，回退指针减少了节点之间指针的更新复杂度，提升性能。

639.Redis 的 hash 是什么？

回答重点

Redis 的 hash 是一种键值对集合，可以将多个字段和值存储在同一个键中，便于管理一些关联数据。 特点如下：

1. 适合存储小数据，使用哈希表实现，能够在内存中高效存储和操作。
2. 支持快速的字段操作（如增、删、改、查），非常适合存储对象的属性。

扩展知识

hash 常用命令

HSET：设置 hash 中指定字段的值。

1

HSET user:1001 name "mianshiya"

HGET：获取 hash 中指定字段的值。

1

HGET user:1001 name

HMSET：一次性设置多个字段的值。

1

HMSET user:1001 name "mianshiya" age "18" city "shanghai"

HMGET：一次性获取多个字段的值。

1

HMGET user:1001 name age

HDEL：删除 hash 中的一个或多个字段。

1

HDEL user:1001 age

HINCRBY：为 hash 中的字段加上一个整数值。

1

HINCRBY user:1001 age 1

Hash 底层实现解析

Hash 是 Redis 中的一种数据基础数据结构，类似于数据结构中的哈希表，一个 Hash 可以存储 2 的 32 次方 - 1 个键值对（约 40 亿）。底层结构需要分成两个情况：

• Redis 6 及之前，Hash 的底层是压缩列表加上哈希表的数据结构（ziplist + hashtable）
• Redis 7 之后，Hash 的底层是紧凑列表（Listpack） 加上哈希表的数据结构（Listpack + hashtable）

ziplist 和 listpack 查找 key 的效率是类似的，时间复杂度都是 O（n），其主要区别就在于 listpack 解决了 ziplist 的级联更新问题。

那么 hash 在什么时候使用 ziplist 和 listpack，什么时候使用 Hashtable 呢？

Redis 内有两个值，分别是 hash-max-ziplist-entries （hash-max-listpack-entries）以及 hash-max-ziplist-value（hash-max-listpack-value），即 Hash 类型键的字段个数（默认512）以及每个字段名和字段值的长度（默认64）。

redis 7.0 为了兼容早期的版本，并没有把 ziplist 相关的值删掉。

当 hash 小于这两个值的时候，会使用 listpack 或者 ziplist 进行存储。

当大于这两个值的时候会使用 hashtable 进行存储。

这里需要注意一个点，在使用 hashtable 结构之后，就不会再退化成 ziplist 或 listpack，之后都是使用 hashtable 进行存储。

这里需要注意，这两个值是可以修改的。如下图所示，将其值修改为 4399 以及 2024 并且查询后效果如下图所示：

聊聊 Redis 中的 Hashtable？

面试官可能会细问 Hashtable 相关的知识点。

Hashtable 就是哈希表实现，查询时间复杂度为 O(1)，效率非常快。

看下 HashTable 的结构：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

typedef struct dictht {
    //哈希表数组
    dictEntry **table;
    //哈希表大小
    unsigned long size;  
    //哈希表大小掩码，用于计算索引值
    unsigned long sizemask;
    //该哈希表已有的节点数量
    unsigned long used;
} dictht;

dictht 一共有 4 个字段：

• table：哈希表实现存储元素的结构，可以看成是哈希节点（dictEntry）组成的数组。
• size：表示哈希表的大小。
• sizemask：这个是指哈希表大小的掩码，它的值永远等于 size-1，这个属性和哈希值一起约定了哈希节点所处的哈希表的位置，索引的值 index = hash（哈希值） & sizemask。
• used：表示已经使用的节点数量。

我们再看下哈希节点（dictEntry）的组成，它主要由三个部分组成，分别为 key，value 以及指向下一个哈希节点的指针，其源码中结构体的定义如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

typedef struct dictEntry {
    //键值对中的键
    void *key;
  
    //键值对中的值
    union {
        void *val;
        uint64_t u64;
        int64_t s64;
        double d;
    } v;
    //指向下一个哈希表节点，形成链表
    struct dictEntry *next;
} dictEntry;

结合以上图片，我们可以发现，哈希节点中的 value 值是由一个联合体组成的。因此，这个值可以是指向实际值的指针、64位无符号整数、64 为整数以及 double 的值。

这样设计的主要目的就是为了节省 Redis 的内存空间，当值是整数或者浮点数的时候，可以将值的数据存在哈希节点中，不需要使用一个指针指向实际的值，从一定程度上节省了空间。

渐进式 rehash

还需要了解另一个面试重点，Redis 的渐进式 rehash。

从字面意思上来说，就是一点点地扩容，而不是直接一次性完成扩容。

我们再来看这个图：

dict 有两个 dictht 组成，为什么需要 2 个哈希表呢？主要原因就是为了实现渐进式。

在平时，插入数据的时候，所有的数据都会写入 ht[0] 即哈希表 1，ht [1] 哈希表 2 此时就是一张没有分配空间的空表。

但是随着数据越来越多，当 dict 的空间不够的时候，就会触发扩容条件，其扩容流程主要分为三步：

1）首先，为哈希表 2 即分配空间。新表的大小是第一个大于等于原表 2 倍 used 的 2 次方幂。举个例子，如果原表即哈希表 1 的值是 1024，那个其扩容之后的新表大小就是 2048。

分配好空间之后，此时 dict 就有了两个哈希表了，然后此时字典的 rehashidx 即 rehash 索引的值从 -1 暂时变成 0 ，然后便开始数据转移操作。

2）数据开始实现转移。每次对 hash 进行增删改查操作，都会将当前 rehashidx 的数据从在哈希表 1 迁移到 2 上，然后 rehashidx + 1，所以迁移的过程是分多次、渐进式地完成。

注意：插入数据会直接插入到 2 表中。

3）随着操作不断执行，最终哈希表 1 的数据都会被迁移到 2 中，这时候进行指针对象进行互换，即哈希表 2 变成新的哈希表 1，而原先的哈希表 1 变成哈希表 2并且设置为空表，最后将 rehashidx 的值设置为 -1。

就这样，渐进式 rehash 的过程就完成了。

Hash 扩容以及缩容的条件

Redis 具体在什么时候会进行扩容和缩容呢？

我们先来说一下扩容，这里涉及到一个概念，即负载因子，redis 中 hash 的负载因子计算有一条公式：

1

负载因子 = 哈希表已保存节点的数量 /  哈希表的大小

Redis 会根据负载因子的情况决定是否采取扩容：

1. 负载因子大于等于 1，这个时候说明空间非常紧张，新数据是在哈希节点的链表上找到的，这个时候如果服务器没有执行 RDB 快照或者 AOF 重写这两个持久化机制的时候，就会进行 rehash 操作。
2. 当负载因子大于等于 5，这个时候说明哈希冲突非常严重了，这个时候无论有没有进行 AOF 重写或者 RDB 快照，都会强制执行rehash 操作。

缩容也和负载因子有关，当负载因子小于 0.1 的时候，就会进行缩容操作。这个时候新表大小是老表的 used 的最近的一个 2 次方幂。例如老表的 used = 1000，那么新表的大小就是 1024。如果没有执行 RDB 快照和 AOF 重写的时候就会进行缩容，反之不会进行。

640.Redis和Memcached有哪些区别？

回答重点

从数据结构上：

• Redis：支持多种数据结构，如字符串、列表、集合、有序集合和哈希表，适合存储复杂数据类型。
• Memcached：仅支持简单的键值对存储，数据结构较为单一。

从持久化上：

• Redis：支持持久化功能，可以将数据保存在磁盘上，通过 RDB 和 AOF 两种方式实现数据的持久化。
• Memcached：不支持数据持久化，重启后数据会丢失，适合临时数据存储。

从分布式架构上：

• Redis：内置支持主从复制和集群分片（Redis Cluster），能在分布式环境中提供高可用性和扩展性。
• Memcached：没有内置分片支持，需要在客户端代码中实现分布式逻辑。

从功能上：

• Redis：支持发布订阅、Lua 脚本等特性。
• Memcached：特性较少。

扩展知识

内存管理

• Redis：使用高效的内存管理算法，支持内存回收策略（如 LRU、LFU 和 TTL）来管理内存使用。
• Memcached：使用 slab 分配器管理内存，以避免内存碎片，但对内存使用的控制不如 Redis 灵活。

Redis 内存淘汰策略

• 643.Redis 中有哪些内存淘汰策略？

641.Redis支持事务吗？如何实现？

回答重点

Redis 支持事务，但它的事务与 MySQL 中的事务有所不同。MySQL 中的事务主要支持 ACID 的特性，而 Redis 中的事务主要保证的是多个命令执行的原子性，即所有的命令在一个原子操作中执行，不会被打断。

还有一个很重要的点，就是 MySQL 中的事务是支持回滚的，而 Redis 中的事务是不支持回滚的。

扩展知识

Redis 的事务

Redis 支持事务，通过使用 MULTI、EXEC、WATCH 和 DISCARD 等命令来实现。事务中的命令会被排队并在调用 EXEC 时一次性执行，保证了事务的原子性。

具体实现流程如下：

1. 开始事务：使用 MULTI 命令开始一个事务，之后的所有命令都会被排队。
2. 添加命令：在事务中添加命令，这些命令不会立即执行，而是存储在队列中。
3. 执行事务：使用 EXEC 命令执行队列中的所有命令，确保原子性。
4. 取消事务：使用 DISCARD 命令可以放弃事务，清空命令队列。
5. 监视键：使用 WATCH 命令可以监视一个或多个键，如果在事务执行前这些键被修改，则 EXEC 将不会执行，确保数据一致性。

Redis 事务不支持回滚功能

Redis 事务一旦执行，所有命令都会被应用到数据中，即使其中某个命令失败。因此，在设计时需充分考虑可能的错误。

Redis 官网也进行了相关描述，如下图所示：

从 Redis 2.6.5 开始，服务器会在累计命令的过程中检测到错误，此时执行 EXEC 会拒绝执行事务，并且返回一个错误，同时丢弃该事务。

但如果事务执行的过程中发生了错误，Redis 会继续执行剩下的命令，并不会对事务进行回滚，这个是 Redis 和 MySQL 最不一样的地方，并且也不支持多种隔离级别的设置，因为 Redis 是单线程执行，只能是串行隔离级别。

可以认为 Redis 的事务是一个残血的事务，更多只是一个噱头，不是我们平时理解的事务。

642.Redis数据过期后的删除策略是什么？

回答重点

Redis 数据过期主要有两种删除策略，分别为定期删除、惰性删除两种：

• 定期删除：Redis 每隔一定时间（默认是 100 毫秒）会随机检查一定数量的键，如果发现过期，则将其删除。这种方式能够在后台持续清理过期数据，防止内存膨胀。
• 惰性删除：在每次访问键时，Redis 检查该键是否已过期，如果已过期，则将其删除。这种策略保证了在使用过程中只删除不再需要的数据，但在不访问过期键时不会立即清除。

扩展知识

定期删除细节

定期删除策略是 Redis 内部的一个定时任务，周期性（每 100ms）地扫描一些设置了过期时间的键。

要注意，Redis 并不会一次性扫描所有设置了过期时间的键，因为这样会消耗大量的 CPU 资源。它会在每次扫描时限制扫描的时间和数量，以避免对性能产生过大的影响，因此可能会有部分键过期了没有被及时删除。

每次获取 20 个 key 判断是否过期，如果发现过期的 key 占比超过 25% 则继续再拉 20 个，如果小于 25% 则停止。这里还有一个时间限制，即一次删除时间不超过 25ms，即如果发现占比超过 25% 的时候，需要判断目前是否已经花了 25ms，如果已经用了这么多时长也结束。

惰性删除优缺点

• 优点：可以减少 CPU 的占用，因为只有查询到了相关的数据才执行删除操作，不需要主动去定时删除。
• 缺点：如果一直没有查询一个 Key，就有可能不会被删除，这样就容易造成内存泄漏问题。

内存回收机制

实际上，除了这两个删除，还有一个机制也会淘汰 key，即当 Redis 内存使用达到设置的 maxmemory 限制时，会触发内存回收机制。此时会主动删除一些过期键和其他不需要的键，以释放内存。具体的删除策略有以下几种：

• volatile-lru：从设置了过期时间的键中使用 LRU（Least Recently Used，最近最少使用）算法删除键。
• allkeys-lru：从所有键中使用 LRU 算法删除键。
• volatile-lfu：从设置了过期时间的键中使用 LFU（Least Frequently Used，最少使用频率）算法删除键。
• allkeys-lfu：从所有键中使用 LFU 算法删除键。
• volatile-random：从设置了过期时间的键中随机删除键。
• allkeys-random：从所有键中随机删除键。
• volatile-ttl：从设置了过期时间的键中根据 TTL（Time to Live，存活时间）删除键，优先删除存活时间短的键。
• noeviction：不删除键，只是拒绝写入新的数据。

Redis 在正常情况下对过期键的处理就是惰性删除 + 定期删除一起使用，主动删除（内存回收）其实属于异常的兜底处理了。

Redis 键过期时间的设置

• EXPIRE：设置键的过期时间（以秒为单位）。
• PEXPIRE：设置键的过期时间（以毫秒为单位）。
• SETEX：在设置键值的同时定义过期时间。
• PSETEX：类似于 SETEX，但支持毫秒级的过期时间。

643.Redis中有哪些内存淘汰策略？

回答重点

Redis 的内存淘汰策略一共有 8 种。8 种里面可以细分为两大类，即开启数据淘汰和不开启数据淘汰这两大类，然后开启数据的那一类又可以进行细分，分为基于过期时间的淘汰策略以及全部数据的淘汰策略。

不淘汰数据（默认）：

• noeviction：当运行内存超过最大设置内存的时候，不会淘汰数据，而是直接返回报错禁止写入

设置了过期时间的数据淘汰：

• volatile-random：随机淘汰掉设置了过期时间的 key
• volatile-ttl：优先淘汰掉较早过期的 key
• volatile-lru（redis3.0之前默认策略）：淘汰掉所有设置了过期时间的，然后最久未使用的 key
• volatile-lfu（redis4.0后新增）：与上面类似，不过是淘汰掉最少使用的 key

所有数据的数据淘汰：

• allkeys-random：随机淘汰掉任意的 key
• allkeys-lru：淘汰掉缓存中最久没有使用的 key
• allkeys-lfu（redis4.0后新增）：淘汰掉缓存中最少使用的 key

扩展知识

不同淘汰策略适用场景

• noeviction：适用于所有数据都被持久化或避免丢失任何数据的场景。
• allkeys-lru：适用于希望保证最常访问的数据在内存中的场景。如电商促销活动中，某些商品会在短时间内被频繁访问，此时不会被淘汰。
• allkeys-lfu：适用于希望保证访问频率最高的数据在内存中的场景。如社交媒体或直播类应用中，某些热点内容访问次数高，不能被淘汰。
• allkeys-random：适用于对数据没有严格的优先级需求。
• volatile-lru：同 allkeys-lru，仅只关心设置了过期时间的键。
• volatile-random：同 allkeys-random，仅只关心设置了过期时间的键。
• volatile-ttl：适用于对实时性较敏感的场景，比如存储用户会话等。
• volatile-lfu：同 allkeys-lru，仅只关心设置了过期时间的键。

noeviction 演示

通过 config set maxmemory 先将其内存大小修改至 2 字节，然后设置一个超过 2 字节的字符串值 99999，其会报一个 OOM 的错误，并且不允许写入。

不过需要注意一个点，虽然其不支持写入数据，但是已有的数据并不会删除，其还是可以进行查询和删除操作，如下图所示，这里演示了 keys * 指令，发现其执行结果正常。

这里补充一个知识点，如果不设置最大内存大小或者设置最大内存大小为 0 的话，在 64 位操作系统下不限制内存大小，在 32 位操作系统下最多使用 3 GB 内存。

内存淘汰配置

可以通过修改 Redis 配置文件（redis.conf）中的 maxmemory-policy 参数来设置不同的内存淘汰策略（配置后需要重启 redis，重启重启后配置不会丢失）。

例如：

1

maxmemory-policy allkeys-lru

或者通过 Redis 命令动态设置（立即生效，不需要重启，但是重启后就失效了）：

1

CONFIG SET maxmemory-policy allkeys-lru

644.Redis的Lua脚本功能是什么？如何使用？

回答重点

Redis 的 Lua 脚本功能允许用户在 Redis 服务器端执行自定义的 Lua 脚本，以实现原子操作和复杂逻辑。其核心点包括：

• 原子性：Lua 脚本的所有命令在执行过程中是原子的，避免了并发修改带来的问题。
• 减少网络往返次数：通过在服务器端执行脚本，减少了客户端和服务器之间的网络往返次数，提高了性能。
• 复杂操作：可以在 Lua 脚本中执行复杂的逻辑，比如批量更新、条件更新等，超过了单个 Redis 命令的能力。

例如常见基于 Redis 实现分布式锁就需要结合 lua 脚本来实现。

lua 本身是不具备原子性的，但由于 Redis 的命令是单线程执行的，它会把整个 lua 脚本作为一个命令执行，会阻塞其间接受到的其他命令，这就保证了 lua 脚本的原子性。

扩展知识

Lua 脚本的基本结构

调用 Redis 命令：

• 使用 redis.call 调用 Redis 原生命令。
• 使用 redis.pcall 进行安全调用，如果脚本中的某些命令失败，可以捕获错误，而不是直接中断执行。这样可以在脚本内处理错误。

参数传递：

• keys 表示传入的键名数组。
• Argv 表示传入的参数数组。

Lua 脚本使用示例

基本的 GET 和 SET 操作

1

EVAL "local value = redis.call('get', KEYS[1]) if not value then redis.call('set', KEYS[1], ARGV[1]) end return value" 1 mykey "default_value"

分析： 这段脚本首先获取键 mykey 的值。

• 如果 mykey 不存在，则设置其值为 default_value。
• 返回 mykey 的当前值。

步骤：

1. redis.call('get', KEYS[1]) 获取键的值。
2. if not value then redis.call('set', KEYS[1], ARGV[1]) end 检查值是否存在，不存在则设置默认值。
3. return value 返回当前值。

原子递增计数器

1

EVAL "local current = redis.call('INCR', KEYS[1]) return current" 1 counter_key

分析： 这段脚本使用 INCR 原子性地递增 counter_key 的值。

步骤：

1. redis.call('INCR', KEYS[1]) 直接递增。
2. 返回递增后的值。

限流控制

假设我们要实现一个简单的限流器，每分钟允许访问 100 次。

1
2
3
4
5
6
7
8

if current < ARGV[1] then
    redis.call('INCR', KEYS[1])
    redis.call('EXPIRE', KEYS[1], 60)
    return true
else
    return false
end
]] 1 rate_limit_key 100

分析：

• 该脚本检查当前的访问次数是否超过限制。
• 如果未超过限制，则增加计数并设置过期时间。
• 返回布尔值表示是否允许访问。

步骤：

1. local current = tonumber(redis.call('GET', KEYS[1]) or 0) 获取当前计数，默认为 0。
2. 判断是否小于限制值 ARGV[1]。
3. 若未超过，则 INCR 当前计数并设置过期时间。
4. 返回布尔值表示是否允许访问。

Lua 预加载脚本

可以使用 SCRIPT LOAD 将 Lua 脚本预加载到 Redis，以提高执行效率：

1

SCRIPT LOAD "return redis.call('GET', KEYS[1])"

此命令返回脚本的 SHA1 哈希值，后续可用 EVALSHA 命令通过该哈希值执行。

Lua 脚本使用注意点

由于 Redis 执行 Lua 脚本期间，无法处理其他命令，因此如果 Lua 脚本的业务过于复杂，则会产生长时间的阻塞，因此编写 Lua 脚本时应尽量保持简短和高效。

Redis 默认限制 Lua 执行脚本时间为 5s，如果超过这个时间则会终止且抛错，可以通过 lua-time-limit 调整时长。

如果 Lua 脚本中的部分命令执行失败会怎样？

例如以下这段 lua 脚本：

1
2
3
4
5

-- 正确的 SET 命令
redis.call("SET", "my_key", "mianshiya")

-- 错误的 HSET 命令
redis.call("HSET", "my_hash", "field_mianshiya") -- 缺少值参数

此时，执行上述的 lua 脚本，my_key 会被成功执行，由于 HSET 缺少参数，会报错，而 my_key 并不会被回滚。

所以实际上 Lua 脚本并不能完全保证原子性，但是官方认为这种错误正常情况下不可能发生，属于开发者的人为因素（语法错误，或者执行了不应该执行的命令）导致的，他们不背这个锅。

Lua 知识点

Lua 语言是一门轻量级的脚本语言，使用 C 语言编写，具有简洁的语法，易于学习和使用，广泛应用于游戏开发、嵌入式系统等领域。它设计的主要目的是为了嵌入其他程序，实现灵活的扩展和定制功能，并且具备快速的执行速度，能够满足各种开发需求。

Lua 语言具有以下优点：

1. 轻量级：占用资源少，易于嵌入其他程序。
2. 简洁高效：语法简单，执行效率高。
3. 跨平台：可在多种操作系统上运行。
4. 扩展性强：方便与其他语言集成。
5. 快速开发：减少开发时间和成本。
6. 灵活性高：适应各种不同的项目需求。
7. 易于学习：入门难度低，容易掌握。
8. 解释执行：无需编译，便于调试。
9. 资源占用少：对系统资源的需求相对较低。
10. 社区活跃：有丰富的文档和工具支持。

645.Redis 的Pipeline功能是什么？

回答重点

Redis 的 Pipeline 功能允许客户端在一次网络请求中批量发送多个命令，以减少网络延迟并提高性能。通过将多个命令打包发送，客户端可以在不等待每个命令响应的情况下继续发送其他命令，从而显著提高吞吐量。

好处：

• 节省了网络传输时间
• 减少了 Redis 服务端上下文切换带来的开销

扩展知识

与事务的区别

• Pipeline 并不保证命令的原子性，也不支持事务特性。如果某个命令失败，其他命令仍会继续执行。
• Redis 的事务是通过 MULTI、EXEC 命令实现的，可以保证一组命令的原子性。

使用注意事项

需要注意 Pipeline 不宜包装过多的命令，因为会导致客户端长时间的等待，且服务器需要使用内存存储响应，所以官方推荐最多一次 10k 命令。

还有一点需要注意 pipeline 命令执行的原子性不能保证，如果要保证原子性则使用 lua 脚本或者事务。

Pipeline 示例代码

Java 的 Jedis 库实现

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

import redis.clients.jedis.Jedis;
import redis.clients.jedis.Pipeline;

public class RedispipelineExample {
    public static void main(String[] args) {
        // 创建 Redis 连接
        Jedis jedis = new Jedis("localhost", 6379);
        // 开始 pipeline
        Pipeline pipeline = jedis.pipelined();
        // 批量设置键值对
        for (int i = 0; i < 1000; i++) {
            pipeline.set("key" + i, "value" + i);
        }
        // 执行所有命令
        pipeline.sync();
        // 关闭连接
        jedis.close();
    }
}

使用 Python 的 redis-py 库：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

import redis

r = redis.StrictRedis(host='localhost', port=6379, db=0)
pipeline = r.pipeline()

for i in range(1000):
    pipeline.set(f'key{i}', f'value{i}')

# 执行所有命令
pipeline.execute()

性能测试

使用 pipeline 可以在性能测试中显著减少与 Redis 的交互延迟，适合在高负载情况下进行优化。参考网络上的一个执行实验结果，使用 Pipeline 性能提升了 100 倍。

• 非 pipeline 操作 10000 次字符串数据类型 set 写入，耗时：1073 毫秒
• pipeline 操作 10000 次字符串数据类型 set 写入，耗时：10 毫秒

Pipeline 进一步分析

正常情况下，如果要执行多条命令，那么操作如下：

而 Redis pipeline（管道）使得客户端可以一次性将要执行的多条命令封装成块一起发送给服务端，具体过程如下图所示：

Redis 服务器在收到来自管道发送的多条命令之后，会先把这些命令按序执行，并将执行结果保存到缓存中，直到最后一条命令执行完成，再把命令执行的结果一起返回给客户端。

Redis 使用 pipeline 主要有以下好处：

1）节省了 RTT

RTT（Round Trip Time）即往返时间。Redis 客户端将要执行的多条命令一次性给服务器，显然减少了往返时间。

拿快递来理解，将所有快递都装进卡车在两地一次性配送和将快递分批装进面包车，多次往返两地送完快递。很显然一次性用卡车送完花在两地往返的时间最短。

2）减少了上下文切换带来的开销

当服务器需要从网络中读取数据时，都会产生一次系统调用，系统调用是非常耗时的操作。其中涉及到程序由用户态切换到内核态，再从内核态切换回用户态的过程。当我们执行 100 条 Redis 指令的时候，就发生 100 次用户态到内核态之间上下文的切换，但是如果使用管道的话，虽然多条命令一同发送给服务器，就只需要进行一次上下文切换就好了，这样就可以节省性能。

646.Redis中的Big Key问题是什么？如何解决？

回答重点

Redis 中的 “big Key” 是指一个内存空间占用比较大的键（Key），它有什么危害呢？

• 内存分布不均：在集群模式下，不同 slot 分配到不同实例，如果大 key 被映射到一个实例，则分布不均，查询效率也会受影响。
• 由于 Redis 单线程执行命令，操作大 Key 时耗时较长，从而导致 Redis 出现其它命令阻塞的问题。
• 大 Key 对资源的占用大，在你进行网络 I/O 传输的时候，导致你获取过程中产生的网络流量较大，从而产生网络传输的延迟长甚至网络传输发现阻塞的现象。例如一个 key 2MB，请求 1000 次 2000 MB。
• 客户端超时。因为操作大 Key 时耗时较长，可能导致客户端等待超时。

如何解决 big key 问题？

可以从以下几个方向进行入手：

开发方面

• 对要存储的数据进行压缩，压缩之后再进行存储
• 大化小，即把大对象拆分成小对象，即将一个大 Key 拆分成若干个小 Key，降低单个 Key 的内存大小
• 使相合适的数据结构进行存储，比如一些用 String 存储的场景，可以考虑使用 Hash、Set 等结构进行优化

业务层面

• 可以根据实际情况，调整存储策略，只存一些必要的数据。比如用户的不常用信息（地址等）不存储，仅存储用户 ID、姓名、头像等。
• 优化业务逻辑，从根源上避免大 Key 的产生。比如一些可以不展示的信息，直接移除等。

数据分布方面

• 采用 Redis 集群方式进行 Redis 的部署，然后将大 Key 拆分散落到不同的服务器上面，加快响应速度

扩展知识

怎样算 big key？

大 Key 可能出现在不同的场景中，不过其本质都是相同的，就是对应的值其所占内存非常大。例如：

1）大型字符串

1

set key "面试鸭xxxxxx······（此处省略无数个字符）"

2）大型哈希表

1

HMSET student:8927 name "yupi" nickname "面试鸭" 

这个时候可能有同学会问了，到底占用多少的存才算得上是 big key 呢？ 其实这个没有一个很绝对的说法，主要还是取决于具体的场景以及应用需求。参考阿里云redis文档：

当然，这些标准并不是绝对的，具体的情况还是需要根据应用场景和实际情况来进行调整，这个需要你在面试前说明清楚。

使用 bigkeys 命令查询 bigkeys

这个是 Redis 内置的指令，直接在 Redis 的客户端 redis-cli 中就可以调用使用，该命令可以获取 Redis 的整体信息，并且显示各种类型数据中最大的 Key。 如下所示，在命令行终端输入 redis-cli --bigkeys 就可以看到（docker 版本的还可能会出现查找失败的情况）。

这种方法有优点，就是其是 Redis 内置的，其统计非常方便。

它的原理就是 Redis 内部执行 scan 命令，遍历整个实例所有的 Key，针对 key 的类型执行 strlen、hlen、scard 等命令获取字符串长度或集合的元素个数。

所以在线上执行这个命令的需要，需要关注性能问题，可以通过 -i 命令控制扫描的休息间隔，时间单位是秒。

还有一点，元素多不一定代表占用的内存多，需要实际评估下。

647.如何解决 Redis 中的热点 key 问题？

回答重点

Redis 中的热点 Key 问题是指某些 Key 被频繁访问，导致 Redis 的压力过大，进而影响整体性能甚至导致集群节点故障。

解决热点 Key 问题的主要方法包括：

• 热点 key 拆分：将热点数据分散到多个 Key 中，例如通过引入随机前缀，使不同用户请求分散到多个 Key，多个 key 分布在多实例中，避免集中访问单一 Key。
• 多级缓存：在 Redis 前增加其他缓存层（如 CDN、本地缓存），以分担 Redis 的访问压力。
• 读写分离：通过 Redis 主从复制，将读请求分发到多个从节点，从而减轻单节点压力。
• 限流和降级：在热点 Key 访问过高时，应用限流策略，减少对 Redis 的请求，或者在必要时返回降级的数据或空值。

扩展知识

热点 key 的定义

热点 Key 与 big key 一样，没有一个很明确的定义来约定什么样的 key 叫做热点 key。

我们可以参考阿里云 Redis 对热 key 的定义：

可以看到，如果一个 key 的访问频率占比过大，或带宽占比过大，都属于热点 key。

由于 Redis 的读写是单线程执行的，所以热点 key 可能会影响 Redis 的整体效率，消耗大量的 CPU 资源，从而降低 Redis 的整体吞吐量。集群环境下会使得流量不均衡，从而导致读写热点倾斜问题的发生。

如何发现热 key？

1）根据业务经验进行分析

这个主要就是依据业务场景进行分析，通过经验判断哪些 key 可能成为热门 key，比如某明星的花边新闻、秒杀活动，演唱会门票等。

• 优点：这个方案实现起来简单直接，只有直接进行判断就可以了，基本没有什么成本。
• 缺点：这个主要依据业务能力，对于业务能力有一定的要求，并且不是所有的业务都能判断出来是否是热 key 的。且有些突发事情是无法预测的。

2）redis 集群监控

这种方式主要依据与 Redis 集群，我们只需要查看集群中哪个 Redis 出现 QPS 倾斜，而出现 QPS 倾斜的实例有极大的概率存在热点 Key。

• 优点：这种方案和上面差不多，由于企业的 Redis 大多数是集群部署，所以使用起来非常简单。
• 缺点：每次发生状况都需要排查，因为不一定所有的 QPS 倾斜都是热 Key 导致的。

3）使用 hotkey 监控

这个是 Redis 4.0 版本之后引入的一个新的指令，只需要在命令行执行 redis-cli 的时候加上 –hotkeys 的选项就可以了。它是通过 scan + object freq 实现的。

• 优点：因为这个命令是 Redis 自带的，使用起来简单快捷
• 缺点：需要扫描整个 keyspace，如果 Redis 中的 key 数量比较多的话，可能导致执行时间非常长，且实时性不好。

4）使用 monitor 命令

如下图所示，这个是 Redis 自 1.0 起就支持的功能。

当通过 MONITOR 命令开启监视器之后，Redis 只需要在执行之后结合一些日志和相关的分析工具就可以进行统计。

• 优点：这个方案的优点在于这个是 Redis 原生支持的功能，使用起来简单快捷。
• 缺点：monitor 非常消耗性能，单个客户端执行 monitor 就会损耗 50% 的性能！不推荐这个方式！

以下为 redis 官网的 benchmark：

5）客户端收集

在操作 Redis 之前，通过加上统计 Redis 键值查询频次的逻辑，将统计数据发送给一个聚合计算平台进行计算，计算之后查看相对应的结果

• 优点：对性能损耗较低。
• 缺点：成本较大，企业如果没有聚合计算平台还需要引入。

6）代理层收集

在代理层进行统一的收集，因为有些服务在请求 Redis 之前都会请求一个代理服务，这种场景可以使用在代理层收集 Redis 热 Key 数据，和在客户端收集比较类似。

• 优点：客户端使用方便，不需要考虑 SDK 多语言异构差异和升级成本高的问题。
• 缺点：需要给 Redis 定制一个代理层，进行转发等操作，构建代理成本不低，且转发有性能损耗。

应用程序中的多级缓存

在应用程序中，一般结合使用一级缓存和二级缓存：

• 一级缓存：一般指的是应用程序本地缓存（如 JVM 内存中的缓存）。
• 二级缓存：则为 Redis 缓存。当数据不在一级缓存中时，才会请求二级缓存。

通过这种多级缓存架构，可以有效减少 Redis 的访问次数，从而避免单 Key 的热点问题。

热点 key 的拆分

我们可以按照不同场景做不同的“拆分“。有些场景可以全量拷贝，即将 mianshiya 这个 key 复制成 mianshiya_1、mianshiya_2、mianshiya_3 ，它们之间的数据是一致的，这样不同用户都访问到全量的数据。

有些场景直接进行 key 的拆分，mianshiya_1、mianshiya_2、mianshiya_3 各存一部分的数据，不同用户仅需访问不同数据即可，例如一些推流信息，因为一个热点往往有很多发布者，大家看一部分，后续热度稍微降低下来，可以替换数据。

不同用户可以进行 hash，将用户 id 哈希之后取余得到后缀，拼上 mianshiya_ 即可组成一个 key。

648.Redis 的持久化机制有哪些？

回答重点

Redis 提供两种主要的持久化机制：

RDB（Redis Database）快照：

• RDB 是通过生成某一时刻的数据快照来实现持久化的，可以在特定时间间隔内保存数据的快照。
• 适合灾难恢复和备份，能生成紧凑的二进制文件，但可能会在崩溃时丢失最后一次快照之后的数据。

AOF（Append Only File）日志：

• AOF 通过将每个写操作追加到日志文件中实现持久化，支持将所有写操作记录下来以便恢复。
• 数据恢复更为精确，但文件体积较大，重写时可能会消耗更多资源。

Redis 4.0 新增了 RDB 和 AOF 的混合持久化机制。

扩展知识

RDB 持久化详解

RDB 持久化通过创建快照来获取内存某个时间点上的副本，利用快照可以进行方便地进行主从复制，默认快照文件为 dump.rdb。

redis.conf 文件可以配置在 x 秒内如果至少有 y 个 key 发生变化就会触发命令进行持久化操作。

它的优点：

• 快速加载：RDB 生成的快照文件是压缩的二进制文件，适合备份和灾难恢复。
• 低资源占用：RDB 持久化在 Redis 主线程之外进行，不会对主线程产生太大影响。

它的缺点：

• 数据丢失风险：由于 RDB 是间隔性保存的快照，如果 Redis 崩溃，可能会丢失上次保存快照后的数据。

RDB 持久化命令：

• save：在主线程生成 RDB 文件，因此生成其间，主进程无法执行正常的读写命令，需要等待 RDB 结束。
• bgsave：利用 Fork 操作得到子进程，在子进程执行 RDB 生成，不会阻塞主进程，默认使用 bgsave。

bgsave 流程（重点）：

1）检查子进程（检查是否存在 AOF/RDB 的子进程正在进行），如果有返回错误

2）触发持久化，调用 rdbSaveBackground

3）开始 fork，子进程执行 rdb 操作，同时主进程响应其他操作。

4）RDB 完成后，替换原来的旧 RDB 文件，子进程退出。

注意事项（重点）：

1）Fork 操作会产生短暂的阻塞，微秒级别操作过后，不会阻塞主进程，整个过程不是完全的非阻塞。

2）RDB 由于是快照备份所有数据，而不是像 AOF 一样存写命令，因为 Redis 实例重启后恢复数据的速度可以得到保证，大数据量下比AOF 会快很多。

3）Fork 操作利用了写时复制，类似与 CopyOnWriteArrayList。

小知识-写时复制：

在子进程创建时，它不会直接将主进程地址空间全部复制，而是共享同一个内存。

之后如果任意一个进程需要对内存进行修改操作，内存会重新复制一份提供给修改的进程单独使用。

更多可看：

• 649. Redis 在生成 RDB 文件时如何处理请求？

AOF 持久化详解

AOF 持久化机制是指将 Redis 写命令以追加的形式写入到磁盘中的 AOF 文件，AOF 文件记录了 Redis 在内存中的操作过程，只要在 Redis 重启后重新执行 AOF 文件中的写命令即可将数据恢复到内存中。

AOF 机制的优点：

• AOF 机制比 RDB 机制更加可靠，因为 AOF 文件记录了 Redis 执行的所有写命令，可以在每次写操作命令执行完毕后都落盘存储。

AOF 机制的缺点：

• AOF 机制生成的 AOF 文件比 RDB 文件更大，当数据集比较大时，AOF 文件会比 RDB 文件占用更多的磁盘空间。
• AOF 机制对于数据恢复的时间比 RDB 机制更加耗时，因为要重新执行 AOF 文件中的所有操作命令。

混合持久化

RDB 和 AOF 都有各自的缺点。

如果 RDB 备份的频率低，那么丢的数据多。备份的频率高，性能影响大。

AOF 文件虽然丢数据比较少，但是恢复起来又比较耗时。

因此 Redis 4.0 以后引入了混合持久化，通过 aof‐use‐rdb‐preamble 配置开启混合持久化。

当 AOF 重写的时候（注意混合持久化是在 aof 重写时触发的）。它会先生成当前时间的 RDB 快照，将其写入新的 AOF 文件头部位置。

这段时间主线程处理的操作命令会记录在重写缓冲区中，RDB 写入完毕后将这里的增量数据追加到这个新 AOF 文件中，最后再用新 AOF 文件替换旧 AOF 文件。

如此一来，当 Redis 通过 AOF 文件恢复数据时，会先加载 RDB，然后再重新执行指令恢复后半部分的增量数据，这样就可以大幅度提高数据恢复的速度！

AOF 写回策略

AOF 提供了三种写回策略，决定何时将数据同步到磁盘中：

• always：每次写操作后立即调用 fsync，将数据同步到磁盘。这种策略保证了最高的数据安全性，但也会显著降低性能，因为每个写操作都要等待磁盘写入完成。
• everysec：每秒调用一次 fsync，将数据同步到磁盘。这种策略在性能和数据安全性之间做了折中，默认情况下，Redis 使用这种策略。最多会丢失 1 秒的数据。
• no：由操作系统决定何时将数据写入磁盘。通常，操作系统会在一定时间后或缓冲区满时同步数据到磁盘。这种策略具有最高的性能，但数据安全性较低，因为在 Redis 崩溃时可能会丢失较多的数据。

设置 always 能一定保证数据不丢失吗？

答案是不能！因为 Redis 是先执行命令再写入 aof，所以如果执行命令写入 aof 这段时间 Redis 宕机了，重启后也无法利用 aof 恢复！

所以 Redis 的持久化机制，并不能保证数据不丢失！

AOF 重写机制

AOF 文件随着写操作的增加会不断变大，过大的 AOF 文件会导致恢复速度变慢，并消耗大量磁盘空间。所以，Redis 提供了 AOF 重写机制，即对 AOF 文件进行压缩，通过最少的命令来重新生成一个等效的 AOF 文件。

拿 key A 举个例子，AOF 记录了每次写命令如 set A 1、set A 2、set A 3。实际上前面的 set A 1、set A 2 是历史值，我们仅关心最新的值，因此 AOF 重写就是仅记录数据的最终值即可，即set A 3，这样 AOF 文件就“瘦身”了。

注意：AOF 重写并不是对现有的 AOF 文件进行修改，而是根据当前每个键的最新值转换为对应的写命令，写入新的 AOF 文件，形成一个新文件。

注意：后台 AOF 重写，也是需要 fork 子线程，因此也有写时复制的机制。

AOF 重写流程如下：

1. 创建子进程：Redis 使用 BGREWRITEAOF 命令创建一个子进程，负责 AOF 重写操作。
2. 生成新的 AOF 文件：子进程根据当前数据库的状态，将每个键的最新值转换为对应的写命令，并写入新的 AOF 文件。例如，对于一个列表键，子进程会使用一条 RPUSH 命令将所有元素写入，而不是记录之前的多次操作。
3. 处理新写入的命令：在重写过程中，主进程仍然处理新的写操作。为了避免数据不一致，主进程会将这些新的写命令同时追加到现有的 AOF 文件和一个缓冲区（aof_rewrite_buf）中。
4. 合并新命令：当子进程完成新的 AOF 文件的写入后，主进程会将缓冲区中的新命令追加到新的 AOF 文件中，确保其包含所有最新的操作。
5. 替换旧的 AOF 文件：最后，Redis 使用新的 AOF 文件替换旧的文件，实现 AOF 文件的重写。

AOF 重写可以通过手动触发或自动触发：

1）手动触发：使用 BGREWRITEAOF 命令可以手动触发 AOF 重写。

2）自动触发：通过配置文件中的参数控制自动触发条件，参数如下：

• auto-aof-rewrite-min-size：AOF 文件达到该大小时允许重写（默认 64 MB）。
• auto-aof-rewrite-percentage：当前 AOF 文件大小相对于上次重写后的增长百分比达到该值时触发重写。

Redis 7.0 MP-AOF（Multi-Part Append Only File）

7.0 之前的 AOF 重写有三大问题：

1. 内存开销：aof_buf 和 aof_rewrite_buf 中大部分内容是重复的。
2. CPU 开销：主进程需要花费 CPU 时间往 aof_rewrite_buf 写入数据，并向子进程发送 aof_rewrite_buf 中的数据。子进程需要消耗 CPU 时间将aof_rewrite_buf 写入新 AOF 文件。
3. 磁盘开销：aof_buf数据会写到当前的 AOF 文件，aof_rewrite_buf数据写到新的 AOF 文件，一份数据需要写两次磁盘。

针对以上问题 Redis 7.0 引入了 MP-AOF（Multi-Part Append Only File）机制。简单来说就是将一个 AOF 文件拆分成了多个文件：

• 一个基础文件（base file），代表数据的初始快照
• 增量文件（incremental files），记录自基础文件创建以来的所有写操作，可以有多个
• 基础文件和增量文件都会存放在一个单独的目录中，并由一个清单文件（manifest file）进行统一跟踪和管理

大致流程如下：

可以看到，重写期间的数据变更直接写到 aof_buf 再到新的增量 AOF 文件中，避免了之前多个 buf 的写入。

且子进程独立重写基础的 AOF，于主进程无交互，节省了主进程的 CPU 开销。

当重写完毕后，仅需更新 manifest 文件，加入新的增量 AOF 文件和基础 AOF 文件，然后将之前的增量 AOF 文件和基础 AOF 文件标记为历史文件（会被异步删除）即可。更新完 manifest 就代表 AOF 重写结束。

AOF 文件修复

如果 AOF 文件因系统崩溃等原因损坏，可以使用 redis-check-aof 工具修复。该工具会截断文件中的不完整命令，使其恢复到一致状态。

649.Redis 在生成 RDB 文件时如何处理请求？

回答重点

在 Redis 生成 RDB 文件时是异步的（使用 bgsave 命令），采用了 fork 子进程的方式来进行快照操作。生成 RDB 文件的过程由子进程执行，主进程继续处理客户端请求，所以可以保证 Redis 在生成快照的过程中依然对外提供服务，不会影响正常请求。

扩展知识

生成 RDB 文件的时候，数据可以修改吗？

当然可以。主进程会正常处理客户端的请求，进行数据的修改。但数据被修改还叫快照吗？

此时就运用了写时复制的技术。

当主进程 fork 出一个子进程后，并不会把主进程的所有内存数据重新复制一份给子进程，而是让主进程和子进程共享相同的内存页面。

底层的实现仅仅复制了页表，但映射的物理内存还是同一个。这样做可以加快 fork 的速度，减少性能损耗（fork会阻塞主进程）。

此时，主进程收到写命令，需要修改数据，那么主进程会将对应数据所在的页复制一份，对复制的副本进行修改。此时子进程指向的还是老的页，因此数据没有变化，符合快照的概念。

通过在写的时候才触发内存的复制，可以显著地降低 Redis 实例的性能压力，最大限度的减少 RDB 对服务正常运行的影响。

避免高峰期生成 RDB

如果 RDB 时间长，且写并发高，此时会被系统产生比较大的影响。

原因是因为写时复制时，如果共享的每一页内存都被修改，就会使得内存极速膨胀，最大内存可以膨胀两倍，所以要注意内存的使用量，防止内存过载。

RDB 会产生大量的磁盘 I/O，要注意磁盘性能导致的影响。

还需要注意 CPU 负载，毕竟有大量的数据需要写入。

因此如果 RDB 在高峰期可能会影响到正常业务，需要合理安排生成 RDB 的时机。

650.Redis 的哨兵机制是什么？

回答重点

Redis 的哨兵机制（Sentinel） 是一种高可用性解决方案，用于监控 Redis 主从集群，自动完成主从切换，以实现故障自动恢复和通知。

主要功能包括：

• 监控：哨兵不断监控 Redis 主节点和从节点的运行状态，定期发送 PING 请求检查节点是否正常。
• 自动故障转移：当主节点发生故障时，哨兵会选举一个从节点提升为新的主节点，并通知客户端更新主节点的地址，从而实现高可用。
• 通知：哨兵可以向系统管理员或其他服务发送通知，以便快速处理 Redis 实例的状态变化。

扩展知识

哨兵机制的由来

主从架构中，如果采用读写分离的模式，即主节点负责写请求，从节点负责读请求。假设这个时候主节点宕机了，没有新的主节点顶替上来的话，就会出现很长一段时间写请求没响应的情况。

针对这个情况，便出现了哨兵这个机制。它主要进行监控作用，如果主节点挂了，将从节点切换成主节点，从而最大限度地减少停机时间和数据丢失。

哨兵机制对应的架构图如下所示：

• 哨兵节点（Sentinel）: 主要作用是对 Redis 的主从服务节点进行监控，当主节点发生故障的时候，哨兵节点会选择一个合适的从节点升级为主节点，并通知其他从节点和客户端进行更新操作。
• Redis 节点：主要包括 master 以及 slave 节点，就是 Redis 提供服务的实例。

一般哨兵需要集群部署，至少三台哨兵组成哨兵集群。

主观下线和客观下线

哨兵是如何判断 Redis 中主节点挂了的呢？主要涉及到了两个机制：主观下线以及客观下线。

1）主观下线

Sentinel 每隔 1s 会发送 ping 命令给所有的节点。如果 Sentinel 超过一段时间还未收到对应节点的 pong 回复，就会认为这个节点主观下线。

“一段时间”是配置项 down-after-milliseconds 设定的。

2）客观下线

注意，只有主节点才有客观下线，从节点没有。

假设目前有个主节点被一个 sentinel 的判断主观下线了，但可能主节点并没问题，只是因为网络抖动导致了一台哨兵的误判。所以此时哨兵需要问问它的队友，来确定这个主节点是不是真的出了问题！

因此，它会向其他哨兵发起投票，其他哨兵会判断主节点的状态进行投票，可以投赞成或反对。

如果认为下线的总投票数大于 quorum（一般为集群总数/2 + 1，假设哨兵集群有 3 台实例，那么 3 / 2 + 1 = 2），则判定该主节点客观下线，此时就需要进行主从切换，而只有哨兵的 leader 才能操作主从切换。

Sentinel leader 是如何选举出来的？

Sentinel leader 节点的选举实际上涉及到分布式算法 raft，感兴趣的同学可以深入去了解一下，这里主要简单说一下哨兵集群选择 leader 的方式：

判断主节点主观下线的 sentinel 就是候选者，此时它想成为 leader。如果同时有两个 sentinel 判断主观下线，那么它们都是候选人，一起竞争成为 leader。

候选者们会先投自己一票，然后向其他 sentinel 发送命令让它们给自己投票。每个哨兵手里只有一票，投了一个之后就不能投别人了。

最后，如果某个候选者拿到哨兵集群半数及以上的赞成票，就会成为 leader。这里有一个注意的点，为了保证 sentinel 选举的时候尽量避免出现平票的情况，sentinel 的节点个数一般都会是奇数，比如 3,5,7 这样。

Redis 主节点选举

选出哨兵 leader 之后，需要选出 Redis 主从集群中的新 master 节点。

首先需要把一些已经下线的节点全部剔除，然后从正常的从节点中选择主节点，其主要经过以下三个流程:

1. 根据从节点的优先级进行选择，优先选择优先级的值比较小的节点（优先级的值越小优先级越高，优先级可通过 slave-priority 配置）。
2. 如果节点的优先级相同，则查看进行主从复制的 offset 的值，即复制的偏移量，偏移量越大则表示其同步的数据越多，优先级越高。
3. 如果 offset 也相同了，那只能比较 ID 号，选择 ID 号比较小的那个作为主节点（每个实例 ID 不同）。

选好主节点之后，哨兵 leader 会让其他从节点全部成为新 master 节点的 slave 节点。

最后利用 redis 的发布/订阅机制，把新主节点的 IP 和端口信息推送给客户端，此时主从切换就结束了。

可能还有同学关心旧主节点恢复了怎么办？实际上哨兵会继续监视旧的主节点，如果它上线了，哨兵集群会向它发送 slaveof 命令，让它成为新主节点的从节点。

651.Redis 主从复制的实现原理是什么？

回答重点

Redis 的主从复制是指一个 Redis 实例（主节点）可以将数据复制到一个或多个从节点（从节点），从节点从主节点获取数据并保持同步。

复制流程：

• 开始同步：从节点通过向主节点发送 PSYNC 命令发起同步。
• 全量复制：如果是第一次连接或之前的连接失效，从节点会请求全量复制，主节点将当前数据快照（RDB文件）发送给从节点。
• 增量复制：全量复制完毕后，主从之间会保持一个长连接，主节点会通过这个连接将后续的写操作传递给从节点执行，来保证数据的一致。

扩展知识

Redis 主从架构

下图就是一个 Redis 主从架构图：

主从架构可以实现读写分离。写操作可以请求主节点，而读操作只请求从节点，这样就能减轻主节点的压力。

整个主从集群仅主节点可以写入，其它从节点都通过复制来同步数据，这样就能保证数据的一致性。并且对读请求分散到多个节点，提高了 Redis 的吞吐量，从一定程度上也提高了 Redis 的可用性。

主从复制原理详解

Redis 之间主从复制主要有两种数据同步方式，分别是全量同步和增量同步。

1） 全量同步

• runid 指的是主服务器的 run ID，从节点第一次同步不知道主节点 ID，于是传递 “?"。
• offset 为复制进度，第一次同步值为 -1。

文字版本的流程：

• 从节点发送 psync ？ -1，触发同步。
• 主节点收到从节点的 psync 命令之后，发现 runid 没值，判断是全量同步，返回 fullresync 并带上主服务器的 runid 和当前复制进度，从服务器会存储这两个值。
• 主节点执行 bgsave 生成 RDB 文件，在 RDB 文件生成过程中，主节点新接收到的写入数据的命令会存储到 replication buffer 中。
• RDB 文件生成完毕后，主节点将其发送给从节点，从节点清空旧数据，加载 RDB 的数据。
• 等到从节点中 RDB 文件加载完成之后，主节点将 replication buffer 缓存的数据发送给从节点，从节点执行命令，保证数据的一致性。

待同步完毕后，主从之间会保持一个长连接，主节点会通过这个连接将后续的写操作传递给从节点执行，来保证数据的一致。

2） 增量同步

主从之间的网络可能不稳定，如果连接断开，主节点部分写操作未传递给从节点执行，主从数据就不一致了。

此时有一种选择是再次发起全量同步，但是全量同步数据量比较大，非常耗时。因此 Redis 在 2.8 版本引入了增量同步（psync 其实就是 2.8 引入的命令），仅需把连接断开其间的数据同步给从节点就好了。

此时需要介绍下 repl_backlog_buffer。

repl_backlog_buffer 是一个环形缓冲区，默认大小为 1m。主节点会将写入命令存到这个缓冲区中，但是大小有限，待写入的命令超过 1m 后，会覆盖之前的数据，因为是环形写入。

增量同步也是 psync 命令，如果主节点判断从节点传递的 runid 和主节点一致，且根据 offset 判断数据还在repl_backlog_buffer中，则说明可以进行增量同步。

于是就去 repl_backlog_buffer 查找对应 offset 之后的命令数据，写入到 replication buffer 中，最终将其发送给 slave 节点。slave 节点收到指令之后执行对应的命令，一次增量同步的过程就完成了。

如果根据 offset 判断数据已经被覆盖了，此时只能触发全量同步！

因此可以调整 repl_backlog_buffer 大小，尽量避免出现全量同步。

replication buffer 和 repl_backlog_buffer 的区别

replication buffer

因为不同的从节点同步速度不一样，主节点会为每个从节点都创建一个 replication buffer，它用于实时传输写命令，且大小是动态的，因为对于同步速度较慢的从服务器，需要更多的内存来缓存数据。

虽说 replication buffer 没有明确的大小限制，但是可以通过 client-output-buffer-limit 间接控制，该参数可以设置不同类型客户端（普通、从服务器、发布订阅）的输出缓冲区限制。当缓冲区大小超过限制时，Redis 会断开与客户端（从节点其实就是一个客户端）的连接。

client-output-buffer-limit slave 256mb 64mb 60

上述配置表示，如果从服务器的输出缓冲区大小超过 256 MB 或超过 64 MB 的时间达到 60s，Redis 将断开与从服务器的连接。

repl_backlog_buffer

repl_backlog_buffer 在主节点上只有一个，存储最近的写命令，用于从服务器重新连接时进行部分重同步。

652.Redis集群的实现原理是什么？

回答重点

Redis 集群（Redis cluster）是通过多个 Redis 实例组成的，每个实例存储部分的数据（即每个实例之间存储的数据是不重复的）。

具体是采用哈希槽（Hash Slot）机制来分配数据，将整个键空间分为 16384 个槽（slot），每个 Redis 实例负责一定范围的哈希槽。数据的 key 经过哈希函数计算后可以得到 16384 取余即可定位到对应的节点。

客户端在发送请求时，会通过集群的任意节点进行连接，如果该节点存储了对应的数据则直接返回结果，反之该节点会根据请求的键值计算哈希槽并路由到正确的节点。

简单来说，集群就是通过多台机器分担单台机器上的压力。

（如果不理解集群原理，可以以下面两个图示为例）

扩展知识

Redis 集群中节点之间的信息如何同步？

Redis 集群内每个节点都会保存集群的完整拓扑信息，包括每个节点的 ID、IP 地址、端口、负责的哈希槽范围等。

节点之间使用 Gossip 协议进行状态交换，以保持集群的一致性和故障检测。每个节点会周期性地发送 PING 和 PONG 消息，交换集群信息，使得集群信息得以同步。

Gossip 的优点：

• 快速收敛：Gossip 协议能够快速传播信息，确保集群状态的迅速更新。
• 降低网络负担：由于信息是以随机节点间的对谈方式传播，避免了集中式的状态查询，从而降低了网络流量。

Gossip 协议

Gossip 主要特点：

1. 分布式信息传播：每个节点定期向其他节点发送其状态信息，确保所有节点对集群的状态有一致的视图。
2. 低延迟和高效率：Gossip 协议设计为轻量级的通信方式，能够快速传播信息，减少单点故障带来的风险。
3. 去中心化：没有中心节点，所有节点平等地参与信息传播，提高了系统的鲁棒性。

工作原理：

1. 状态更新：每个节点在给定的时间间隔内，向随机选择的其他节点发送其自身的状态信息，包括节点的主从关系、槽位分布等。
2. 信息更新：接收到状态信息的节点会根据所接收到的数据更新自己的状态，并将更新后的状态继续传播给其他节点。
3. 节点检测：通过周期性发送状态信息，节点可以检测到其他节点的存活状态。如果某个节点未能在预定时间内响应，则该节点会被标记为故障节点。
4. 容错处理：在检测到节点故障后，集群中的其他节点可以采取措施（如重新分配槽）以保持系统的高可用性。

Redis 集群分片原理图示

Redis 集群会将数据分散到 16384（2^14）个哈希槽中。集群中的每个节点负责一定范围的哈希槽。在 Redis 集群中，使用 CRC16 哈希算法计算键的哈希值，以确定该键应存储在哪个节点。

集群结构如下所示：

每个节点会有一部分的槽位，然后对应的键值会根据其本身的 key，映射到一个哈希槽中，其主要流程如下：

• 根据键的 key，按照 CRC 16 算法计算一个 16 bit 的值，然后将 16 bit 的值对 16384 取模进行取余运算，最后得到一个对应的哈希槽编号。
• 根据每个节点分配的哈希槽区间，对应编号的数据就在对应的区间上，就能找到对应的分片实例。

为了方便大家理解，我这里画一个对应的关系图，以三个节点为例：

假设我们有一个 Redis 集群，包含三个主节点（Node1、Node2、Node3），它们分别负责以下哈希槽：

• Node1：哈希槽 0-5460
• Node2：哈希槽 5461-10922
• Node3：哈希槽 10923-16383

现在要存储一个键为 user:10001 的数据。

计算哈希槽：

1. 使用 CRC16 哈希算法计算 user:10001 的哈希值。
2. 假设计算结果为 12345。
3. 然后，计算该值对应的哈希槽：
   • 哈希槽 = 12345 % 16384 = 12345。

确定目标节点：

• 12345 落在 Node3 的负责范围（10923-16383），因此，user:10001 会被存储在 Node3 中。

Redis 集群中请求 key 示例（客户端直接连接的并不是对应 key 的节点）

如果客户端连接的是集群中的 Node1，但需要访问存储在 Node3 的键 user:10001，查询过程如下：

查询过程：

1. 计算哈希槽：

   • 客户端使用 CRC16 算法计算 user:10001 的哈希值（假设为 12345）。
   • 计算哈希槽：12345 % 16384 = 12345。

2. 查询请求：

   • 因为客户端连接的是集群中的 node1，所以客户端发送查询命令 GET user:10001 到 Node1。

3. Node1 响应：

   • Node1 检测到请求的键 user:10001 属于 Node3，返回一个 moved 错误，指示客户端请求的键在另一个节点上，moved 错误会返回目标节点的信息（例如，Node3 的 IP 和端口）。

4. 重新连接：

   • 客户端根据返回的目标节点信息，建立与 Node3 的连接。

5. 再次发送查询请求：

   • 客户端向 Node3 发送 GET user:10001。

6. 获取结果：

   • Node3 查询到 user:10001 的值（假设为 {“name”: “查调峰”, “age”: 18}），并返回结果。

为什么 Redis 哈希槽节点的数目是 16384 呢？

github 上有人向作者提问过：

简单总结分析一下：

1）首先是消息大小的考虑：

正常的心跳包需要带上节点完整配置数据，心跳还是比较频繁的，所以需要考虑数据包的大小。如果使用 16384 数据包只要 2k，如果用了 65535 则需要 8k。

实际上槽位信息使用一个长度为 16384 位的数组来表示，节点拥有哪个槽位，就将对应位置的数据信息设置为1，否则为 0。

心跳数据包就包含槽位信息如下图所示：

这里我们看到一个重点，即在消息头中最占空间的是 myslots[CLUSTER SLOTS/8]。

• 当槽位为 65536 时，这块的大小是：65536÷8÷1024=8kb
• 当槽位为 16384 时，这块的大小是：16384÷8÷1024=2kb

如果槽位为 65536 ，这个 ping 消息的消息头就太大了，浪费带宽。

2）集群规模的考虑

集群不太可能会扩展超过 1000 个节点，16384 够用且使得每个分片下的槽又不会太少。

653.Redis 集群会出现脑裂问题吗？

回答重点

Redis 集群存在脑裂问题的风险，特别是在网络分区的情况下，可能会导致同一集群内出现多个主节点，导致数据不一致。

扩展知识

什么是脑裂

脑裂是指在分布式系统中，由于网络分区或其他问题导致系统中的多个节点（特别是主节点）误以为自己是唯一的主节点。这种情况会导致多个主节点同时提供写入服务，从而引起数据不一致。

分布式系统就像一个团队在干活，如果发生了脑裂，就好比这个团队突然因为某些原因，比如通信出了问题，分成了几个小团体。

每个小团体都以为自己是整个团队，都在按自己的方式工作，各自为政，对同一件事有不同的决策和做法，就像有的说要这么干，有的说要那么干。

这样一来，整个系统就乱套了，数据也可能变得不一致，服务也变得不正常了，这就是分布式系统中的脑裂。

导致脑裂出现原因主要是网络分区。

Redis 中的脑裂

例如发生了网络分区，主节点与哨兵、从节点分区了。

此时哨兵发现联系不上主节点，于是发起选举，选了新的主节点，此时 Redis 就出现了两个主节点：

这就发生了脑裂，此时客户端写数据应该写到哪台上呢？写哪都会导致数据不一致。

Redis 中如何避免脑裂问题的发生呢？

这里需要了解两个参数：

• min-slaves-to-write：设置主节点在至少有指定数量的从节点确认写操作的情况下才执行写操作
• min-salves-max-lag：设置从节点的最大延迟（以秒为单位），如果从节点的延迟超过这个值，则该从节点不会被计入 min-slaves-to-write 的计数中

举个例子：当 min-slaves-to-write 设置为 2，min-slaves-max-lag 设置为 10 秒时，主节点只有在至少有 2 个从节点延迟不超过 10 秒的情况下才会接受写操作。

这两个参数就使得发生脑裂的时候，如果某个主节点跟随的从节点数量不够或延迟较大，就无法被写入，这样就能避免脑裂导致的数据不一致。

建议集群部署奇数个节点，例如集群数为 5，那么可以设置 min-slaves-to-write 为 3，min-slaves-max-lag 为 5-10 秒。

脑裂问题能完全避免吗？

并不能。即使配置了以上两个参数也可能会因为脑裂导致数据不一致。

举个例子，假设某个主节点临时出了问题，哨兵判断它主观下线，然后开始发起选举。

在选举进行的时候，主节点恢复了，此时它还是跟着很多从节点，假设 min-slaves-max-lag 配置了 10s，可能此时从节点和主节点延迟的时间才 6s，因此此时主节点还是可以被写入。

而等选举完毕了，选出新的主节点，旧的主节点被哨兵操作需要 salveof 新主，此时选举时间内写入的数据会被覆盖，因此就导致了数据不一致的问题。

654.Redis 的订阅发布功能是什么？你了解吗？

回答重点

Redis 的订阅发布功能（Publish/Subscribe，简称 Pub/Sub），是一种消息通信机制，用于在不同客户端之间实现消息的实时传递和广播。使用 Pub/Sub 模型，客户端可以订阅一个或多个频道，当有其他客户端向这些频道发布消息时，所有订阅了该频道的客户端都会立即收到消息。

主要功能包括：

• 发布（Publish）：某个客户端向指定的频道发布消息。
• 订阅（Subscribe）：一个或多个客户端订阅指定的频道，并在频道接收到消息时立刻获取该消息。

扩展知识

什么是发布/订阅模型？

发布/订阅其实属于消息队列中的一种消息通信模型，生产者（pub）发送消息，订阅者（sub）接收消息。

这里我们展示一下 Redis 的发布/订阅逻辑。如下图所示，发布者向一个或者多个频道发布消息，订阅者可以订阅一个或者多个频道所发布的消息。

当发布者发送新消息到对应的频道的时候，订阅者可以收到对应的信息。

Redis 实现发布/订阅

简单演示下 Redis 发布/订阅模型的使用。

首先我们先创建并发布一个 message 到 Redis 频道，这里我们用三条信息进行对应的测试，如图所示

1

publish channel message

然后实现对应的频道订阅

1

subscribe channel 

可以看到，频道发布的消息都被消费到了。

解析下上述结果。

首先是 subscribe 以及 channel，其分别表示执行订阅以及订阅的频道。

integer 1 表示订阅成功。

message 表示接收到的消息，之后出现的 channel 表示订阅频道，后面就是消息数据。

订阅成功之后，客户端会一直保持订阅状态，直到手动取消订阅或连接断开。

到此为止，一个基于 Redis 简单的发布/订阅模型就成功实现了。

它支持消费者阻塞式拉取消息，另外还提供了匹配订阅，消费者可以根据一定的规则，订阅多个队列。

例如subscribe mianshiya.*，此时如果生产者发布了 mianshiya.1、mianshiya.2、mianshiya.3 等队列的消息，消费者都可以接收到。

命令汇总：

• SUBSCRIBE channel：用于订阅某个频道。
• PUBLISH channel message：用于向某个频道发布消息。
• UNSUBSCRIBE channel：取消订阅某个频道。
• PSUBSCRIBE pattern：支持使用模式匹配订阅（如通配符*）来动态地订阅多个频道。

Redis 发布/订阅模型的原理

Redis 是如何实现这个功能的呢？实际上很简单。

消费者订阅队列，实际上就是在 Redis 中保存了一个映射关系，即队列 x -> 消费者 1。

如果生产者往这个队列 x 发送一条消息，Redis 不会做任何的存储动作，而是查找映射关系，然后立马转发给消费者1，所以 Redis 实际上就是提供了一个“转发通道”。如果找到多个映射关系，那么就都转发，所以支持多消费者的实现。

因此，不论是 rdb 还是 aof 都不会存储消息。

Redis 发布/订阅模型的缺点

会丢数据！

从原理我们就可以得知，Redis 并不会存储消息，那么如果生产者发布消息的时候，消费者宕机了，当服务恢复时，其间生产者发送的消息就丢失了。

不仅是宕机会导致消息丢失，如果消费者消费过慢也有可能导致消息丢失。

在面试鸭《[651. Redis 主从复制的实现原理是什么？](#651Redis 主从复制的实现原理是什么)》这题中，提到了 client-output-buffer-limit 参数，默认 pubsub 配置的是 32mb 8mb 60，即缓冲区一旦超过 32 MB 或持续 60s 超过 8M 直接把消费者下线。

Redis 虽然不会存储消息，但是消息会先写入这个缓冲区，供消费者拉取消费。如果消费者处理太慢，导致这个缓冲区溢出，那么消费者被强行下线，消息也就丢了。

Redis 发布/订阅模型应用场景

Redis 的哨兵集群和 Redis 实例通信用的就是发布/订阅模型。

一般业务上的即时通信场景也可以使用，但是由于消息会丢失，大部分情况下还是会使用消息队列中间件来实现发布/订阅。

655.Redis 中如何实现分布式锁？

回答重点

在 Redis 中实现分布式锁的常见方法是通过set ex nx 命令 + lua 脚本组合使用。确保多个客户端不会获得同一个资源锁的同时，也保证了安全解锁和意外情况下锁的自动释放。

扩展知识

理解 Redis 实现的分布式锁

如果基于 Redis 来实现分布锁，需要利用 set ex nx 命令 + lua 脚本。

1）加锁：SET lock_key uniqueValue EX expire_time NX 2）解锁：使用 lua 脚本，先通过 get 获取 key 的 value 判断锁是否是自己加的，如果是则 del。

lua 脚本如下：

1
2
3
4
5
6

if redis.call("GET",KEYS[1]) == ARGV[1]
then
    return redis.call("DEL",KEYS[1])
else
    return 0
end

我们来一一理解一下。

首先锁需要有过期机制。假设某个客户端加了锁之后宕机了，锁没有设置过期机制，会使得其他客户端都无法抢到锁。

EX expire_time 就是设置了锁的过期，单位是秒。还一个 PX， 也是过期时间，单位是毫秒。

然后，在 2.6.12 版本之前只有 SETNX 即 SET if Not eXists，它表示如果 key 已存在，则什么都不会做，返回 0，如果不存在则会设置它的值，返回 1。

那个时候 SETNX 和过期时间的设置就无法保证原子性，如果客户端在发送完 SETNX 之后就宕机了，还没来得及设置过期时间，一样会导致锁不会被释放。

因此 2.6.12 版本之后，优化了 SET 命令，使得可以执行 set ex px。

最后，再解释下什么是 uniqueValue，翻译过来就是一个唯一的值。

之所以要设置唯一值是为了防止被别的客户端给释放了。

我们来看下这个场景：

1. 客户端 1 加锁成功，然后执行业务逻辑，但执行的时间超过了锁的过期时间
2. 此时锁已经过期被释放了，客户端 2 加锁成功
3. 客户端 2 执行业务逻辑
4. 客户端 1 执行完了，执行释放锁的逻辑，即删除锁。

客户端 2 一脸懵，我还在执行着呢，怎么锁被人释放了？？

所以每个客户端加锁（客户端可能是每个线程），需要是设置一个唯一标识，比如一个 uuid，防止锁被别的客户端误释放了。

因为需要先判断锁的值和唯一标识是否一致，一致后再删除释放锁，这里就涉及到两步操作，只有使用了 lua 脚本才能保证原子性，这也是为什么释放锁需要用 lua 脚本的原因。

单点故障问题

单台 Redis 实现分布式锁存在单点故障问题，如果采用主从读写分离架构，如果一个客户端在主节点上锁成功，但是主节点突然宕机，由于主从延迟导致从节点还未同步到这个锁，此时可能有另一个客户端抢到新晋升的主节点，此时会导致两个客户端抢到锁，产生了数据不一致。

基于这个情况，Redis 推出了 Redlock。

Redlock 红锁

Redlock 是 Redis 官方推荐的一种实现分布式锁的算法，适用于集群环境下。

Redlock 的基本思想：

• 部署多个 Redis 实例（通常为 5 个）。
• 客户端在大多数实例（如至少 3 个）上请求锁，并在一定时间内获得成功，表示加锁成功。
• 使用 Redlock 可以提供更高的容错性，即使部分 Redis 实例故障，仍然可以获得锁。

Redlock 的实现流程：

• 客户端尝试在每个 Redis 实例上加锁，必须在有限时间内（通常为锁的过期时间）完成所有实例的加锁。
• 如果大多数实例（N/2 + 1）加锁成功，则表示加锁成功。
• 否则，客户端将释放所有已经加锁的实例，重新尝试。

Redlock 的缺点包括：

• 复杂性：实现 Redlock 需要多个 Redis 实例，增加了系统的复杂性和维护成本。

• 时间同步依赖：Redlock 依赖于多个节点的系统时间的一致性。如果节点之间的时间不同步（例如发生时间回拨），可能导致锁的有效性受到影响。

• 不适用于高并发：在高并发场景下，因需要访问多个实例同时尝试获取锁，可能会导致锁获取的性能下降。

• 锁的续期问题：在长时间的操作中，可能需要手动续期锁，因为涉及多个实例，增加了实现的复杂度和风险。

• Redis 的 Red Lock 是什么？你了解吗？

Redis 分布锁注意事项以及其它常见分布式锁的实现

• Redis 分布锁注意事项以及其它常见分布式锁的实现
• Redisson 分布式锁的原理
• 10745. Redisson 看门狗（watch dog）机制了解吗？

656.分布式锁在未完成逻辑前过期怎么办？

回答重点

若锁在未完成逻辑前就过期，此时可能会产生数据不一致的问题。因为锁过期了，此时如果再出现一个客户端争抢锁，即可拿到锁然后同时进行业务操作，这等于锁失效了。

此时可以在逻辑执行过程中定期续期锁，确保锁在处理过程中不会过期。

扩展知识

看门狗机制

业界出了一个看门狗机制来防止这种情况的产生。

理论很简单，在抢到锁之后，后台会有一个任务，定时向 redis 进行锁的续期。比如锁的过期时间是 30s，可以每过三分之一时长（30/3）10s 后就去 redis 重新设置过期时间为 30s。

在锁被释放的时候，就移除这个定时任务。

redisson

redisson 是一个类库，封装了很多 redis 操作，便于我们使用。

其实现的分布式锁就引入了看门狗机制，具体原理和上面所述的一致，基于 Netty 的时间轮实现的定时任务，关于时间轮的面试题解析可查看《时间轮》。

并且 redisson 支持可重入锁，即同一个线程可以多次获取同一个分布式锁，而不会导致死锁。实现方法如下：

• 在获取锁时，检查当前锁的唯一标识是否已经属于当前线程。
• 如果是，则增加一个重入计数器。
• 释放锁时，减少重入计数器，只有当计数器为 0 时才真正释放锁。

657.Redis 的 Red Lock 是什么？你了解吗？

回答重点

Red Lock，又称为红锁，是一种分布式锁的实现方案，旨在解决在分布式环境中使用 Redis 实现分布式锁时的安全性问题。

一般情况下，我们在生产环境会使用主从+哨兵方式来部署 Redis。

如果我们正在使用 redis 分布式锁，此时发生了主从切换，但从节点上不一定已经同步了主节点的锁信息。

所以新的主节点上可能没有锁的信息。此时另一个业务去加锁，一看锁还没被占，于是抢到了锁开始执行业务逻辑。

此时就发生了两个竞争者同时进入临界区操作临界资源的情况，可能就会发生数据不一致的问题。

所以 Redis 官方推出了红锁，避免这种状况产生。它主要解决的问题就是当部分节点发生故障也不会影响锁的使用和数据问题的产生。

扩展知识

红锁实现原理

首先要使用红锁需要集群部署 redis，官方推荐至少 5 个实例，不需要部署从库和哨兵，仅需主库。

这 5 个实例（可以更多，我们按 5 个来讲述）之间没有任何关系（不同于 redis cluster），它们之间不需要任何信息交互。

客户端会对这 5 个实例依次申请锁，如果最终申请成功的数量超过半数（>=3），则表明红锁申请成功，反之失败。

再来看下异常情况。假设有一台实例宕机了怎么办？实际上没任何影响，因为理论上能申请成功的数量可以达到 4，超过了半数。

也因为没有主从机制，不会有同步丢失锁的问题。

具体加锁流程如下：

1）客户端获取当前时间（t1）。

2）客户端按照顺序依次对 N 个 Redis 节点利用 set 命令进行加锁操作，对每个节点加锁都会设置超时时间（远小于锁的总过期时间），如果当前节点请求超时，立马向下一个节点申请锁。

3）当客户端成功从半数的 Redis 节点获取到了锁，这个时候获取一下当前时间 t2，然后计算加锁过程的总耗时 t（t2 - t1）。如果 t < 锁的过期时间，这个时候就可以判断加锁成功，反之加锁失败。

4）加锁成功则执行业务逻辑，加锁失败则依次向全部节点发起释放锁的流程。

上述的 set 加锁命令和解锁命令都遵循正常的分布式锁的使用规范，例如设置过期时间、唯一标识、lua 脚本释放等等。更详细可看面试鸭《redis 如何实现分布式锁？》这题。

红锁一定安全吗？

不一定。

来看下面这个图，是一位大佬 Martin Kleppmann 画的：

解释一下。如果 client 1 抢到了红锁，但是此时发生了 gc（垃圾回收），暂停（STW）了很久，与此同时 redis 中的锁过期了。

锁过期的同一时刻 gc 结束了，client 1 认为自己还持有锁，正常执行后续逻辑，而 client 2 也在此时拿到了锁，开始执行后续逻辑。

这不就有问题了吗？

除了 gc，如果出现时钟漂移，例如几个 redis 实例时间跳跃，导致锁提前过期了，也可能会造成别的 client 抢到锁。

所以，从理论上看红锁并不是无懈可击的，还是有概率出现问题，只不过这个概率非常小。

业务上

从上面的内容大家也可以知道红锁的实现成本其实不低，需要有至少 5 个实例，而且因为要依次加锁，所以性能来说也比不上单实例的 redis 加锁，且极端环境下还是有问题。

所以一般业务上还是使用主从+哨兵来实现分布式锁。

658.Redis 实现分布式锁时可能遇到的问题有哪些？

回答重点

1. 业务未执行完，锁已到期

2. 单点故障问题

3. 主从问题不同步问题

4. 网络分区问题

5. 时钟漂移问题

6. 锁的可重入性问题

7. 误释放锁问题

扩展知识

业务未执行完，锁已到期

为了避免持有锁的客户端崩溃或因网络问题断开连接时，锁无法被正常释放，需要给锁设置过期时间。

那么就有可能出现业务还在执行，锁已到期的情况。

可以设置一种续约机制（Redisson 中的看门狗机制），线程 a 在执行的时候，设置一个超时时间，并且启动一个守护线程，守护线程每隔一段时间就去判断线程 a 的执行情况，如果 a 还没有执行完毕并且 a 的时间快过期了，就重新设置一下超时时间，即继续续约。

锁的过期时间的设置也需要好好评估一下。

如果设置太长，业务结束了它还在阻塞的话，会影响 Redis 的性能。如果设置太短，就出现刚说的问题，因此要保证是设置一个合理的时间使得在大多数情况下任务能够在锁过期之前完成。

单点故障问题

如果 Redis 单机部署，当实例宕机或不可用，整个分布式锁服务将无法正常工作，阻塞业务的正常执行。

主从问题

如果线上 Redis 是主从+哨兵部署的，则分布式锁可能会有问题。

因为 Redis 的主从复制过程是异步实现的，如果 Redis 主节点获取到锁之后，还没同步到其他的从节点，此时 Redis 主节点发生宕机了，这个时候新的主节点上没锁的数据，因此其他客户端可以获取锁，就会导致多个应用服务同时获取锁。

网络分区

在网络不稳定的情况下，客户端与 Redis 之间的连接可能中断，如果未设置锁的过期时间，可能会导致锁无法正常释放。如果有多个锁，还可能引发锁的死锁情况。

时钟漂移

因为 Redis 分布式锁依赖于实例的时间来判断是否过期，如果时钟出现漂移，很可能导致锁直接失效。

可以让所有节点的系统时钟通过 NTP 服务进行同步，减少时钟漂移的影响。

659.Redis 中的缓存击穿、缓存穿透和缓存雪崩是什么？

回答重点

缓存击穿：指某个热点数据在缓存中失效，导致大量请求直接访问数据库。此时，由于瞬间的高并发，可能导致数据库崩溃。

缓存穿透：指查询一个不存在的数据，缓存中没有相应的记录，每次请求都会去数据库查询，造成数据库负担加重。

缓存雪崩：指多个缓存数据在同一时间过期，导致大量请求同时访问数据库，从而造成数据库瞬间负载激增。

解决方案

缓存击穿：

• 使用互斥锁，确保同一时间只有一个请求可以去数据库查询并更新缓存。
• 热点数据永不过期。

缓存穿透：

• 使用布隆过滤器，过滤掉不存在的请求，避免直接访问数据库。
• 对查询结果进行缓存，即使是不存在的数据，也可以缓存一个标识，以减少对数据库的请求。

缓存雪崩：

• 采用随机过期时间策略，避免多个数据同时过期。
• 使用双缓存策略，将数据同时存储在两层缓存中，减少数据库直接请求。

扩展知识

缓存雪崩解析

缓存雪崩是指在某个时间点，大量缓存同时失效或被清空，导致大量请求直接打到数据库或后端系统，造成系统负载激增，甚至引发系统崩溃。

这通常是由于缓存中的大量数据在同一时间失效引起的。

想象一个电商系统，用户量很大，假设某一系列的商品缓存突然同一时间失效，那就会造成我们的缓存雪崩，导致服务全部打到了数据库，引发严重后果。

解决办法

缓存键同时失效：

1）过期时间随机化：设置缓存的过期时间，加上一个随机值，避免同一时间大量缓存失效。

2）使用多级缓存：引入多级缓存机制，如本地缓存和分布式缓存相结合，减少单点故障风险。

3）缓存预热：系统启动时提前加载缓存数据，避免大量请求落到冷启动状态下的数据库。

4）加互斥锁：使得没缓存或缓存失效的情况下，同一时间只有一个请求来构建缓存，防止数据库压力过大。

缓存中间件故障：

1）服务熔断：暂停业务的返回数据，直接返回错误。

2）构建集群：构建多个 Redis 集群保证其高可用。

缓存击穿解析

缓存击穿指的是某一热点数据缓存失效，使得大量请求直接打到了数据库，增加数据库负载。

想象一下大家都在抢茅台，但在某一时刻茅台的缓存失效了，大家的请求打到了数据库中，这就是缓存击穿。

缓存雪崩是多个 key，大量数据同时过期，而缓存击穿是某个热点 key 崩溃，可以认为缓存击穿是缓存雪崩的子集。

解决办法

1）加互斥锁：保证同一时间只有一个请求来构建缓存，跟缓存雪崩相同。

2）热点数据永不过期：不要给热点数据设置过期时间，在后台异步更新缓存。

缓存穿透解析

缓存穿透是指查询一个不存在的数据，由于缓存中肯定不存在，导致每次请求都直接访问数据库，增加数据库负载。

攻击者可以通过构造不存在的 key 发起大量请求，对数据库造成很大的压力，可能会造成系统宕机。

解决办法

1）防止非法请求：检查非法请求，封禁其 IP 以及账号，防止它再次为非作歹。

2）缓存空值：将数据库中不存在的结果（例如空值）也缓存起来，并设置一个较短的过期时间，避免频繁查询数据库。

3）使用布隆过滤器：使用布隆过滤器来快速判断一个请求的数据是否存在，如果布隆过滤器判断数据不存在，则直接返回，避免查询数据库。

互斥锁实现示例（Java）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

public class CacheService {
    private Jedis jedis = new Jedis("localhost");
    private Lock lock = new ReentrantLock();

    public String getData(String key) {
        // 尝试从缓存获取数据
        String value = jedis.get(key);
        
        // 如果缓存不存在
        if (value == null) {
            // 加锁以防止并发请求
            lock.lock();
            try {
                // 再次检查缓存，避免重复查询
                value = jedis.get(key);
                if (value == null) {
                    // 查询数据库
                    value = queryDatabase(key);
                    // 将结果放入缓存
                    jedis.set(key, value);
                }
            } finally {
                // 释放锁
                lock.unlock();
            }
        }
        return value;
    }
}

说明：

1. 缓存查询：首先尝试从 Redis 中获取数据。
2. 加锁：如果缓存中没有数据，使用 ReentrantLock 加锁，确保只有一个线程可以查询数据库。
3. 二次检查：在加锁后再次检查缓存，避免重复查询。
4. 数据库查询：如果缓存仍然没有数据，查询数据库并将结果存入缓存。
5. 释放锁：确保锁在查询结束后被释放，以防止死锁。

这种方式有效地防止了缓存击穿，因为即使在高并发的情况下，只有一个请求会去数据库查询数据，其他请求则会等待锁释放。如果后端是多实例部署，一般实例数量也不多，即使使用本地锁也行，因为并发也不高。

布隆过滤器

• 663. 如何使用 Redis 快速实现布隆过滤器？

660.Redis 中如何保证缓存与数据库的数据一致性？

回答重点

缓存和数据库的同步可以通过以下几种方式:

1）先更新缓存，再更新数据库

2）先更新数据库存，再更新缓存

3）先删除缓存，再更新数据库，后续等查询把数据库的数据回种到缓存中

4）先更新数据库，再删除缓存，后续等查询把数据库的数据回种到缓存中

5）缓存双删策略。更新数据库之前，删除一次缓存；更新完数据库后，再进行一次延迟删除

6）使用 Binlog 异步更新缓存，监听数据库的 Binlog 变化，通过异步方式更新 Redis 缓存

以上就是实现数据库与缓存一致性的六种方式，这里前面三种都不太推荐使用，后面三种的话其主要根据实际场景：

• 如果是要考虑实时一致性的话，先写 MySQL，再删除 Redis 应该是较为优的方案，虽然短期内数据可能不一致，不过其能尽量保证数据的一致性。
• 如果考虑最终一致性的话，推荐的是使用 binlog + 消息队列的方式，这个方案其有重试和顺序消费，能够最大限度地保证缓存与数据库的最终一致性。

扩展知识

我们以 MySQL 和 Redis 为主要实现的案例对上述几个方案再进行展开分析。

先更新缓存，再更新数据库

由于网络原因，请求顺序无法保证，可能出现先更新缓存的请求，后更新数据库，而后更新缓存的请求反而先更新了数据库，这样就出现了缓存数据为 20，数据库数据为 10，即数据不一致的情况。

先写数据库，再写缓存

这个问题上面其实一样，都是因为并发和网络问题导致的数据库与缓存不一致。

先删除缓存再写数据库

盘一下流程：

1. 请求 A 先对缓存中的数据进行删除操作。
2. 请求 B 这个时候来执行查询，发现缓存中数据为空，就去数据库进行查询并回写缓存。
3. 这个时候请求 A 删除缓存中的数据之后，进行数据库数据的更新。
4. 但此时请求 B 已经把从数据库查询到的原始数据回写缓存了，这个时候就出现了上图的情况，数据库中查询的值是 20，而缓存中的数据是 10 。

读操作获取到的数据是过时的数据，虽然写操作已经完成了，但是因为缓存被删除了，读操作就必须从数据库中读取到旧值，并不是最新的数据。

缓存双删（先删除缓存，再写数据库，然后过一段时间再删除缓存）

这个方案为了避免旧数据被回种，等待一段时间后再延迟删除缓存。

也可以使用消息队列、定时任务或者延迟任务等方式去实现延迟删除：

先写数据库，再删除缓存

先把数据库的信息修改了，然后再删除对应的缓存，然后在修改数据库期间，可以允许一定时间的缓存不一致，保证缓存的最终一致性。

不过这种模型也有一定的问题，如下图所示：

其主要原因在于有一个写操作，此时刚好缓存失效，又在同一时刻刚好有一个并发读请求过来，且回写缓存的请求晚于缓存删除，导致数据库与缓存的不一致。

从上面的表述可以知道，这个发生的概率比较低，一般而言业务上都会使用这个方案。

先写数据库，通过 Binlog ,异步更新缓存

先修改数据库，然后通过 Canal 监听数据库的 binlog 日志，记录数据库的修改信息，然后通过消息队列异步修改缓存的数据。

这里需要注意需要保证顺序消费，保证缓存中数据按顺序更新，然后再加上重试机制，避免因为网络问题导致更新失败。

强一致性补充

可以使用分布式读写锁实现强一致性。读写锁中读和读操作不互斥，读写互斥，写写互斥。

写操作流程：

• 获取写锁。
• 更新数据库。
• 删除缓存。
• 释放写锁。

读操作流程：

• 获取读锁。
• 查询缓存：如果命中缓存，释放读锁，返回结果。如果缓存未命中，读取数据库，并将数据更新到缓存。
• 释放读锁。

661.Redis String 类型的底层实现是什么？（SDS）

回答重点

Redis 中的 String 类型底层实现主要基于 SDS（Simple Dynamic String 简单动态字符串）结构，并结合 int、embstr、raw 等不同的编码方式进行优化存储。

扩展知识

C 语言字符串的缺陷

Redis 为什么没有使用 C 标准库提供的字符串，而是实现了一种动态字符串？因为 C 语言的字符串本质上就是 char* 的字符数组，存在一定缺陷：

• C 语言字符数组的结尾位置就用“\0”表示，意思是指字符串的结束
• C 语言字符数组获取长度只能通过遍历获得，时间复杂度是 O(n)
• 字符串操作函数不高效且不安全，比如缓冲区溢出，其可能导致程序异常终止

对比 C 语言字符串

sds 进一步解析

SDS 底层结构是 sdshdr，在 redis 4.x 及以上版本引入了 sdshdr 变种，如 sdshdr16、sdshdr64 等，根据字符串长度动态选择不同的实现，进一步优化内存使用。

例如以下的 sdshdr64：

1
2
3
4
5
6

struct __attribute__ ((__packed__)) sdshdr64 {
    uint64_t len; /* used */
    uint64_t alloc; /* excluding the header and null terminator */
    unsigned char flags; /* 3 lsb of type, 5 unused bits */
    char buf[];
};

1）len （长度）:记录了 SDS 字符串数组的长度，当需要获取字符串长度的时候，只需要返回这个成员变量的值就可以了，时间复杂度是 O(1)。

2）alloc（分配空间长度）:这个字段的主要作用是指分配给字符数组的存储的空间大小，当需要计算剩余空间大小的时候，只需要 alloc - len 就可以直接进行计算，然后判断空间大小是否符合修改需求，如果不满足需求的话，就执行相应的修改操作，这样的话就可以很好地解决我们上面所说的缓冲区溢出问题。

3）flags（表示 SDS 的类型）:一共设计了五种类型的 SDS，分别是 sdshdr 5、sdshdr 8、sdshdr 16、sdshdr 32、sdshdr 64（这个的记忆也很简单，就是 32 开始，128，即 2 的多少次方去记忆就可以了），通过使用不同存储类型的结构题，灵活保存不同大小的字符串，从而节省内存空间。

4）buf（存储数据的字符数组）：主要起到保存数据的作用，如字符串、二进制数据（二进制安全就是一个重要原因）等。

不同编码的选择

1）int 编码：如果一个字符串可以被解析为整数，并且整数值比较小，Redis 会直接使用整数编码。

1
2
3
4
5

struct redisObject {
    unsigned type:4;      // 数据类型（字符串、哈希等）
    unsigned encoding:4;  // 编码类型（int、embstr、raw等）
    int64_t ptr;          // 实际的数据指针，这里直接存储整数值
};