自学内容网 自学内容网
自学内容网 > 正文

Redis

🕗 发布于 2024-11-15 09:55 redis  数据库  缓存  

1.什么是 Redis

1.1.Redis（基于内存的键值数据库系统）

Redis，全称 Remote Dictionary Server，是一个开源的、基于内存的键值数据库系统。作为一种 NoSQL 数据库，Redis 不同于传统的关系型数据库（如 MySQL、PostgreSQL），它不使用表格存储数据，也没有严格的表结构，而是采用键值对的形式（Key-Value）存储和操作数据。

键值数据库的定义

键值数据库（Key-Value Store）是一类 NoSQL 数据库，它的存储结构基于键（Key）和值（Value）对的形式。每一个键在数据库中是唯一的，通过键可以直接定位和访问到对应的值。相比于关系型数据库需要扫描表来查找数据，键值数据库可以直接查找到对应的数据，极大地提高了存取效率。

Redis 的设计初衷是实现高性能的数据存取，因此它的主要存储介质是内存（RAM），这使得 Redis 在读写速度上非常快。同时，Redis 支持持久化存储，将数据定期保存到磁盘上，即便发生故障也能恢复。Redis 在技术上结合了内存数据库的高速性和磁盘数据库的持久性，适合于需要快速响应和大量并发访问的场景。

1.2.Redis 的核心特点

Redis 是一种内存数据库，意味着它的数据主要保存在内存中以提高读写速度。其主要特点包括：

1.高性能：

  • Redis 的数据操作全部在内存中完成，因此访问速度极快，读写响应时间在微秒级。
  • 由于 Redis 支持多种数据结构，允许高效存储和访问更复杂的数据类型，从而进一步提升性能。

2.键值对中的值支持丰富的数据类型：

  • Redis 支持多种数据结构：字符串（String）、哈希（Hash）、列表（List）、集合（Set）、有序集合（Sorted Set），以及 位图（Bitmap）、HyperLogLog、地理空间索引等高级数据类型。
  • 这些数据类型扩展了键值数据库的使用场景，使 Redis 能够处理更多种类的任务（如计数器、排行榜、消息队列等）。

3.持久化功能：

  • 虽然 Redis 是内存数据库，但它提供了持久化选项，确保数据在服务重启或崩溃后不会丢失。
  • RDB（Redis Database Backup）：定时生成内存快照，保存到磁盘。
  • AOF（Append Only File）：记录每一次写操作并定期将日志保存到磁盘，可以在服务器重启时恢复数据。

4.高可用性和分布式架构：

  • Redis 支持主从复制（Master-Slave），可以实现数据的冗余存储和读取的负载均衡。
  • 通过 Redis Sentinel 和 Redis Cluster，Redis 可以提供自动故障转移、分布式存储和高可用性。

5.原子性操作：

  • Redis 的操作原子性较强，特别适合在分布式环境中处理事务操作。
  • 通过多种数据类型的操作命令，可以确保在高并发情况下数据一致性。

1.3.Redis 是如何作为键值数据库的

Redis 的数据存储基于键值对。每个键在 Redis 中都唯一存在，键的名称可以是字符串类型，而值的类型则可以多种多样，包括以下几种主要数据结构：

  • String（字符串）：最简单的键值对形式，用于存储字符串或数值。
  • List（列表）：用于存储有序的字符串集合，可以从两端进行插入和删除操作。
  • Hash（哈希表）：一个包含键值对的集合，类似于对象结构，适用于存储对象的多个属性。
  • Set（集合）：一个无序且唯一的字符串集合，适合去重和快速查找。
  • Sorted Set（有序集合）：一个带有分数的集合，按照分数排序，常用于排行榜应用。

Redis 使用内存来存储数据，使得所有的数据操作都非常快速。每次写入、读取或删除操作，Redis 都会直接在内存中完成，因此 Redis 适合用于对性能要求高、数据实时性高的应用场景。通过键直接查找到值，Redis 提供了极快的访问速度。

1.4.Redis 与其他键值数据库的区别

虽然 Redis 和其他键值数据库（如 Memcached）一样，都是基于键值对进行存储和查询，但 Redis 具有以下区别：

  • 数据结构的丰富性：Redis 支持更为丰富的数据结构，使其在功能上比 Memcached 更强大，适合更广泛的应用场景。
  • 持久化能力：Redis 提供 RDB 和 AOF 持久化机制，确保数据在服务重启后仍然可用，而大多数键值数据库仅用于内存缓存。
  • 集群和高可用支持：Redis 支持主从复制和 Redis Cluster，可实现分布式存储和容错。

1.5.Redis 的应用场景

Redis 作为键值数据库的应用场景非常广泛，包括但不限于以下几类：

  • 缓存：通过 Redis 存储经常访问的数据，减少数据库的访问次数，提高系统的响应速度。
  • 会话管理：在分布式系统中存储用户会话数据，实现跨服务器会话共享。
  • 消息队列：利用 Redis 的 List 结构，作为消息队列，实现异步数据处理。
  • 实时分析：用于在线人数统计、计数器等需要实时更新和获取的数据。

2.Redis 的工作原理详解

Redis 的高效性能源于它的内存数据存储方式、数据结构模型、事件驱动模型、以及持久化和数据淘汰机制。以下是 Redis 工作原理的详细解释：

2.1. 基于内存的数据存储与持久化机制

Redis 的数据存储主要依赖于内存，以确保高性能的读写速度。同时，Redis 提供了数据持久化机制，以保证数据在断电或系统故障时不会丢失。

  • 内存存储：Redis 将所有数据存储在内存中，从而实现快速的数据读取和写入。内存数据存储比基于磁盘的数据库快得多，适合对实时性要求较高的应用场景。
  • 数据持久化：Redis 支持两种持久化方式：
    • RDB（Redis Database）快照：Redis 可以定期将内存中的数据生成快照（Snapshot），保存到磁盘文件中。这样即使系统重启，Redis 也可以从最近一次快照恢复数据。RDB 的持久化操作是间歇性的，适合不需要精确实时数据的场景。
    • AOF（Append Only File）日志：AOF 持久化将每一次写操作都记录在日志文件中。Redis 重启时会读取 AOF 文件并依次重放操作，以恢复数据。AOF 更具实时性，适合数据一致性要求较高的场景。

Redis 可以灵活地选择持久化方式，甚至可以将 RDB 和 AOF 结合使用，在不同场景中取得持久化和性能的平衡。

2.2. 键值存储结构与多种数据结构

Redis 采用键值对（Key-Value）存储，数据通过键直接定位，查询非常迅速。同时，Redis 提供多种数据结构以支持不同的数据处理需求：

  • String（字符串）：最基础的数据类型，可以存储字符串、整数、浮点数，适合简单的键值存储场景。
  • Hash（哈希表）：适用于存储对象，提供多层次键值结构，可用于存储用户属性等。
  • List（列表）：存储有序的字符串序列，支持在两端插入和删除操作，适合实现消息队列。
  • Set（集合）：无序且唯一的字符串集合，适用于去重操作。
  • Sorted Set（有序集合）：带分数的集合，按分数排序，可用于排行榜等场景。

Redis 基于不同的数据结构提供不同的命令，保证操作的高效性。这些数据结构均使用内存中的优化设计，以便快速处理数据。

2.3. 单线程事件驱动模型

Redis 使用单线程事件驱动模型处理客户端的请求。在 Redis 中，所有的命令处理都是在一个线程中完成的。这种单线程模型的设计具有以下优点：

  • 无锁并发：由于 Redis 使用单线程，不会产生多线程环境中的锁竞争问题，减少了上下文切换和锁操作的开销，保证了执行的效率。
  • I/O 多路复用：Redis 利用 I/O 多路复用技术（如 epoll），在一个线程中实现了对大量客户端请求的并发处理。I/O 多路复用允许 Redis 在一个线程中同时监听多个网络连接，极大提高了处理效率。

Redis 的事件循环模型将 I/O 操作变为事件触发机制，使得 Redis 可以轻松处理数万个并发请求。

2.4. 数据存取机制

Redis 的键值存储机制主要通过哈希表实现，操作流程如下：

1. 写入操作

当用户执行写入操作（如 SET 命令）时，Redis 会进行以下步骤：

  • 生成键值对：Redis 接收客户端传递的键和值，将其生成键值对。
  • 存储到哈希表：Redis 在内存的哈希表中存储这个键值对，通过键计算哈希值以快速定位数据的存储位置。
  • 持久化操作：根据 Redis 的配置，决定是否将该操作记录到持久化文件中。如果启用了持久化机制（如 AOF 或 RDB），Redis 会将写入操作记录下来以便数据在重启时恢复。

这种基于哈希表的存储方式使得 SET 操作通常在常数时间内完成，具备极高的写入速度。

2. 读取操作

当用户执行读取操作（如 GET 命令）时，Redis 按以下步骤进行处理：

  • 通过键查找数据：Redis 通过键计算哈希值，在内存的哈希表中找到相应的存储位置。
  • 返回对应的值：找到键后，Redis 将对应的值从内存中读取并返回给客户端。

由于 Redis 通过哈希表直接定位到键的存储位置，GET 操作也能在常数时间内完成，非常高效。

3. 删除操作

当用户执行删除操作（如 DEL 命令）时，Redis 按以下步骤删除数据：

  • 在哈希表中查找键：Redis 通过键在哈希表中查找对应的数据位置。
  • 移除键值对：找到该键后，Redis 将该键值对从哈希表中移除。
  • 更新持久化文件：如果配置了持久化模式（如 AOF），Redis 会将该删除操作记录到持久化文件中，以保证删除操作在重启后仍然生效。

Redis 使用哈希表存储和查找键值，查找速度通常是常数级的，能够快速响应客户端请求。

2.5. 数据淘汰策略

由于 Redis 的数据存储在内存中，受限于内存大小，Redis 提供了多种数据淘汰策略来管理内存中的数据，以便在接近内存上限时有效释放空间：

  • noeviction：拒绝新写入，不淘汰数据。
  • allkeys-lru：使用最近最少使用（LRU）算法，在所有键中淘汰最近未使用的键。
  • volatile-lru：仅对设置了过期时间的键使用 LRU 淘汰策略。
  • allkeys-random：从所有键中随机选择进行淘汰。
  • volatile-ttl：从设置了过期时间的键中选择即将过期的键淘汰。

这些策略帮助 Redis 在不同场景下更好地控制内存使用，保证系统稳定。

2.6. 发布订阅与管道技术

Redis 还支持发布订阅（Pub/Sub）和管道（Pipeline）技术，以提升处理能力和灵活性：

  • 发布订阅：Redis 提供了发布订阅机制，允许客户端订阅特定的频道，当有消息发布到该频道时，所有订阅的客户端会收到通知。该功能广泛用于实时通知系统和事件驱动架构中。
  • 管道：Redis 允许客户端将多个命令批量发送，而不必等待每个命令的返回。这种批处理机制可以减少网络延迟，提高效率。

2.7. 渐进式哈希与自动扩展

Redis 的哈希表采用渐进式哈希（Incremental Rehashing）机制，确保在表扩展或缩小时不会出现性能波动：

  • 渐进式哈希：当哈希表需要扩展时，Redis 不会一次性完成所有数据迁移，而是每次操作时逐步迁移部分数据，直到完成全部扩展。
  • 自动扩展与缩小：Redis 根据哈希表负载因子自动调整表大小，保证哈希表性能，同时避免内存浪费。

3.数据类型与操作 

3.1. String（字符串）

特点：

  • String 是 Redis 中最简单、最基础的数据类型，每个键（key）对应一个字符串值（value）。
  • 支持存储文本、整数、浮点数等，可以执行字符串追加、数值自增自减等操作。
  • 最大存储长度为 512 MB。

核心操作命令：

命令说明示例
SET key value设置键 key 的值为 value，若键已存在则覆盖SET user:name "Alice"
GET key获取键 key 的值GET user:name
INCR key将键 key 的整数值加 1INCR user:visit_count
DECR key将键 key 的整数值减 1DECR user:remaining_points
APPEND key value将 value 追加到 key 的当前值后面APPEND user:name " Smith"

示例场景：网站访问量计数

在网站中可以使用 String 类型记录每日访问量，每次用户访问时将计数器加 1。

SET website:visits:2023-11-02 0          # 初始化当天访问量
INCR website:visits:2023-11-02           # 每次访问增加 1
GET website:visits:2023-11-02            # 获取当天访问量

3.2. Hash（哈希）

特点：

  • Hash 是一种存储键值对集合的数据结构，一个 key 下可以包含多个字段（field）和字段值（value）。
  • 适合用于存储结构化数据，例如用户信息、商品属性等，避免为每个字段创建多个 key。

核心操作命令：

命令说明示例
HSET key field value设置哈希表 key 中的字段 field 为 valueHSET user:1001 name "Alice"
HGET key field获取哈希表 key 中字段 field 的值HGET user:1001 name
HMSET key field1 value1 field2 value2 ...同时设置哈希表 key 中多个字段的值HMSET user:1001 age 25 email "alice@example.com"
HGETALL key获取哈希表 key 中所有的字段和值HGETALL user:1001
HINCRBY key field increment为哈希表 key 中的数值字段 field 增加 incrementHINCRBY user:1001 age 1

示例场景：用户信息存储

使用 Hash 存储用户信息，例如姓名、年龄、邮箱等：

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

HGET user:1001 name                # 返回 "Alice"
HGETALL user:1001                  # 返回所有字段和值
HINCRBY user:1001 age 1            # 将 age 增加 1

3.3. List（列表）

特点：

  • List 是一个有序的字符串序列，支持从两端插入和移除元素。
  • 可以实现先进先出（FIFO）和先进后出（LIFO）操作，适用于消息队列、任务队列等场景。

核心操作命令：

命令说明示例
LPUSH key value1 value2 ...将一个或多个值插入到列表 key 的头部LPUSH task:queue "Task1" "Task2"
RPUSH key value1 value2 ...将一个或多个值插入到列表 key 的尾部RPUSH task:queue "Task3"
LPOP key移除并返回列表 key 的头部元素LPOP task:queue
RPOP key移除并返回列表 key 的尾部元素RPOP task:queue
LRANGE key start stop获取列表 key 中指定范围的元素LRANGE task:queue 0 -1

示例场景：任务队列

可以使用 List 类型将任务按顺序存入队列中，并按先进先出的方式处理任务。

LPUSH task:queue "Task1" "Task2"       # 插入两个任务到队列头部
RPUSH task:queue "Task3"               # 插入任务到队列尾部

LPOP task:queue                        # 返回并移除 "Task2"
LRANGE task:queue 0 -1                 # 返回队列中的所有任务

3.4. Set（集合）

特点：

  • Set 是一个无序集合，每个元素唯一，不允许重复，适合用于去重、交集、并集等集合运算。
  • 常用于统计唯一值或查找共同元素的场景。

核心操作命令：

命令说明示例
SADD key member1 member2 ...向集合 key 添加一个或多个成员SADD user:1001:tags "Redis" "Database"
SREM key member1 member2 ...从集合 key 中移除一个或多个成员SREM user:1001:tags "Database"
SISMEMBER key member判断成员 member 是否在集合 key 中SISMEMBER user:1001:tags "Redis"
SMEMBERS key获取集合 key 中的所有成员SMEMBERS user:1001:tags
SCARD key获取集合 key 中的成员数量SCARD user:1001:tags

示例场景：用户标签系统

可以使用 Set 存储用户的标签信息，并保证标签不重复。

SADD user:1001:tags "Redis" "Database" "Caching"   # 添加标签
SISMEMBER user:1001:tags "Redis"                   # 检查 "Redis" 标签是否存在
SREM user:1001:tags "Database"                     # 移除标签 "Database"
SMEMBERS user:1001:tags                            # 返回所有标签

3.5. Sorted Set/ Zset（有序集合）

Zset 是 Redis 中对 Sorted Set 的简称 

特点：

  • 元素唯一：zset 中的每个元素是唯一的，不能重复。
  • 分数排序：每个元素都关联了一个浮点数类型的分数（score），Redis 会根据分数将元素进行升序排列。
  • 支持范围查询：可以按照分数范围或排名范围获取元素，提供灵活的查询能力。
  • 具备集合的操作：支持添加、删除、更新元素等操作。

核心操作命令：

命令说明示例
ZADD key score1 member1 score2 member2 ...向有序集合 key 添加成员及其分数ZADD leaderboard 100 "Alice" 200 "Bob"
ZRANGE key start stop [WITHSCORES]按分数从低到高返回集合 key 中指定范围的成员ZRANGE leaderboard 0 -1 WITHSCORES
ZREVRANGE key start stop [WITHSCORES]按分数从高到低返回集合 key 中指定范围的成员ZREVRANGE leaderboard 0 1 WITHSCORES
ZREM key member1 member2 ...移除有序集合 key 中的一个或多个成员ZREM leaderboard "Alice"
ZSCORE key member获取成员 member 在有序集合 key 中的分数ZSCORE leaderboard "Alice"

示例使用场景 

  • 排行榜：zset 的分数排序特性使其非常适合用于排行榜，例如游戏的积分排行榜、网站活跃度排行榜等。

  • 带权重的优先队列：可以用 zset 来实现优先级队列，每个元素的分数代表优先级，按分数排序保证高优先级的元素优先处理。

  • 时间序列数据：可以将时间戳作为分数，将事件作为元素存入 zset，从而按时间顺序进行事件的插入和查询。

3.6.总结

Redis 的五大数据类型通过不同的数据结构和操作命令满足了各种应用场景的需求：

  • String：简单键值存储，适合计数器、单一属性缓存。
  • Hash：结构化存储，适用于存储对象数据（如用户信息）。
  • List：有序队列，适合消息队列、任务队列。
  • Set：无序集合，用于去重、唯一性统计、共同好友等。
  • Sorted Set：有序集合，适合排行榜和积分排名。

4. 持久化机制

4.1.RDB（Redis Database，快照）

4.1.1.RDB 的工作原理

RDB 持久化是一种基于快照的持久化方式。Redis 会在指定的时间间隔内，将内存中所有的数据生成一个“快照”（Snapshot），然后将这个快照保存到一个二进制文件（通常为 dump.rdb）中。可以把 RDB 文件理解为 Redis 数据库在某一时刻的一个“截图”。

4.1.2. RDB持久化的使用

1.配置 RDB 持久化

在 Redis 配置文件 redis.conf 中，可以使用 save 选项来配置 RDB 自动保存的触发条件。例如：

save 900 1       # 在 900 秒（15 分钟）内有至少 1 次写操作，触发 RDB 保存
save 300 10      # 在 300 秒（5 分钟）内有至少 10 次写操作，触发 RDB 保存
save 60 10000    # 在 60 秒（1 分钟）内有至少 10000 次写操作，触发 RDB 保存

默认情况下，Redis 会在满足这些条件时自动生成 RDB 文件。可以根据业务需求调整这些参数以控制快照频率。

2.手动触发 RDB 持久化

可以使用以下命令手动触发 RDB 快照生成：

  • BGSAVE：生成快照时 Redis 会 fork 一个子进程执行操作，主进程可以继续处理请求。

    BGSAVE

    BGSAVE 会在后台异步生成 RDB 文件（通常为 dump.rdb），执行完后会将生成的快照文件保存在 Redis 的工作目录中。

  • SAVE：阻塞主线程，直接生成 RDB 快照。

    SAVE

    SAVE 命令在 Redis 主线程执行，会阻塞客户端请求直到保存完成，因此不建议在生产环境中使用。

3.关闭 Redis 时自动保存

在 redis.conf 文件中可以设置 Redis 在正常关闭时是否保存 RDB 文件：

stop-writes-on-bgsave-error yes  # 当 RDB 生成失败时停止写操作
rdbcompression yes               # 开启 RDB 文件压缩
rdbchecksum yes                  # 开启 RDB 文件校验
dbfilename dump.rdb              # 设置 RDB 文件名
dir /path/to/redis/data          # 设置 RDB 文件保存路径
  • 上述配置并不会直接让 Redis 在关闭时自动保存，这些配置主要是针对 RDB 文件的生成和存储的细节设置。Redis 在关闭时自动保存 RDB 文件的机制，是基于 Redis 的默认行为：当 Redis 正常关闭时，会自动触发 RDB 快照的保存。 

  • stop-writes-on-bgsave-error yes：这是一个保护性配置，用来防止在 RDB 持久化失败时继续写操作。如果 Redis 在执行 BGSAVE 过程中出现问题，无法正常生成 RDB 文件，则 Redis 会暂停所有写操作，以防数据丢失。这是为了避免数据被写入内存但未能及时保存到 RDB 文件中。

  • rdbcompression yes：此配置项用于在生成 RDB 文件时对其进行压缩。启用后，RDB 文件会以 LZF 算法进行压缩，从而减少磁盘空间的占用。

4.RDB 文件的恢复

当 Redis 重启时，RDB 文件会自动加载到内存中，以恢复数据。只需确保 dump.rdb 文件在工作目录中，Redis 启动时会检查该文件并加载数据。

4.1.3.RDB 的优缺点

优点：

  • 性能开销低：因为 RDB 是在指定的时间间隔生成的，Redis 可以在较长的时间间隔内保存一次快照，因此不会频繁写入磁盘，对性能的影响较小。
  • 恢复速度快：RDB 文件是一个紧凑的二进制文件，在 Redis 重启时可以快速加载到内存中，适合数据量较大的场景。

缺点：

  • 数据丢失风险：因为 RDB 文件是周期性生成的，所以在快照之间的数据变动没有被记录。一旦 Redis 宕机，则从最后一次快照到宕机时的数据会丢失。例如，如果 Redis 每 5 分钟生成一次 RDB 文件，而在第 4 分钟时服务器宕机，那么这 4 分钟内的数据将无法恢复。
  • 快照过程开销大：每次生成 RDB 快照时，Redis 都会创建一个子进程来完成数据快照操作。这个过程会占用较多的 CPU 和内存，尤其是在数据量较大时，可能会导致短时间的性能波动。

4.1.4.适用场景

RDB 适用于数据一致性（宕机数据不丢失）要求较低的场景，例如：

  • 定期备份和数据存档：RDB 的快照方式非常适合周期性备份需求。由于 RDB 文件是完整的数据快照，体积小、恢复速度快，可以方便地将 RDB 文件存储到远程服务器或云存储中，用于数据的长期备份和归档。

  • 数据分析和大数据处理：RDB 文件生成间隔可调，不会对 Redis 实时写入操作造成较大影响。适合用于数据分析场景，如需要周期性地将 Redis 中的数据导出进行分析，但不需要实时的数据一致性。

  • 需要快速重启的系统：RDB 文件是一个紧凑的二进制文件，加载速度快，适合需要快速重启的场景。当 Redis 重启后，可以直接加载 RDB 文件恢复到最近的快照状态，从而缩短重启时间。

4.2.AOF（Append Only File，仅追加文件）

4.2.1.AOF 的工作原理

AOF 持久化记录了 Redis 每次发生的写操作（如 SET、INCR），并将这些操作按顺序逐条追加到一个日志文件（appendonly.aof）中。可以理解为 AOF 记录了 Redis 每次写入数据的“日志”，Redis 重启时可以通过重放日志中的操作一步步恢复数据。

4.2.2. AOF持久化的使用

1.配置 AOF 持久化

在 Redis 配置文件 redis.conf 中，可以通过以下参数开启和配置 AOF 持久化：

appendonly yes                   # 开启 AOF 持久化
appendfilename "appendonly.aof"  # AOF 文件名

2.设置 AOF 同步方式

AOF 的写入方式由配置文件中的 appendfsync 参数控制，有三种模式：

appendfsync always     # 每次写操作都同步到 AOF 文件，确保数据完整性，但性能较差
appendfsync everysec   # 每秒将写操作同步到 AOF 文件，默认模式，平衡性能和数据完整性
appendfsync no         # 不主动同步，由操作系统控制缓存刷新，性能最高，但数据丢失风险较大

一般建议选择 everysec 模式，即每秒将写操作记录到 AOF 文件中。这种模式下，最多丢失 1 秒的数据，兼顾性能和数据完整性。

3.AOF 文件的恢复

当 Redis 启动时，如果 AOF 持久化已启用，Redis 会优先加载 AOF 文件以恢复数据。AOF 文件记录了所有写操作的历史，Redis 会按顺序重放每条命令以恢复数据。

4.2.3.AOF 的优缺点

优点：

  • 数据丢失风险小：AOF 记录了每次写入的操作日志，如果选择 always 模式，Redis 宕机时不会丢失任何数据，即使是 everysec 模式，也最多丢失 1 秒的数据。
  • 文件可读性好：AOF 文件记录的是 Redis 命令，可以手动编辑或查看历史操作，以便于排查问题。

缺点：

  • 文件体积大：AOF 会记录每一个写操作的日志，文件增长较快，长时间运行可能会占用大量磁盘空间。
  • 恢复速度较慢：AOF 需要重放日志中的所有写入操作，日志条目多时恢复速度较慢。

4.2.4.AOF 文件重写

为了防止 AOF 文件无限增长，Redis 提供了 AOF 重写机制，将文件中重复操作进行合并，以减少文件体积。比如，一个键被多次 SET 操作，重写后只保留最后一次 SET 操作，从而缩减文件大小，提高恢复速度。

1.手动触发 AOF 重写

由于 AOF 文件会随着写入操作的增加而不断增长，Redis 提供了 AOF 文件重写机制，可以通过 BGREWRITEAOF 命令手动触发：

BGREWRITEAOF

Redis 会以当前内存数据为基础重写 AOF 文件，并将文件中的重复操作进行合并，以减少文件体积并优化写入性能。

2.自动触发 AOF 重写

可以在 redis.conf 文件中设置自动重写的条件：

auto-aof-rewrite-percentage 100       # AOF 文件大小是上次重写后文件大小的 2 倍时触发重写
auto-aof-rewrite-min-size 64mb        # AOF 文件大小达到 64MB 时才触发重写

这两个参数控制了自动重写的触发条件：当 AOF 文件大小超过上次重写后文件大小的 100% 且文件大小大于 64MB 时，Redis 将自动进行重写。

4.2.5.适用场景

AOF 适用于数据一致性（宕机数据不丢失）要求较高的场景，例如：

  • 金融交易系统：金融系统中的交易数据、订单数据等对一致性要求较高。AOF 可以配置为 appendfsync always 模式，即每次写操作都立即记录到 AOF 文件中，确保数据在宕机时几乎不丢失。

  • 计数器、积分系统：在积分系统或计数器场景中，每个操作都需要保存，例如积分的增减、商品库存的修改等。这些操作需要即时同步到磁盘，以便在宕机后恢复时能完整地还原操作记录，避免数据不一致。

  • 实时日志、消息存储：在日志和消息系统中，需要持久化写入的操作，以便系统异常退出时能恢复所有的写入记录，避免数据丢失。AOF 的 everysec 模式可以保证每秒数据的持久化。

适用业务举例

  • 电商平台订单系统：每个订单和交易数据都需要记录，避免系统异常导致的交易数据丢失。
  • 用户数据保存：社交媒体或互动应用中，用户的增删操作、点赞、评论等数据需要保证一致性，避免丢失用户操作记录。

4.3.Redis 的混合持久化策略：RDB 与 AOF 的组合应用

Redis 从 4.0 版本开始支持混合持久化，将 RDB 快照和 AOF 日志结合在一起，以发挥两种持久化方式的优势：既减少了 AOF 文件的体积和恢复时间，又保证了数据的完整性。混合持久化策略被认为是高性能和高数据一致性之间的一个平衡解决方案。

4.3.1. 混合持久化的工作原理

在传统的持久化模式下，RDB 和 AOF 是单独存在的：

  • RDB 通过快照定期保存 Redis 的全部数据状态。
  • AOF 则记录每一次写操作的日志，保证即使在 Redis 意外停止时也可以恢复最近的数据。

在混合持久化模式下，Redis 生成 AOF 文件时会将当前的内存快照（即 RDB 格式的数据）写入 AOF 文件的开头，并将此后的增量操作（写命令）以 AOF 格式追加到文件末尾。这使得 AOF 文件既包含了一个完整的数据快照，也包含了之后的写操作日志。

具体过程如下：

  1. 生成快照：Redis 首先将当前内存中的数据生成一个 RDB 格式的快照，将此快照内容写入到新的 AOF 文件开头。
  2. 记录增量写操作：快照生成后，Redis 将自快照生成以来的所有写操作按 AOF 日志格式追加到文件末尾，形成增量写操作日志。

这样生成的 AOF 文件包含两部分内容：

  • RDB 快照部分：存储了 Redis 生成 AOF 文件时的全量数据。
  • AOF 增量部分：记录了从 RDB 快照生成时到文件重写结束期间的所有写操作。

这意味着当 Redis 启动时，Redis 在使用混合持久化时的恢复过程如下：

  1. 加载 RDB 部分：Redis 启动时，会从 AOF 文件中提取 RDB 部分，直接加载到内存中，以获得快照生成时的完整数据状态。
  2. 应用增量 AOF 日志：加载完 RDB 快照后，Redis 会继续读取 AOF 文件的增量部分，并逐条重放写操作日志，以恢复到最新的数据状态。

这种恢复流程比传统的 AOF 文件恢复更高效，因为 RDB 快照部分已经存储了大部分数据，而增量 AOF 日志相对较小，可以快速恢复。 

4.3.2. 配置混合持久化

要启用混合持久化，只需要在 Redis 配置文件 redis.conf 中开启 aof-use-rdb-preamble 选项：

aof-use-rdb-preamble yes

设置为 yes 时，Redis 在重写 AOF 文件时会采用混合持久化策略，将 RDB 快照作为前缀写入 AOF 文件。

完整配置示例：启用混合持久化

在 Redis 配置文件 redis.conf 中，启用混合持久化的配置示例如下：

# 启用 AOF 持久化
appendonly yes

# 设置 AOF 文件名
appendfilename "appendonly.aof"

# 设置 AOF 的同步模式，建议使用 everysec 模式
appendfsync everysec

# 启用混合持久化，将 RDB 作为 AOF 前缀
aof-use-rdb-preamble yes

# 设置 RDB 保存条件，确保定期生成 RDB 快照
save 900 1
save 300 10
save 60 10000

配置完后，Redis 会在开启 AOF 持久化的基础上，采用混合持久化策略进行数据保存和恢复。

4.3.3. 混合持久化的优缺点

优点

  • 加快数据恢复速度：传统的 AOF 需要重放所有写操作来恢复数据，恢复时间随着日志的增长而延长。而在混合模式下，由于 AOF 文件开头已经包含了一个完整的 RDB 快照，Redis 启动时可以直接加载 RDB 部分的数据，再应用少量增量操作即可完成数据恢复，大大加快了恢复速度。

  • 优化了磁盘空间使用：由于 AOF 文件重写后将当前内存状态压缩成 RDB 格式的快照，避免了冗余的操作日志，因此 AOF 文件的体积较小。

  • 降低了数据丢失风险：在 AOF 模式下，只要配置 appendfsync 为 always 或 everysec，可以保证数据不易丢失。即使 RDB 文件中未包含最近的数据变动，这些变动也会在增量 AOF 日志中被记录下来，确保数据完整性。

缺点

  • 文件体积较大：由于 AOF 文件前缀包含了 RDB 快照，在有大量数据的情况下，AOF 文件初始体积会增大。因此，选择合适的磁盘空间和定期进行 AOF 文件重写尤为重要。
  • 增量 AOF 部分的写入频率：增量日志的写入频率仍然受 appendfsync 参数控制，因此如果设置为 always，频繁的写入可能影响性能。在使用混合持久化时，可以考虑使用 everysec 模式以平衡性能和数据一致性。

4.3.4. 混合持久化的适用场景

混合持久化适用于高数据一致性（宕机数据不丢失）和高性能（快速重启）并重的场景，适合那些既要求数据完整性，又需要快速恢复的业务场景，例如：

  • 高可用的缓存层和数据库缓存：在 Redis 作为数据库缓存或高可用的缓存层时，混合持久化策略可以在保证较高数据一致性的同时，提供较快的恢复速度。RDB 快照和 AOF 增量日志的组合使得 Redis 宕机后可以快速重启，减少数据丢失。

  • 快速重启的分布式系统：在一些分布式系统中，Redis 宕机和重启的时间对整体系统的运行影响较大，因此要求 Redis 既要快速恢复数据，又要保证数据的高一致性。混合持久化可以缩短恢复时间，适合需要频繁重启或维护的系统。

  • 实时性和数据安全并存的系统：对于那些既需要数据实时更新、又要求一定的数据安全性的系统，比如实时统计、金融市场数据分析等，混合持久化在保证系统快速恢复的同时提供较好的数据一致性。

适用业务举例

  • 实时数据监控系统：在一些需要高频数据写入和高一致性的监控系统中，混合持久化可以在不牺牲性能的前提下确保数据的安全性和快速恢复。
  • 在线游戏：在游戏中用户的进度、等级等需要实时保存的数据可以使用混合持久化，以确保用户数据不会因服务器重启而丢失。

4.4.数据一致性在 Redis 持久化中的应用

在 Redis 的持久化策略中，数据一致性主要体现在是否可以在系统故障后，准确恢复到最后一次写入操作的状态：

  • RDB 持久化：RDB 通过定期生成快照来保存数据，这种方式并不保证高一致性，因为在两次快照之间可能有数据更新未被保存，因此当 Redis 宕机时，可能会丢失最近一段时间内的写入操作，导致数据不一致。

  • AOF 持久化：AOF 可以记录每次写操作，特别是在 appendfsync always 模式下，AOF 会在每次写入后立即同步到磁盘，从而实现较高的一致性。即便 Redis 意外宕机，恢复时数据也是最新的，避免丢失最近的数据写入。

  • 混合持久化：混合持久化结合了 RDB 快照和 AOF 日志，以保证系统在性能和一致性之间取得平衡。这种方式适合需要在快速恢复和数据一致性之间平衡的场景。

4.5.三种持久化方式对比

特性RDB（快照）AOF（仅追加文件）混合持久化（RDB + AOF）
工作原理定期生成内存数据快照，保存整个数据库的状态每次写操作都记录到 AOF 文件，按顺序保存写操作将 RDB 快照写入 AOF 文件的开头，之后记录增量写操作
数据一致性较低：在两次快照之间的数据更新可能会丢失较高：通过配置（如 always 模式）可最大限度保证一致性较高：结合 RDB 和 AOF，数据丢失风险低
性能影响较低：生成快照时会占用资源，但生成间隔可调节较高：频繁的写操作可能影响性能，特别是在 always 模式下中等：RDB 快照和增量日志结合，性能开销适中
文件体积较小：保存的是完整快照，数据更紧凑较大：记录所有写操作，日志文件持续增大中等：包含 RDB 部分的快照和少量增量日志
恢复速度快：直接加载 RDB 文件即可恢复慢：需要逐条重放 AOF 文件中的写操作快：加载 RDB 快照部分，然后重放少量增量日志
持久化文件可读性不可读：二进制格式可读：记录 Redis 命令，便于查看和手动修改部分可读：AOF 增量部分记录 Redis 命令
适用场景数据一致性要求不高、快速重启、定期备份数据一致性要求高、实时记录、日志恢复高一致性要求且需快速恢复的场景，例如分布式缓存
典型应用缓存系统、数据备份、分析系统交易系统、积分系统、实时日志在线游戏、实时监控系统、高可用缓存层

说明

  • RDB 持久化：适用于对实时数据要求不高的场景。其优点在于文件体积小、恢复速度快，但数据一致性较低，可能丢失最近的一些数据。典型应用场景包括定期备份和缓存系统等。

  • AOF 持久化：适用于需要高一致性的场景，尤其是在金融交易或积分系统等关键数据场景中，通过记录所有写操作保证尽量少的丢失数据，但文件体积较大、恢复速度相对较慢。

  • 混合持久化：在 RDB 和 AOF 基础上进一步优化，既保留了 RDB 的高恢复速度，又兼具 AOF 的数据一致性，适用于数据一致性和恢复速度要求都较高的场景，例如分布式缓存和实时监控系统。

5. 缓存淘汰策略

在 Redis 中，缓存的管理涉及两种不同的机制：缓存淘汰策略 和 缓存过期处理。

  • 缓存淘汰策略：当 Redis 达到内存上限时，决定如何选择和删除缓存数据，以腾出空间来存储新的数据。allkeys-* 策略会在所有键中选择要淘汰的键，而 volatile-* 策略仅在设置了过期时间的键中进行淘汰操作。
  • 缓存过期处理：用于管理有过期时间的数据，即控制过期的数据何时从缓存中删除。Redis 通过定期删除和惰性删除机制来清理过期的数据，以降低内存占用和系统负载。

缓存过期处理也被包含在缓存淘汰策略之中，是一种只对设置了过期时间的数据进行淘汰的缓存淘汰策略。

5.1. 缓存淘汰策略

缓存淘汰策略在 Redis 达到最大内存限制时生效（由 maxmemory 参数设置）。Redis 提供了多种策略用于选择应当删除的数据。

  • 如果希望在所有键中进行淘汰，包括没有设置过期时间的键：那么应该选择 allkeys 开头的策略（如 allkeys-lru、allkeys-lfu）。这种策略适合缓存系统中的数据没有严格的过期时间，或者希望 Redis 根据访问频率或使用时间来动态管理所有缓存。

  • 如果只希望在有过期时间的键中进行淘汰：则选择 volatile 开头的策略（如 volatile-lru、volatile-lfu）。这种策略适合对时效性要求较高的数据场景，比如实时新闻、临时会话数据等。Redis 在内存达到上限时，只淘汰那些已经设置了过期时间的键，而保留其他键。

5.1.1淘汰策略选项

可以在 Redis 配置文件 redis.conf 中，通过 maxmemory-policy 配置淘汰策略：

maxmemory-policy <策略名>

Redis 支持以下几种缓存淘汰策略：

场景推荐淘汰策略描述
高频访问的缓存数据allkeys-lru高频访问数据不易被淘汰，适用于用户活跃数据的缓存。
短期有效的缓存数据volatile-lru在带有过期时间的数据中淘汰最少使用的键，适合用于临时缓存的数据。
长期热点数据allkeys-lfu在所有键中淘汰访问频率最低的键，适合用于热门文章或商品推荐的场景。
数据访问模式随机allkeys-random适用于访问模式无明显规律的数据缓存，通过随机删除释放空间。
强时效性数据volatile-ttl在即将过期的键中优先删除剩余生存时间最短的，适合需要及时更新的短期有效数据。
关键数据持久化noeviction不进行淘汰，达到内存上限后直接拒绝写入，确保持久存储的数据不会被删除。

5.1.2 各种缓存淘汰策略的具体机制

1. LRU（Least Recently Used）——最近最少使用

原理：LRU 策略根据数据的最近使用时间进行淘汰。Redis 记录每个键的最后一次访问时间，当需要淘汰时，会选择最近未使用的键进行删除。

  • allkeys-lru：在所有键中淘汰最近最少使用的键。
  • volatile-lru：仅在设置了过期时间的键中，淘汰最近最少使用的键。

适用场景：适合有明显访问频率差异的数据，例如用户活跃数据的缓存管理。

2. LFU（Least Frequently Used）——最不经常使用

原理：LFU 策略根据数据的访问频率进行淘汰。Redis 记录每个键的访问次数，淘汰访问次数最低的键。此策略适合访问频次较为稳定的场景。

  • allkeys-lfu：在所有键中淘汰访问频率最低的键。
  • volatile-lfu：仅在设置了过期时间的键中，淘汰访问频率最低的键。

适用场景：适用于长期热点数据的场景，比如常访问的静态数据缓存。

3. Random（随机淘汰）

原理：随机淘汰策略不考虑数据的使用时间或访问频率，随机选择一部分键进行删除。适用于不关心数据访问频率的场景。

  • allkeys-random：在所有键中随机选择键进行淘汰。
  • volatile-random：仅在设置了过期时间的键中随机选择键进行淘汰。

适用场景：适合访问模式较随机、不规律的缓存场景。

4 TTL（Time to Live）——生存时间

原理：TTL 策略在即将过期的键中选择删除剩余生存时间最短的键。只在设置了过期时间的键中生效。

  • volatile-ttl：在设置了过期时间的键中，淘汰即将过期的键。

适用场景：适用于对时效性要求较高的数据，例如新闻数据、即时消息等。

5.2. 缓存过期处理

缓存过期处理用于自动清理那些已设置了过期时间的键，释放内存资源。Redis 配置了两种方式来处理过期的键：定期删除和惰性删除，确保在平衡性能和数据清理之间做到优化。

5.2.1 设置过期时间

可以使用以下命令为键设置过期时间：

  • EXPIRE key seconds：设置键 key 在 seconds 秒后过期。
  • PEXPIRE key milliseconds：设置键 key 在 milliseconds 毫秒后过期。
  • EXPIREAT key timestamp：将键 key 的过期时间设定为指定的时间戳 timestamp（秒）。
  • TTL key：查询键 key 的剩余生存时间。

示例：

SET user:1234 "data"
EXPIRE user:1234 300             # 设置键 300 秒后过期
TTL user:1234                     # 查询剩余生存时间

5.2.2 Redis 过期处理机制

Redis 自动使用定期删除和惰性删除两种机制来处理过期数据，无需手动配置。

定期删除（定时扫描）：

  • 默认情况下，Redis 每隔 100 毫秒随机抽取一部分设置了过期时间的键，检查并删除已过期的键。
  • 这样做避免了在某一时刻集中清理大量过期数据导致性能波动，通过分散删除操作，保证系统平稳运行。

惰性删除（惰性过期）：

  • 当 Redis 接收到某个键的访问请求时，会检查该键是否已经过期。
  • 如果键已过期，Redis 会在返回空结果前删除该键。
  • 惰性删除的好处在于不需要周期性扫描所有键，而是根据键的访问情况清理过期数据，降低系统负担。

 5.2.3 过期处理优化

为了保证缓存的高效性和合理利用内存，Redis 过期处理机制的优化方法如下：

  • 分布式设置过期时间：避免所有键在同一时间点过期。为每个键设置一个随机偏移量，以便过期时间更均匀分布。例如，使用 EXPIRE key 300 + rand(0, 60) 来分散过期时间，减少大量缓存同一时间过期导致的性能波动。

  • 结合淘汰策略与过期机制：可以选择合适的策略，如 volatile-lru，仅淘汰有过期时间的键，并优先淘汰不常用的数据，以减少内存消耗，确保重要数据不被删除。

6.缓存问题处理

6.1. 缓存穿透

定义

缓存穿透是指用户请求的数据既不在缓存中，也不存在于数据库中，导致每次请求都会绕过缓存，直接访问数据库。当大量请求请求这些不存在的数据时，可能会对数据库造成巨大的压力，甚至导致数据库崩溃。

产生原因

  • 恶意请求大量不存在的数据，绕过缓存直接访问数据库，造成数据库压力激增。
  • 业务逻辑缺乏校验，对一些无效请求（如空值、错误参数等）未进行处理。

解决方案

1.缓存空结果：

  • 当查询结果为空（即数据库中不存在该数据）时，将该空结果也缓存起来，并设置一个较短的过期时间（例如 1 分钟）。
  • 优势在于：下次请求该数据时可以直接从缓存中获取空值，避免继续访问数据库。
  • 示例：假设查询 user:12345 这个键时数据库中无该用户，那么可以在缓存中将 user:12345 对应的值设为空，并设置 60 秒的过期时间。

2.布隆过滤器（Bloom Filter）：

  • 使用布隆过滤器在缓存之前快速判断数据是否存在。布隆过滤器是一种高效的概率数据结构，可以判断一个数据“可能存在”或“肯定不存在”，非常适合大数据场景。
  • 将所有可能存在的数据提前加载到布隆过滤器中，当请求一个键时，先通过布隆过滤器判断。如果布隆过滤器判断该数据不存在，则直接返回，不查询缓存和数据库。

应用场景：适合需要存储大量键的数据，比如电商系统中的商品 ID。

3.参数校验与拦截：

  • 在接口层增加参数校验和过滤，对明显无效的请求进行拦截。
  • 例如，若用户 ID 应该为正整数，则可以在请求进入系统时先验证用户 ID 的合法性，过滤掉一些不合法的请求，防止无效请求进入缓存和数据库。

6.2. 缓存击穿

定义

缓存击穿是指某个热点数据（缓存中存在且被高频访问）在过期的瞬间，由于并发请求较多，导致大量请求在缓存过期的瞬间同时访问数据库，从而造成数据库压力过大。这种情况发生在缓存突然失效，并且请求量较大的场景。

产生原因

  • 某个高频访问的热点数据在缓存中失效。
  • 数据更新或缓存设置问题，导致热点数据过期后未能及时更新。

解决方案

1.热点数据永不过期：

  • 对于特定的热点数据，可以将其缓存设置为永不过期，以避免因过期导致的缓存击穿。
  • 同时，可以使用定时任务或后台线程来定期更新这些缓存数据，以保证数据的实时性。
  • 应用场景：适合热点数据少且更新不频繁的场景，例如首页配置数据、应用中的一些基础配置信息等。

2.互斥锁（Mutex）：

  • 在缓存失效时，通过加锁机制确保只有一个请求能查询数据库并更新缓存。其他请求则等待缓存更新完毕后，再从缓存中读取数据，避免大量并发请求直接访问数据库。
  • 实现方法：在缓存过期时，尝试获取分布式锁，只有获得锁的请求去查询数据库并更新缓存，其他请求等待缓存更新完成后再访问缓存。

3.提前刷新缓存：

  • 在缓存即将过期之前，提前触发缓存更新操作，保证缓存不会被全部失效。
  • 可以使用后台定时任务或消息队列，提前一段时间更新热点数据，以确保用户始终能从缓存中读取数据。
  • 应用场景：适用于缓存数据更新频率较高、过期时间可以预估的情况。

6.3. 缓存雪崩

定义

缓存雪崩是指在某个时间点大量缓存同时过期，或者缓存服务器不可用，导致大量请求直接涌向数据库，造成数据库压力骤增，甚至可能引起数据库崩溃。

产生原因

  • 大量缓存设置了相同的过期时间，在某一时刻同时失效。
  • 缓存服务器宕机或发生网络故障，导致缓存服务不可用，所有请求直接流向数据库。

解决方案

1.设置过期时间的随机化：

  • 在为缓存数据设置过期时间时，增加一个随机值，使缓存的过期时间分布更加均匀，避免大量缓存同时过期。
  • 例如，可以将过期时间设置为 expireTime + rand(0, 300) 秒，分散缓存失效的时间，减少瞬时过期的风险。
  • 应用场景：适合有大量相似数据缓存的场景，如电商网站中的商品详情缓存等。

2.多级缓存（本地缓存 + 分布式缓存）：

  • 建立多级缓存架构，在本地或应用服务器上设置一级缓存（如 Guava Cache）和 Redis 分布式缓存作为二级缓存。
  • 当 Redis 缓存失效时，可以从本地缓存中获取数据，避免大量请求直接涌向数据库。
  • 应用场景：适用于大规模缓存系统、实时性要求不高的数据。

3.请求限流与降级：

  • 在发生雪崩时，可以使用限流策略来限制对数据库的请求数量，确保系统稳定运行。
  • 超过请求阈值的请求可以返回默认值、友好提示，或进入降级处理流程。
  • 应用场景：适用于关键系统或高峰期的限流处理。

4.缓存预热：

  • 在系统启动或高峰期到来之前，提前将热点数据加载到缓存中，确保缓存中有必要的数据，避免突然的大量请求导致缓存雪崩。
  • 可以通过后台线程、定时任务等方式将热点数据写入缓存，以便系统上线时直接从缓存中获取数据。
  • 应用场景：适用于缓存数据量较多、冷启动时的缓存系统。

5.缓存高可用架构：

  • 通过 Redis 集群、哨兵模式（Sentinel）等机制来保证缓存系统的高可用性。当某个缓存节点不可用时，系统能够自动切换到其他节点，确保缓存服务的持续可用。
  • 应用场景：适用于高可用要求的分布式系统。

6.4.总结

问题类型描述主要解决方案
缓存穿透请求的数据既不在缓存中也不在数据库中，大量请求穿过缓存访问数据库缓存空结果、布隆过滤器、参数校验
缓存击穿高并发请求集中访问缓存中某个热点数据，缓存过期导致直接访问数据库热点数据永不过期、互斥锁、提前刷新缓存
缓存雪崩大量缓存同时过期或缓存服务器不可用，导致大量请求直接访问数据库设置过期时间随机化、多级缓存、限流与降级、缓存预热、高可用

7.性能优化 

在 Redis 中，为了实现高效的缓存和快速的数据访问，可以从多个方面进行性能优化：

  • 命令优化：避免高时间复杂度命令，使用 Pipeline 和 Lua 脚本减少请求次数，选择合适的数据结构。
  • 内存使用优化：设置最大内存限制和合理的淘汰策略，选择合适的数据编码，减少内存消耗。
  • Redis 性能监控：使用 INFO 和慢查询日志实时监控 Redis 状态，并结合第三方工具和警报系统实现全面监控。

7.1. 命令优化

Redis 是一个单线程的内存数据库，所有命令在同一线程上执行，因此每条命令的执行时间直接影响系统的吞吐量。合理优化命令的使用，可以有效提升 Redis 的性能。

1. 避免使用高时间复杂度的命令

Redis 中有一些命令的时间复杂度较高，可能导致较长时间的阻塞，特别是在大数据量操作时。这些命令包括：

  • KEYS：列出所有键，时间复杂度为 O(N)，容易导致阻塞。建议使用 SCAN 命令代替，它支持分批次地扫描键，不会阻塞 Redis。
  • SMEMBERS、LRANGE（对于大范围数据）：直接获取整个集合或列表，时间复杂度较高，处理大量数据时可能引发阻塞。建议使用 SSCAN、HSCAN、ZSCAN、LRANGE（限定范围）等分步获取数据。SCAN 系列命令以增量方式扫描键，每次返回部分结果，减少阻塞。
  • SORT：用于对集合或列表排序，时间复杂度为 O(N*log(N)+M*log(M))。如果数据量大，可以考虑在客户端或应用层进行排序。

2. 使用 Pipeline 批量处理命令

Redis 支持使用管道（Pipeline）功能将多个命令组合在一起，一次性发送给 Redis 执行，减少网络往返次数，提升性能。

  • 原理：Pipeline 可以将多个命令通过一次请求发送到 Redis，避免多次网络请求造成的延迟。
  • 应用场景：适用于需要对 Redis 执行大量独立操作的情况，例如批量写入数据、批量获取数据。

示例（Java 代码）：

Pipeline pipeline = jedis.pipelined();
for (int i = 0; i < 1000; i++) {
    pipeline.set("key" + i, "value" + i);
}
pipeline.sync();

3. 使用 Lua 脚本

Lua 脚本可以将多个命令封装在一个脚本中，在 Redis 服务器端一次性执行。避免多个命令分别发送引起的延迟。Lua 脚本执行过程中 Redis 不会被其他命令打断，保证了操作的原子性。同时减少网络交互次数，提升性能。

  • 优点：可以将多条 Redis 命令合并为一个脚本操作，避免复杂业务逻辑下的网络延迟。
  • 应用场景：适合多步操作必须在一起完成的场景，如检查并设置键的值、原子性计数器等。

示例（Lua 脚本）：

-- 伪代码：原子性检查并设置值
local current = redis.call('GET', KEYS[1])
if not current then
    redis.call('SET', KEYS[1], ARGV[1])
    return ARGV[1]
else
    return current
end

4. 合理选择数据结构

Redis 提供了多种数据结构（如 String、Hash、List、Set、Sorted Set 等），选择合适的数据结构可以显著提升性能。例如：

  • 计数器：使用 INCR、DECR 等原生命令来实现自增和自减，而不是使用 Hash 存储计数器。
  • Hash 表：适合存储对象的属性，例如用户信息，可以有效减少键的数量和内存占用。
  • List、Set、Sorted Set：根据数据是否有序、是否允许重复选择合适的数据结构。例如排行榜使用 Sorted Set。

7.2. 内存使用优化

合理管理内存，能够提升 Redis 的运行效率，减少资源浪费。Redis 提供了多种内存优化手段，通过选择合适的配置和数据编码方式，可以有效控制内存占用。

1. 设置最大内存限制

通过设置 Redis 的最大内存限制（maxmemory 参数），可以防止 Redis 因超出内存限制而崩溃。配置 maxmemory 后，还可以配合使用 maxmemory-policy 参数设置淘汰策略，以保证 Redis 在达到内存上限时优先淘汰不重要的数据。

示例：限制 Redis 使用 4GB 内存，并设置淘汰策略：

maxmemory 4gb
maxmemory-policy allkeys-lru

2. 合理选择数据编码

Redis 提供了多种数据编码（如 ziplist、hashtable、intset 等），可以根据数据量大小选择合适的编码，以减少内存消耗。例如：

  • Ziplist（压缩列表）：用于存储小量数据的列表和哈希。可以通过在 redis.conf 中设置 hash-max-ziplist-entries 和 hash-max-ziplist-value 参数控制使用 ziplist 编码的条件，减小内存占用。

  • hash-max-ziplist-entries 512
hash-max-ziplist-value 64

3. 使用共享对象

Redis 内部对常用的小整数和短字符串进行共享，减少了重复创建相同内容的内存开销。可以在应用中尽量复用相同的字符串，避免重复创建内容相同的键或值。

4. 定期清理无用数据

定期删除过期或不再使用的键，释放内存空间。可以使用 SCAN 命令配合删除操作，避免一次性删除大量键导致阻塞。

7.3. Redis 性能监控

监控 Redis 的性能状态可以帮助发现潜在的瓶颈并及时优化。Redis 提供了一些命令和工具，用于监控内存使用、命中率、慢查询等信息。此外，还可以通过第三方工具进行可视化监控。

1. 使用 INFO 命令获取实时状态

Redis 提供了 INFO 命令，可以获取 Redis 的状态信息，包括内存使用、命中率、连接数等。可以定期查看这些信息，以及时发现问题。

示例：

INFO memory        # 查看内存使用情况
INFO stats         # 查看统计信息
INFO clients       # 查看客户端连接信息

关键指标：

  • 内存使用情况：used_memory、used_memory_rss，查看 Redis 实际使用的内存。
  • 命中率：keyspace_hits、keyspace_misses，反映缓存命中情况，命中率越高越好。
  • 连接数：connected_clients，监控客户端连接数量，避免连接过多导致性能下降。

2. 监控慢查询日志

Redis 支持慢查询日志功能，可以记录执行时间超过阈值的命令。慢查询日志帮助发现可能影响性能的耗时操作，便于进一步优化。

配置慢查询：

slowlog-log-slower-than 10000     # 记录执行时间超过 10 毫秒的命令
slowlog-max-len 128               # 设置慢查询日志的最大长度

查看慢查询日志：

SLOWLOG GET        # 获取慢查询日志
SLOWLOG LEN        # 查看慢查询日志的长度

3. 使用 MONITOR 命令实时监控

MONITOR 命令可以实时打印 Redis 接收到的所有命令，适合在开发和调试阶段进行详细跟踪。

  • 注意，MONITOR 会产生大量输出，长期在生产环境中使用可能影响性能。

示例：

MONITOR

4. 第三方监控工具

  • Redis-Stat：轻量级 Redis 监控工具，可以实时监控 Redis 运行状态。
  • Redis Live：提供可视化监控界面，可实时查看 Redis 吞吐量、内存使用、命中率等指标。
  • Prometheus + Grafana：通过 Redis Exporter 将 Redis 指标导入 Prometheus，再通过 Grafana 实现可视化监控，适用于对 Redis 进行全面、实时监控的场景。

5. 配置警报和通知

使用监控系统对关键性能指标（如内存使用、命中率、慢查询等）设置阈值，超出阈值时触发警报并发送通知，以便及时响应性能问题。可以将 Redis 的关键指标接入报警系统（如 Prometheus Alertmanager），当某一指标异常时会即时通知管理员。

8. Redis分布式架构

8.1.主从复制 

8.1.1.什么是主从复制？

主从复制（Master-Slave Replication）是一种将数据从主节点（Master）复制到从节点（Slave）的机制。在 Redis 中，主从复制的主要目的是实现数据冗余备份、读写分离和数据的高可用。

  • 主节点负责处理所有的写入请求（例如 SET、DEL 等）。
  • 从节点只读，不处理写入操作。它的主要作用是同步主节点的数据，并提供读服务以分担主节点的压力。

通过主从复制，Redis 可以让读写操作分离，主节点处理写操作，从节点处理读操作，提升系统的整体性能。此外，从节点作为主节点的数据备份，可以在主节点故障时用于故障恢复。

8.1.2.主从架构原理

在 Redis 主从架构中，通常只有主节点负责接收写请求，并将数据写入自身。当配置了从节点后，主节点会自动将数据同步给从节点，从节点不会主动接收写请求，只负责从主节点获取数据并提供只读服务。

主要原理：

  • 写操作集中于主节点：所有写操作只发生在主节点上，保证数据的唯一入口。
  • 从节点同步主节点：主节点的每次数据更改都会被同步到从节点，以保证从节点的数据和主节点保持一致。
  • 读写分离：主节点处理写操作，从节点处理读操作，实现了读写分离，减轻了主节点的负担。
  • 数据冗余：从节点作为主节点的备份，当主节点出现故障时，可以将从节点提升为主节点以保证服务的连续性。

这种架构特别适用于读多写少的应用场景，因为从节点可以承接大量的读请求，从而提高系统的整体吞吐量。

8.1.3.数据同步方式

Redis 主从复制的数据同步方式分为 全量同步 和 增量同步，具体选择哪种同步方式取决于从节点的状态。

1. 全量同步

全量同步是指在从节点首次连接主节点时，主节点会把全部数据发送给从节点，从节点接收数据并加载到自己的内存中。

全量同步的步骤如下：

  1. 请求同步：从节点向主节点发送同步请求。
  2. 主节点生成快照：主节点生成数据快照（RDB 文件），并将快照文件传送给从节点。
  3. 加载快照：从节点接收快照文件，并将数据加载到内存中。
  4. 增量同步：快照加载完成后，主节点会继续将新的增量数据发送给从节点。

全量同步通常在从节点首次连接主节点，或主从节点之间连接中断并重连时触发。

2. 增量同步

增量同步是在全量同步完成后，主节点的每次写操作都会被增量同步到从节点，从节点根据这些增量数据更新自身数据。

  • 增量同步的效率较高，只发送主节点发生的更改部分，减少了网络传输和数据处理的开销。
  • 增量同步能够实时保持主从节点的数据一致性，适合实时性要求较高的场景。

增量同步是 Redis 主从复制的核心机制，在全量同步完成后，主节点的每次写操作都会被实时推送到从节点，保持主从数据的一致性。

8.1.4.主从复制的配置

配置 Redis 主从复制非常简单。通常只需要在从节点配置文件中指定主节点的 IP 地址和端口号，从节点启动后会自动连接主节点并开始同步数据。

在 Redis 主从架构中，主节点和从节点通常运行在不同的 Redis 实例上，每个节点（实例）有自己的配置文件。主从架构的实现通常需要部署多个 Redis 实例，即多个 Redis 进程，各自独立运行。

1.启动主节点：启动主节点实例，无需特殊配置。

redis-server /path/to/redis-master.conf

2.配置从节点：在从节点的配置文件（redis.conf）中，指定主节点的 IP 地址和端口号。

示例：在从节点配置文件中加入以下配置，将从节点连接到主节点的 IP 地址 127.0.0.1 和端口号 6379。

replicaof 127.0.0.1 6379

3.启动从节点：启动从节点实例，启动后从节点会自动向主节点请求同步数据。

redis-server /path/to/redis-slave.conf

4.动态设置主从关系：也可以在 Redis 已经运行的情况下，使用命令设置主从关系：

SLAVEOF <master-ip> <master-port>  # 设置当前节点为从节点，指定主节点
SLAVEOF NO ONE                     # 取消主从关系，将当前节点变为主节点

5.主从同步状态查看

可以在从节点上使用 INFO replication 命令查看主从复制的状态：

INFO replication

该命令会显示主从状态、主节点信息、同步状态等。

8.1.5.主从复制的应用场景

  • 读多写少的场景：例如电商网站的商品详情、社交网络中的用户信息等，读请求远多于写请求的场景，可以通过主从复制减轻主节点的读压力。
  • 数据备份：从节点作为主节点的实时备份，可以在主节点发生故障时提供数据冗余。
  • 负载均衡：将读请求分发到不同的从节点，分摊请求压力，实现负载均衡。
  • 快速故障恢复：在主节点故障后，迅速将从节点切换为主节点，减少服务中断时间。

8.1.6.主从复制的优缺点

优点

  • 读写分离：主从复制可以将读请求分散到从节点，提升读性能。
  • 数据冗余：从节点作为主节点的数据副本，保障数据不易丢失。
  • 简单配置：主从复制的配置简单，不需要太多额外的设置。

缺点

  • 数据一致性：由于存在同步延迟，主节点和从节点的数据可能会有短暂的不一致。
  • 单点写入：所有写请求都集中在主节点，主节点的写入性能可能成为瓶颈。
  • 故障恢复不自动化：如果没有哨兵机制辅助，当主节点故障时需要手动切换到从节点。

8.2.哨兵机制

Redis 的 哨兵机制（Sentinel） 是一种用于实现高可用性的监控机制。它在主从架构的基础上，引入了自动故障监控和主从切换的功能。通过哨兵机制，Redis 可以在主节点故障时自动选举新的主节点，从而确保服务的持续可用性。

8.2.1.哨兵机制的作用

哨兵机制的核心功能包括以下几方面：

  • 监控：哨兵进程会持续监控主节点和从节点的状态，定期检查是否有节点出现故障。
  • 通知：当某个节点发生故障时，哨兵会向管理员发送通知，提示节点出现异常。
  • 自动故障转移（主从切换）：当主节点故障时，哨兵会将一个从节点提升为新的主节点，并通知其他从节点与新的主节点建立同步关系。
  • 配置中心：客户端可以通过哨兵获取当前主节点的位置，从而自动连接到正确的主节点，不需要手动调整配置。

8.2.2.哨兵机制的工作原理

哨兵机制依赖于多个哨兵进程来共同监控 Redis 的主从节点。多个哨兵组成一个“哨兵集群”，通过协同工作来确认节点状态、进行故障切换和通知客户端。

1. 主从切换过程

当哨兵检测到主节点故障时，自动进行主从切换的流程如下：

  1. 故障判断：哨兵进程定期发送 PING 命令给主从节点，如果发现主节点在指定时间内无响应，则认为主节点可能故障。
  2. 故障确认：当一个哨兵认为主节点故障时，会向其他哨兵发出“协商请求”。只有当超过一定数量的哨兵（达到 quorum 数量）同意主节点故障时，才会真正开始故障转移。
  3. 选举新主节点：哨兵集群会选择一个从节点作为新的主节点，通常选择数据最完整、延迟最小的从节点。
  4. 通知从节点：哨兵会通知其他从节点，将它们的同步对象更新为新的主节点，建立新的主从关系。
  5. 通知客户端：客户端可以通过哨兵获取当前的主节点地址。切换完成后，哨兵会向客户端更新主节点的信息，确保客户端可以继续访问新的主节点。

2. 多数派机制

在哨兵机制中，为了避免误判，哨兵通过多数派机制（Quorum）来确认故障。

  • 多数派判定：当一个哨兵检测到主节点不可用时，不会立刻开始故障转移，而是请求其他哨兵确认。如果有足够数量（达到 quorum 值）的哨兵同意主节点故障，才会开始故障转移。
  • 故障转移条件：quorum 值可以在配置文件中设置。假设 quorum 设置为 2，那么至少需要 2 个哨兵认为主节点不可用，才会进行主从切换。

3. 客户端自动连接

客户端可以通过哨兵服务来动态获取主节点的信息。客户端在连接 Redis 时，不直接连接主节点，而是先连接哨兵查询当前主节点的地址。这样，即使主节点发生故障，客户端也可以通过哨兵获取新的主节点地址，自动连接新的主节点，保证服务不中断。

8.2.3.哨兵的配置方法

要使用哨兵机制，通常需要运行多个哨兵进程（至少 3 个哨兵）来监控 Redis 主从节点，确保高可用。

配置文件示例

哨兵的配置文件通常以 sentinel.conf 命名，以下是一个简单的配置示例：

port 26379                                    # 哨兵监听的端口
sentinel monitor mymaster 127.0.0.1 6379 2    # 监控的主节点，2 表示至少 2 个哨兵认为故障才进行切换
sentinel down-after-milliseconds mymaster 5000  # 如果 5 秒内无响应，则认为节点故障
sentinel failover-timeout mymaster 60000        # 故障转移的超时时间，默认 60 秒
sentinel parallel-syncs mymaster 1              # 故障转移后，从节点并行同步的数量

配置项说明

  • sentinel monitor：定义需要监控的主节点，mymaster 是主节点的名称，127.0.0.1 和 6379 是主节点的 IP 和端口，2 表示至少 2 个哨兵确认主节点故障后才进行故障转移。
  • sentinel down-after-milliseconds：如果主节点在 5 秒内没有响应，哨兵会判定主节点可能故障。
  • sentinel failover-timeout：在故障转移过程中，如果超过 60 秒仍未完成，则认为故障转移失败。
  • sentinel parallel-syncs：当新的主节点选出后，有多少个从节点可以并行同步数据。

启动哨兵

配置完成后，可以使用以下命令启动哨兵进程：

redis-sentinel /path/to/sentinel.conf

如果想使用 Redis 服务端启动哨兵模式，也可以使用以下命令：

redis-server /path/to/sentinel.conf --sentinel

8.2.4.哨兵机制的优缺点

优点

  • 自动故障恢复：主节点故障后，哨兵可以自动切换到从节点，提升服务的高可用性。
  • 客户端自动发现：通过哨兵，客户端可以自动获取新的主节点地址，不需要手动修改配置。
  • 监控与通知：哨兵会实时监控主从节点状态，出现异常时可以通知管理员。

缺点

  • 复杂度增加：哨兵机制需要额外的哨兵进程和配置，管理和维护相对复杂。
  • 短暂中断：在主从切换的过程中，客户端可能会出现短暂的连接中断。

8.2.5.哨兵机制的应用场景

哨兵机制适合需要高可用性和自动故障恢复的场景，尤其是业务场景中对 Redis 服务中断较为敏感的情况。典型的应用场景包括：

  • 用户登录状态维护：需要随时在线访问缓存的系统，哨兵可以在主节点故障时自动切换，保证用户访问不中断。
  • 实时排行榜：高并发场景下实时刷新排名数据，哨兵机制能够在主节点故障时迅速切换，从而保障数据访问的连续性。
  • 电商系统：在商品库存、用户信息、购物车等需要高可用的数据服务中，哨兵机制能够在主节点发生故障时自动切换，从而减少系统的宕机时间。
  • 社交平台：在用户状态、消息缓存等对服务稳定性要求高的场景，哨兵机制可以自动处理主节点故障，保证服务的连续性。

8.3.Redis Cluster集群 

Redis Cluster 是 Redis 的分布式集群模式，主要解决单机 Redis 在数据量和高可用性方面的限制。它通过将数据分片存储在多个节点上，实现数据的水平扩展，并支持节点间的通信和自动容错功能。 

8.3.1. 数据分片

Redis Cluster 的数据分片通过“哈希槽”（Hash Slot）机制来实现。

哈希槽（Hash Slot）机制

Redis Cluster 将所有的数据分为 16384 个哈希槽（Hash Slots），每个键值通过 CRC16 哈希算法计算出一个槽号（范围在 0 到 16383 之间），Redis Cluster 根据槽号来决定将数据存储在哪个节点上。每个节点负责管理一部分槽，多个节点共同存储和管理所有的数据。

  • 数据存储：在 Redis Cluster 中，所有的键根据槽号分布在不同的节点上，确保数据被均匀分配，达到负载均衡的效果。
  • 槽分配：Redis Cluster 的每个节点可以负责多个槽，通过分配不同槽到不同节点，实现了数据的水平扩展。

示例

假设有三个节点（Node A、Node B、Node C），可以将 16384 个槽分配给这些节点，如下所示：

  • Node A：负责槽 0 到 5461
  • Node B：负责槽 5462 到 10922
  • Node C：负责槽 10923 到 16383

当客户端存储数据时，Redis 会计算键的哈希槽号，然后将数据存储在相应的节点上。通过增加或减少节点数量，可以灵活扩展集群容量。

8.3.2. 节点间通信

Redis Cluster 的节点通过Gossip 协议进行通信，Gossip 是一种分布式系统常用的通信协议，主要用于状态同步和故障检测。Redis Cluster 中的节点通过 Gossip 协议定期交换彼此的状态信息，以保持数据一致性并检测节点的可用性。

通过Gossip 协议进行通信

  • PING 和 PONG 消息：每个节点会定期向其他节点发送 PING 消息，其他节点收到后返回 PONG 消息。通过这种心跳机制，节点可以检测到集群中其他节点的健康状态。
  • 故障检测：当某个节点在指定时间内没有响应其他节点的 PING 消息，该节点会被标记为“主观下线”（Suspect Down，简称 SDOWN）。如果多个节点确认该节点不可用，则标记其为“客观下线”（Objectively Down，简称 ODOWN）。
  • 节点间信息同步：节点间定期交换集群信息，包括槽位分配、节点状态等，以确保集群的全局状态一致。

节点类型

Redis Cluster 中的节点有两种类型：

  1. 主节点（Master）：负责管理数据和处理客户端请求。每个主节点负责一部分哈希槽，并存储相应的数据。
  2. 从节点（Slave）：作为主节点的备份，当主节点发生故障时，从节点可以接管主节点的职责，保障数据的高可用性。

每个主节点通常有一个或多个从节点作为备份，主从节点之间通过异步复制保持数据一致。

8.3.3. 集群管理

Redis Cluster 的集群管理功能包括节点的添加与删除、数据重新分配和负载均衡等操作，帮助集群管理员动态调整集群结构以满足业务需求。

1. 节点的添加与删除

Redis Cluster 支持动态添加和删除节点，方便扩展或缩减集群容量。

  • 添加节点：在 Redis Cluster 中可以添加新的主节点，将部分槽迁移到新节点，从而实现集群扩展。新节点加入后会接管一部分槽，并存储相关的数据。
  • 删除节点：如果需要缩小集群规模，可以将某个节点的数据迁移到其他节点后再将其移除。删除节点需要确保其负责的槽已迁移到其他节点上，避免数据丢失。

2. 数据重新分配

Redis Cluster 支持数据槽的重新分配，可以手动或自动平衡节点之间的负载。

  • 当添加新节点或删除节点时，Redis Cluster 会重新分配槽，确保数据均匀分布在各个节点上。
  • Redis Cluster 使用 MIGRATE 命令将某个槽的数据从一个节点迁移到另一个节点，确保数据的完整性。

3. 负载均衡

Redis Cluster 没有自带的自动负载均衡功能（即不会在节点负载高时自动迁移槽位），它不支持检测各节点的存储容量或负载情况并自动调整数据分布。要实现自动化的负载平衡，可以借助第三方工具（如 redis-trib 脚本）来定期检测负载并触发重分配，但这些操作本身仍需人为配置和管理。

在 Redis Cluster 中，可以通过重新分配槽来实现负载均衡，避免某些节点因数据过多而成为性能瓶颈。

  • 负载均衡：当节点的存储容量或负载超过一定阈值时，可以通过槽迁移将部分数据转移到其他节点，保持集群负载平衡。
  • 负载均衡：管理员也可以手动调整槽的分配，以实现均衡分布。

Redis Cluster 的集群管理功能保证了集群的弹性扩展性，使其能够灵活应对数据量和访问量的变化。

8.3.4. 容错机制

Redis Cluster 具备完善的容错机制，即使某些节点发生故障，集群也能自动恢复并保持正常运行。主要通过以下方式实现容错：

1. 主从复制与故障切换

Redis Cluster 每个主节点可以有一个或多个从节点作为备份。当主节点发生故障时，集群会自动将该主节点的一个从节点提升为新的主节点，以确保数据不丢失。

  • 故障检测：集群中的其他节点通过 Gossip 协议检测到主节点故障后，会发起投票确认故障。
  • 主从切换：确认主节点故障后，集群会选择该主节点的一个从节点，将其提升为新的主节点。
  • 同步更新：所有节点会更新集群元数据，让其他从节点重新指向新的主节点继续同步数据。

2. 客户端重定向

当客户端向集群发送请求时，如果请求的键不在连接的节点上，集群会返回 MOVED 错误，指示客户端重定向到正确的节点去请求数据。

  • 自动重定向：大多数 Redis 客户端库支持自动重定向功能，客户端收到 MOVED 错误后，会自动重新连接到正确的节点。
  • 读写请求路由：通过客户端的重定向机制，Redis Cluster 能够有效处理数据分片后的读写请求，保证客户端能够透明地访问分布式数据。

3. 故障恢复与数据重建

当主节点重新上线或集群结构发生变化时，Redis Cluster 会自动恢复故障节点的数据，并重新分配数据槽，保证集群数据的一致性和完整性。

  • 槽重建：当一个主节点恢复上线，集群会重新分配该节点负责的槽，并确保数据的同步。
  • 节点恢复：如果恢复的是从节点，集群会将其重新作为主节点的备份，保持主从冗余。

Redis Cluster 的容错机制确保了集群的高可用性，即使部分节点出现故障，也能通过主从切换、客户端重定向和故障恢复等机制保证数据的持续访问。

8.3.5.配置 Redis Cluster

1. 为每个节点准备独立的配置文件

Redis Cluster 中的每个节点都是一个独立的 Redis 实例，每个实例需要单独的配置文件。例如，可以创建 6 个配置文件 redis-node-6379.conf、redis-node-6380.conf 等，每个配置文件中指定不同的端口和集群配置。

配置文件示例（以 redis-node-6379.conf 为例）：

port 6379                        # 设置 Redis 实例的端口
cluster-enabled yes              # 启用集群模式
cluster-config-file nodes-6379.conf  # 集群节点配置文件
cluster-node-timeout 5000        # 集群节点的超时时间，单位为毫秒
appendonly yes                   # 启用 AOF 持久化，确保数据持久化

要创建 6 个节点的 Redis Cluster，需要分别指定 6 个不同的端口，确保每个实例的 port 参数和 cluster-config-file 参数唯一。

2. 启动所有 Redis 实例

在每个配置文件路径下，启动 Redis 实例。例如：

redis-server /path/to/redis-node-6379.conf
redis-server /path/to/redis-node-6380.conf
redis-server /path/to/redis-node-6381.conf
redis-server /path/to/redis-node-6382.conf
redis-server /path/to/redis-node-6383.conf
redis-server /path/to/redis-node-6384.conf

这 6 个 Redis 实例将会监听不同的端口，并等待进一步的集群初始化。

3. 创建 Redis Cluster

使用 redis-cli 提供的 --cluster 命令来创建集群，并指定每个节点的 IP 和端口号。在此步骤中，Redis 会自动将节点分配为主节点或从节点。

集群创建命令：

redis-cli --cluster create <node1-ip>:6379 <node2-ip>:6380 <node3-ip>:6381 <node4-ip>:6382 <node5-ip>:6383 <node6-ip>:6384 --cluster-replicas 1
  • <node1-ip>:6379 等表示节点的 IP 地址和端口。
  • --cluster-replicas 1 表示为每个主节点分配一个从节点（即 3 个主节点和 3 个从节点）。

执行该命令后，redis-cli 会进行一些检查，并询问是否确认分配槽位。输入 yes 后，Redis 将完成集群创建，槽位将自动分配给主节点，每个主节点还会有一个从节点进行数据备份。

示例：

redis-cli --cluster create 127.0.0.1:6379 127.0.0.1:6380 127.0.0.1:6381 127.0.0.1:6382 127.0.0.1:6383 127.0.0.1:6384 --cluster-replicas 1

4. 检查集群状态

在集群创建完成后，可以使用以下命令检查集群状态，确保所有节点成功加入集群并分配了槽位。

redis-cli -c -p 6379 cluster nodes

此命令会列出集群中每个节点的状态，包括节点 ID、IP 地址、端口、角色（主节点或从节点）以及当前分配的槽位范围。

查看集群状态：

redis-cli -c -p 6379 cluster nodes

该命令会返回集群的整体状态，包括槽位分配情况、连接数和集群的健康状态（状态显示为 cluster_state:ok 表示集群正常运行）。

8.3.6常用集群管理命令

在 Redis Cluster 中，当你添加或删除节点时，槽位不会自动重新分配，你需要手动进行槽位迁移。Redis Cluster 默认不会在节点数量变化时自动调整槽位分配，这样做是为了避免在生产环境中因槽位迁移带来的数据移动和性能影响。因此，在新增或移除节点时，手动进行槽位重新分配是必需的。

配置完成后，以下命令可以帮助你管理 Redis Cluster：

1.检查槽位分配：

redis-cli -c -p 6379 cluster slots

该命令可以显示槽位分配情况，包括每个主节点负责的槽位范围。

2.查看集群状态：

redis-cli -c -p 6379 cluster info

查看集群是否处于正常状态（cluster_state:ok 表示正常）。

3.添加新节点：

可以使用以下命令将新节点加入集群，扩展集群容量：

redis-cli --cluster add-node <new-node-ip>:<new-node-port> <existing-node-ip>:<existing-node-port>

4.移除节点：

可以使用以下命令从集群中移除节点：

redis-cli --cluster del-node <node-id>

注意，移除节点前需确保其槽位已迁移到其他节点。

5.迁移槽位：

在添加新节点或重新分配槽位时，可以使用以下命令进行槽位迁移：

redis-cli --cluster reshard <existing-node-ip>:<existing-node-port>

该命令会引导你进行槽位迁移，并将指定的槽位转移到新节点上。

9. Redis事务

Redis 事务是指一组命令的原子性执行，能够保证这些命令按顺序执行，但 Redis 事务与传统的关系型数据库事务不同，它不提供回滚和隔离级别等特性。Redis 提供了一些命令来支持事务操作，其中主要包括 MULTI、EXEC 和 WATCH，并通过 WATCH 实现了简单的乐观锁机制，帮助解决并发冲突。

9.1.Redis 事务支持的基本命令

Redis 事务通常包括以下几个步骤和命令：

  1. MULTI：标记事务的开始。MULTI 命令之后的所有命令都会被暂时存储起来，等待后续执行。
  2. 命令入队：在 MULTI 之后的命令会依次进入事务队列，但不会立即执行。
  3. EXEC：执行事务队列中的所有命令。所有命令会按顺序一次性执行，Redis 保证事务内的命令要么全部执行成功，要么都不执行（如果事务前出现 WATCH 监控的冲突情况）。
  4. DISCARD：取消事务。MULTI 之后，如果执行了 DISCARD 命令，那么事务队列中的命令会被清除，不再执行。
  5. WATCH：用于实现乐观锁。可以监控一个或多个键的变化，在 EXEC 前如果监控的键发生变化，事务将中止。

事务的基本特点：

  • 批量执行：事务中的所有命令会按顺序依次执行。
  • 原子性：事务中的每个命令会一次性、顺序地执行，EXEC 提交后，所有命令要么全部执行，要么不执行。

示例：使用 MULTI 和 EXEC 创建事务

MULTI
SET user:1001 "Alice"
INCR visits:1001
EXEC

在这个例子中，MULTI 开始事务，SET 和 INCR 命令进入事务队列，最后由 EXEC 一次性执行。

9.2.Redis 事务的命令详解

1. MULTI 和 EXEC

  • MULTI：开始事务，之后的命令不会立即执行，而是依次进入事务队列。
  • EXEC：提交事务，将事务队列中的命令一次性执行。如果事务中包含的任何命令有错误，Redis 不会中止整个事务，但会跳过执行有错误的命令。

注意：Redis 事务没有回滚机制，即使其中一个命令出错，其他命令仍会被执行。

示例：

MULTI
SET product:1001 "Laptop"
INCR stock:1001
EXEC

在 EXEC 执行前，可以继续往队列中添加命令，最终在 EXEC 提交后 Redis 会按顺序执行所有命令。

2. WATCH

WATCH 命令在 Redis 中用于实现乐观锁（Optimistic Locking）机制。WATCH 会监视一个或多个键，如果这些键在事务执行前被其他客户端修改，当前事务会自动中止，以避免并发冲突。这样可以确保在事务提交前，监视的键没有发生变化，从而保证数据的一致性。

WATCH 的工作流程：

  1. 在事务开始前，使用 WATCH 监视一个或多个键。
  2. 如果监视的键在 EXEC 执行前被其他客户端修改，则 EXEC 会中止，不会执行事务队列中的命令。
  3. 如果监视的键未被修改，则 EXEC 正常执行事务。

示例：使用 WATCH 实现条件更新

假设有一个账户余额 balance，我们想在余额足够的情况下执行扣款操作。

WATCH balance
# 获取余额
balance = GET balance
if int(balance) >= 100:
    MULTI
    DECRBY balance 100  # 扣除 100
    EXEC
else:
    UNWATCH  # 余额不足，取消监视

在这个示例中：

  • 首先使用 WATCH 监控 balance 键。
  • 读取 balance 的当前值，并检查是否满足扣款条件。
  • 如果满足条件，进入事务（MULTI），并执行扣款操作。
  • 如果 balance 在 EXEC 之前被其他客户端修改，EXEC 执行时会检测到 WATCH 的冲突情况并自动取消事务，避免并发修改问题。

3. DISCARD

DISCARD 用于取消事务。执行 MULTI 后，如果不想执行事务队列中的命令，可以使用 DISCARD 清除事务队列，放弃本次事务。

MULTI
SET name "Alice"
SET age 25
DISCARD  # 放弃事务，name 和 age 的设置不会生效

在上述例子中，DISCARD 取消了事务，name 和 age 的设置都不会执行。

9.3.Redis 的乐观锁机制

Redis 通过 WATCH 实现了简单的乐观锁（Optimistic Locking），用于解决并发条件下的数据一致性问题。

乐观锁的基本思路：

  • 使用 WATCH 监控一个或多个关键的键。
  • 在事务执行前检查监控的键是否被其他客户端修改过。
  • 如果键被其他客户端修改，则中止事务，避免对被修改的数据进行更新。

乐观锁的应用场景：

  1. 库存扣减：在电商平台上，商品库存的扣减是典型的并发操作。WATCH 可以在扣减库存前确保库存数量的准确性。
  2. 余额扣减：在金融系统中，余额扣减操作需要保持数据一致性。通过 WATCH 可以避免在余额更新过程中出现并发冲突。
  3. 抢购场景：在秒杀或抢购场景中，可以使用 WATCH 确保库存的唯一性，避免超卖。

使用 WATCH 实现并发安全的扣款操作

假设有一个账户余额 balance，每次扣款 100，并确保在并发操作下余额的一致性。

WATCH balance
balance = int(redis.get("balance"))
if balance >= 100:
    redis.multi()
    redis.decrby("balance", 100)
    redis.exec()  # 如果 balance 被修改，exec 会返回 nil，事务失败
else:
    redis.unwatch()  # 如果余额不足，取消监视

在该示例中，WATCH 用于监控 balance，以确保在 EXEC 之前 balance 没有被其他请求修改。通过 WATCH，可以避免多客户端同时扣减余额导致的余额错误。

9.4.Redis 事务的优缺点

优点

  • 原子性：事务内的命令要么全部执行，要么不执行，保障数据一致性。
  • 操作简单：通过 MULTI、EXEC、WATCH 等命令可以方便地实现事务和简单的并发控制。
  • 乐观锁支持：通过 WATCH 实现乐观锁，避免了大部分并发冲突问题。

缺点

  • 没有回滚：Redis 不支持事务回滚。如果事务内的命令出错，Redis 不会撤销已执行的命令。
  • 隔离级别低：Redis 不提供严格的隔离级别，在事务执行过程中，其他客户端可以继续访问未监控的键。
  • 单一节点限制：Redis 的事务不支持跨节点操作，在分布式环境中需要额外的事务机制支持。

7. Lua脚本支持

7.1.Redis中使用Lua脚本的优势

  • 原子性：在Redis中，Lua脚本是作为一个事务整体执行的，意味着在脚本执行过程中不会被其他命令打断。所有Redis命令在脚本内的执行都保证了操作的原子性，这对一些需要多次读写操作的业务逻辑特别重要，比如实现一个复杂的计数器、分布式锁等。

  • 减少网络交互：传统的Redis客户端操作是基于请求-响应模式的，每一次Redis命令都需要一次网络交互。使用Lua脚本可以将多个Redis命令整合到一个脚本中执行，减少了客户端与Redis之间的通信次数，显著降低了网络延迟。

  • 扩展性：Redis提供的命令集虽然丰富，但在某些复杂场景下不足以支持定制化逻辑。Lua脚本允许我们自定义操作逻辑，从而拓展Redis的功能。例如，通过Lua脚本可以实现限流、队列、计数等复杂业务逻辑。

  • 复用性：使用Lua脚本可以将常用的复杂操作封装起来，并在不同场景中复用，简化客户端代码，同时减少对Redis的直接操作。

7.2.Lua脚本的基本语法

7.2.1.执行Lua脚本的基本格式

Redis通过EVAL命令执行Lua脚本，基本格式如下：

EVAL <script> <numkeys> <key1> <key2> ... <arg1> <arg2> ...
  • <script>：Lua脚本内容，以字符串形式提供。
  • <numkeys>：键的数量，即KEYS数组的长度。
  • <key1> <key2> ...：传入的键名，会通过KEYS数组传递到Lua脚本中。
  • <arg1> <arg2> ...：其他参数，通过ARGV数组传递到Lua脚本中。

示例

以下脚本设置键值：

EVAL "return redis.call('SET', KEYS[1], ARGV[1])" 1 mykey myvalue

解析：

  • script为return redis.call('SET', KEYS[1], ARGV[1])，即执行SET命令，将mykey的值设置为myvalue。
  • numkeys为1，表示键的数量为1。
  • mykey放入数组KEYS[]的KEYS[1]的位置。
  • myvalue放入数组ARGV[]的ARGV[1]的位置。

7.2.2.基本命令 

1.变量

使用local定义局部变量。例如：

local count = 10

2.控制结构

Lua支持if条件、for循环和while循环。例如：

local count = 0
if count < 10 then
    count = count + 1
end

3.函数

定义函数时，使用local function语法。例如：

local function add(a, b)
    return a + b
end

4.传入参数

在Lua脚本中，通过KEYS数组和ARGV数组获取参数：用KEYS[i]来获取传入的键名，用ARGV[i]获取传入的键值或其他参数。例如：

local key1 = KEYS[1]
local value1 = ARGV[1]
redis.call("SET", key1, value1)

5.return 的作用

在Redis的Lua脚本中，return的作用是将结果返回给调用脚本的客户端。返回的内容可以是任何Lua类型的值，包括：

  • 字符串：返回redis.call()或redis.pcall()的结果，或自定义的字符串。
  • 数字：返回脚本内计算的结果，例如计数器的增量。
  • 表（数组）：返回多个值时，可以使用Lua的表结构。

7.2.3.调用Redis命令

redis.call()和redis.pcall()用于在Lua脚本中调用Redis命令，它们的基本格式如下：

redis.call("<Redis命令>", <参数1>, <参数2>, ...)
  • <Redis命令>：这是一个字符串形式的Redis命令，支持Redis的所有命令，如SET、GET、HSET、INCR等。
  • <参数1>, <参数2>, ...：这些是Redis命令需要的参数。通常，第一个参数是操作的键名，后续的参数是该命令所需的其他值。

redis.call() 和 redis.pcall() 的区别

  • redis.call()：严格模式。如果调用的Redis命令失败（例如访问了不存在的键），脚本会抛出一个错误并终止执行。适用于我们确定命令不会出错的场景。

  • redis.pcall()：安全模式。即使命令失败，脚本也不会终止，而是返回一个包含错误信息的表格。适用于需要更高容错性，脚本可能会继续执行的场景。

示例比较：假设键mykey不存在

使用redis.call()会抛出错误：如果mykey不存在且脚本期望有值，那么可能会报错并终止执行。

redis.call("GET", "mykey")

使用redis.pcall()会返回一个错误消息，而不是直接抛出错误：

local result = redis.pcall("GET", "mykey")
if result.err then
    return "An error occurred: " .. result.err
else
    return result
end

这里result可能包含错误信息，可以通过result.err进行检查，

7.2.4.执行大型Lua脚本的方法

在Redis中，如果Lua脚本内容较长，直接在命令行中编写可能不便且容易出错。Redis提供了两种方法来执行大型Lua脚本，确保脚本执行的效率和便捷性。

1. 使用脚本文件

将Lua脚本保存在文件中，通过命令行读取文件内容并传递给EVAL命令执行。这种方式特别适合处理复杂或大型的脚本。

步骤：

  1. 将Lua脚本内容写入文件，例如script.lua。
  2. 在命令行中读取文件内容并执行脚本。

示例

假设我们有一个文件script.lua，内容如下：

-- script.lua
local key1 = KEYS[1]
local value1 = ARGV[1]
redis.call("SET", key1, value1)
return redis.call("GET", key1)

我们可以使用以下命令在Redis中执行脚本：

EVAL "$(cat script.lua)" 1 mykey myvalue
  • $(cat script.lua)用于读取文件内容并传递给EVAL。
  • 1表示传递了一个键名。
  • mycounter和2作为参数传入脚本中，分别对应KEYS[1]和ARGV[1]。

这种方法适用于在本地开发环境下快速测试和执行较长的Lua脚本。

2. 使用SCRIPT LOAD和EVALSHA命令缓存脚本

对于经常使用的较长脚本，我们可以将其缓存到Redis中，然后通过EVALSHA命令调用缓存的脚本。SCRIPT LOAD会返回一个SHA-1校验码，以后可以直接使用这个校验码执行脚本，而无需每次都传输完整的脚本内容。

步骤：

  1. 使用SCRIPT LOAD将Lua脚本加载到Redis的脚本缓存中。
  2. Redis会返回该脚本的SHA-1校验码，用于标识脚本。
  3. 以后通过EVALSHA <sha1>命令调用缓存的脚本。

示例

假设我们有一个脚本文件script.lua

加载脚本到缓存：

SCRIPT LOAD "$(cat script.lua)"

Redis会返回一个SHA-1校验码，比如e0e1f9fabfc9d4800c877a703b823ac0578ff8db。

通过EVALSHA执行脚本：

之后可以通过以下命令来执行该脚本：

EVALSHA e0e1f9fabfc9d4800c877a703b823ac0578ff8db 1 mykey myvalue

EVALSHA后接SHA-1校验码，不需要传递脚本内容。1 mykey 10表示传入一个键名mykey和参数10。

使用EVALSHA时，Redis不会再次加载脚本内容，而是直接从缓存中获取并执行，因此节省了传输脚本的时间。这种方法非常适合需要频繁执行的较大脚本。

7.3.Redis中的典型应用场景

7.3.1. 分布式锁

场景：在分布式环境中，多个客户端可能需要对同一资源进行互斥访问，例如多个微服务实例操作同一个数据库记录时，需要一个分布式锁来确保数据一致性。

实现： Lua脚本可以通过判断锁是否存在来实现分布式锁。这一脚本先检查指定的锁键是否存在，如果不存在则创建锁并设置过期时间，确保即使客户端崩溃，锁也能自动释放。

local lockKey = KEYS[1]
local lockValue = ARGV[1]
local ttl = ARGV[2]

if redis.call("EXISTS", lockKey) == 0 then
    redis.call("SET", lockKey, lockValue, "EX", ttl)
    return true
else
    return false
end

  • 解释：

    • EXISTS 检查锁是否已存在。
    • 如果不存在，则使用 SET 命令设置锁，EX 参数设定锁的过期时间。
    • 返回 true 表示锁获取成功，false 表示锁已被占用。

  • 应用：这种脚本适用于实现分布式锁，确保在微服务环境下数据操作的安全性。

7.3.2. 限流

场景：限流用于控制请求频率，避免在短时间内过多的请求压垮系统。常见应用包括API请求限流和用户操作频率限制。

实现： Lua脚本可以实现限流器，在给定时间窗口内控制请求数量。如果请求数量超过设定的限流值，则拒绝后续请求。

local key = KEYS[1]
local limit = tonumber(ARGV[1])
local current = tonumber(redis.call("GET", key) or "0")

if current >= limit then
    return false
else
    redis.call("INCR", key)
    redis.call("EXPIRE", key, 1)
    return true
end

  • 解释：

    • GET 获取当前请求计数，如果键不存在则默认计数为0。
    • INCR 递增计数，表示当前窗口内又有一次请求。
    • EXPIRE 设置键的过期时间为1秒，这样每秒自动重置计数。
    • 返回 true 表示请求被允许，返回 false 表示已达限流上限。

  • 应用：此方法可以用来实现API限流、用户操作限流，避免服务被过载。

7.3.3. 计数器

场景：计数器是Redis中的典型应用，用于实现点击量统计、访问量计数等需求。计数器在高并发的场景下尤为重要，需要保证数据一致性。

实现： Lua脚本可以确保在并发情况下进行计数器的原子递增或递减操作。

local counterKey = KEYS[1]
local increment = tonumber(ARGV[1])

local current = tonumber(redis.call("GET", counterKey) or "0")
local new_value = current + increment

redis.call("SET", counterKey, new_value)
return new_value

  • 解释：

    • GET 获取计数器当前值，如果不存在则默认值为0。
    • 增加或减少指定的值 increment，得到新的计数。
    • SET 将新的计数值写回到键中。
    • 返回 new_value 作为最新的计数值。

  • 应用：此方法适用于高并发的计数需求，如视频点击量、文章阅读量等场景。

7.3.4. 队列

场景：在一些任务分发或延迟队列的场景中，Redis常用作消息队列。通过Lua脚本，可以实现任务的入队和出队操作，确保多消费者环境下的顺序和准确性。

实现： Lua脚本可以确保任务的出队操作具备原子性，避免多个消费者同时取出同一个任务。

local queueKey = KEYS[1]

local task = redis.call("LPOP", queueKey)
if task then
    return task
else
    return nil
end

  • 解释：

    • LPOP 从队列中弹出最左边的任务。
    • 如果队列为空，返回 nil，否则返回任务内容。

  • 应用：此脚本可用于消息分发和队列消费场景，确保每个任务只被一个消费者取出和处理。

7.3.5. 购物车库存扣减

场景：在电商应用中，当用户点击购买商品时，需要扣减库存，并确保库存扣减操作的原子性，避免超卖的情况发生。

实现： Lua脚本可以检查库存是否足够，如果足够则扣减库存并返回操作成功；否则返回库存不足。

local stockKey = KEYS[1]
local qty = tonumber(ARGV[1])

local stock = tonumber(redis.call("GET", stockKey) or "0")
if stock >= qty then
    redis.call("DECRBY", stockKey, qty)
    return true
else
    return false
end

  • 解释：

    • GET 获取当前库存量。
    • 如果库存量大于或等于购买数量，则执行 DECRBY 扣减库存。
    • 返回 true 表示扣减成功，false 表示库存不足。

  • 应用：这种操作常见于电商平台，确保多用户同时购买时库存的一致性，防止超卖。

7.3.6. 分布式计数器

场景：分布式计数器用于多个节点协同计数，比如统计全平台的用户访问量。需要原子性增量操作，并且允许高并发。

实现： 使用Lua脚本确保每次的计数操作是原子的，可以准确统计每次计数更新。

local counterKey = KEYS[1]
local increment = tonumber(ARGV[1])

redis.call("INCRBY", counterKey, increment)
return redis.call("GET", counterKey)

  • 解释：

    • INCRBY 增加指定计数值 increment。
    • 返回计数器最新的值。

  • 应用：适用于跨节点、跨服务的计数器需求，比如实时访问量统计。

7.3.7. 复杂的条件更新

场景：某些业务逻辑中，需要根据多个条件来更新Redis中的值，例如用户积分或状态更新。

实现： Lua脚本允许我们进行复杂条件判断，例如用户的积分更新需要先判断用户是否存在以及积分是否满足某些条件。

local userKey = KEYS[1]
local points = tonumber(ARGV[1])

local userExists = redis.call("EXISTS", userKey)
if userExists == 1 then
    local currentPoints = tonumber(redis.call("HGET", userKey, "points") or "0")
    if currentPoints + points >= 0 then
        redis.call("HINCRBY", userKey, "points", points)
        return redis.call("HGET", userKey, "points")
    else
        return "Insufficient points"
    end
else
    return "User does not exist"
end

  • 解释：

    • 检查用户是否存在。
    • 如果用户存在且积分充足，增加或减少积分。
    • 返回最新的积分或错误消息。

  • 应用：适用于用户积分系统或需要多条件判断的数据更新场景。

7.4.性能优化：减少网络交互、提升执行效率

  • 减少网络交互：将多次Redis命令通过Lua脚本封装成一次调用，减少了客户端与Redis之间的网络往返。例如，通过Lua脚本在服务端完成“读取-更新”操作，比两次交互快得多。

  • 批量操作：通过Lua脚本可以实现批量操作。例如批量删除多键时，传入多个键名，并在脚本中逐一删除，这样避免了多次网络请求。

  • 降低Redis I/O压力：在高并发下，通过Lua脚本可以减少Redis的频繁读写。例如限流操作可以用Lua脚本来避免每个请求都对Redis的多次访问。

  • 缓存脚本：对于较大的Lua脚本，通过SCRIPT LOAD命令加载到缓存，Redis会返回SHA-1校验码，后续可以用EVALSHA调用脚本，这样可以避免频繁传输大脚本内容，节省网络带宽和执行时间。

8. Redis的安全性

8.1.访问控制

Redis通过密码验证和ACL权限管理来控制用户访问，以便确保只有经过授权的用户能够访问和操作数据。

8.1.1.密码验证

Redis的密码验证是实现访问控制的基本方式。设置密码后，客户端必须在每次连接时提供正确的密码，否则将无法执行任何操作。

配置方法：

在Redis配置文件（通常为redis.conf）中设置requirepass参数以启用密码验证。例如：

设置好密码后，重启Redis服务以使配置生效。

使用方法：

连接Redis时，客户端应首先使用AUTH命令提供密码：

只有通过密码验证的客户端才能执行Redis命令，否则会收到“NOAUTH”错误。

注意事项：

  • 密码验证适用于基本的安全需求，但应当避免在生产环境中只依赖于密码保护。
  • 建议使用较长和复杂的密码，并定期更换，以提高安全性。

8.1.2.ACL权限管理

Redis 6.0及以上版本支持ACL（访问控制列表），可以更细粒度地管理用户权限。ACL允许创建多个用户，每个用户可以设置不同的密码和访问权限，例如控制用户可以执行的命令和访问的键。

ACL功能特点：

  • 创建不同的用户：可以为不同用户分配不同的访问权限。
  • 命令权限：限制用户可以执行的命令，例如只允许读取操作或特定的写操作。
  • 键权限：可以控制用户仅能访问特定的键或键的前缀。

常用ACL配置命令：

1.创建和配置用户：

ACL SETUSER <username> on >password ~<key pattern> +<permissions>
  • <username>：用户名。
  • on：激活用户（off表示禁用用户）。
  • >password：为用户设置密码。
  • ~<key pattern>：使用~<key pattern>可以指定用户能访问的键范围。例如：
    • ~cache:*：用户只能访问以cache:开头的键。
    • ~public:*：用户只能访问以public:开头的键。
    • ~*：允许用户访问所有键。
  • +<permission>可以为用户分配命令权限，支持以下两种设置方式：
    • 权限标签：用@表示命令集合，便于快捷配置。
      • @all：允许所有命令，完全访问权限。
      • @read：允许读取相关的命令（如GET、MGET、INFO等）。
      • @write：允许写入相关的命令（如SET、DEL、INCR等）。
    • 具体命令：可以单独添加具体的Redis命令，如+get、+set。

示例：

  • 创建管理员用户admin，允许执行所有命令并访问所有键：
  • ACL SETUSER admin on >adminpassword +@all ~*
  • 创建只读用户readonly，允许读取但禁止写入，能访问所有键：
  • ACL SETUSER readonly on >readonlypassword +@read -@write ~*
  • 创建受限用户limited，仅能访问以prefix开头的键，并能执行GET和SET操作：
  • ACL SETUSER limited on >limitedpassword ~prefix* +get +set

2.查看用户权限：

ACL GETUSER <username>

3.删除用户：

ACL DELUSER <username>

ACL优点：

  • ACL支持更细粒度的控制，可以根据用户的不同需求分配不同的权限，避免所有用户共享一个密码和完全权限。
  • 适合多用户场景中的权限管理需求，例如区分管理员和只读用户。

8.2.网络隔离

网络隔离是一种通过限制Redis实例的网络访问范围来提高安全性的方式。通常情况下，我们可以通过内网访问和防火墙设置来实现网络隔离，防止Redis实例被未经授权的网络访问。

8.2.1.内网访问

默认情况下，Redis监听所有网络接口，这意味着任何可以访问该服务器的设备都可以尝试连接Redis。为了提高安全性，建议配置Redis只监听内网IP，避免Redis暴露在公网中。

配置方法：

在Redis配置文件（redis.conf）中找到bind参数，配置Redis仅监听内网IP：

bind 127.0.0.1 192.168.1.10
  • 127.0.0.1：表示本地回环地址，只允许本地访问。
  • 192.168.1.10：表示服务器的内网IP地址。

重启Redis服务使配置生效。

使用protected-mode保护模式：

Redis的protected-mode在没有设置绑定IP或密码时，会自动启用，限制外部访问。

protected-mode yes

保护模式是Redis在没有设置适当安全措施（如密码或绑定IP）时的一道防护。

8.2.2.设置防火墙规则

为了进一步限制Redis的网络访问范围，可以使用防火墙来设置规则，确保只有特定的IP地址可以访问Redis实例。可以使用Linux的iptables或云服务的安全组来设置防火墙规则。

配置方法（以Linux的iptables为例）：

仅允许指定IP访问Redis端口（默认6379）：

iptables -A INPUT -p tcp -s <trusted_ip> --dport 6379 -j ACCEPT
  • <trusted_ip>：指定允许访问Redis的IP地址。

拒绝所有其他IP的访问：

iptables -A INPUT -p tcp --dport 6379 -j DROP

云服务安全组设置：

如果Redis部署在云服务器上（如AWS、阿里云），建议使用云提供的安全组来控制网络访问。

可以设置安全组规则，只允许来自特定IP地址或VPC网络的访问。

网络隔离优点：

网络隔离通过限制Redis实例的网络访问范围，避免Redis实例暴露在公网中，减少遭受恶意攻击的风险。

9. 核心应用场景

9.1.缓存系统

Redis在缓存系统中主要负责缓存数据的存储和管理，其核心功能包括数据缓存、会话管理和分布式缓存。缓存系统的引入，目的是减少对数据库的频繁访问，以降低数据库负载、加快响应速度和提高系统的可扩展性。

9.1.1. 数据缓存

数据缓存是Redis最常见的应用场景之一，通过缓存应用频繁访问的数据库数据，减少数据库的压力，加快系统响应。

  • 典型应用：将用户信息、商品信息等热点数据存储在Redis中，当用户访问时，直接从Redis中获取数据，避免了频繁查询数据库。
  • 优点：高效的内存读取，能够快速响应请求，避免数据库性能瓶颈。

使用方法：

  • 当数据查询请求到来时，系统首先会从Redis中获取数据。
  • 如果Redis中存在该数据（缓存命中），则直接返回缓存结果。
  • 如果Redis中不存在该数据（缓存未命中），则从数据库中获取，并将结果写入Redis缓存以供下次查询。

9.1.2.会话缓存

会话缓存用于存储用户的会话信息，通常包括登录状态、用户偏好设置等。在分布式系统中，Redis作为会话缓存，能够让多个服务器共享会话信息，实现无状态化服务，使得用户的会话信息能够在多个服务器间保持一致。

应用场景：用户登录时会在Redis中存储一个唯一的会话ID（Session ID）和用户数据。通过Redis的自动过期机制，可以在用户不活跃后自动清除会话数据。

示例：

登录成功后，在Redis中设置一个用户会话数据，并设置过期时间：

SET session:12345 "user_id:1001" EX 3600  # 过期时间为1小时
  • 每次用户请求时，通过GET session:12345来验证会话是否有效。

优点：实现跨服务器的共享会话，简化分布式架构中的会话管理。

9.1.3.分布式缓存

在流量较大或数据量较多的情况下，单一Redis实例可能无法满足需求，此时可以将Redis配置为分布式缓存，通过集群方式将数据分布在多个Redis实例中。Redis分布式缓存通常通过Redis Cluster实现，可以让数据自动分布到不同节点，支持水平扩展和故障切换。

原理：Redis Cluster将数据划分成多个分片（slot），每个节点负责处理一部分分片的数据。客户端根据数据的键值确定数据所在的分片位置，直接请求相应的节点。

示例：

  • Redis Cluster在部署时将数据分为16384个槽位（slot），每个键根据哈希值落入一个槽位，这样每个Redis实例可以持有不同的槽位集合。
  • 分布式缓存中，多个Redis实例协同工作，可以显著提高缓存的容量和访问速度。

优点：支持水平扩展，适合大规模的数据缓存需求，可以承载更高的请求量和更大的数据存储。

9.2.分布式锁 

在分布式系统中，不同的服务或进程（即多个“节点”）需要协同工作、共享资源。这种系统架构被称为分布式环境，特点是多个独立的节点在不同的服务器上运行，并通过网络相互通信。分布式环境具有更高的处理能力和可靠性，但也带来了资源争用和数据一致性的问题。特别是当多个节点同时访问同一个资源时，容易导致数据冲突。为了解决这种资源争用问题，引入了分布式锁。

9.2.1.什么是分布式锁？

分布式锁是一种机制，用于确保在分布式环境中，多个节点对同一资源的访问是互斥的，即同一时刻只能有一个节点能获取到锁并访问资源，其他节点则需要等待或轮询。分布式锁的核心作用是协调资源访问，确保每个节点按顺序进行操作，从而避免数据不一致或冲突。

分布式锁具备以下几个关键特性：

  • 互斥性：同一资源在同一时间只能被一个节点访问。
  • 超时控制：设置锁的超时时间，防止客户端崩溃或死锁导致锁长时间占用。
  • 唯一性验证：确保只有获取锁的客户端才能释放锁，避免其他客户端误解锁。

Redis因其高性能和原子操作的支持，是实现分布式锁的常用工具。通过Redis，我们可以在分布式系统中轻松实现资源的独占控制，从而保障系统数据的完整性和一致性。

9.2.2.Redis实现分布式锁的四种主要方法

  • 第一种方法如果不使用lua脚，则不具有原子性，原子性的来源是因为使用了lua脚本。
  • 第一种方法在使用lua脚本的情况下，与第三种的唯一区别是第一种方法锁的释放是通过锁的过期自动释放锁，而第三种方法锁的释放在过期自动释放之前，在满足创建锁与持有锁都为同一客户端的前提下（唯一性验证），可以提前释放锁。

Redis实现分布式锁常用的三种方法是SETNX + EXPIRE、SET NX EX和Lua脚本实现完整分布式锁。我们将逐一介绍每种方法的实现原理及区别。

1. SETNX + EXPIRE

SETNX + EXPIRE是实现分布式锁的一种经典方法，利用SETNX和EXPIRE来完成加锁和设置过期时间。为了保证操作的原子性，通常通过Lua脚本将SETNX和EXPIRE组合在一起执行，以防止命令之间被打断。

实现逻辑

  • 加锁：使用SETNX（Set if Not Exists）命令尝试创建一个锁键。如果键不存在，则创建锁并返回成功；如果键已经存在，则表示锁已被占用，当前客户端无法获取锁。
  • 设置超时时间：为锁键设置一个超时时间，防止客户端因故障无法释放锁时造成死锁。
  • 释放锁：通常依赖锁的自动过期时间，一般不在任务完成后手动执行解锁。此方法不进行唯一性验证。

示例：通过Lua脚本实现SETNX + EXPIRE

为了保证原子性，将SETNX和EXPIRE组合成一个Lua脚本：

if redis.call("SETNX", KEYS[1], ARGV[1]) == 1 then
    redis.call("EXPIRE", KEYS[1], ARGV[2])
    return true
else
    return false
end
  • KEYS[1]：锁键。
  • ARGV[1]：锁的值（通常为唯一标识，如UUID），用于标识哪个客户端持有锁。
  • ARGV[2]：锁的超时时间，防止死锁。

2. 使用SET命令原子化设置锁

从Redis 2.6.12版本开始，SET命令支持了原子化的NX和EX选项，允许同时设置锁和过期时间。

实现逻辑：

使用SET命令同时创建锁并设置过期时间。

示例：

SET lock_key unique_value NX EX 10
  • NX：仅在键不存在时设置。
  • EX 10：设置过期时间为10秒。

优点：此方法是原子操作，但在解锁的时候并没有进行唯一性验证。

3. 使用Lua脚本实现完整的分布式锁

为了确保解锁时的安全性和唯一性验证，Redis可以利用Lua脚本实现一个更安全的分布式锁方案。该方案的关键在于唯一性验证，确保只有持有锁的客户端才能解锁，从而避免误解锁的情况。

实现逻辑

  1. 加锁：使用Lua脚本执行SETNX和EXPIRE，确保操作的原子性。每个客户端生成一个唯一标识（如UUID）作为锁的值，以区分不同客户端持有的锁。
  2. 解锁时的唯一性验证：在解锁时，Lua脚本会首先检查锁的值是否与当前客户端的唯一标识匹配，只有匹配时才执行删除锁的操作。这样可以确保其他客户端不会误删除当前持有的锁。

示例：完整的加锁和解锁过程

加锁脚本：

if redis.call("SETNX", KEYS[1], ARGV[1]) == 1 then
    redis.call("EXPIRE", KEYS[1], ARGV[2])
    return true
else
    return false
end

解锁脚本：

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

  • 验证唯一性：redis.call("GET", KEYS[1]) == ARGV[1]

    • 这一步通过检查锁的值是否与客户端的唯一标识（ARGV[1]）一致，确保只有持有锁的客户端才能执行解锁操作。
    • 如果锁的值不匹配，则说明该锁已经被其他客户端重新获取，此时不进行任何操作，返回0。

  • 删除锁：redis.call("DEL", KEYS[1])

    • 在验证通过的前提下执行DEL操作，将锁删除，释放资源。

优点

  • 安全性更高：Lua脚本确保了加锁和解锁的过程是原子的，并且通过唯一性验证防止误解锁。
  • 避免竞态条件：确保锁不会被无关的客户端误删，从而提高分布式锁的可靠性。

4. Redlock算法

Redlock是Redis的作者提出的一种分布式锁算法，适用于在多个Redis实例上实现锁的管理。Redlock通过在多个独立的Redis实例上尝试获取锁来提高锁的可靠性。

  • 实现逻辑：

    • 客户端在多个Redis实例上尝试获取锁。
    • 客户端需要获得大多数（如5个实例中的3个）Redis实例的锁才能认为锁获取成功。
    • 如果客户端成功获取锁，可以执行操作；完成后需在所有实例上释放锁。

  • 优点：即使部分Redis实例发生故障，Redlock依然能够保证锁的有效性，提高分布式锁的可靠性。

9.2.3.Redis分布式锁的应用场景

Redis分布式锁适用于以下常见场景：

  • 订单处理：在电商平台中，用户提交订单时需要加锁，以避免同一订单被多次提交。
  • 库存管理：在并发购买场景中，多个客户端需要扣减库存时，分布式锁确保只有一个客户端能扣减库存，防止超卖。
  • 任务调度：在任务调度系统中，确保任务只被一个服务实例处理，避免重复执行。

9.3.消息队列

Redis作为消息队列广泛应用于分布式系统中，主要用于任务的异步处理、服务之间的解耦和消息传递。Redis提供了三种主要的消息队列实现方式：发布/订阅（Pub/Sub）和Stream流。下面将详细介绍Redis在消息队列中的应用和每种实现方式的特点。

9.3.1.什么是消息队列？

消息队列是一种在分布式系统中用来在生产者和消费者之间传递消息的数据结构。消息队列的作用是将消息异步存储在队列中，允许生产者（消息的发送方）和消费者（消息的接收方）独立地进行消息传递。消息队列的典型特点有：

  • 解耦：消息队列允许生产者和消费者在不同的时间、不同的服务中独立工作，提供了服务之间的解耦。
  • 异步处理：生产者可以立即返回，而不必等待消费者完成处理。
  • 消息存储和转发：消息队列存储消息并按顺序转发给消费者，确保消息传递的可靠性和顺序性。

9.3.2.Redis实现消息队列的两种方式

1. 发布/订阅（Pub/Sub）模式

发布/订阅模式（Pub/Sub）是一种实时消息推送机制，生产者可以将消息发布到一个或多个频道（channel）中，所有订阅该频道的消费者会即时收到消息。Redis的发布/订阅机制类似于广播系统，消息发布后会立即被订阅者消费。

工作原理

  • 发布者：生产者将消息发布到指定的频道。
  • 订阅者：消费者订阅一个或多个频道，一旦有新消息发布到这些频道，订阅者会立即收到消息。

Redis的Pub/Sub模式的通信是实时的，消息不会存储，因此在消息发布的瞬间，订阅者必须在线且处于订阅状态，才能收到消息。

实现示例

发布消息：

PUBLISH my_channel "Hello, World!"
  • 这条命令将消息 "Hello, World!" 发布到频道 my_channel。

订阅频道：

SUBSCRIBE my_channel
  • 当客户端执行SUBSCRIBE命令订阅my_channel后，会收到所有发布到该频道的消息。

优缺点

  • 优点：实现简单，实时性高，适用于即时通信、实时通知等对消息延迟敏感的场景。
  • 缺点：Pub/Sub不持久化消息，没有存储历史消息的功能。若订阅者掉线或当时未处于订阅状态，消息将无法再被接收，这在需要消息可靠传递的场景中是一个缺点。

适用场景

  • 聊天室：所有用户都实时收到消息，消息无需存储。
  • 实时推送：需要将即时消息快速推送到多个客户端，但不需要持久化消息。

2. Stream（流）模式

从Redis 5.0开始，Redis引入了Stream（流）数据结构，提供了一个更加完善的消息队列功能。与Pub/Sub不同，Stream模式支持消息持久化和消费组（Consumer Group），可以实现复杂的消息传递和可靠性控制。

工作原理

  • 消息生产者：通过XADD命令将消息添加到Stream中，消息会以流的形式追加到队列末尾。
  • 消息消费者：通过XREAD或XREADGROUP命令从Stream中读取消息，可以读取最新消息或从特定位置开始读取。
  • 消费组：消费组允许多个消费者消费同一Stream中的消息，且每个消息在同一消费组内只会被一个消费者消费。消费组可以实现并发消费，并支持消息确认和消费进度管理。

Stream的核心功能

  • 持久化：Stream中的消息可以永久存储，除非显式删除，确保消息不会丢失。
  • 消息确认：消费者读取消息后，需要通过XACK命令确认已处理消息，从而实现消息的确认机制，确保消息不被重复消费。
  • 消费组（Consumer Group）：支持同一Stream被多个消费者并行消费，适合需要并发处理的场景。

实现示例

添加消息到Stream：

XADD mystream * field1 value1 field2 value2
  • mystream：Stream的名称。
  • *：让Redis自动生成消息ID。
  • field1 value1：消息的字段和值，可以包含多个字段。

读取消息：

使用XREAD读取消息，通常用于单个消费者从Stream读取消息。

XREAD COUNT 2 STREAMS mystream 0
  • COUNT 2：每次读取两条消息。
  • mystream：Stream的名称。
  • 0：表示从最早的消息开始读取。

使用XREADGROUP命令通过消费组读取消息，适合多个消费者并行读取。

XREADGROUP GROUP group_name consumer_name COUNT 2 STREAMS mystream >
  • GROUP group_name consumer_name：指定消费组名称和消费者名称。
  • >：表示从消费组的最新位置读取。

确认消息：

消费者在处理完消息后，使用XACK确认消息已处理，防止消息再次被消费。

XACK mystream group_name message_id
  • mystream：Stream名称。
  • group_name：消费组名称。
  • message_id：要确认的消息ID。

优点：

  • 持久化：消息可以永久存储，确保消费者掉线或暂时离线后可以继续消费。
  • 消费组：支持多消费者并发处理，实现消息的负载均衡。
  • 消息确认机制：可以防止消息丢失，确保每条消息都被处理。

适用场景

  • 任务调度系统：任务生成后存入Stream，由多个消费者并发消费并处理，适合处理高并发任务。
  • 日志系统：日志生成后可以永久存储，供多个消费者分析和处理。
  • 事件溯源系统：所有事件都记录在Stream中，可以随时回溯处理历史消息。


原文地址：https://blog.csdn.net/m0_73837751/article/details/142904529

免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！

相关文章

自学内容网
Copyright © 2015-2024