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

Redis完全指南：从基础功能到缓存管理与高可用性设计

🕗 发布于 2024-11-06 09:46 redis  

文章目录

第1章 Redis入门概述

1.1 Redis简介

Redis（Remote Dictionary Server）是一种开源的高性能内存数据库，主要用于高速数据读取、写入和缓存。它的核心特性是键值对（Key-Value）存储，支持多种数据类型，具有丰富的功能和极低的延迟。因此，Redis被广泛应用于高并发场景，如缓存系统、实时数据分析、任务队列等。

1.2 Redis的特点

Redis具有以下几个显著特点：

  1. 高性能：Redis存储在内存中，可以提供微秒级的高性能读写操作。
  2. 丰富的数据类型：包括String、Hash、List、Set、Sorted Set五种基本数据类型，以及特殊类型如Geospatial、HyperLogLog、Bitmap等，能够满足多样化的数据存储需求。
  3. 支持持久化：提供RDB（快照）和AOF（增量日志）两种持久化方式，保证数据在系统重启或故障时不会丢失。
  4. 发布/订阅机制：支持消息队列功能，可以实现实时的发布和订阅。
  5. 多种高可用方案：包括主从复制、哨兵模式和集群模式，确保Redis在大规模分布式环境下的高可用性。

1.3 Redis的适用场景

Redis的高性能和丰富的数据类型，使其在以下场景中得到了广泛应用：

  • 缓存：用于数据缓存、页面缓存等，可大幅度提升应用的响应速度。
  • 排行榜：通过Sorted Set实现排名和积分功能，广泛应用于游戏排行榜、视频点击量排行等。
  • 分布式锁：利用Redis的单线程特性和String的原子操作，实现分布式锁机制，保障数据的一致性。
  • 计数器：String和HyperLogLog类型可以快速实现访问量、点赞数等计数功能。
  • 会话存储：存储用户会话数据，如登录状态，便于分布式系统中的数据共享。

1.4 Redis的优势与劣势

优势：

  • 支持丰富的数据结构，操作灵活高效；
  • 高吞吐量，满足高并发需求；
  • 提供多种持久化机制，保障数据安全；
  • 支持集群部署，便于扩展和维护。

劣势：

  • 内存需求较大，不适合存储海量数据；
  • 持久化机制在极端情况下可能导致数据丢失；
  • 单线程架构在CPU密集型操作中性能较差。

第2章 Redis安装与配置

2.1 Redis在Windows上的安装

Redis的主要开发和部署环境是Linux，但它也支持Windows安装。以下是Windows上的安装步骤：

  1. 访问Redis的GitHub Release页面，选择适合的版本下载。
  2. 解压下载的文件，找到 redis-server.exe，运行以下命令启动Redis服务：
    redis-server.exe redis.windows.conf
  3. 使用redis-cli.exe进行连接，验证Redis服务是否正常启动。

2.2 Redis在Linux上的安装

在Linux环境下，Redis的安装更加简便，以下以Ubuntu为例：

  1. 更新软件包管理器：
    sudo apt update
  2. 安装Redis：
    sudo apt install redis-server
  3. 启动Redis服务并检查状态：
    sudo systemctl start redis
sudo systemctl status redis

2.3 Redis在Mac上安装

使用Homebrew安装Redis

  1. 安装Homebrew（如果尚未安装）

    Homebrew是Mac OS X上的软件包管理工具。如果你的Mac上还没有安装Homebrew，可以打开终端并运行以下命令来安装：

    /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

    安装完成后，按照终端中的提示将Homebrew添加到你的PATH环境变量中。

  2. 更新Homebrew

    在安装任何软件包之前，最好先更新Homebrew到最新版本：

    brew update

  3. 安装Redis

    使用Homebrew安装Redis非常简单，只需运行：

    brew install redis

  4. 启动Redis服务器

    安装完成后，你可以使用以下命令启动Redis服务器：

    brew services start redis

    或者，如果你不想让它在后台运行，可以使用：

    redis-server /usr/local/etc/redis.conf

  5. 验证Redis是否正在运行

    你可以通过以下命令来检查Redis服务器是否正在运行：

    redis-cli ping

    如果Redis正在运行，你应该会收到PONG作为响应。

  6. 停止Redis服务器

    如果你需要停止Redis服务器，可以使用：

    brew services stop redis
从源码编译安装
  1. 从Redis官网下载最新的稳定版本源码。
  2. 解压下载的压缩包。
  3. 进入解压后的目录。
  4. 运行make命令来编译源码。
  5. 编译完成后，运行make test来测试编译结果。
  6. 最后，运行make install来安装Redis。
Docker 安装

如果你使用Docker，可以通过以下命令拉取并运行Redis镜像：

docker run --name some-redis -d redis

这将在后台启动一个名为some-redis的Redis容器。

2.4 配置文件详解与优化

Redis的配置文件通常为redis.conf，可以进行一些优化设置：

  • 持久化配置：

    • appendonly yes：开启AOF持久化。
    • save 900 1、save 300 10：定期保存数据快照，保证数据安全。

  • 内存管理：

    • maxmemory <bytes>：设置Redis最大使用内存。
    • maxmemory-policy：配置内存淘汰策略，包括allkeys-lru、volatile-lru等不同的淘汰算法。

  • 网络配置：

    • bind <IP>：设置Redis监听的IP地址。
    • port <PORT>：指定Redis服务端口，默认为6379。

  • 日志与监控：

    • loglevel notice：设置日志级别，以便监控和排查问题。

第3章 Redis的五大数据类型

Redis提供了五种核心的数据类型，每种类型都支持独特的数据结构和操作。接下来，我们将详细介绍每种类型的底层结构及实现原理。

3.1 String类型

功能：String类型是Redis中最基础的数据类型，用于存储字符串或二进制数据（如图片和序列化后的对象）。它支持简单的键值对存储和丰富的操作，如字符串拼接、递增递减、过期时间设置等。

常用命令：

SET key value     # 设置键值对
GET key           # 获取键对应的值
INCR key          # 将值自增1
DECR key          # 将值自减1
APPEND key value  # 向现有值追加内容
SETEX key time value  # 设置带过期时间的键值对

底层数据结构：

  1. 简单动态字符串（SDS）：Redis的String类型底层采用了SDS（Simple Dynamic String）数据结构，其与C语言的字符串不同，具备高效的长度记录和扩容机制，避免了C字符串带来的越界问题。
  2. 整数编码：对于数值类型的String，Redis内部将其编码为整数类型以便高效存储和运算。

实现原理：

  • SDS结构：SDS在结构中预留空间，避免频繁的内存重分配，同时能够自动扩展和缩减内存，保证高效的字符串操作。
  • 整数操作：对于INCR、DECR等数值操作，Redis会将键值解析为整数，进行原子操作，以保证线程安全性。

应用场景：

  • 计数器：例如网站的访问量统计或点赞次数。
  • 共享Session：将用户的会话信息集中存储在Redis中，保证分布式服务的一致性。

3.2 Hash类型

功能：Hash类型用于存储键值对集合，适合存储对象数据。例如，存储用户信息时可以将“用户ID”作为键，将“姓名”、“年龄”等属性作为Hash字段。

常用命令：

HSET key field value  # 设置Hash字段
HGET key field        # 获取Hash字段的值
HDEL key field        # 删除Hash字段
HGETALL key           # 获取所有字段和值
HLEN key              # 获取Hash字段的数量

底层数据结构：

  1. 哈希表：当字段数量较多时，Hash类型会以字典的形式存储字段和值，确保高效的增删查改。
  2. Ziplist（压缩列表）：当字段较少、数据较小且简单时，Hash类型使用压缩列表（类似链表结构）来存储，减少内存开销。

实现原理：

  • 哈希表：使用开链法解决Hash冲突，能够在O(1)时间内完成增删查改。
  • 压缩列表：字段数量较少时，使用Ziplist可以通过紧凑的存储减少内存使用，但查询效率略低于哈希表。

应用场景：

  • 用户信息存储：例如用户ID作为键，姓名、年龄、性别作为字段，便于存取与修改。
  • 会话管理：便于在不同服务间共享会话数据。

3.3 List类型

功能：List类型用于存储有序的字符串集合，支持从两端插入和弹出，类似于双端链表。它可以用作队列、栈等数据结构。

常用命令：

LPUSH key value   # 从左侧插入
RPUSH key value   # 从右侧插入
LPOP key          # 从左侧弹出
RPOP key          # 从右侧弹出
LRANGE key start end  # 获取指定范围内的列表元素

底层数据结构：

  1. 双向链表：用于大多数情况，方便从两端操作。
  2. 压缩列表（Ziplist）：用于元素较少且较短的场景，以减少内存占用。

实现原理：

  • 双向链表：Redis通过双向链表实现List，使其支持从两端快速操作，即插入和删除时间复杂度均为O(1)。
  • 压缩列表：当数据量较小时，Redis使用压缩列表存储，以减少链表结构中指针的内存开销。

应用场景：

  • 消息队列：List可以实现生产者-消费者模式，便于构建任务队列。
  • 用户收藏：记录用户最近收藏的文章或商品等。

3.4 Set类型

功能：Set类型是无序集合，用于存储不重复的字符串元素，并提供交集、并集、差集等集合操作。

常用命令：

SADD key member     # 添加元素
SREM key member     # 移除元素
SMEMBERS key        # 返回所有集合元素
SISMEMBER key member # 判断元素是否存在
SINTER key1 key2    # 返回多个集合的交集

底层数据结构：

  1. 哈希表：大多数场景使用哈希表实现Set，便于快速查找。
  2. 整数集合（Intset）：当集合中的元素都是整数且数量较小时，使用Intset以减少内存使用。

实现原理：

  • 哈希表：基于哈希表的Set可以在O(1)的时间复杂度下进行元素的增删查操作。
  • 整数集合：对于整数集合，Redis会动态扩展Intset大小，保证低内存使用率和快速操作。

应用场景：

  • 去重操作：如电商商品分类标签的存储，防止重复存储相同标签。
  • 社交关系管理：可以通过集合操作实现好友列表的交集、并集和差集。

3.5 Sorted Set类型

功能：Sorted Set（有序集合）与Set类似，但Sorted Set中的每个元素会关联一个分数，并按分数排序。它常用于排行榜、积分系统等需要排序的场景。

常用命令：

ZADD key score member   # 添加带分数的元素
ZRANGE key start end    # 按分数升序获取元素
ZREVRANGE key start end # 按分数降序获取元素
ZSCORE key member       # 获取成员的分数
ZRANK key member        # 获取成员排名（升序）

底层数据结构：

  1. 跳表（Skip List）：Sorted Set主要采用跳表作为底层数据结构，用于高效排序和范围查找。
  2. 哈希表：用于存储元素与分数的映射关系，以便快速查找指定元素的分数。

实现原理：

  • 跳表：Redis选择跳表而非平衡树，是因为跳表的实现简单，且支持快速的插入、删除、查询、范围查找操作，时间复杂度为O(logN)。
  • 哈希表：在插入新元素时，跳表和哈希表同时进行更新，保证数据一致性。

应用场景：

  • 排行榜：例如游戏排行榜、商品销售榜等，根据分数进行排序。
  • 带优先级的队列：通过分数表示优先级，实现优先级队列功能。

3.6 总结

数据类型功能描述底层数据结构应用场景
String键值对存储，支持数值操作简单动态字符串、整数编码计数器、Session共享
Hash键值对集合，适合存储对象哈希表、压缩列表用户信息存储
List有序字符串集合双向链表、压缩列表消息队列、任务队列
Set无序集合，去重哈希表、整数集合去重、社交关系管理
Sorted Set有序集合，带权重排序跳表、哈希表排行榜、优先级队列

第4章 Redis的三种特殊数据类型

除了五大基础数据类型，Redis还提供了三种特殊的数据类型，专门用于处理位置数据、不重复计数和位操作等特定需求。它们分别是：Geospatial（地理位置类型）、HyperLogLog（基数统计类型）和Bitmap（位图类型）。

4.1 Geospatial（地理位置数据类型）

功能：Geospatial数据类型用于存储地理位置信息（经纬度）并实现距离计算。适用于位置查询、距离测量等地理相关功能，比如“查找附近的餐馆”或“计算两地之间的距离”。

常用命令：

GEOADD key longitude latitude member    # 添加地理位置信息
GEOPOS key member                       # 获取指定地点的经纬度
GEODIST key member1 member2 unit        # 计算两地点之间的距离
GEORADIUS key longitude latitude radius unit [WITHDIST]  # 查询某位置附近的成员
GEORADIUSBYMEMBER key member radius unit [WITHDIST]      # 查询指定地点附近的成员

底层数据结构：

  • Geospatial类型的底层实现基于有序集合（Sorted Set），其中地理位置信息通过经纬度生成的“GeoHash”作为分数存入。GeoHash算法将经纬度编码为一个数值，使得Redis可以基于分数高效地检索附近的元素。
  • 具体来说，GEOADD命令会将地理坐标转为GeoHash值，并存入Sorted Set中，借助Sorted Set的排序能力实现范围查询和距离计算。

实现原理：

  • GeoHash编码：将二维空间（经纬度）转换为一维空间（整数值），实现高效范围查询。
  • 分层检索：通过分级的GeoHash前缀，可以逐步缩小检索范围，提高效率。
  • 跳表：Redis的Sorted Set采用跳表结构，支持快速插入、删除和范围查询，使得地理位置的附近查询性能较高。

应用场景：

  • 查找附近位置：例如根据用户位置查询附近餐馆、酒店等服务。
  • 导航和地图服务：可用于路线规划、距离计算和地理围栏等功能。

4.2 HyperLogLog（基数统计类型）

功能：HyperLogLog是一种近似去重计数的数据结构，用于快速计算大量数据的基数（去重后的数量）。与Set不同的是，HyperLogLog对数据元素不做实际存储，只记录出现的概率，因此在大数据量情况下使用更少的内存。

常用命令：

PFADD key element1 element2 ...   # 添加元素到HyperLogLog中
PFCOUNT key                       # 统计HyperLogLog中不重复元素的数量
PFMERGE destkey sourcekey1 sourcekey2 ...  # 合并多个HyperLogLog

底层数据结构：

  • 稀疏矩阵与概率统计：HyperLogLog的核心是概率统计算法，通过稀疏矩阵记录数据分布来近似估算基数。其结构使用多种哈希函数映射数据分布。
  • 精度与空间利用：HyperLogLog在计算基数时能够保持在2%误差范围内，所占内存固定在12KB左右，不会随数据量增多而变化。

实现原理：

  • 哈希函数映射：HyperLogLog对每个元素进行多次哈希映射，并记录最远的哈希值位数，从而近似计算出基数。
  • 稀疏矩阵更新：新增数据会更新稀疏矩阵中的最大值，矩阵大小保持固定。
  • 概率估计：通过最大值的分布，使用概率公式推算去重后的基数数量。

应用场景：

  • 页面访问量统计：适用于大规模流量场景下的去重统计，比如PV统计。
  • 活跃用户统计：在社交平台、直播等应用中，用于统计某时间段的独立用户数。

4.3 Bitmap（位图数据类型）

功能：Bitmap是一种基于位的操作数据类型，适合记录二进制状态，例如签到、在线状态等。Bitmap以整数的位为单位进行存储，每个位（bit）存储0或1，常用于存储大量布尔值或二进制数据。

常用命令：

SETBIT key offset value    # 设置指定位置的值（0或1）
GETBIT key offset          # 获取指定位置的值
BITCOUNT key [start end]   # 统计位图中值为1的个数
BITOP operation destkey key1 key2 ...  # 对多个Bitmap进行位运算

底层数据结构：

  • 位数组：Bitmap的底层是连续的二进制位存储，每8个位（bit）组成一个字节（Byte）。
  • 紧凑存储：位数组方式能够高效存储大量布尔值，占用内存较少，例如一个8位整数能表示8个布尔值。

实现原理：

  • 二进制位操作：每个Bit代表一个状态，Redis通过移位操作、掩码（Mask）操作来实现位值的存储、设置与查询。
  • 位操作：BITOP支持AND、OR、XOR等位运算，可以快速完成多个Bitmap的合并、交集等操作。

应用场景：

  • 用户签到：如记录用户每月的签到状态，使用Bitmap可极大减少内存占用。
  • 活跃用户统计：比如某日活跃用户的签到统计，位图通过位数即可表示数百万用户的状态。
  • 布尔状态存储：在游戏或应用中用于记录用户成就、活动参与等布尔状态。

4.4 三种特殊数据类型总结

数据类型功能描述底层数据结构应用场景
Geospatial地理位置数据存储与计算GeoHash、Sorted Set附近搜索、位置计算
HyperLogLog基数统计、去重统计稀疏矩阵、概率算法UV统计、大量去重统计
Bitmap位操作数据类型，记录布尔状态位数组（Bit Array）签到、状态标记、在线用户统计

第5章 Redis配置详解

Redis的配置文件通常为 redis.conf，可以通过修改配置文件来调整Redis的性能、持久化策略、内存管理和安全设置等。Redis的默认配置已经涵盖了大多数使用场景，但根据实际需求，优化这些配置可以进一步提高系统性能和资源利用率。

5.1 内存管理配置

Redis作为内存数据库，需要严格控制内存的使用。以下是一些与内存管理相关的配置：

  1. maxmemory

    maxmemory <bytes>
    • 配置说明：指定Redis实例可以使用的最大内存（单位为字节）。
    • 配置建议：对于缓存服务，通常将 maxmemory 设置为服务器总内存的70-80%。

  2. maxmemory-policy

    maxmemory-policy <policy>
    • 配置说明：指定当内存使用达到 maxmemory 上限时的淘汰策略。
    • 配置选项：
      • volatile-lru：优先删除设置了过期时间的键中最近最少使用的键。
      • allkeys-lru：在所有键中删除最近最少使用的键。
      • volatile-random：随机删除设置了过期时间的键。
      • allkeys-random：随机删除所有键。
      • volatile-ttl：删除即将过期的键。
      • noeviction：不删除任何数据，直接返回错误（推荐用于严格数据持久化的场景）。
    • 配置建议：如果Redis主要用于缓存，建议选择 allkeys-lru 以确保缓存的高效利用；而对于严格持久化需求的业务，可以选择 noeviction 以避免数据丢失。

  3. maxmemory-samples

    maxmemory-samples 5
    • 配置说明：此项配置决定Redis在选择要淘汰的键时，抽样的键数量，默认值为5。值越大，策略的精确度越高，但同时CPU消耗也增加。

5.2 持久化配置

Redis支持两种持久化方式：RDB（快照）和AOF（Append Only File），可以通过以下配置调整其持久化行为。

  1. RDB持久化
    RDB通过快照机制在指定间隔将内存中的数据写入硬盘，生成 .rdb 文件。

    save 900 1   # 900秒内如果至少1个键发生变化，则进行一次RDB快照
save 300 10  # 300秒内如果至少10个键发生变化，则进行一次RDB快照
save 60 10000  # 60秒内如果至少10000个键发生变化，则进行一次RDB快照
    • 配置建议：对于实时性要求不高的场景，可以延长快照间隔以减少I/O操作；若数据较重要，可以缩短间隔，提高数据恢复的精度。
    • 停止RDB持久化：可以通过删除 save 配置项来禁用RDB持久化。

  2. AOF持久化
    AOF通过追加日志的方式记录每条写命令，文件通常为 appendonly.aof。

    appendonly yes          # 开启AOF持久化
appendfsync everysec    # 每秒将写操作同步到硬盘
    • AOF写入策略：
      • always：每次写入操作后立即同步到磁盘，数据最安全但性能较差。
      • everysec：每秒同步一次，兼顾数据安全和性能。
      • no：由操作系统决定何时写入磁盘，性能最好但存在数据丢失风险。
    • 配置建议：一般选择 everysec，以获得性能与数据持久性的平衡。

  3. 混合持久化
    Redis 4.0及以上版本支持混合持久化，将RDB快照和AOF结合，提高恢复效率。

    aof-use-rdb-preamble yes
    • 配置说明：启用该项后，AOF文件开头为RDB快照内容，后续再追加增量命令，启动恢复速度更快。

5.3 安全配置

  1. bind

    bind 127.0.0.1
    • 配置说明：指定Redis绑定的IP地址。默认绑定本地地址 127.0.0.1，若要外网访问则设置为服务器公网IP。
    • 配置建议：生产环境建议仅允许局域网访问，以降低被攻击风险。

  2. protected-mode

    protected-mode yes
    • 配置说明：在没有密码设置且绑定为公网地址时，Redis会自动启用保护模式，拒绝外部连接。

  3. requirepass

    requirepass <password>
    • 配置说明：为Redis服务设置访问密码。
    • 配置建议：如果Redis需要对外提供服务，建议设置强密码以防止未经授权的访问。

5.4 网络配置

  1. timeout

    timeout 300
    • 配置说明：指定客户端连接的超时时间（秒），如果在超时时间内未进行任何操作，Redis会自动断开连接。
    • 配置建议：对于短连接的客户端，可以适当缩短超时时间，减少资源占用。

  2. tcp-keepalive

    tcp-keepalive 60
    • 配置说明：指定TCP连接的保活周期（秒），默认60秒。设置为0将禁用TCP保活。
    • 配置建议：启用保活机制有助于自动断开无效连接，避免连接堆积。

5.5 日志与监控配置

  1. 日志级别

    loglevel notice
    • 配置说明：设置Redis的日志级别，分为debug、verbose、notice和warning四种级别。
    • 配置建议：生产环境建议使用 notice，确保记录关键信息而不影响性能。

  2. 日志文件

    logfile "/var/log/redis/redis-server.log"
    • 配置说明：指定日志文件的位置，若设置为空，则日志将输出到标准输出。
    • 配置建议：生产环境建议将日志记录到文件，便于问题排查。

  3. 慢查询日志

    slowlog-log-slower-than 10000
    • 配置说明：慢查询日志用于记录执行时间超过指定毫秒数的查询。slowlog-log-slower-than设置查询时间阈值，单位为微秒，-1表示关闭慢查询日志。
    • 配置建议：可以根据业务情况设置查询时间阈值，例如10000微秒（即10毫秒）用于监控较慢的查询。

  4. 慢查询日志记录数

    slowlog-max-len 128
    • 配置说明：指定Redis保存的慢查询日志条数，超过该条数时旧日志将被覆盖。
    • 配置建议：设置合适的记录条数，通常128条可以覆盖大部分慢查询需求。

5.6 客户端连接配置

  1. maxclients

    maxclients 10000
    • 配置说明：指定Redis可以同时连接的最大客户端数量，超出时新连接将被拒绝。
    • 配置建议：设置为符合服务器性能的合理数量。可以通过 ulimit 命令调整系统文件描述符上限以支持更多连接。

  2. maxmemory-policy
    Redis也可配置连接数量上的淘汰策略，通过timeout、tcp-keepalive等配置动态管理连接，提升资源利用率。

5.7 配置总结

配置项配置说明推荐设置
maxmemoryRedis最大内存使用限制服务器内存的70-80%
maxmemory-policy内存淘汰策略缓存建议设置为allkeys-lru
appendonlyAOF持久化开关缓存数据建议开启
appendfsyncAOF同步策略everysec
requirepassRedis访问密码强密码
loglevel日志级别生产环境为 notice
timeout客户端空闲超时时间300秒左右
tcp-keepaliveTCP保活设置60秒
slowlog-log-slower-than慢查询阈值根据需求设置
maxclients最大客户端连接数根据服务器性能

第6章 Redis持久化机制

Redis是一种内存数据库，默认情况下，数据存储在内存中以便于快速读写，但如果不进行持久化处理，系统断电或故障重启后数据会全部丢失。为此，Redis提供了两种持久化机制：RDB（Redis Database Backup）和AOF（Append Only File），分别适用于不同的数据可靠性需求和使用场景。

6.1 RDB持久化

概述：RDB持久化是一种快照（Snapshot）机制，按照一定的时间间隔将内存数据生成快照并保存到硬盘。RDB文件的默认名称为 dump.rdb，存放在Redis的工作目录中。

优缺点：

  • 优点：
    • 启动快速：RDB文件较小，Redis在启动时可以快速加载数据。
    • 磁盘IO少：RDB采用定时保存，不会频繁写入磁盘，适合低频度更新的场景。
    • 备份方便：RDB文件生成独立的二进制快照，便于远程备份和恢复。
  • 缺点：
    • 数据可能丢失：RDB是定期保存，若在最后一次快照与系统异常之间有新数据写入，则会丢失这部分数据。
    • 性能影响：在生成快照时，由于Redis会fork一个子进程执行写入，可能占用较多内存资源，影响性能。

适用场景：

  • 适合对数据实时性要求不高的场景，如周期性任务处理、数据分析和报表等。

常用配置：

save 900 1       # 900秒内如果至少1个键发生变化，则进行一次RDB快照
save 300 10      # 300秒内如果至少10个键发生变化，则进行一次RDB快照
save 60 10000    # 60秒内如果至少10000个键发生变化，则进行一次RDB快照
  • 自动快照频率：可以根据业务需求调整 save 配置的频率，例如数据变动较少时可以延长保存间隔。
  • 禁用RDB持久化：可以通过删除所有 save 配置项禁用RDB持久化，适用于需要严格实时数据的场景。

如何触发快照：

  • Redis启动时根据配置自动触发。
  • 使用SAVE命令手动触发快照（阻塞主线程）。
  • 使用BGSAVE命令后台生成快照，不阻塞主线程。

6.2 AOF持久化（默认开启方式）

概述：AOF是另一种持久化方式，通过追加日志的方式记录所有写操作。每次写入命令都被追加到文件 appendonly.aof 中，系统重启时可通过重放AOF文件恢复数据。

优缺点：

  • 优点：
    • 数据安全性高：AOF可以通过 appendfsync always 实现每次写入操作都实时同步到硬盘，提供高数据安全性。
    • 更丰富的数据恢复：AOF记录了所有写操作日志，支持灵活的持久化策略，数据丢失风险小。
    • 文件可读性：AOF文件是文本格式，便于数据分析和编辑。
  • 缺点：
    • 文件较大：AOF文件不断追加写操作记录，文件大小增长较快，需定期压缩文件（重写）。
    • 恢复速度慢：AOF重启恢复时间比RDB长，尤其在日志积累较多时。

适用场景：

  • 适用于数据实时性要求高且不能容忍数据丢失的场景，如金融数据、订单信息等。

常用配置：

appendonly yes                 # 开启AOF持久化
appendfsync everysec           # 每秒同步一次（推荐）
  • AOF同步策略：
    • appendfsync always：每次写操作后立即同步到磁盘，数据最安全但性能开销大。
    • appendfsync everysec：每秒同步一次，性能与安全性折中。
    • appendfsync no：由操作系统决定同步时机，性能最好但有数据丢失风险。

AOF重写机制：

  • 随着AOF文件增长，Redis会定期对AOF文件进行重写（Rewrite），即重新生成一个较小的AOF文件以降低磁盘占用。
  • Redis不会直接修改原始AOF文件，而是将新命令写入一个临时文件中，重写完成后将临时文件替换原文件。
  • 配置项 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size 用于设置AOF重写的触发条件：
    auto-aof-rewrite-percentage 100       # 文件大小达到初始大小的100%时触发重写
auto-aof-rewrite-min-size 64mb        # 文件大小至少达到64MB时才触发重写

6.3 RDB与AOF对比

特性RDB持久化AOF持久化
文件体积通常较小文件体积较大
数据恢复速度恢复速度较快恢复速度相对较慢
数据安全性可能丢失最后一次快照后的数据数据丢失较少，always模式下完全不丢失
配置灵活性配置选项较少配置选项较多，支持多种同步模式
性能开销性能开销小性能开销较大
适用场景数据一致性要求不高的场景数据一致性要求高的场景

AOF文件比RDB文件大的原因：

  1. 数据冗余：AOF 文件包含了所有写操作的记录，这意味着它包含了大量冗余数据。例如，如果一个键被多次修改，AOF 文件会记录每一次修改，而 RDB 只记录最终状态。
  2. 命令记录：AOF 文件记录的是命令本身，而不是数据状态。这意味着 AOF 文件包含了命令的文本表示，这通常比 RDB 文件中存储的二进制数据要大。
  3. 重写机制：虽然 AOF 文件可以通过重写机制来减小大小，但这个过程并不是实时的，只有在达到一定条件时才会触发。因此，在重写之前，AOF 文件可能会变得非常大。
  4. 压缩：RDB 文件在创建时会进行压缩，而 AOF 文件通常不会进行压缩，这也会导致 AOF 文件比 RDB 文件大。

6.4 RDB与AOF混合持久化

Redis 4.0及以上版本引入了混合持久化功能，结合了RDB和AOF的优势。该功能会在AOF文件的开头写入RDB快照内容，然后将后续增量数据以AOF日志形式追加，从而实现高效的恢复。

配置方法：

aof-use-rdb-preamble yes

优点：

  • 提升数据恢复速度：AOF文件中包含RDB的快照数据，在系统重启时只需恢复RDB快照后再追加增量日志。
  • 文件较小：AOF文件的初始内容为RDB快照，占用空间相对较小。

6.5 持久化策略建议

Redis在生产环境中常用的持久化策略有以下几种，根据不同需求可以灵活配置：

  1. 缓存用途（低数据安全性要求）：

    • 关闭AOF和RDB，最大化性能，不进行数据持久化。
    • 开启RDB，配置为长时间间隔（如5-10分钟保存一次），以节省磁盘空间。

  2. 一般业务用途（中等数据安全性要求）：

    • 开启RDB，配置为短时间间隔快照。
    • 开启AOF，配置 appendfsync everysec 以降低数据丢失风险。

  3. 高数据安全性要求：

    • 同时开启RDB和AOF持久化，AOF采用 appendfsync always 以确保每次写入都进行同步。
    • 使用混合持久化功能，获得较高的恢复效率和数据安全性。

6.6 持久化总结

持久化方式优点缺点适用场景
RDB文件小、启动恢复速度快可能丢失最后一次快照后的数据对实时性要求不高的场景
AOF数据安全性高，文件可读文件大，启动恢复速度较慢实时性要求高的数据
混合持久化结合RDB和AOF优势，启动更高效配置稍复杂需要高效持久化和快速恢复的场景

第7章 Redis事务操作

Redis支持简单的事务操作，允许一组命令在事务中被顺序执行。虽然与关系型数据库相比，Redis的事务机制较为简化，但在特定场景下能够有效保证数据操作的原子性。

7.1 Redis事务的特性

Redis的事务具有以下几个特性：

  1. 命令的顺序执行：事务中的所有命令会按顺序执行，Redis不支持事务中的并发操作。
  2. 没有回滚机制：Redis事务不支持回滚，即使事务中的部分命令执行出错，其他命令依旧会继续执行。
  3. 原子性：事务内的每条命令本身是原子的，但整个事务并非原子执行。也就是说，Redis无法保证所有命令要么全部成功，要么全部失败。

7.2 Redis事务的基本命令

Redis的事务主要通过以下几个命令来实现：

  • MULTI：开始一个事务。
  • EXEC：执行事务中的所有命令。
  • DISCARD：取消事务，清除事务队列中的所有命令。
  • WATCH：监控一个或多个键，若在事务执行前监控的键被其他命令修改，则事务将被取消。

7.3 Redis事务的使用示例

以下示例展示了Redis事务的基本使用流程：

MULTI              # 开始事务
SET key1 "value1"  # 命令加入事务队列
SET key2 "value2"  # 命令加入事务队列
EXEC               # 执行事务中的所有命令

在上述事务中，MULTI命令将开启事务，后续的SET key1 "value1" 和 SET key2 "value2"命令会加入事务队列，等待EXEC命令执行。在EXEC执行后，事务内的所有命令将按顺序执行。

若在执行EXEC前调用DISCARD，则会清空事务队列，取消该事务：

MULTI
SET key1 "value1"
DISCARD    # 取消事务，队列中的所有命令被清除

7.4 乐观锁与WATCH命令

Redis的事务支持乐观锁机制，使用WATCH命令监控一个或多个键。若事务执行前，所监控的键发生了修改，则事务会被自动取消。

示例：使用WATCH实现乐观锁

假设一个电商场景中，每次更新库存时需要确保数据一致性，使用WATCH命令可以检测库存是否被其他客户端修改：

WATCH stock          # 监控库存键
val = GET stock      # 获取当前库存
if val > 0:          # 检查库存是否充足
    MULTI            # 开始事务
    DECR stock       # 扣减库存
    EXEC             # 提交事务
else:
    UNWATCH          # 取消监控
  • 若在执行EXEC之前，stock键被其他客户端修改，则事务会被取消，EXEC返回空响应，避免超卖情况。
  • UNWATCH可以手动取消对键的监控。

7.5 事务的错误处理

在Redis事务中，有两种类型的错误：

  1. 入队错误：命令入队时发生的错误。此类错误会阻止事务执行，例如拼写错误或不支持的命令。Redis在执行EXEC之前就会报错。

  2. 执行错误：在事务提交后，某条命令执行失败。例如数据类型不匹配导致的错误。在此情况下，其他命令依旧会继续执行，Redis不会回滚整个事务。

示例：事务中的错误处理

MULTI
SET key1 "value1"
INCR key1            # 错误，key1的值非数值类型
SET key2 "value2"
EXEC

在上述示例中，INCR key1命令会因类型错误而执行失败，但整个事务依然继续执行，SET key2 "value2"会成功。

7.6 Redis事务的实现原理

Redis的事务是通过命令队列的形式实现的：

  1. 命令入队：在MULTI命令执行后，后续所有命令会依次被加入事务队列，等待EXEC命令触发。
  2. 队列执行：当EXEC被调用时，Redis会按照入队顺序执行所有命令。由于Redis单线程的特性，命令的执行是串行的，不存在并发问题。
  3. 取消监控：若WATCH监控的键发生变动，EXEC时Redis会自动取消该事务。

7.7 Redis事务的使用建议

  1. 尽量避免复杂事务：Redis的事务缺少回滚机制，且事务命令越多越容易出错，建议避免包含大量命令的复杂事务。
  2. 监控关键键：在并发场景下使用WATCH命令监控关键键，配合乐观锁机制可以有效避免数据冲突。
  3. 关注执行错误：对于可能发生执行错误的事务，应检查事务执行结果，以便处理部分命令失败的情况。

7.8 Redis事务操作总结

特性说明
事务执行顺序按照入队顺序依次执行
回滚机制不支持事务的回滚，某条命令失败不影响其他命令
乐观锁使用WATCH监控键，避免并发冲突
错误处理分为入队错误（阻止事务）和执行错误（单命令失败不回滚）
实现机制通过单线程命令队列，保证顺序执行

第8章 Redis发布/订阅功能

Redis支持发布/订阅（Pub/Sub）功能，允许消息的实时传递，使不同客户端之间可以进行消息通信。通过发布/订阅模式，客户端可以将消息发布到某个频道，所有订阅该频道的客户端都能收到该消息。Redis的发布/订阅模型类似于消息队列的工作方式，是实现实时消息传递的有效手段。

8.1 发布/订阅模型概述

Redis的发布/订阅模型包括三个基本角色：

  1. 发布者（Publisher）：负责向指定频道发布消息。
  2. 订阅者（Subscriber）：订阅指定的频道，实时接收该频道发布的消息。
  3. 频道（Channel）：消息发布和接收的载体，发布者将消息发布到频道，订阅者从频道接收消息。

Redis的发布/订阅系统支持点对多的消息传递，即一个发布者的消息可以被多个订阅者接收，实现了多对多的消息广播。

8.2 发布/订阅的基本命令

Redis提供了几条简单易用的命令来实现发布/订阅功能：

  • SUBSCRIBE channel [channel …]：订阅一个或多个频道，订阅者会收到指定频道的消息。
  • UNSUBSCRIBE [channel …]：取消订阅一个或多个频道，不带参数时取消所有订阅。
  • PUBLISH channel message：将消息发布到指定频道。
  • PSUBSCRIBE pattern [pattern …]：按模式订阅，匹配模式的频道发布的消息将被接收。
  • PUNSUBSCRIBE [pattern …]：取消按模式订阅的频道，不带参数时取消所有模式订阅。

示例：发布/订阅命令的使用

# 订阅者
SUBSCRIBE news    # 订阅频道news

# 发布者
PUBLISH news "Hello, Redis!"  # 发布消息到频道news

以上示例中，订阅者执行SUBSCRIBE news后，发布者发布的消息“Hello, Redis!”将被订阅者实时接收到。

8.3 Redis发布/订阅的实现原理

Redis的发布/订阅功能的核心实现原理基于消息广播机制：

  1. 订阅记录：Redis会将每个频道的订阅关系记录在哈希表中，每个频道关联一个订阅者列表。
  2. 消息广播：当消息发布时，Redis根据订阅关系找到相应的订阅者列表，并将消息推送给所有订阅者。
  3. 模式匹配：对于模式订阅，Redis会匹配频道名称和模式，并将符合的消息广播给模式订阅的客户端。

Redis发布/订阅的实现基于其单线程架构，消息推送的延迟较低，因此在轻量实时通信的场景下表现良好。

8.4 发布/订阅的应用场景

Redis的发布/订阅功能适用于以下场景：

  1. 实时消息系统：在聊天室或社交网络中，发布/订阅模型可以用于发送和接收即时消息。
  2. 事件通知：在微服务架构中，不同服务间可通过Redis的发布/订阅进行事件通知，例如库存更新、订单状态变更等。
  3. 缓存更新：多个服务间可以通过发布/订阅来通知缓存的更新需求，以便各自更新缓存数据。
  4. 实时监控：用于系统和应用监控，实时发布监控数据到频道，由客户端或服务消费这些数据。

8.5 发布/订阅模式的注意事项

  1. 消息可靠性：Redis的发布/订阅模型不保证消息的持久性，一旦消息发布完成便立即转发给订阅者，未在线的订阅者将无法收到消息。因此，发布/订阅不适合要求高可靠性消息传递的场景。
  2. 扩展性限制：发布/订阅功能受Redis单线程架构限制，消息发布速度会受到一定影响，不适用于高吞吐量的场景。对于更高并发需求，可使用消息队列（如Kafka、RabbitMQ）等专业的消息系统。
  3. 订阅者的处理能力：如果订阅者无法及时处理消息，将导致消息积压，影响整体系统性能。

8.6 发布/订阅功能总结

特性说明
订阅管理支持频道和模式两种订阅方式
消息广播点对多消息传递，一个发布者的消息可以被多个订阅者接收
消息不持久消息发布后即传递给当前在线订阅者，离线订阅者无法收到
适用场景实时消息传递、事件通知、实时监控等
适用限制不适用于高可靠性和高并发要求的场景

第9章 Redis主从复制机制

Redis的主从复制（Replication）功能允许将一个Redis主服务器的数据复制到一个或多个从服务器，以实现数据的高可用性和负载均衡。主从复制是Redis集群架构的基础之一，配合哨兵模式或Redis集群模式可实现高可用和自动故障转移。

9.1 主从复制的基本概念

Redis主从复制的基本结构如下：

  1. 主节点（Master）：主节点负责处理所有的写入请求并将数据更新推送给从节点。
  2. 从节点（Slave）：从节点被动接收主节点的更新，可用于读取操作，从而分担主节点的压力。
  3. 一主多从结构：Redis支持一个主节点对应多个从节点，从节点之间不进行数据同步，所有更新均来源于主节点。

9.2 主从复制的实现原理

Redis的主从复制大致分为以下几步：

  1. 初次同步：当从节点与主节点建立连接时，主节点会将自身的RDB文件快照传输给从节点，完成全量同步。

    • 主节点生成RDB快照并将快照数据传输给从节点。
    • 从节点加载RDB快照并应用更新，完成初次数据同步。

  2. 增量复制：初次同步完成后，主节点会将后续的写操作命令增量同步给从节点，从节点按顺序执行写操作以保持与主节点的数据一致。

    • 主节点将新收到的写操作记录到复制缓冲区并逐条发送给从节点。
    • 从节点接收到更新命令后，依次执行，确保与主节点一致。

  3. 断线重连与复制偏移量：Redis使用复制偏移量来跟踪主从节点的同步进度。当主从连接断开且重新连接时，从节点会基于偏移量向主节点请求丢失的数据，主节点通过增量同步完成丢失数据的补充。

  4. 部分重同步：如果从节点与主节点的偏移量一致，从节点仅需接收主节点在断开期间的操作记录，避免全量同步，提高重连效率。

9.3 主从复制的配置步骤

配置Redis主从复制相对简单，只需在从节点配置文件中指定主节点的IP和端口即可。

示例：假设主节点的IP为192.168.1.100，端口为6379，配置从节点连接主节点的步骤如下：

  1. 修改从节点的配置文件 redis.conf，添加以下配置项：

    replicaof 192.168.1.100 6379

  2. 或在从节点Redis启动后，通过命令行动态配置：

    SLAVEOF 192.168.1.100 6379

  3. 查看主从状态，连接Redis客户端后，输入以下命令检查从节点的状态：

    INFO replication

    在返回结果中，role:slave表示当前节点为从节点，并显示主节点的IP和端口。

9.4 主从复制的应用场景

Redis主从复制广泛应用于以下场景：

  1. 读写分离：在读写需求不均衡的场景中，主节点负责写操作，从节点负责读操作，从而提高系统整体性能。
  2. 数据备份：通过主从复制将主节点的数据实时同步到从节点，确保数据高可用，从节点可作为备份节点。
  3. 故障切换：在主节点故障时，可以将从节点切换为主节点，确保服务连续性（可结合哨兵模式实现自动化故障转移）。

9.5 主从复制的常见问题及解决方案

  1. 延迟问题：当主节点写入频繁，网络传输负载较高时，从节点可能会出现同步延迟，导致数据一致性问题。

    • 解决方案：增大从节点的缓冲区，优化网络环境，并适当增加从节点数量分散读操作。

  2. 主节点故障：当主节点故障时，从节点无法获取最新数据，所有写操作会中断。

    • 解决方案：可使用Redis哨兵模式监控主节点状态并在主节点故障时自动进行主从切换。

  3. 脑裂问题：若网络分区导致主从节点无法通信，可能会导致分区后的主从节点都对外提供服务。

    • 解决方案：使用哨兵或Redis集群模式避免脑裂，通过选举机制保障只有一个主节点对外提供写服务。

9.6 主从复制的配置参数

在配置主从复制时，可以根据需求优化以下关键参数：

  1. replica-read-only

    replica-read-only yes
    • 配置说明：从节点的只读属性，默认开启，即从节点只能用于读操作，不允许写操作。

  2. repl-diskless-sync

    repl-diskless-sync no
    • 配置说明：设置为yes时，主节点会直接将数据发送给从节点而不创建RDB文件，从而减少磁盘IO。

  3. repl-diskless-sync-delay

    repl-diskless-sync-delay 5
    • 配置说明：指定在磁盘无状态同步模式下，主节点将数据发送给所有从节点前的等待时间，适合批量同步多个从节点。

  4. repl-timeout

    repl-timeout 60
    • 配置说明：主从节点间同步的超时时间，超过指定时间未收到响应则断开连接。可根据网络状况适当调整，避免误断。

9.7 Redis主从复制总结

特性说明
初次同步主节点生成RDB快照并传输给从节点，完成全量同步
增量复制从节点接收主节点的写操作并执行，实现数据增量同步
读写分离主节点负责写操作，从节点处理读操作，提升性能
常见问题同步延迟、主节点故障、脑裂问题
配置建议根据业务需求优化同步延迟，结合哨兵模式实现自动故障转移

第10章 Redis哨兵模式

Redis哨兵（Sentinel）模式是一种高可用架构，用于监控Redis主从架构中的主节点状态，并在主节点发生故障时自动进行故障转移，将某个从节点提升为主节点。哨兵模式可以确保Redis集群的高可用性，使应用在主节点故障后仍能继续正常工作。

10.1 哨兵模式的核心功能

Redis哨兵模式主要包含以下几个核心功能：

  1. 主节点监控：哨兵会持续监控主节点的健康状态，发现故障时自动触发故障转移。
  2. 自动故障转移：当主节点不可用时，哨兵会将一个从节点提升为新的主节点，并将其他从节点指向新的主节点。
  3. 通知机制：哨兵会通知客户端新的主节点地址，确保客户端可以连接到正确的主节点。
  4. 配置中心：哨兵作为Redis集群的配置中心，提供最新的主节点信息。

10.2 哨兵模式的架构

哨兵模式的架构包括以下组件：

  1. 哨兵节点（Sentinel Nodes）：负责监控Redis服务器状态，多个哨兵节点之间相互协作，分布式进行主节点的健康检查。
  2. 主节点（Master）：提供写操作和数据的主控节点。
  3. 从节点（Slaves）：从主节点复制数据，用于读操作和灾备。故障转移时某个从节点会被提升为主节点。

在哨兵模式中，Redis集群一般部署多个哨兵节点（通常为3个或更多奇数个节点），多个哨兵节点通过投票机制决定是否进行故障转移，确保故障判定的可靠性。

10.3 哨兵的工作原理

哨兵通过周期性的PING请求监控主节点和从节点的状态，同时各哨兵之间也会发送心跳包相互确认在线状态。哨兵模式的工作流程如下：

  1. 主观下线（Subjective Down, SDOWN）：单个哨兵检测到主节点无响应，标记该节点为主观下线。
  2. 客观下线（Objective Down, ODOWN）：多数哨兵一致确认主节点故障，则将主节点标记为客观下线，触发故障转移。
  3. 故障转移：哨兵通过投票选举一个从节点作为新的主节点，并更新所有其他从节点的复制对象，使其指向新的主节点。
  4. 通知客户端：完成故障转移后，哨兵将新主节点信息通知客户端，客户端重新连接到新主节点。
  5. 恢复监控：故障转移后，哨兵继续监控新的主节点和其他从节点，保持集群的高可用性。

10.4 哨兵模式的配置步骤

Redis哨兵模式的配置主要在哨兵节点的配置文件中完成（例如 sentinel.conf 文件），以下是关键配置项：

示例配置：
假设主节点的IP为 192.168.1.100，端口为 6379，哨兵配置文件示例如下：

# 配置监控的主节点，格式为: sentinel monitor <master-name> <ip> <port> <quorum>
sentinel monitor mymaster 192.168.1.100 6379 2

# 设置哨兵触发故障转移的条件
sentinel down-after-milliseconds mymaster 5000

# 故障转移时最多允许几个从节点同时进行数据同步
sentinel parallel-syncs mymaster 1

# 故障转移超时时间，超出时间未完成则放弃
sentinel failover-timeout mymaster 15000

配置说明：

  1. sentinel monitor：配置哨兵监控的主节点，mymaster 是主节点的别名，192.168.1.100 和 6379 分别为主节点的IP和端口，2 表示至少需要2个哨兵同意主节点故障才能判定主节点下线。
  2. sentinel down-after-milliseconds：指定哨兵多久检测不到主节点时，认为主节点已下线（单位为毫秒）。
  3. sentinel parallel-syncs：设置故障转移后，最多允许多少个从节点同时与新的主节点进行同步。
  4. sentinel failover-timeout：设置故障转移的超时时间（单位为毫秒）。

启动哨兵：
可以通过以下命令启动Redis哨兵模式：

redis-sentinel /path/to/sentinel.conf

可以启动多个哨兵节点以增加故障检测的可靠性。

10.5 哨兵模式的应用场景

Redis哨兵模式的典型应用场景包括：

  1. 高可用Redis集群：在生产环境中部署哨兵模式，通过自动故障转移保障Redis的高可用性。
  2. 灾备切换：当主节点出现故障时，哨兵可以自动切换到从节点并将其提升为主节点，减少人工运维的压力。
  3. 动态配置更新：哨兵自动将新主节点的信息通知客户端，确保客户端始终连接到正确的主节点。

10.6 哨兵模式的常见问题及解决方案

  1. 脑裂问题：当哨兵集群因网络分区发生脑裂，可能会导致多个哨兵认为不同的从节点为主节点。

    • 解决方案：确保部署奇数个哨兵节点，并设置合理的quorum值（一般为哨兵数量的一半以上），以提高故障判断的可靠性。

  2. 哨兵间通信中断：哨兵节点间无法通信时，可能会导致错误的故障转移判断。

    • 解决方案：确保哨兵节点在网络拓扑中尽量靠近，并提供良好的网络连接以保证通信正常。

  3. 客户端连接超时：客户端在主节点切换期间可能会出现连接超时或读写失败。

    • 解决方案：客户端应实现重连机制，并设置较短的超时时间以快速连接到新的主节点。

10.7 哨兵模式总结

特性说明
主节点监控哨兵定期检测主节点状态，判断其是否故障
自动故障转移主节点故障时自动选择从节点提升为主节点
通知客户端更新客户端的主节点信息，确保客户端连接正确的主节点
配置中心哨兵充当Redis集群的配置中心，动态更新主从结构
适用场景高可用性需求、自动故障恢复、无缝灾备切换

第11章 Redis内存淘汰机制及过期Key处理

Redis是一种基于内存的数据存储系统，当内存达到上限时，需要进行数据淘汰以确保新数据能够写入。Redis提供了多种内存淘汰策略，用户可以根据需求选择合适的策略来管理内存。此外，Redis还具备过期Key自动清理功能，可以定时清除已过期的数据，以优化内存使用。

11.1 Redis内存淘汰机制概述

当Redis内存使用达到上限（maxmemory参数设置），根据maxmemory-policy指定的策略，Redis会选择性地删除部分数据以腾出空间。Redis的内存淘汰策略分为以下几类：

  1. 无操作：直接返回内存不足错误，不做数据淘汰。
  2. 删除部分数据：基于不同算法选择并删除部分数据。
  3. 删除所有数据：从全体数据中按规则删除符合条件的Key。

11.2 Redis的内存淘汰策略

Redis提供了八种主要的内存淘汰策略，可以通过配置文件中的maxmemory-policy参数进行设置：

策略名称描述适用场景
volatile-lru从设置了过期时间的Key中，淘汰最近最少使用的Key适合缓存模式，存储有时效性的缓存数据
allkeys-lru从所有Key中淘汰最近最少使用的Key不区分缓存与持久化数据的场景
volatile-lfu从设置了过期时间的Key中淘汰访问频率最低的Key对访问频率较高的数据进行缓存
allkeys-lfu从所有Key中淘汰访问频率最低的Key适合存储频繁访问的数据
volatile-ttl从设置了过期时间的Key中，淘汰即将过期的Key偏向即将过期的数据（时间敏感场景）
volatile-random随机淘汰设置了过期时间的Key适用于存储缓存数据
allkeys-random随机淘汰所有Key所有数据随机淘汰
noeviction不做任何数据淘汰，内存耗尽时返回错误数据不允许丢失的严格持久化场景

注释：

  • LRU（Least Recently Used）：最近最少使用策略，优先淘汰最近未被访问的数据。
  • LFU（Least Frequently Used）：最少使用频率策略，优先淘汰访问频率最低的数据。
  • TTL（Time To Live）：优先淘汰即将过期的数据，适用于对时效要求较高的数据。

11.3 Redis内存淘汰策略的配置示例

以下是常用的Redis配置选项，用户可以在redis.conf中进行设置，或使用命令动态配置：

maxmemory 512mb                     # 设置Redis的最大内存为512MB
maxmemory-policy allkeys-lru        # 设置淘汰策略为在所有Key中删除最近最少使用的Key

当内存超过512MB时，Redis会根据LRU策略从所有Key中删除最少使用的数据。

11.4 Redis过期Key清除机制

Redis支持为每个Key设置过期时间，过期的Key将会被自动删除。Redis的过期Key清除机制包含以下三种策略：

  1. 惰性删除：只有在访问Key时，Redis才检查其是否已过期，如果已过期则删除。

    • 优点：对CPU友好，只在需要时检查数据。
    • 缺点：可能会有大量过期Key存在内存中，导致内存浪费。

  2. 定期删除：Redis定期随机抽取部分Key检查是否过期，删除过期的Key。

    • 优点：减少内存浪费，及时清理已过期的数据。
    • 缺点：定期删除会消耗部分CPU资源，检查频率和清除数据量需配置合适，以免影响性能。

  3. 定期与惰性结合：Redis实际应用中采用惰性删除和定期删除结合的方式，既能节省CPU资源，又能尽量减少过期数据的内存占用。

配置示例：
在redis.conf文件中可以通过以下配置项调整定期删除的频率：

hz 10   # 配置Redis内部任务的频率，单位为Hz。较高的频率会增加过期Key的检查次数。

11.5 Redis过期Key的实现原理

Redis使用定时器和惰性策略相结合的方式管理过期Key：

  1. 定时器检查：Redis会定期从数据库中随机选取一部分键，检查其是否过期。每次定时删除时，若随机抽取的键中有超过25%已过期，则再次随机抽取一定数量的Key，直到过期比例低于25%。
  2. 惰性删除机制：当用户访问某个Key时，Redis会检查该Key是否已过期，若已过期则立刻删除。

通过结合定时清理和惰性清理，Redis可以在保证内存不被过期Key长期占用的情况下，减少CPU的过多消耗。

11.6 内存淘汰与过期Key的应用场景

  1. 短生命周期的缓存数据：可以使用volatile-lru或allkeys-lru策略，将不常访问的缓存数据淘汰。
  2. 数据高实时性要求：通过volatile-ttl策略淘汰即将过期的数据，确保数据的实时性。
  3. 严格持久化的场景：对于需要长期保存的数据，选择noeviction策略以防止数据被淘汰。

11.7 Redis内存淘汰及过期Key清除策略总结

特性描述适用场景
内存淘汰策略当内存达到上限时，根据策略选择删除部分数据高并发缓存、控制内存的场景
过期Key惰性删除访问Key时检查是否过期，节省CPU资源数据访问量较高但过期率较低的场景
过期Key定期删除定期随机抽取部分Key检查过期状态，及时清理数据高并发过期Key较多的场景

第12章 缓存击穿及解决方案

缓存击穿指的是在高并发场景中，某个热点Key在缓存过期后，瞬间出现大量请求直接访问数据库，导致数据库压力骤增，甚至可能导致系统崩溃。这种问题通常出现在热点数据的访问量极高的业务场景下，比如秒杀活动、热点新闻或社交平台中的热门内容。

12.1 缓存击穿的成因

缓存击穿一般是由以下原因造成的：

  1. 热点数据失效：在高并发请求集中访问同一个热点数据时，若该数据在缓存中过期，所有请求会直接落到数据库。
  2. 缓存容量限制：若缓存容量有限且采用LRU等淘汰策略，某些热点数据被提前淘汰，随后的请求将直接访问数据库。
  3. 业务峰值：在秒杀、抢购等业务场景下，大量用户同时请求特定资源，若缓存过期或未命中，则可能导致数据库负载骤增。

12.2 缓存击穿的解决方案

Redis提供多种方案来缓解缓存击穿问题，常用的解决方案包括：

方案一：热点Key提前预热

在业务高峰期或热点数据预知的情况下，可通过手动或自动预热的方式，提前将热点数据加载到缓存中，减少直接访问数据库的请求。

  • 预热方式：
    • 手动预热：在业务开始前将常用的热点数据提前加载到Redis中。
    • 自动预热：编写定时任务或脚本，在Redis中预加载常用Key，以避免缓存过期后直接访问数据库。

示例：

# 手动将热点数据存入Redis，设置较长的过期时间
SETEX hot_key 3600 "hot_data"
方案二：加锁机制（互斥锁）

在缓存过期后，使用分布式锁限制只有一个请求能够访问数据库，其余请求需等待缓存数据更新后再访问缓存，避免同时请求数据库。

  • 实现步骤：

    • 当缓存过期时，客户端尝试获取分布式锁。
    • 若成功获取锁，则请求数据库，获得数据后更新缓存，并释放锁。
    • 若未获取锁，则客户端等待一段时间，之后从缓存中获取数据。

  • Redis加锁示例：

    # 使用SETNX获取锁，成功返回1，失败返回0
SETNX lock_key 1

# 数据更新后删除锁
DEL lock_key

    注意：分布式锁的有效时间应略长于查询数据库所需时间，以确保数据更新前锁不会被误释放。

方案三：设置热点数据不过期

对于特定的热点数据，可以通过设置较长的过期时间，或使其永不过期，从而避免缓存失效带来的数据库压力。不过期数据可以通过定时任务或异步更新的方式进行刷新，以确保数据的时效性。

示例：

# 设置热点Key不过期
SET hot_key "hot_data"
方案四：逻辑过期（延长缓存有效时间）

逻辑过期是将数据设置为长时间有效，通过后台任务异步检查数据是否需要更新。即使缓存中的数据已逻辑过期，仍返回给客户端，同时异步更新缓存内容。

  • 实现步骤：
    • 将数据的逻辑过期时间存入Redis。
    • 读取数据时，若数据逻辑过期，先返回给用户，同时触发后台任务更新缓存。
    • 此方案将更新任务延迟到后端，减少数据库访问压力。

12.3 缓存击穿解决方案的对比

方案优点缺点适用场景
热点Key提前预热减少缓存击穿，提升缓存命中率需提前预知热点数据预知数据峰值，固定热点场景
加锁机制限制数据库访问，避免并发请求对数据库冲击增加响应延迟访问量大，缓存过期的高并发场景
不设置过期时间热点数据不失效，避免直接访问数据库数据更新需额外逻辑控制热点数据稳定且不频繁变化
逻辑过期数据返回实时，异步更新减少直接数据库访问需额外定时任务，逻辑复杂数据更新频繁但需要高时效性

12.4 缓存击穿的总结

缓存击穿常见于高并发业务场景，通过Redis的加锁、预热、不设置过期时间、逻辑过期等手段，可以在一定程度上避免缓存击穿，保护数据库不受高并发访问的冲击。在实际应用中，选择合适的解决方案能够显著提高系统的稳定性和响应速度。

第13章 缓存雪崩及解决方案

缓存雪崩指的是大量缓存数据在某一时刻集中失效，导致大量请求直接访问数据库，给数据库带来巨大压力，严重时可能导致数据库崩溃。缓存雪崩通常发生在大批量缓存设置了相同的过期时间，或因系统故障导致大量缓存数据被清空的场景。

13.1 缓存雪崩的成因

缓存雪崩的成因主要包括以下几种情况：

  1. 缓存集中失效：大量缓存Key设置了相同的过期时间，导致某一时间点全部失效，大量请求直击数据库。
  2. 缓存服务故障：缓存服务器宕机或出现不可用情况，导致所有请求直接落到数据库。
  3. 流量突增：流量高峰期（如促销活动、抢购等）产生大量并发请求，缓存容量不足以应对所有请求，未命中的请求直接访问数据库。

13.2 缓存雪崩的解决方案

Redis提供了多种方案来应对缓存雪崩，以减少缓存失效对数据库的影响。常用的解决方案包括：

方案一：为缓存设置随机过期时间

通过为缓存Key设置不同的过期时间，可以避免大批量数据在同一时间点失效，减少请求集中访问数据库的风险。

  • 实现方法：设置缓存数据时，在固定的过期时间上随机添加一个时间范围，以保证过期时间分散。

示例：

# 设置数据过期时间，增加随机秒数
EXPIRE key_name $((60*60 + RANDOM % 600))  # 设置1小时到1小时10分钟的随机过期时间
方案二：双缓存机制

双缓存机制是指使用两个相同的数据缓存，通过轮流更新的方式，保证缓存数据的可用性。若缓存A失效，则访问缓存B并更新缓存A，避免大量请求直接访问数据库。

  • 实现步骤：
    • 在缓存失效后，客户端访问备用缓存而不是直接访问数据库。
    • 读取完备用缓存数据后，异步更新失效的缓存数据。

示例：

# 使用缓存A和缓存B，轮流更新
GET cache_A || GET cache_B  # 若A失效，则从B获取数据，并更新A
方案三：构建多级缓存架构

使用多级缓存架构，如在Redis前增加本地缓存（如Guava、Caffeine等）或Memcached作为一级缓存，以缓解单点缓存失效的压力。当Redis失效时，本地缓存仍能提供部分数据，避免大量请求直接访问数据库。

示例架构：

客户端 -> 本地缓存（如Guava） -> Redis -> 数据库
方案四：限流与降级处理

在流量高峰期，可以对请求进行限流或降级处理，限制请求访问频率，保护数据库不被过载访问。

  • 限流：对请求访问频率进行控制，超过限流阈值的请求直接拒绝或排队。
  • 降级：对于一些非关键业务，在缓存失效时返回默认值或缓存旧数据，避免频繁访问数据库。

示例：

# 使用Redis计数器实现限流，每秒只允许处理100个请求
INCR user_request
EXPIRE user_request 1
if user_request > 100:
    reject_request  # 超过限制的请求直接拒绝
方案五：热点数据提前预加载

对访问量较大的热点数据，可以通过定时任务将数据预加载到缓存中，保证在业务高峰期缓存数据处于可用状态，避免失效时出现雪崩现象。

示例：

# 定时任务预加载热点数据
SETEX hot_data 3600 "preloaded_data"

13.3 缓存雪崩解决方案的对比

方案优点缺点适用场景
设置随机过期时间缓解集中失效问题，简单易实现难以精确控制缓存更新时间大量Key同时过期的场景
双缓存机制提供备用缓存，减少数据库压力占用更多缓存空间高频访问的热点数据
多级缓存架构分散缓存压力，提升缓存命中率实现较复杂，需运维多级缓存需要高并发低延迟的场景
限流与降级处理避免大量请求直击数据库，保护系统稳定部分请求可能被拒绝，体验下降高峰期、非关键数据请求
热点数据预加载减少失效带来的访问压力，提升命中率数据需定期更新，适用范围有限访问量稳定的热点数据

13.4 缓存雪崩的总结

缓存雪崩在高并发、流量突增或缓存集中失效时非常容易发生，通过设置随机过期时间、双缓存机制、多级缓存架构、限流和降级处理等方式，可以有效缓解缓存雪崩对数据库的冲击，保护系统的稳定性。综合运用这些方案，能提升系统的整体抗压能力，并优化数据访问的效率。

总结

在本篇Redis学习文章中，我们系统地探讨了Redis的核心功能、数据结构、持久化机制、事务操作、高可用配置以及缓存管理等重要内容，以下是各章要点的概述：

  1. Redis的基本概念与应用场景：Redis是一种高性能的内存数据库，支持多种数据类型和多样化的操作，广泛用于缓存、排行榜、分布式锁和实时数据分析等场景。

  2. 五大数据类型及其底层结构：Redis支持String、Hash、List、Set和Sorted Set五大数据类型，每种数据类型背后都有独特的数据结构（如SDS、哈希表、跳表等）和适用场景，如String类型用于计数器，List适合消息队列等。

  3. 三种特殊数据类型：Redis提供了Geospatial、HyperLogLog和Bitmap三种特殊数据类型，分别用于地理位置存储、基数统计及布尔状态记录，适合处理特殊需求的业务场景。

  4. 持久化机制：Redis支持RDB（快照）和AOF（追加日志）两种持久化方式。RDB适用于冷备份和快速恢复，而AOF则通过增量日志记录提供更高的数据安全性。Redis 4.0还支持RDB和AOF的混合持久化，提高了系统恢复效率。

  5. 事务操作与乐观锁机制：Redis通过MULTI、EXEC、DISCARD和WATCH命令实现事务。尽管不支持回滚，但WATCH命令提供了乐观锁机制，适用于并发访问的场景。

  6. 发布/订阅功能：Redis的发布/订阅机制支持实时消息广播，适用于消息队列、实时通知等需求，但不适合高可靠性或高并发要求的消息系统。

  7. 主从复制与高可用配置：Redis主从复制、哨兵模式和集群模式提供了从数据同步到自动故障转移的完整方案，适用于构建高可用、可扩展的Redis架构。

  8. 缓存管理与优化：

    • 缓存击穿：通过热点数据预热、分布式锁等手段避免缓存失效带来的数据库压力。
    • 缓存雪崩：设置随机过期时间、双缓存机制、限流与降级等手段，防止大量Key集中失效对数据库的冲击。
    • 内存淘汰机制：Redis提供了多种淘汰策略（如LRU、LFU等），结合惰性删除与定期删除机制，保证内存空间的合理利用。

通过这些核心功能和机制，Redis为处理高并发、高实时性及数据一致性等复杂场景提供了强有力的支持。掌握这些Redis基础与进阶知识，将帮助我们更好地利用Redis在各种项目中实现高效、稳定的数据存储和缓存解决方案。

在这里插入图片描述


原文地址：https://blog.csdn.net/tatasix/article/details/143501492

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

相关文章

自学内容网
Copyright © 2015-2024