Redis八股

Redis 缓存穿透

实际场景：电商商品查询中的缓存穿透问题

场景描述

假设有一个电商平台，用户可以通过输入商品ID（如 product:1001）查询商品信息。系统使用 Redis 作为缓存层，数据库（如 MySQL）作为持久化存储。正常情况下，用户请求商品ID时：

系统先查询 Redis 缓存，若存在直接返回结果；
若 Redis 中无数据，则查询数据库，并将结果写入 Redis 缓存。

问题出现：

某天，有大量用户（或攻击者）频繁请求不存在的商品ID（如 product:9999999、product:abc、product:-123），这些ID在数据库中根本不存在。此时：

Redis 缓存中没有这些ID（未命中）；
每个请求都会穿透到数据库查询，但数据库也无结果；
数据库因高频无效查询而负载激增，可能导致宕机或响应延迟。

这种现象就是缓存穿透，即请求的资源既不在缓存也不在数据库中，导致所有请求直接打到数据库。

解决方案详解

1. 布隆过滤器（Bloom Filter ）

原理：

布隆过滤器是一个高效的数据结构，用于判断某个元素是否可能存在于集合中。它通过哈希算法将已有的合法ID映射到一个位图中。当请求到来时，先检查布隆过滤器：

若ID不存在于布隆过滤器：直接拦截请求，不再查询缓存和数据库；
若ID可能存在：继续查询缓存和数据库。

场景应用：

在电商系统启动时，将数据库中所有合法商品ID（如 product:1001 到 product:1000000）预加载到布隆过滤器中；
当用户请求 product:9999999 时，布隆过滤器会快速判断该ID不在合法集合中，直接返回"不存在"，避免后续查询；
对于合法ID（如 product:1001），布隆过滤器会放行，继续查询缓存和数据库。

优点：

无需存储所有ID的完整列表，节省内存；
查询速度极快（常数级时间复杂度）；
有效拦截恶意请求，减轻数据库压力。

缺点：

有一定的误判率（可能误判某些ID为存在，但说你不存在你就百分百不存在）=说你存在你可能存在或不存在，说你不存在你必定不存在；
无法删除ID（需改用其他数据结构如Counting Bloom Filter）。

2. 缓存空值（ Null Caching）

原理：

当查询数据库发现某个ID不存在时，将空值（ null ）缓存到 Redis 中，并设置较短的过期时间（如5分钟）。后续相同请求直接从缓存返回空值，减少数据库查询。

场景应用：

用户首次请求 product:9999999，Redis 未命中；
系统查询数据库，发现不存在该ID；
将 product:9999999 的空值写入 Redis，并设置5分钟过期；
随后的请求直接从 Redis 获取空值，不再访问数据库。

优点：

实现简单，成本低；
有效应对短时间内的重复无效请求。

缺点：

可能缓存大量无用的空值，占用内存；
如果攻击者不断更换无效ID（如 product:1000001、product:1000002），会导致缓存中堆积大量空值，反而加重 Redis 负担。

3. 接口层校验（ID合法性检查）

原理：

在应用层对用户输入的ID进行格式校验，拦截非法请求。例如：

检查ID是否为数字；
检查ID是否在合理范围内（如ID必须大于0且小于最大值）；
拦截明显无效的ID（如负数、特殊符号）。

场景应用：

用户请求 product:abc（非数字）或 product:-123（负数）时，接口层直接返回错误信息，不再查询缓存和数据库；
对合法ID（如 product:1001）继续执行缓存和数据库查询流程。

优点：

直接拦截非法请求，减少无效流量；
无需依赖额外数据结构（如布隆过滤器）。

缺点：

依赖业务规则的合理性（如ID范围可能变化）；
无法防御所有攻击（如攻击者构造合法但不存在的ID）。

4. 综合方案：多层防护

在实际场景中，通常结合多种方法以达到最佳效果：

接口层校验：拦截明显非法的ID（如负数、非数字）；
布隆过滤器 ：拦截合法但不存在的ID（如 product:9999999）；
缓存空值：应对短时间内重复查询的ID（如攻击者多次请求同一无效ID）；
限流熔断：对高频请求进行限流，防止数据库过载。

总结

在电商商品查询场景中，缓存穿透的根源是攻击者或异常请求频繁查询不存在的资源。通过布隆过滤器拦截非法ID、缓存空值减少数据库压力、接口校验过滤无效请求，可以有效缓解问题。实际部署时，建议结合多层防护策略，既能应对突发攻击，又能保证系统稳定性和性能。

缓存击穿

实际场景：电商热销商品详情页查询中的缓存击穿问题

场景描述

假设有一个电商平台，某款限量版手机（如 product:1001）因库存紧张而成为热销商品，用户频繁通过商品ID查询其详情（如价格、库存、促销活动）。系统使用 Redis 缓存商品信息，数据库（如 MySQL）作为持久化存储。正常情况下：

用户请求时，系统先查询 Redis 缓存；
若缓存命中，直接返回数据；
若缓存未命中，查询数据库并将结果写入 Redis。

问题出现：

某天，该商品的缓存因过期或被删除失效。此时：

大量用户同时请求 product:1001，Redis 未命中；
所有请求直接穿透到数据库查询；
数据库因高频请求负载激增，可能引发响应延迟甚至宕机。

这种现象就是缓存击穿，即某个热点 Key 失效后，大量请求直接访问数据库。

解决方案详解

1. 互斥锁（Mutex Lock）

原理：

通过分布式锁机制，确保同一时间只有一个线程负责重建缓存，其他线程等待或返回旧数据。

场景应用：

用户请求 product:1001，Redis 未命中；
线程1尝试获取分布式锁（如 Redis 的 SET key NX PX 命令），若成功，则负责查询数据库并重建缓存；
其他线程（线程2、线程3...）因无法获取锁，需等待线程1完成缓存重建，或直接返回降级信息（如"加载中"）；
线程1写入 Redis 后释放锁，后续请求直接从缓存获取数据。

优点：

保证数据一致性（所有线程最终获取最新数据）；
避免数据库被高频请求击穿。

缺点：

增加请求响应时间（线程需等待锁释放）；
可能导致线程阻塞，影响系统吞吐量；
需处理死锁（如锁未释放）和锁竞争问题。

2. 逻辑过期（Logical Expiration）

原理：

缓存 Key 永不过期，但在数据中存储逻辑过期时间。当查询时发现数据已过期，异步更新缓存，同时返回旧数据。

场景应用：

用户请求 product:1001，Redis 缓存命中但数据逻辑过期；
线程1检测到过期时间已到，尝试获取锁；
若获取锁成功，线程1异步查询数据库并更新 Redis 缓存；
其他线程无需等待，直接返回旧数据；
缓存更新完成后，后续请求获取最新数据。

优点：

请求无需等待锁释放，响应速度快；
降低数据库瞬时压力。

缺点：

存在短暂数据不一致窗口期（返回旧数据）；
实现复杂（需管理逻辑过期时间和锁机制）；
需权衡数据一致性与性能。

对比与适用场景

|-----------|-------------------|------------------|
| 方案 | 互斥锁 | 逻辑过期 |
| 核心思想 | 锁定缓存重建，其他线程等待 | 缓存永不过期，异步更新 |
| 数据一致性 | 强一致性（返回最新数据） | 弱一致性（可能返回旧数据） |
| 性能 | 低（线程等待） | 高（无需等待） |
| 实现复杂度 | 简单 | 复杂（需管理逻辑过期和异步更新） |
| 适用场景 | 对数据一致性要求高，可接受短时延迟 | 对性能要求高，允许短时旧数据 |

总结

在电商热销商品查询场景中，缓存击穿的根源是热点 Key 失效后并发请求直接冲击数据库。通过互斥锁，可以确保缓存重建的原子性，但需权衡响应时间；通过逻辑过期，可提升性能但需容忍短暂数据不一致。实际部署时，需根据业务需求选择方案：

强一致性优先：使用互斥锁；
高并发性能优先：结合逻辑过期和异步更新。

缓存雪崩

实际场景：电商促销活动中的缓存雪崩问题

场景描述

假设某电商平台在"双11"促销期间，所有商品的缓存（如商品详情、库存、价格）被统一设置为 2小时过期（TTL=7200秒）。活动结束后，大量用户访问热销商品（如限量版手机、热门家电），导致所有缓存同时失效，请求直接涌入数据库。数据库因瞬时高压负载（如每秒数万次查询）崩溃，用户无法查看商品信息，订单系统瘫痪。

解决方案详解

1. 给不同的 Key 的 TTL 添加随机值

原理：

为每个缓存 Key 设置随机过期时间，避免所有缓存同时失效。例如，将原本统一的 2 小时过期时间（7200秒）改为 7200 ± 720秒（即 6480~7920秒随机区间）。

场景应用：

在促销期间，为每个商品缓存设置随机 TTL：
- 商品A的缓存过期时间为 7200 + 300秒 = 7500秒；
- 商品B的缓存过期时间为 7200 - 200秒 = 7000秒；
- 商品C的缓存过期时间为 7200 + 500秒 = 7700秒。
这样，缓存失效时间分散在 2小时±10分钟 的范围内，避免同一时间集中失效。

优点：

简单有效，无需额外代码改造；
显著降低数据库瞬时压力。

缺点：

需合理设置随机范围，避免过期时间过于分散导致缓存利用率下降。

2. 利用 Redis 集群提高服务的可用性

原理：

通过 Redis 集群部署（如主从复制 + 哨兵模式或 Redis Cluster），确保缓存服务高可用。即使部分节点故障，其他节点仍能提供服务，避免缓存整体失效。

场景应用：

电商平台部署 Redis Cluster，将商品缓存分布在多个节点上：
- 节点1存储商品A~Z的缓存；
- 节点2存储商品AA~ZZ的缓存；
- 节点3存储热点商品（如限量手机）的缓存。
当某个节点故障时，Cluster 会自动切换到备用节点，确保缓存服务不中断。

优点：

避免单点故障导致缓存雪崩；
提升系统容灾能力。

缺点：

需投入更多硬件资源部署集群；
配置和维护复杂度较高。

3. 给缓存业务添加降级限流策略

原理：

当缓存失效或数据库压力过大时，通过 熔断、限流、降级 机制保护后端服务。例如：

熔断：当数据库响应超时或错误率过高时，直接返回默认值（如"系统繁忙"）；
限流：限制单位时间内请求的 QPS（如每秒最多处理 1000 个请求）；
降级：关闭非核心功能（如商品评价、推荐），仅保留核心功能（如商品详情）。

场景应用：

用户请求商品详情时，若 Redis 缓存未命中且数据库负载过高：
- 熔断：直接返回"当前访问人数过多，请稍后再试"；
- 限流：限制每秒最多 1000 个请求访问数据库；
- 降级：关闭商品评价模块，仅返回商品基础信息。

优点：

有效保护数据库不被击穿；
提升用户体验（避免系统完全不可用）。

缺点：

需权衡降级策略的粒度（如是否关闭非核心功能）；
需实时监控系统状态并动态调整策略。

4. 给业务添加多级缓存

原理：

通过 本地缓存 + 分布式缓存 的多级架构，当分布式缓存（如 Redis）失效时，本地缓存（如 Caffeine、Guava）仍能提供数据。

场景应用：

第一级缓存（本地缓存）：
- 使用 Caffeine 缓存商品详情，设置 TTL=5分钟；
- 商品详情更新后，本地缓存异步刷新。
第二级缓存（Redis）：
- Redis 缓存商品详情，设置 TTL=2小时；
- 当 Redis 缓存失效时，优先读取本地缓存；
- 若本地缓存也失效，再查询数据库并更新两级缓存。

优点：

双重保障，显著降低数据库访问频率；
提升系统抗并发能力。

缺点：

增加系统复杂度（需维护多级缓存一致性）；
本地缓存占用内存资源。

总结：多策略协同抵御缓存雪崩

在电商促销活动中，缓存雪崩的根本原因是大量缓存同时失效，导致数据库高压。通过以下组合策略可有效缓解问题：

分散缓存过期时间（随机 TTL） → 避免集中失效；
Redis 集群部署 → 提升缓存服务可用性；
降级限流 → 保护数据库不被击穿；
多级缓存 → 双重兜底，减少数据库访问。

最终效果：

缓存失效时，请求被分散处理，数据库负载平稳；
即使缓存服务部分故障，本地缓存和限流策略仍能维持系统基本可用；
保障促销活动期间的系统稳定性和用户体验。

redis数据与mysql数据进行同步

实际场景：电商平台的商品库存与缓存同步

场景描述

假设某电商平台在"618"促销期间，用户需要购买限量商品（如手机、家电）。商品库存数据同时存储在 MySQL（持久化存储） 和 Redis（缓存） 中。用户下单时，系统需要同时更新 MySQL 和 Redis 的库存数据，确保两者的一致性。若同步失败，可能导致超卖或库存显示异常。

核心问题

强一致性需求：秒杀场景中，库存扣减必须实时同步到 MySQL 和 Redis，避免超卖。
允许延时一致的场景：商品详情页的展示信息（如商品描述、价格）可容忍一定延迟，可通过异步通知同步。

解决方案详解

一、强一致性业务的解决方法

场景：秒杀商品库存扣减

目标：确保 Redis 和 MySQL 的库存数据实时一致，避免超卖。

解决方案：使用分布式锁

原理：

在更新 MySQL 和 Redis 时，通过分布式锁（如 Redisson 提供的 RLock）确保同一时间只有一个线程操作数据。
锁的粒度为商品 ID，避免并发冲突。

实现步骤：

获取分布式锁：
1. 当用户下单时，系统根据商品 ID 获取分布式锁（如 lock:product:1001）。
2. 锁未释放前，其他请求需等待，避免并发修改。
更新 MySQL 和 Redis：
1. 步骤1：查询 MySQL 当前库存，确保库存充足。
2. 步骤2：在事务中更新 MySQL 的库存（扣减 1）。
3. 步骤3：更新 Redis 的库存（扣减 1）。
4. 步骤4：释放分布式锁。
处理异常情况：
1. 若 MySQL 更新成功但 Redis 更新失败，需记录日志并触发补偿机制（如定时任务重试）。
2. 若锁超时，需重新尝试或回滚操作。

优点：

强一致性：通过锁机制确保 MySQL 和 Redis 同步完成后再释放锁。
避免超卖：锁粒度细，确保并发安全。

缺点：

性能瓶颈：锁会阻塞并发请求，高并发场景下需优化锁粒度或使用分段锁。
实现复杂：需处理锁超时、死锁、补偿逻辑等问题。

二、允许延时一致的业务解决方法

场景：商品详情页信息同步

目标：商品描述、价格等信息允许短时间延迟同步，通过异步通知更新缓存。

解决方案：异步通知 + 延迟补偿

原理：

当 MySQL 数据更新后，通过 消息队列 或 Canal 工具异步通知 Redis 更新缓存。
允许缓存数据在短时间内与数据库不一致，但最终保持一致。

实现步骤：

异步通知更新缓存：
1. 方案1：消息队列：
  - 当商品信息更新时，将更新事件发送到消息队列（如 Kafka/RabbitMQ）。
  - 消费者监听队列，异步更新 Redis 中的商品信息。
2. 方案2：Canal 监听 Binlog：
  - 使用 Canal 工具监听 MySQL 的 Binlog 日志，解析数据变更事件。
  - 当检测到商品信息更新时，自动更新 Redis 中的缓存。
设置缓存过期时间：
1. 为 Redis 中的商品信息设置合理的 TTL（如 5 分钟）。
2. 若缓存未及时更新，用户读取时会从 MySQL 加载最新数据并重新写入缓存。

优点：

高性能：异步更新减少对数据库的直接压力，提升系统吞吐量。
解耦：业务逻辑与缓存更新解耦，降低代码复杂度。

缺点：

数据延迟：缓存更新可能存在短时间延迟（如几秒到几分钟）。
消息丢失风险：需确保消息队列的可靠性（如 ACK 机制）和幂等性处理。

总结：不同场景的同步策略

|-----------|------------------|-----------|------------------|
| 场景 | 同步方式 | 一致性类型 | 适用业务 |
| 秒杀库存扣减 | 分布式锁（强一致性） | 强一致性 | 高并发、关键业务（如库存、支付） |
| 商品详情页信息展示 | 消息队列/Canal（异步通知） | 最终一致性 | 低频更新、允许短时延迟的业务 |

选择建议

强一致性场景：
1. 必须实时同步数据，使用分布式锁或事务（如 Redisson 的读写锁）。
2. 适合高并发、关键业务（如金融交易、库存管理）。
允许延时一致场景：
1. 通过异步通知（消息队列/Canal）更新缓存，结合缓存过期策略。
2. 适合低频更新、允许短时延迟的业务（如商品详情、用户资料）。

实际应用中的权衡

性能 vs 一致性：强一致性会牺牲性能，需根据业务优先级选择策略。
系统复杂度：异步方案需处理消息丢失、重复消费等问题，需设计补偿机制。
成本：分布式锁和消息队列会增加系统开销，需评估资源投入。

redis的持久化：RDB和AOF

实际场景：电商平台的高并发秒杀活动

场景描述

某电商平台在"618"促销期间，用户需要秒杀限量商品（如手机、家电）。商品库存和订单数据通过 Redis 缓存加速访问，但需要将关键数据持久化到磁盘以防止服务器宕机导致数据丢失。Redis 提供了两种持久化机制：RDB（快照）和 AOF（追加日志）。下面通过该场景详细讲解两者的原理、优缺点及适用场景。

一、RDB（Redis Database）快照持久化

1. 工作原理

快照机制 ：RDB 通过定期生成内存数据的全量快照（Snapshot），将当前 Redis 的数据状态保存为二进制文件（默认文件名为 dump.rdb）。快照是某个时间点的完整数据副本，包含所有键值对、过期时间等信息。
触发方式：
- 自动触发 ：通过配置规则（如 save 60 10000）触发，表示在 60 秒内如果有至少 10000 次键修改，则生成快照。
- 手动触发 ：通过 SAVE（阻塞主线程）或 BGSAVE（后台异步执行）命令生成快照。
实现细节：
- 写时复制（COW） ：Redis 使用 fork 子进程生成快照，子进程共享父进程的内存页表。当父进程修改数据时，会触发 COW 机制，复制被修改的内存页，确保子进程的数据一致性。
- 文件格式：RDB 文件是压缩的二进制文件，体积通常比 AOF 文件小（约为内存数据的 1/10），适合快速恢复。

2. 在秒杀场景中的表现

库存扣减 ：假设秒杀商品库存为 1000 件，Redis 内存中实时更新库存（如 stock:1001 键的值）。当达到配置规则（如 save 60 10000）时，Redis 会生成 RDB 快照，将当前库存值（如 900 件）持久化到磁盘。
宕机恢复：如果服务器宕机，重启后 Redis 会加载最新的 RDB 文件，恢复到快照生成时的状态（如库存 900 件）。但宕机发生时，如果快照尚未生成，最后一次快照后的数据（如扣减到 800 件）会丢失。

3. 优点与缺点

优点：
- 高性能：快照生成由子进程处理，主进程不阻塞，适合高并发场景。
- 恢复速度快：二进制文件加载迅速，适合大规模数据恢复（如百万级键）。
- 文件紧凑：适合备份和远程传输。
缺点：
- 数据丢失风险：两次快照之间的数据可能丢失（取决于触发频率）。
- fork 性能问题 ：数据量较大时，fork 操作可能阻塞主进程（如 50GB 数据 fork 耗时约 2.5 秒）。

4. 适用场景

允许分钟级数据丢失：如缓存数据、非关键业务（如商品详情页展示）。
需要快速恢复：如灾备场景（RDB 文件可定期备份到远程服务器）。

二、AOF（Append Only File）日志持久化

1. 工作原理

日志记录 ：AOF 通过记录所有写操作命令（如 SET stock:1001 999）到磁盘文件（默认文件名为 appendonly.aof），重启时通过重放这些命令恢复数据。
同步策略：
- appendfsync always：每次写操作都同步到磁盘，数据最安全但性能最低。
- appendfsync everysec（默认）：每秒同步一次，平衡性能与安全性。
- appendfsync no：由操作系统决定同步时机，性能最高但数据安全性最低。
文件重写 ：AOF 文件会不断增长（如记录 10 万次 DECR stock:1001 操作），Redis 提供 BGREWRITEAOF 命令压缩文件。重写过程通过子进程执行，移除冗余命令（如合并多次 DECR 为单条 SET）。

2. 在秒杀场景中的表现

订单记录 ：用户下单时，Redis 记录订单信息（如 order:10001 {"user": "A", "product": 1001}）。AOF 会将这些写操作追加到日志文件中。
宕机恢复 ：如果服务器宕机，重启后 Redis 会重放 AOF 文件中的所有命令，恢复到宕机前的状态（如订单 10001 存在）。即使宕机发生在 everysec 同步间隔内，最多丢失 1 秒的数据。

3. 优点与缺点

优点：
- 数据安全性高：记录所有写操作，最多丢失 1 秒数据（默认配置）。
- 可读性强：AOF 文件是文本格式，可直接查看和调试。
- 支持增量备份：通过截取 AOF 日志片段进行备份。
缺点：
- 文件体积大 ：AOF 文件通常比 RDB 文件大（如记录 100 次 DECR 操作）。
- 恢复速度慢：需要重放所有命令，大数据集恢复耗时较长。
- 性能开销 ：频繁同步磁盘可能影响性能（尤其是 appendfsync always）。

4. 适用场景

对数据一致性要求高：如关键业务（如支付、订单处理）。
允许一定性能损失：如金融系统、交易日志记录。

三、混合持久化（Redis 4.0+）

1. 工作原理

混合持久化结合 RDB 和 AOF 的优势：

首次生成：先以 RDB 格式保存当前数据快照，再将增量写操作以 AOF 格式追加。
文件结构：混合文件前半部分是 RDB 快照，后半部分是 AOF 日志。

2. 在秒杀场景中的表现

库存与订单：混合持久化在秒杀活动中兼顾性能与安全性。RDB 快照快速恢复库存数据，AOF 日志确保订单记录不丢失。
宕机恢复：重启后，Redis 先加载 RDB 快照（如库存 900 件），再重放 AOF 日志中的增量操作（如扣减到 800 件）。

3. 优点与缺点

优点：
- 兼顾性能与安全性：RDB 快速恢复 + AOF 数据一致性。
- 文件体积优化：比纯 AOF 文件小，恢复速度比纯 RDB 快。
缺点：
- 实现复杂：需 Redis 4.0+ 版本支持。

4. 适用场景

综合需求：需要高性能恢复和高数据一致性的场景（如金融、电商核心业务）。

四、场景对比与选择建议

|-------------|------------------|-------------|---------------------------|
| 场景 | RDB | AOF | 混合持久化 |
| 秒杀库存扣减 | 快速生成快照，但可能丢失最近数据 | 安全性高，但恢复较慢 | 推荐（兼顾性能与安全性） |
| 订单记录 | 不适合（可能丢失订单数据） | 推荐（确保订单不丢失） | 推荐（结合 RDB 快速恢复 + AOF 安全性） |
| 商品详情页展示 | 推荐（允许短时数据延迟） | 可选（需权衡性能） | 可选（优化恢复速度） |

五、总结

RDB 适合对性能要求高、允许短时数据丢失的场景（如缓存、灾备）。
AOF 适合对数据一致性要求高的场景（如订单、支付）。
混合持久化 是两者的最佳平衡方案，推荐在生产环境中使用。

通过合理配置 RDB/AOF 的触发规则和同步策略，可在秒杀等高并发场景中实现数据安全与性能的平衡。

redis的数据过期策略：惰性删除和定期删除

实际场景：电商平台的用户会话缓存管理

场景描述

某电商平台在用户登录后，会为每个用户生成一个会话Token，用于标识用户的登录状态。为了提升性能，平台将这些Token存储在 Redis 中，并设置 TTL（Time To Live） 为30分钟（即用户30分钟内无操作则自动登出）。同时，平台需要确保过期的Token及时清理，避免内存浪费。

一、Redis的过期策略概述

Redis通过 惰性删除 和 定期删除 两种策略协同管理过期数据：

惰性删除：在访问键时检查是否过期，若过期则删除。
定期删除：周期性扫描并删除部分过期键。

二、惰性删除（Lazy Expiration）

1. 触发时机

用户访问Token时：当用户发起请求（如查看购物车、下单），Redis会检查该Token是否已过期。
- 示例：用户A的Token设置TTL为30分钟，但用户A在登录后未进行任何操作。此时，Token已过期，但Redis不会主动清理，直到用户A再次访问平台。

2. 执行流程

检查过期 ：当用户访问Token时，Redis从 过期字典（expires dict） 中查找该Token的过期时间。
删除过期键 ：若当前时间 > 过期时间，Redis立即删除该Token并返回空值（如 null 或错误信息）。

3. 优点与缺点

优点：
- CPU友好：仅在访问时检查过期，避免不必要的扫描开销。
- 实时性：确保用户访问时立即清理过期数据。
缺点：
- 内存浪费：未被访问的过期Token会长期占用内存（如用户B的Token已过期但未被访问）。
- 延迟问题：过期Token可能在内存中停留较长时间（取决于访问频率）。

4. 应用场景

低频访问的键：如用户历史浏览记录、未使用的优惠券。
对实时性要求高的场景：如支付回调验证Token有效性。

三、定期删除（Active Expiration）

1. 触发时机

周期性扫描 ：Redis默认每秒执行 10次扫描任务（通过 hz 配置项调整），随机抽取一定数量的键检查过期状态。
- 示例：每秒扫描20个键，若发现1/4的键已过期，则重复扫描直到过期比例下降。

2. 执行流程

随机抽样：从所有设置了TTL的键中随机选取20个键。
检查过期：逐个判断键是否过期，若过期则删除。
动态调整：
1. SLOW模式：默认每秒执行10次扫描，每次耗时不超过25ms。
2. FAST模式：在空闲时高频扫描（如每2ms一次），每次耗时不超过1ms。

3. 优点与缺点

优点：
- 内存释放：主动清理未被访问的过期键，避免内存膨胀。
- 平衡性能：通过限制扫描频率和键数，减少对CPU的影响。
缺点：
- 无法完全及时：某些过期键可能未被扫描到，导致内存占用延迟。
- 配置敏感 ：需根据业务负载调整 hz 参数（过高增加CPU开销，过低导致清理不及时）。

4. 应用场景

高频写入的键：如秒杀活动的库存计数器、实时排行榜。
内存敏感的场景：如缓存大量临时数据（如验证码、会话Token）。

四、协同工作：惰性 + 定期删除

1. 在电商场景中的表现

用户A的Token：
- 未访问：30分钟后未被访问，Redis通过定期删除扫描到该键并删除。
- 已访问：用户A再次访问时触发惰性删除，立即清理过期Token。
用户B的Token：
- 高频访问：若用户B频繁操作（如加购、下单），定期删除可能未扫描到该键，但惰性删除确保每次访问时清理过期数据。
- 低频访问：若用户B长时间未操作，定期删除会主动清理其Token。

2. 主从同步中的过期处理

主库：过期键删除时，主库会向AOF文件写入 DEL 命令。
从库：从库异步接收并执行 DEL 命令。若网络延迟导致同步失败，可能出现主从数据不一致（如从库仍保留过期键）。

3. 内存淘汰策略补充

当Redis内存达到上限时，过期策略与 内存淘汰机制 协同工作：

Volatile-TTL：优先删除剩余TTL较短的键。
AllKeys-LRU：删除最近最少使用的键（包括未过期键）。

五、配置建议与优化

1. 参数调优

hz 配置：默认值为10（每秒10次扫描），高并发场景可调高至20，但需监控CPU使用率。
maxmemory-policy ：设置合理的内存淘汰策略（如 volatile-ttl 优先清理即将过期的键）。

2. 避免批量过期

随机TTL ：为类似键设置不同过期时间（如 EXPIRE key1 300, EXPIRE key2 305），避免大量键同时过期导致内存抖动。
分片存储：将大规模数据分散到多个Redis实例，减少单实例扫描压力。

六、总结

|----------|----------------|-----------------|-------------|----------------|
| 策略类型 | 触发方式 | 优点 | 缺点 | 适用场景 |
| 惰性删除 | 访问键时触发 | CPU开销低，实时性强 | 内存浪费，依赖访问频率 | 低频访问的缓存数据 |
| 定期删除 | 周期性扫描（默认10次/秒） | 主动释放内存，平衡性能与内存 | 无法完全及时，配置敏感 | 高频写入或内存敏感的业务 |
| 协同工作 | 惰性 + 定期删除 | 互补优势，减少内存与CPU冲突 | 需合理配置参数 | 大多数缓存场景（如会话管理） |

通过合理配置和场景适配，Redis的过期策略能够在保证性能的同时，高效管理内存资源。

redis的数据淘汰策略

实际场景：电商平台的商品信息缓存管理

场景描述

某电商平台拥有数百万商品，每个商品的详细信息（如价格、库存、图片、描述）需要频繁访问。为了提升性能，平台将商品信息缓存到 Redis 中。由于商品数量庞大，Redis内存无法容纳所有数据，因此需要配置内存淘汰策略，在内存不足时自动清理部分数据，保留高价值信息。

一、Redis内存淘汰策略概述

Redis提供了 8种内存淘汰策略，分为两类：

全局淘汰策略 （allkeys-*）：针对所有键（无论是否设置过期时间）。
局部淘汰策略 （volatile-*）：仅针对设置了过期时间（TTL）的键。

二、策略详解与电商场景应用

1. noeviction（默认策略）

行为：内存不足时拒绝所有写入操作，仅允许读取。
适用场景：数据不可丢失的场景（如支付系统）。
电商案例：若平台缓存商品库存信息且不允许任何丢失，可启用此策略。但若内存不足，新商品库存更新会失败，可能导致服务不可用（如秒杀活动时库存扣减失败）。
风险：需严格监控内存使用，避免OOM（Out Of Memory）错误。

2. allkeys-lru（最近最少使用）

行为：从所有键中淘汰最久未被访问的数据。
适用场景：缓存热点数据（如热门商品）。
电商案例 ：平台商品信息中，20%的热门商品（如手机、家电）占80%的访问量。启用 allkeys-lru 后，Redis会优先保留热门商品的缓存，冷门商品（如小众配件）被淘汰。当用户查询冷门商品时，系统从数据库加载并重新缓存。
优点：提升热门数据命中率，减少数据库压力。
缺点：冷门商品首次访问时需等待数据库加载。

3. volatile-ttl（优先删除剩余时间短的键）

行为：从设置了过期时间的键中，优先删除剩余时间（TTL）最短的键。
适用场景：时效敏感数据（如促销活动、限时折扣）。
电商案例 ：平台设置商品促销信息的TTL为24小时。启用 volatile-ttl 后，Redis会优先清理即将过期的促销数据（如剩余5分钟的活动），而非保留长期有效的商品信息。
优点：避免无效数据占用内存。
缺点：对无过期时间的数据无效。

4. allkeys-random（随机淘汰）

行为：从所有键中随机删除数据。
适用场景：数据访问无明显规律（如测试环境）。
电商案例：若平台商品访问模式随机（如新上线商品轮番推广），可启用此策略。但可能误删热门商品缓存，导致频繁回源数据库。
优点：实现简单，无额外计算开销。
缺点：无法保证热点数据留存。

5. volatile-lru（局部LRU）

行为：仅针对设置了过期时间的键，淘汰最久未访问的键。
适用场景：混合存储场景（部分数据需长期保留，部分数据可过期）。
电商案例：商品详情页的缓存分为两类：
- 长期缓存：核心商品信息（如价格、描述）无过期时间。
- 临时缓存 ：用户浏览记录（TTL=1小时）。启用 volatile-lru 后，Redis优先清理用户浏览记录（过期数据），保留核心商品信息。
优点：保护持久化数据，仅清理临时数据。
缺点：对无过期时间的数据无效。

6. volatile-lfu（局部LFU，Redis 4.0+）

行为：从设置了过期时间的键中，淘汰访问频率最低的数据。
适用场景：访问频率差异大的数据（如高频商品 vs 低频商品）。
电商案例 ：某商品A被频繁访问（如搜索、推荐），商品B极少被查看（如冷门配件）。启用 volatile-lfu 后，Redis优先淘汰商品B的缓存，保留商品A。
优点：精准清理冷数据，保留高频数据。
缺点：依赖访问频率统计，需维护额外计数器。

7. allkeys-lfu（全局LFU，Redis 4.0+）

行为：从所有键中，淘汰访问频率最低的数据。
适用场景：数据访问模式稳定（如固定热销商品）。
电商案例 ：平台核心商品（如旗舰机型）长期热销，其他商品销量波动大。启用 allkeys-lfu 后，Redis保留核心商品缓存，清理销量低的商品。
优点：适合长期热点数据管理。
缺点：实现复杂度高，需维护访问频率计数。

8. volatile-random（局部随机淘汰）

行为：从设置了过期时间的键中随机删除数据。
适用场景：快速释放内存（如临时缓存清理）。
电商案例 ：用户会话Token（TTL=30分钟）缓存中，部分Token因网络延迟未被及时访问。启用 volatile-random 后，Redis随机清理过期Token，避免内存堆积。
优点：实现简单，适合临时数据。
缺点：无法保证清理效率。

三、策略选择建议

|--------------------|----------------|---------------|----------------|
| 策略类型 | 适用场景 | 优势 | 劣势 |
| allkeys-lru | 热点数据缓存（如商品详情页） | 保留高频数据，提升命中率 | 冷门数据首次访问需回源数据库 |
| volatile-ttl | 时效数据（如促销活动） | 清理即将过期数据，节省内存 | 仅针对带TTL的键 |
| volatile-lfu | 访问频率差异大的数据 | 精准清理冷数据，保留热点 | 依赖访问频率统计 |
| noeviction | 数据不可丢失（如支付系统） | 保证数据完整性 | 内存不足时写入失败 |
| allkeys-random | 无规律访问数据（如测试环境） | 实现简单 | 可能误删热点数据 |

四、配置与调优建议

内存监控 ：使用 INFO memory 命令监控 used_memory 和 evicted_keys，观察内存使用和淘汰情况。
动态调整策略 ：通过 CONFIG SET maxmemory-policy <策略名> 动态切换策略，无需重启服务。
混合策略：
1. 对长期数据使用 allkeys-lru。
2. 对临时数据（如浏览记录）使用 volatile-ttl 或 volatile-lfu。
分片存储：将商品信息拆分为多个Redis实例，避免单实例内存瓶颈。
冷热分离：高频数据缓存到Redis，低频数据存储到数据库或磁盘缓存（如SSD）。

五、总结

在电商场景中，allkeys-lru 是最常见的选择，适合保留热门商品信息；volatile-ttl 用于清理即将过期的促销数据；volatile-lfu 则适合访问频率差异大的场景。通过合理配置策略，可显著提升缓存命中率，降低数据库压力，同时优化内存使用效率。

redis的分布式锁是如何实现的？redission

实际场景：电商平台的秒杀活动库存扣减

场景描述

某电商平台在"双十一"期间推出限量秒杀商品（如某款手机），商品库存仅1000台。为防止超卖，平台需要通过 Redis分布式锁 保证多个服务节点（如多个微服务实例）对库存的修改操作是串行化的。同时，需解决以下问题：

锁的有效时长控制：防止业务逻辑耗时过长导致锁过期，引发并发问题。
锁的可重入性：允许同一服务实例在调用链中多次获取同一把锁。
主从一致性：在Redis集群环境下，避免因主从切换导致锁失效。

一、Redis分布式锁的实现原理

1. 基础实现：SETNX + EX（原子操作）

SETNX（Set if Not Exists） ：客户端尝试通过 SETNX key value 命令获取锁。若Key不存在（未被其他客户端占用），则设置Key并返回1（成功），否则返回0（失败）。示例：客户端A尝试获取锁 lock:seckill:phone，若Key不存在，则设置Key并设置过期时间（如30秒）。
EX（Expire） ：为锁设置过期时间（TTL），防止客户端崩溃后锁无法释放（死锁）。问题：SETNX 和 EX 是两个独立命令，非原子性操作。若在设置Key后服务器宕机，可能导致锁未设置过期时间（死锁）。

2. 改进实现：原子SET命令

Redis 2.6+ 的 SET 命令 ：使用 SET key value NX EX 原子性地设置Key并指定过期时间。示例：SET lock:seckill:phone unique_id NX EX 30。若Key不存在且设置成功，返回 OK，否则返回 nil。
Lua脚本保证原子性 ：获取锁后，通过Lua脚本（如判断Key值是否为当前客户端ID）释放锁，防止误删其他客户端的锁。示例：

暂时无法在飞书文档外展示此内容

3. Redisson的优化：看门狗机制（Watch Dog）

自动续期 ：Redisson在加锁时启动一个后台线程（看门狗），定期（默认每10秒）向Redis发送 EXPIRE 命令延长锁的过期时间。示例：客户端A获取锁后，若业务逻辑耗时35秒，看门狗会在10秒和20秒时自动将锁续期至30秒，确保业务执行完成前锁不会过期。
默认行为：
- 未指定租约时间（Lease Time）：默认启用看门狗，锁会持续续期直到业务逻辑结束。
- 指定租约时间 ：若设置 leaseTime=30s，看门狗不会自动续期，锁在30秒后自动释放。

二、Redisson如何合理控制锁的有效时长？

1. 默认看门狗机制

自动续期 ：当客户端调用 RLock.lock() 时，Redisson会启动一个后台线程，每隔 leaseTime/3（默认30秒/3=10秒）检查锁状态。若客户端仍持有锁，自动续期至原始租约时间。优势：业务逻辑耗时不确定时，无需手动管理锁续期，避免锁提前释放。

2. 手动控制租约时间

固定租约时间 ：调用 RLock.lock(30, TimeUnit.SECONDS) 设置锁的租约时间为30秒。若业务耗时超过30秒，锁会自动释放，可能导致并发问题。适用场景：业务逻辑耗时可预测（如短时任务）。
禁用看门狗 ：若设置 leaseTime=30s，看门狗不会自动续期。需在业务逻辑中手动调用 lock.expire(30, TimeUnit.SECONDS) 续期。适用场景：需要精确控制锁生命周期（如支付超时订单）。

3. 配置建议

租约时间：根据业务耗时设置合理租约时间（如短时任务10秒，长时任务60秒）。
续期间隔：避免过于频繁的续期请求（如每5秒续期一次），增加Redis负载。
最终释放 ：在 try-finally 块中确保锁释放，避免资源泄露。

三、Redisson的锁是否支持可重入？

1. 可重入锁的实现原理

Hash结构记录重入次数 ：Redisson使用Redis的Hash数据结构存储锁信息。例如，键 lock:seckill:phone 对应的Hash字段包括：
- threadId：当前持有锁的线程ID。
- reentrantCount：重入次数（初始为1，每次重入递增）。
重入流程：
- 第一次加锁 ：客户端A获取锁，Hash记录 threadId=A, reentrantCount=1。
- 第二次加锁 ：客户端A再次获取锁，reentrantCount 递增为2。
- 释放锁 ：客户端A调用 unlock()，reentrantCount 递减至0时删除Key。

2. 优势

避免死锁：同一线程可多次加锁，无需担心自身阻塞。
灵活性：支持嵌套调用（如方法A调用方法B，均需加锁）。

3. 注意事项

线程隔离：Redisson的重入锁基于线程ID（JVM级别），跨JVM的重入无效。
资源回收 ：需确保所有重入操作最终释放锁，否则可能因 reentrantCount 未归零导致锁未释放。

四、Redisson锁能否解决主从一致性问题？

1. 主从一致性问题的根源

主从同步延迟：在Redis主从架构中，主节点写入锁后，从节点可能因网络延迟未同步。若主节点宕机，从节点升级为主节点，新主节点可能未包含旧锁信息，导致其他客户端可获取锁，引发并发问题。

2. Redisson的解决方案：MultiLock（联锁）

多节点加锁 ：Redisson通过 RedissonMultiLock 同时对多个独立Redis节点（如3个主节点）加锁。示例：客户端A需同时在节点1、2、3上加锁，只有当超过半数节点（如2个）加锁成功时，才认为整体加锁成功。
故障转移容忍：即使某个主节点宕机，只要剩余节点中多数仍持有锁，其他客户端无法获取锁，避免并发问题。

3. 限制与注意事项

性能开销：多节点加锁增加网络延迟和Redis负载。
配置复杂度：需维护多个Redis节点（如哨兵模式或集群模式）。
适用场景：对一致性要求极高（如金融交易），而非普通高并发场景。

五、总结与场景适配

|-------------|--------------------|---------------------------|------------------------|
| 需求 | 实现方案 | Redisson特性 | 注意事项 |
| 锁有效时长控制 | 看门狗自动续期 / 手动设置租约时间 | 自动续期（默认）或手动调用 expire() | 合理设置租约时间，避免锁过早释放或资源浪费 |
| 可重入锁 | Hash记录重入次数 | 支持线程级可重入 | 确保所有重入操作最终释放锁 |
| 主从一致性 | MultiLock多节点加锁 | 通过 RedissonMultiLock 实现 | 配置多个Redis节点，容忍单点故障 |
| 高并发场景 | 原子SET命令 + Lua脚本 | 默认支持 | 监控Redis负载，避免频繁续期导致性能下降 |

电商秒杀场景应用

加锁流程：
- 客户端A调用 RLock.lock() 获取锁 lock:seckill:phone，看门狗自动续期。
- 客户端A执行库存扣减逻辑（如检查库存、更新数据库）。
- 客户端A释放锁，看门狗线程终止。
主从一致性保障 ：若采用 RedissonMultiLock，客户端A需在3个独立Redis主节点加锁。即使其中一个主节点宕机，其他节点仍持有锁，避免客户端B在故障切换后重复扣减库存。

通过上述机制，Redisson的分布式锁在保证高并发性能的同时，解决了锁的有效时长控制、可重入性和主从一致性问题，适用于电商秒杀等高要求场景。

redis的主从同步以及全量同步和增量同步

实际场景：电商平台的高并发订单缓存管理

场景描述

某电商平台在"双十一大促"期间，订单系统面临极高的并发请求（如每秒数万笔订单创建）。为提升性能，平台采用 Redis主从架构，主节点（Master）处理写操作（如订单状态更新），从节点（Slave）处理读操作（如订单查询）。同时，主节点通过 主从同步 将数据实时复制到从节点，确保数据一致性和高可用性。在此过程中，全量同步和 增量同步 是核心机制。

一、Redis主从同步原理

1. 主从架构概述

主节点（Master） ：负责接收客户端的写请求（如 SET order:12345 status:paid），并将数据持久化到内存和磁盘（如RDB/AOF）。
从节点（Slave） ：同步主节点的数据，处理读请求（如 GET order:12345），分担主节点压力。
同步目标：确保从节点的数据与主节点保持一致，实现读写分离和故障转移。

二、全量同步（Full Resynchronization）

1. 触发条件

初次连接：从节点首次连接主节点时（如新部署从节点）。
主从断开时间过长 ：主节点的 复制积压缓冲区（replication backlog） 被覆盖，导致无法通过增量同步恢复数据。
主节点重启：主节点运行ID（runid）变化，从节点需重新同步。

2. 同步流程详解

以电商平台首次部署从节点为例：

从节点发送 SYNC 命令 从节点向主节点发送 SYNC 命令，表示需要全量同步。
主节点生成 RDB 快照
1. 主节点启动后台进程（BGSAVE），生成当前内存数据的 RDB快照文件（如包含所有订单信息）。
2. 在生成RDB期间，主节点继续接收写请求（如新订单创建），并将这些写命令缓存到复制缓冲区（replication buffer）。
传输 RDB 文件
1. 主节点将生成的RDB文件发送给从节点。
2. 从节点清空本地旧数据，加载RDB文件到内存（如加载所有订单状态）。
传输缓冲区命令
1. 主节点将复制缓冲区中的写命令（如新增的订单）发送给从节点。
2. 从节点执行这些命令，追平主节点的最新数据。
进入命令传播阶段
1. 主节点后续的所有写操作（如订单支付状态更新）实时发送给从节点，保持同步。

3. 优势与缺点

优势：
- 确保从节点与主节点数据完全一致（适合初次同步）。
缺点：
- 耗时长（需传输整个RDB文件）。
- 占用大量网络带宽（如RDB文件较大）。
- 主节点在同步期间可能因负载过高导致性能下降。

三、增量同步（Partial Resynchronization）

1. 触发条件

主从短暂断开后重新连接 ：主节点的 复制积压缓冲区 仍包含从节点缺失的写命令。
从节点携带有效的 runid 和 offset：从节点在断开前记录了主节点的运行ID（runid）和复制偏移量（offset）。

2. 同步流程详解

以电商平台从节点因网络波动断开后重新连接为例：

从节点发送 PSYNC 命令 从节点向主节点发送 PSYNC <runid> <offset>，请求增量同步。
1. runid：上次同步时主节点的运行ID（唯一标识）。
2. offset：从节点最后一次接收到的复制偏移量（表示已处理的字节数）。
主节点验证请求
1. 检查 runid 是否匹配当前主节点的运行ID。
2. 检查 offset 是否在 复制积压缓冲区 的范围内（默认1MB）。
发送缺失的写命令
1. 若验证通过，主节点从复制积压缓冲区中提取从 offset 开始的写命令（如断开期间新增的订单）。
2. 发送给从节点，从节点执行这些命令，追平数据。
进入命令传播阶段
1. 主节点继续实时发送后续写命令，保持同步。

3. 优势与缺点

优势：
- 仅传输缺失的写命令，节省网络带宽和时间（适合频繁断开重连场景）。
- 避免全量同步的资源消耗。
缺点：
- 依赖复制积压缓冲区的大小（若缓冲区太小，无法覆盖断开期间的数据，需退化为全量同步）。
- 主节点重启后 runid 变化，需重新全量同步。

四、关键组件解析

1. 复制积压缓冲区（replication backlog）

作用：存储主节点最近发送的写命令（如订单状态更新），用于增量同步。
配置：默认大小为1MB（可通过 repl-backlog-size 调整）。
场景示例：若从节点断开时间较短（如几秒），主节点仍能通过复制积压缓冲区提供增量数据。

2. 运行ID（runid）

作用：标识主节点的身份（每次重启后生成新的runid）。
场景示例：从节点断开后重新连接，若主节点未重启，runid匹配，可尝试增量同步。

3. 复制偏移量（offset）

作用：记录主节点和从节点已处理的字节数（用于判断数据是否一致）。
场景示例：从节点断开前的offset为1000，主节点当前offset为1500，需同步500字节的命令。

五、电商场景中的主从同步实践

1. 初次部署从节点（全量同步）

步骤：
- 从节点首次连接主节点，发送 SYNC 命令。
- 主节点生成RDB文件（包含所有订单数据），发送给从节点。
- 从节点加载RDB并执行缓冲区命令，完成同步。
结果：从节点与主节点数据一致，可处理读请求（如查询订单状态）。

2. 网络波动后的重新连接（增量同步）

场景：从节点因网络波动断开（如5秒），主节点复制积压缓冲区大小为1MB。
步骤：
- 从节点重新连接，发送 PSYNC <runid> <offset>。
- 主节点验证runid匹配，且offset在缓冲区范围内。
- 主节点发送断开期间的写命令（如新增的100笔订单）。
- 从节点执行命令，追平数据。
结果：从节点快速恢复，无需全量同步，减少服务中断时间。

3. 主节点重启后的同步（全量同步）

场景：主节点因硬件故障重启，runid变化。
步骤：
- 从节点尝试 PSYNC，但runid不匹配。
- 主节点强制执行全量同步（发送RDB文件）。
- 从节点加载RDB并执行缓冲区命令。
结果：从节点数据与新主节点一致，但需等待全量同步完成。

六、主从同步的挑战与优化

1. 复制延迟（Replication Lag）

原因：网络延迟、主节点负载过高、从节点处理能力不足。
优化：
- 增加从节点数量，分摊读压力。
- 使用高性能网络设备，减少延迟。

2. 主从切换（故障转移）

场景：主节点宕机，哨兵（Sentinel）或集群（Cluster）自动选举新主节点。
问题：新主节点可能未包含所有数据（如未持久化的写命令）。
优化：
- 启用AOF持久化，确保写命令落盘。
- 配置哨兵或集群的故障转移策略（如优先选择数据最新的从节点）。

3. 内存与带宽消耗

全量同步：RDB文件可能占用大量内存和网络带宽（如10GB数据）。
优化：
- 压缩RDB文件（如使用LZ4算法）。
- 限制同时进行全量同步的从节点数量。

七、总结

|----------|---------------------|---------------|-----------------|
| 同步类型 | 触发条件 | 数据传输内容 | 适用场景 |
| 全量同步 | 初次连接、主从断开时间过长、主节点重启 | RDB快照 + 缓冲区命令 | 初次部署从节点、主节点故障恢复 |
| 增量同步 | 主从短暂断开后重新连接 | 复制积压缓冲区的写命令 | 网络波动后的快速恢复 |

在电商高并发场景中，全量同步确保从节点与主节点数据完全一致，而 增量同步 则通过高效的数据传输减少服务中断时间。合理配置 复制积压缓冲区大小 和主从网络环境，可显著提升系统稳定性和性能。

redis的哨兵模式以及集群脑裂

实际场景：电商平台的高并发订单库存管理

场景描述

某电商平台在"双十一大促"期间，订单系统面临极高的并发请求（如每秒数万笔订单创建）。为提升性能，平台采用 Redis哨兵模式 保障库存数据的高可用性。然而，在网络波动或硬件故障时，哨兵模式可能引发 集群脑裂 问题，导致数据不一致甚至服务不可用。以下是详细分析：

一、Redis哨兵模式详解

1. 哨兵模式的核心功能

监控（Monitor） 哨兵（Sentinel）定期检查主节点（Master）和从节点（Slave）的健康状态。例如，哨兵会通过 PING 命令检测主节点是否响应，若连续30秒无响应（默认配置），判定主节点下线。
**自动故障转移（Failover）**当哨兵确认主节点故障时，会从从节点中选举一个新主节点（如从节点S1），并通知其他从节点复制新主节点。例如，原主节点M1宕机后，哨兵将从节点S1升级为新主节点M1'，并更新客户端连接信息。
**通知（Notification）**哨兵通过事件通知机制（如发布订阅）告知客户端主节点变更，确保客户端连接到新的主节点。
**配置提供（Configuration Provider）**客户端通过哨兵获取当前主节点地址，避免直接硬编码主节点IP。

2. 哨兵模式的工作流程

以电商订单库存管理为例：

正常运行
1. 主节点M1处理写请求（如扣减库存），从节点S1、S2同步数据。
2. 哨兵S1、S2、S3监控主从节点状态。
主节点故障
1. 主节点M1因硬件故障宕机，哨兵S1、S2、S3检测到M1未响应。
2. 若配置的 quorum=2（至少2个哨兵同意），哨兵S1、S2判定M1下线。
故障转移
1. 哨兵S1被选为Leader（通过Raft-like投票机制），启动故障转移流程。
2. 从节点S1被选为新主节点M1'，哨兵通知S2、S3切换为主节点M1'的从节点。
3. 客户端通过哨兵更新连接信息，转向新主节点M1'。
原主节点恢复
1. 故障的主节点M1恢复后，哨兵将其降级为从节点，并同步新主节点M1'的数据。

3. 哨兵模式的配置要点

quorum参数 定义多少哨兵同意主节点故障后触发故障转移。例如，quorum=2 表示至少2个哨兵认为主节点下线，才会执行故障转移。作用：防止单个哨兵误判导致的频繁切换。
down-after-milliseconds 定义哨兵判定节点下线的超时时间。例如，down-after-milliseconds=30000 表示连续30秒无响应才判定节点下线。作用：避免短暂网络抖动导致误判。
部署奇数个哨兵推荐部署3个或5个哨兵节点，确保投票时能达成多数派共识。例如，3个哨兵中2个同意故障转移，则触发操作。

二、Redis集群脑裂问题详解

1. 脑裂的定义与危害

脑裂（Split-Brain） 是指Redis集群因网络分区或配置错误，导致多个主节点同时存在，各自处理写请求，引发数据不一致。

危害：

数据不一致：不同主节点可能写入冲突数据（如同一商品库存被多个主节点扣减）。
数据丢失：旧主节点恢复后，其数据可能被新主节点覆盖，导致写入丢失。
服务不可用：客户端可能连接到错误的主节点，导致读取旧数据或写入失败。

2. 脑裂的触发场景

以电商订单系统为例：

网络分区
1. 主节点M1与哨兵S1、S2位于华北机房，哨兵S3位于华南机房。
2. 华北机房与华南机房网络中断，形成两个独立子网。
3. 华北子网中的哨兵S1、S2判定主节点M1下线，选举S1为新主节点M1'。
4. 华南子网中的哨兵S3仍认为M1存活，继续接受写请求。
5. 两个子网各自维护一个主节点（M1'和M1），导致脑裂。
哨兵误判
1. 短暂网络延迟导致哨兵错误判定主节点故障，提前触发故障转移。
2. 原主节点恢复后，新旧主节点并存，形成脑裂。
主从切换异常
1. 故障转移完成后，旧主节点未正确降级为从节点，继续接收写请求。
2. 新旧主节点同时处理写请求，导致数据冲突。

3. 脑裂的解决方案

以电商订单系统为例，通过以下措施降低脑裂风险：

参数优化
1. min-replicas-to-write 配置主节点至少有N个从节点在线时才允许写入。例如，min-replicas-to-write=1 表示主节点必须至少有一个从节点同步，否则拒绝写请求。作用：避免网络隔离期间主节点单独写入数据（如华北子网的M1'）。
2. cluster-node-timeout 缩短节点判定超时时间（如 cluster-node-timeout=5000），加速故障检测。作用：减少网络波动导致的误判。
部署策略
1. 跨区域部署哨兵将哨兵节点分布在不同地理位置（如华北、华南、华东），避免单一机房故障导致脑裂。
2. 奇数哨兵部署3个或5个哨兵，确保投票时能达成多数派共识。
客户端防护
1. 重试机制客户端在写入失败时自动重试，避免因脑裂导致数据丢失。
2. 监控与告警实时监控哨兵和主节点状态，及时发现脑裂风险。
数据修复
1. 手动干预 脑裂发生后，强制下线异常主节点（如使用 SLAVEOF NO ONE 命令），让集群重新选举。
2. 数据比对 使用 redis-check-aof 或 redis-check-rdb 工具比对冲突数据，修复一致性问题。

三、实际场景中的脑裂案例分析

案例背景

某电商平台在"双十一"期间，库存系统使用Redis哨兵模式管理商品库存。主节点M1部署在华北机房，从节点S1、S2部署在华北和华南机房，哨兵S1、S2、S3分别部署在华北、华南、华东。

脑裂触发过程

网络分区
1. 华北与华南机房网络中断，哨兵S1、S2判定M1下线，选举S1为新主节点M1'。
2. 华南机房的哨兵S3仍认为M1存活，继续接受写请求（如用户A下单扣减库存）。
3. 华北机房的M1'也开始处理写请求（如用户B下单扣减库存）。
数据冲突
1. 用户A的订单在华南机房的M1写入库存扣减（库存为999），但未同步到华北机房的M1'。
2. 用户B的订单在华北机房的M1'写入库存扣减（库存为998）。
3. 网络恢复后，哨兵S3发现M1已宕机，M1'成为唯一主节点。M1'的库存数据（998）覆盖M1的数据（999），导致用户A的订单被错误扣减。

解决方案

参数优化
1. 配置 min-replicas-to-write=1，确保主节点至少有一个从节点在线时才允许写入。
2. 调整 down-after-milliseconds=10000，缩短故障判定时间。
部署调整
1. 将哨兵S3部署到华北机房，确保三个哨兵均在华北机房，避免跨区域网络分区。
2. 部署3主3从架构，每个主节点跨区域分布，减少单点故障风险。
客户端防护
1. 客户端增加重试逻辑，写入失败时尝试重新连接哨兵获取最新主节点信息。
2. 使用 WATCH 命令实现乐观锁，避免并发扣减冲突。

四、总结与关键点

|----------|----------------------------------------------------------------------------|
| 知识点 | 详细说明 |
| 哨兵模式 | 通过监控、故障转移、通知和配置提供功能，实现Redis高可用。需合理配置 quorum 和 down-after-milliseconds。 |
| 脑裂成因 | 网络分区、哨兵误判、主从切换异常等导致多个主节点并存。 |
| 脑裂危害 | 数据不一致、数据丢失、服务不可用。 |
| 解决方案 | 参数优化（如 min-replicas-to-write）、部署策略（奇数哨兵、跨区域部署）、客户端防护（重试、乐观锁）。 |

在电商高并发场景中，哨兵模式通过自动故障转移保障服务可用性，但需通过合理配置和部署策略规避脑裂风险，确保库存数据一致性。

redis的分片集群

实际场景：电商平台的高并发订单库存管理

场景描述

某电商平台在"双十一大促"期间，订单系统面临极高的并发请求（如每秒数万笔订单创建）。为提升性能，平台采用 Redis分片集群 管理商品库存数据。以下是分片集群的作用及数据存储与读取的详细解析：

一、Redis分片集群的作用

1. 解决海量数据存储问题

单实例瓶颈：单个Redis实例的内存和性能有限，无法支撑海量数据（如千万级商品库存）。
分片集群方案：
- 将数据划分为 16384个哈希槽（Hash Slot），每个槽对应一个键值对。
- 集群由多个主节点（Master）组成，每个主节点负责一部分哈希槽（例如，节点A负责0-5000槽，节点B负责5001-10000槽）。
- 扩展性：新增节点时，重新分配哈希槽即可扩容，无需停机。

2. 提升高并发写入能力

分布式写入：订单库存操作（如扣减库存）被分散到不同主节点，避免单节点压力过大。
主从架构：每个主节点可配置多个从节点（Slave），从节点处理读请求（如查询库存），主节点专注于写请求（如修改库存），实现读写分离。

3. 高可用性保障

故障转移：若主节点宕机，从节点自动升级为主节点，继续提供服务。
数据冗余：主从节点间实时同步数据，防止单点故障导致数据丢失。

4. 动态负载均衡

槽位再分配：当节点加入或离开集群时，系统自动迁移哈希槽，平衡各节点负载。
客户端智能路由：客户端缓存槽位与节点的映射关系，快速定位数据所在节点。

二、Redis分片集群中数据的存储与读取

1. 数据存储流程

以商品库存键 product:12345:stock 的存储为例：

哈希槽计算
1. 使用 CRC16算法 计算键的哈希值：
  
  暂时无法在飞书文档外展示此内容
2. 对16384取模，确定哈希槽编号：
  
  暂时无法在飞书文档外展示此内容
槽位分配到节点
1. 集群中主节点A负责槽0-5000，主节点B负责5001-10000，主节点C负责10001-16383。
2. 槽123属于主节点A，因此键 product:12345:stock 存储在主节点A。
写入操作
1. 客户端（如订单服务）发送写请求（如 SET product:12345:stock 1000）到主节点A。
2. 主节点A将数据写入内存，并同步到从节点B1、B2。

2. 数据读取流程

以查询商品库存为例：

哈希槽计算
1. 同样计算键 product:12345:stock 的哈希槽为123。
客户端路由
1. 客户端缓存了槽位与节点的映射关系（如槽123→主节点A），直接向主节点A发送读请求。
2. 若客户端缓存未命中（如新加入节点），主节点会返回 MOVED重定向 响应，告知客户端正确的节点地址。
读取操作
1. 客户端连接主节点A，执行 GET product:12345:stock，获取库存值。
2. 若主节点A宕机，客户端会自动连接从节点B1或B2读取数据。

三、关键机制详解

1. 哈希槽与槽分配

哈希槽数量：固定16384个槽，确保均匀分布。
槽分配规则：
- 集群创建时，使用 CLUSTER ADDSLOTS 命令将槽分配给主节点。
- 动态调整时，通过 CLUSTER SETSLOT 迁移槽位，实现平滑扩容。

2. 客户端路由与重定向

Smart Client：
- 客户端（如JedisCluster）维护槽位与节点的映射表，避免重复查询。
- 当槽位分配变化时，主节点返回 MOVED 响应，客户端更新映射表并重试。
示例：
- 客户端误将请求发送到主节点B（负责5001-10000槽），主节点B检测到键 product:12345:stock 属于主节点A，返回 MOVED 123 192.168.1.10:6379，客户端转向主节点A。

3. 数据迁移与一致性

迁移过程：
- 源节点（旧主节点）逐步将槽内的键同步到目标节点（新主节点）。
- 客户端在迁移期间可能收到 ASK 重定向，临时转向目标节点。
一致性保障：
- 使用 复制机制 确保迁移中数据不丢失。
- 通过 CAS（Compare and Set） 操作避免并发冲突。

4. 故障转移与高可用

故障检测：
- 节点通过心跳包（Ping/Pong）监测彼此状态。
- 若主节点失联超过 cluster-node-timeout（如30秒），集群发起故障转移。
从节点选举：
- 从节点通过Raft协议投票选出新主节点，继承原主节点的槽位和数据。
- 新主节点继续处理请求，从节点同步其数据。

四、电商场景中的实践案例

案例背景

某电商平台在"双十一"期间，商品库存数据量达 1000万条，每秒订单请求量 10万次。采用 3主3从分片集群（每个主节点负责5461槽），部署在三个可用区（Zone A、B、C）。

数据存储实践

键设计：
- 商品库存键格式：product:{id}:stock（如 product:10001:stock）。
- 使用 {id} 作为哈希标签（Hash Tag），确保同商品库存的键分配到同一槽。
槽分配：
- 主节点A（Zone A）负责0-5460槽。
- 主节点B（Zone B）负责5461-10922槽。
- 主节点C（Zone C）负责10923-16383槽。

高并发读写优化

写操作：
- 订单服务将库存扣减请求（如 DECR product:10001:stock）路由到对应主节点。
- 主节点处理写请求后，同步到从节点，确保副本一致性。
读操作：
- 库存查询请求由从节点处理（如 GET product:10001:stock），降低主节点压力。
- 客户端使用 Read From Replicas 策略，随机选择从节点读取数据。

故障恢复

主节点宕机：
- Zone A的主节点A因硬件故障宕机，集群自动将从节点A1升级为新主节点A'。
- 新主节点A'继承原主节点A的槽位（0-5460），继续处理请求。
数据恢复：
- 原主节点A恢复后，作为从节点加入集群，同步新主节点A'的数据。

五、总结

|-------------|--------------------------------|
| 功能 | 实现方式 |
| 海量数据存储 | 16384哈希槽 + 多主节点分片，均匀分布数据。 |
| 高并发写入 | 写请求分散到多个主节点，主从架构分担读压力。 |
| 高可用性 | 故障转移机制 + 主从数据同步，确保服务连续性。 |
| 动态扩展 | 槽位迁移 + 客户端重定向，支持无缝扩容。 |
| 客户端智能路由 | 缓存槽位映射表 + MOVED/ASK重定向，减少网络延迟。 |

在电商高并发场景中，Redis分片集群通过 哈希槽分区 和 主从架构 实现数据的分布式存储与高可用读写，有效应对海量数据和高频操作的挑战。

Redis的速度

Redis 之所以在单线程模型下依然能实现极高的性能，主要得益于以下几个核心设计和优化策略。以下从 技术原理 和 实际场景 两个维度进行详细讲解：

一、单线程模型的核心优势

1. 避免线程切换和锁竞争

单线程的本质 ：Redis 的核心网络 I/O（接收请求、处理命令、返回响应）和数据操作（如 SET、GET）完全由 一个主线程 串行执行。
- 无上下文切换：多线程模型中，线程切换需要保存寄存器状态、栈信息等，带来额外开销。Redis 的单线程完全避免了这一问题。
- 无需锁竞争 ：多线程环境中，多个线程同时操作共享资源时需要加锁（如 mutex），而锁的获取和释放会引发性能损耗。Redis 的单线程模型天然避免了锁竞争问题。

2. 顺序执行保证原子性

命令的串行化 ：Redis 的所有命令按顺序执行，无需额外的原子性保障（除了 MSET、INCR 等原子操作）。
- 避免指令重排：多线程中，指令重排可能导致数据不一致，而单线程模型确保命令严格按顺序执行。
- 简化开发复杂度：开发者无需考虑线程安全问题，代码逻辑更清晰。

3. CPU 不是瓶颈

内存操作主导性能 ：Redis 的性能瓶颈在于 内存访问速度 和网络带宽，而非 CPU 计算能力。
- 内存的高速特性：现代服务器内存的读写速度可达 100,000+ 次/秒（纳秒级延迟），远高于磁盘 I/O。
- CPU 利用率低：Redis 的 CPU 使用率通常较低（如 10%-30%），剩余 CPU 资源可分配给其他任务（如持久化、异步删除等）。

二、高性能的底层技术支撑

1. 内存存储与高效数据结构

纯内存操作：Redis 将所有数据存储在内存中，避免了磁盘 I/O 的延迟（磁盘随机读写延迟约为毫秒级，而内存为纳秒级）。
- 典型场景：
  - 电商库存查询 ：商品库存的 GET 请求在内存中直接完成，无需等待磁盘读取。
  - 实时排行榜 ：使用 ZSET（有序集合）维护实时排名，内存中的跳表（SkipList）结构支持高效插入和查询。
优化的数据结构：Redis 提供了多种数据结构（字符串、哈希表、列表、集合、有序集合等），每种结构针对特定场景进行了优化。
- 字符串（String）：采用预分配空间的 SDS（Simple Dynamic String）结构，减少内存碎片。
- 哈希表（Hash）：使用双哈希表实现渐进式 rehash，避免阻塞。
- 有序集合（ZSET） ：底层使用跳表（SkipList），查询复杂度为 O(logN)，性能接近平衡树。

2. 非阻塞 I/O 与 I/O 多路复用

非阻塞 I/O 模型 ：Redis 使用 事件驱动 的非阻塞 I/O 模型，通过 I/O 多路复用（如 Linux 的 epoll）监听多个客户端连接。
- 工作原理：
  - 客户端连接到达时，Redis 通过 epoll 监听事件（如 readable 或 writable）。
  - 当某个连接准备好读写时，epoll 通知 Redis 主线程处理该连接的请求。
  - 主线程按顺序处理所有事件，无需为每个连接创建独立线程。
- 优势：
  - 高并发支持：单线程可处理数万并发连接（如 10,000+ QPS）。
  - 减少资源消耗：避免线程池中大量线程的创建和销毁开销。
事件循环机制：Redis 使用 Reactor 模型（事件驱动架构），通过事件循环（Event Loop）管理所有 I/O 事件。
- 事件类型：
  - 文件事件（File Events）：处理客户端连接、读写请求。
  - 时间事件（Time Events）：定时任务（如过期键清理）。
- 实际场景：
  - 高并发秒杀：在双十一期间，数万用户同时下单，Redis 通过 I/O 多路复用快速响应每个请求。
  - 消息队列 ：使用 PUB/SUB 或 Stream 数据结构，通过事件驱动高效推送消息。

3. 异步任务与多线程辅助

多线程处理后台任务：Redis 6.0+ 引入多线程支持，但命令执行仍由主线程串行处理。
- 异步任务示例：
  - 持久化（RDB/AOF） ：通过子进程或线程执行 bgsave 和 bgrewriteaof，避免阻塞主线程。
  - 大 Key 删除 ：使用 UNLINK 命令异步删除大对象（如大 Hash），减少主线程阻塞时间。
  - 集群同步：主从节点间的数据复制通过后台线程完成。
- 实际场景：
  - 数据备份：在夜间低峰期执行 RDB 快照，子进程负责持久化，主线程继续处理请求。
  - 缓存清理 ：使用 UNLINK 删除大 Key（如 product:12345:stock:history），避免阻塞主线程。

三、性能优化的关键策略

1. 避免阻塞操作

长耗时命令限制 ：Redis 严格禁止执行可能导致主线程阻塞的操作（如 KEYS *、FLUSHALL）。
- 替代方案：
  - 批量扫描 ：使用 SCAN 代替 KEYS 分批处理数据。
  - 异步删除 ：使用 UNLINK 替代 DEL 删除大 Key。
实际场景：
- 库存统计 ：使用 SCAN 遍历商品库存键，避免一次性加载所有数据。
- 日志清理 ：定期使用 UNLINK 删除过期订单日志，避免阻塞主线程。

2. 合理配置参数

调整 maxmemory 和淘汰策略：
- 内存上限 ：设置 maxmemory 防止内存溢出。
- 淘汰策略 ：选择 LFU（最近最少使用）或 TTL（基于过期时间）策略，确保高频数据优先保留。
实际场景：
- 热点商品缓存：设置较短的 TTL，自动淘汰冷数据，保留热门商品库存信息。
- 限流计数器 ：使用 INCR + EXPIRE 维护限流计数器，避免内存无限增长。

3. 利用多实例分片

多实例扩展 ：虽然 Redis 单线程无法充分利用多核 CPU，但可以通过部署 多个 Redis 实例 实现横向扩展。
- 分片集群：使用 Redis Cluster 将数据分片到多个实例，每个实例独立运行单线程。
- 代理中间件 ：通过 Codis 或 Twemproxy 代理请求到不同实例。
实际场景：
- 分布式锁 ：使用 Redlock 算法跨多个 Redis 实例实现高可用分布式锁。
- 多业务隔离：电商系统将商品库存、用户会话、订单计数器分别部署在不同 Redis 实例中。

四、单线程模型的局限性与适用场景

1. 局限性

无法充分利用多核 CPU：单线程模型受限于 CPU 单核性能，无法发挥多核优势。
- 解决方案：通过部署多个 Redis 实例或使用 Redis Cluster 分片集群。
长耗时命令影响性能 ：如 KEYS *、SORT 等命令可能导致主线程阻塞。
- 解决方案 ：使用 SCAN、ZUNIONSTORE 等替代方案，或拆分大 Key。

2. 适用场景

高并发、低延迟场景：
- 缓存服务：如商品详情、用户会话的快速读写。
- 计数器：如网站访问量统计、限流控制。
- 消息队列：如实时聊天、任务分发。
非 CPU 密集型任务：
- 数据过滤 ：如通过 BITMAP 统计用户行为。
- 分布式锁 ：如通过 SETNX 实现分布式锁。

五、总结

|---------------|--------------------------------------------|
| 核心特性 | 作用 |
| 单线程模型 | 避免线程切换和锁竞争，确保命令顺序执行，简化开发复杂度。 |
| 内存存储 | 数据直接存储在内存中，读写速度远超磁盘 I/O。 |
| 非阻塞 I/O 与多路复用 | 通过 epoll 实现高并发连接处理，单线程可支持数万 QPS。 |
| 高效数据结构 | 优化的字符串、哈希表、跳表等结构，降低时间复杂度。 |
| 异步任务与多线程辅助 | 持久化、大 Key 删除等操作由子进程或线程完成，避免阻塞主线程。 |
| 多实例分片 | 通过部署多个 Redis 实例或使用 Cluster 分片集群，突破单线程性能瓶颈。 |

在实际场景中，Redis 的单线程模型通过 内存操作、事件驱动、无锁设计 等策略，实现了 高吞吐、低延迟 的性能表现。尽管存在多核利用率低的局限性，但通过合理分片和异步任务处理，仍能满足大多数高并发业务需求。

redis的IO多路复用

实际场景：电商平台的秒杀活动

假设某电商平台在"双十一"期间推出限量商品秒杀活动，瞬间涌入数万用户同时抢购，服务器需要处理大量并发请求（如查询库存、扣减库存）。此时，Redis 使用 I/O 多路复用 技术高效管理网络连接和数据操作，确保高吞吐和低延迟。以下是详细解析：

一、场景中的挑战

高并发请求
1. 秒杀开始后，数万用户同时访问服务器，发送 GET（查询库存）和 DECR（扣减库存）请求。
2. 传统单线程阻塞模型（如逐个处理请求）会导致服务器响应缓慢，甚至崩溃。
资源限制
1. 每个请求需要一个独立线程处理，线程切换和锁竞争会消耗大量 CPU 和内存资源。
2. 例如，10,000 个并发请求需要创建 10,000 个线程，系统资源难以支撑。
延迟敏感
1. 用户对响应速度要求极高，延迟超过 1 秒可能导致订单失败或用户体验下降。

二、Redis 的 I/O 多路复用解决方案

1. 核心机制：事件驱动与非阻塞 I/O

Redis 通过 I/O 多路复用（如 Linux 的 epoll）实现单线程事件循环，高效管理多个并发连接。以下是关键步骤：

步骤 1：注册监听事件

文件描述符（FD） 每个客户端连接对应一个文件描述符（FD），Redis 将所有 FD 注册到 epoll 监听器中。
- 示例：
  - 客户端 A 连接 Redis，分配 FD=10。
  - 客户端 B 连接 Redis，分配 FD=11。
  - Redis 调用 epoll_ctl 将 FD=10 和 FD=11 注册到 epoll 实例，监听 readable（可读）和 writable（可写）事件。

步骤 2：事件等待与分发

事件等待 Redis 主线程调用 epoll_wait 等待事件，阻塞直到有事件就绪。
- 优势：
  - 避免轮询（如 select 的 O(n) 复杂度），epoll 直接返回就绪事件列表（O(1) 复杂度）。
  - 例如，10,000 个连接中只有 100 个活跃时，epoll 直接返回这 100 个事件，而传统模型需遍历全部 10,000 个连接。
事件分发 当事件发生（如客户端发送请求），epoll 将事件分发到 Redis 的事件循环中。
- 示例：
  - 客户端 A 发送 GET product:12345:stock 请求，FD=10 变为 readable。
  - Redis 事件循环检测到 FD=10 有数据可读，调用对应的命令处理器（如 GET 的解析逻辑）。

步骤 3：非阻塞处理

非阻塞 I/O Redis 的网络 I/O 操作（如 read 和 write）设置为非阻塞模式，避免因单个请求阻塞整个线程。
- 示例：
  - 客户端 C 发送大请求（如批量 DECR），Redis 主线程调用 read 读取数据，若数据未完全到达，立即返回 EAGAIN 错误，继续处理其他事件。
  - 客户端 D 的响应数据未完全发送，Redis 调用 write 返回 EAGAIN，稍后重试。
避免长耗时操作 Redis 严格禁止执行可能导致主线程阻塞的操作（如 KEYS *），确保事件循环的高效性。
- 替代方案：
  - 使用 SCAN 分批查询键。
  - 使用 UNLINK 异步删除大 Key。

步骤 4：处理业务逻辑

内存操作 Redis 的核心数据操作（如 GET、DECR）基于内存，响应速度极快（纳秒级）。
- 示例：
  - 客户端 A 的 GET product:12345:stock 请求直接从内存中读取库存值。
  - 客户端 B 的 DECR product:12345:stock 请求原子性扣减库存，避免并发冲突。
原子性保障 Redis 的单线程模型天然支持命令的串行化，确保 DECR 等操作的原子性，无需额外锁机制。

步骤 5：响应客户端

事件回调 Redis 主线程将响应结果写入客户端的 FD，触发 writable 事件。
- 示例：
  - 客户端 A 的 GET 响应写入 FD=10，epoll 监听到 writable 事件，通知 Redis 发送数据。
  - 客户端 B 的 DECR 响应写入 FD=11，立即返回操作状态（如 OK）。

三、与传统模型的对比

|----------|--------------------------|------------------------------------|
| 模型 | 传统多线程模型 | Redis I/O 多路复用模型 |
| 资源消耗 | 每个连接需独立线程，线程切换和内存占用高。 | 单线程管理数万连接，资源消耗极低（内存占用仅为 1/100）。 |
| 性能瓶颈 | 线程切换开销大，锁竞争导致延迟。 | 无线程切换和锁竞争，吞吐量更高（100,000+ QPS）。 |
| 扩展性 | 线程数量受限于 CPU 核心数，难以横向扩展。 | 通过部署多个 Redis 实例或使用 Cluster 分片集群扩展。 |
| 适用场景 | 低并发、CPU 密集型任务（如计算密集型应用）。 | 高并发、I/O 密集型任务（如缓存、消息队列、限流）。 |

四、Redis 6.0 的多线程优化

背景Redis 6.0 引入多线程网络 I/O，但仍保持单线程处理业务逻辑，避免锁竞争。
- 默认配置：
  - 网络读写启用多线程（io-threads 4）。
  - 读操作默认不启用多线程（io-threads-do-reads no），因为读性能提升有限。
实际场景中的优化
- 网络读写并行化：
  - 秒杀活动中，客户端请求和响应通过多线程处理，减少主线程阻塞时间。
  - 例如，10,000 个并发请求的网络读写由 4 个线程并行处理，主线程专注于内存操作。
- CPU 利用率提升：
  - 多线程利用多核 CPU，降低网络 I/O 的延迟（如从 1ms 降至 0.5ms）。

五、总结

在秒杀场景中，Redis 的 I/O 多路复用 技术通过以下方式实现高性能：

事件驱动：单线程事件循环处理数万并发连接，避免线程切换和锁竞争。
非阻塞 I/O ：结合 epoll 和 O(1) 事件检测，快速响应活跃连接。
内存操作 ：基于内存的原子性命令（如 DECR）确保低延迟和高吞吐。
多线程优化：Redis 6.0 通过多线程处理网络 I/O，进一步降低延迟。

这一设计使 Redis 在单线程模型下仍能支撑高并发、低延迟的业务需求，成为电商、社交平台等场景的核心组件。

redis网络模型

Redis 的网络模型是其高性能的核心设计之一，结合了 单线程模型 和 I/O 多路复用技术，能够在单线程下高效处理数万并发连接。以下是其网络模型的详细讲解：

一、Redis 网络模型的核心设计

Redis 的网络模型基于 事件驱动 和非阻塞 I/O，通过 I/O 多路复用（如 Linux 的 epoll）实现高并发连接的管理。其核心目标是：

避免线程切换开销：通过单线程处理所有请求，减少上下文切换和锁竞争。
高效管理大量连接：利用 I/O 多路复用技术，同时监听多个客户端连接的读写事件。
内存操作优化：所有数据存储在内存中，避免磁盘 I/O 延迟。

二、I/O 多路复用的实现

I/O 多路复用是 Redis 高性能的关键，其原理是：

一个线程监听多个文件描述符（FD），当某个 FD 准备好读写时，通知线程进行处理。
Redis 根据操作系统选择最优的实现方式：
- Linux ：使用 epoll（边缘触发模式，ET）。
- macOS/FreeBSD ：使用 kqueue。
- 其他平台 ：使用 select 或 poll（性能较低）。

1. epoll 的工作流程

以 Linux 的 epoll 为例，Redis 的网络模型包含以下步骤：

创建 epoll 实例 ：Redis 启动时通过 epoll_create 创建一个 epoll 实例，用于监听所有客户端连接。
注册监听事件：
1. 将服务端 socket（监听端口）注册到 epoll 中，监听 EPOLLIN（可读事件）。
2. 当客户端连接到达时，通过 accept 获取客户端 socket，并将其注册到 epoll 中，绑定读处理器（readQueryHandler）。
等待事件触发 ：Redis 主线程调用 epoll_wait 阻塞等待事件，仅当有客户端连接或数据可读时才被唤醒。
处理事件：
1. 读事件：客户端发送请求时，epoll 通知 Redis 读取数据，解析命令并执行。
2. 写事件 ：将响应结果写回客户端（如 sendReplyToClient）。

2. 事件驱动的处理链

Redis 定义了三类核心处理器，构成事件处理链：

TCP 连接处理器（acceptTcpHandler）
1. 监听服务端 socket 的 EPOLLIN 事件，处理新客户端连接。
2. 接受连接后，将客户端 socket 注册到 epoll 中，并绑定读处理器。
命令请求处理器（readQueryFromClient）
1. 监听客户端 socket 的 EPOLLIN 事件，读取请求数据并解析命令。
2. 将命令加入队列，由主线程按顺序执行。
响应输出处理器（sendReplyToClient）
1. 监听客户端 socket 的 EPOLLOUT 事件，将执行结果写入客户端。

三、单线程模型的优势

Redis 的核心命令执行逻辑始终由 单线程 处理，这是其性能的关键：

避免线程竞争和锁开销
1. 单线程天然避免了多线程环境下的锁竞争和上下文切换开销。
2. 所有命令按顺序串行执行，无需额外同步机制。
保证原子性
1. 单线程模型确保每个命令的执行是原子的（如 INCR、DECR），无需担心并发修改问题。
CPU 缓存利用率高
1. 单线程避免了核心切换，L1/L2 缓存命中率高，减少内存访问延迟。

单线程的局限性

无法利用多核 CPU：单线程受限于 CPU 单核性能，无法发挥多核优势。
长耗时命令影响性能 ：如 KEYS *、FLUSHALL 等命令可能导致主线程阻塞。

四、Redis 6.0 的多线程优化

为突破单线程的性能瓶颈，Redis 6.0 引入了多线程网络 I/O，但核心命令仍由单线程执行：

网络 I/O 多线程化
1. 网络读写（如 read 和 write）由多个线程并发处理，减少主线程阻塞时间。
2. 默认启用 4 个 I/O 线程（可通过 io-threads 配置）。
保留单线程命令执行
1. 多线程仅处理网络 I/O，命令解析和执行仍由主线程完成，避免锁竞争。
适用场景
1. 适合高并发、低延迟的场景（如缓存、消息队列），但不适合 CPU 密集型任务。

五、网络模型的处理流程

1. 客户端连接建立

客户端发起连接请求，Redis 监听 socket 捕获 EPOLLIN 事件。
通过 accept 接受连接，获取客户端 socket 并注册到 epoll 中。

2. 请求处理

客户端发送请求（如 GET key），epoll 触发 EPOLLIN 事件。
Redis 读取数据并解析命令，将命令加入执行队列。
主线程按顺序执行命令（如查询内存中的 key）。

3. 响应返回

命令执行完成后，结果写入客户端 socket 的缓冲区。
epoll 触发 EPOLLOUT 事件，Redis 将响应数据发送给客户端。

六、与传统模型的对比

|----------|--------------------------|--------------------------|
| 模型 | 传统多线程模型 | Redis 网络模型 |
| 资源消耗 | 每个连接占用一个线程，资源消耗高。 | 单线程处理数万连接，资源消耗极低。 |
| 性能瓶颈 | 线程切换和锁竞争导致延迟。 | 无线程切换和锁竞争，吞吐量更高。 |
| 扩展性 | 难以横向扩展，受限于线程数量。 | 通过部署多个实例或分片集群扩展。 |
| 适用场景 | 低并发、CPU 密集型任务（如计算密集型应用）。 | 高并发、I/O 密集型任务（如缓存、消息队列）。 |

七、实际应用场景

高并发缓存服务
1. 如电商秒杀活动，Redis 通过 I/O 多路复用同时处理数万并发请求。
实时消息推送
1. 使用 PUB/SUB 或 Stream 数据结构，通过事件驱动高效推送消息。
分布式锁
1. 通过 SETNX 实现分布式锁，利用单线程原子性保障锁的安全性。

八、总结

Redis 的网络模型通过 单线程 + I/O 多路复用 的设计，实现了高并发、低延迟的性能表现：

I/O 多路复用 （如 epoll）高效管理大量连接，避免阻塞。
事件驱动 按需处理读写事件，减少资源浪费。
单线程模型 避免锁竞争和上下文切换，保证命令的原子性和性能。
多线程网络 I/O（Redis 6.0+）进一步优化网络延迟，提升吞吐量。

这一设计使 Redis 在单线程模型下仍能支撑大规模高并发场景，成为高性能键值存储系统的标杆。

Redis 缓存穿透

实际场景：电商商品查询中的缓存穿透问题

场景描述

解决方案详解

1. 布隆 过滤器 （Bloom Filter ）

2. 缓存 空值 （ Null Caching）

3. 接口层校验（ID合法性检查）

4. 综合方案：多层防护

总结

缓存击穿

实际场景：电商热销商品详情页查询中的缓存击穿问题

场景描述

解决方案详解

1. 互斥锁（Mutex Lock）

2. 逻辑过期（Logical Expiration）

对比与适用场景

总结

缓存雪崩

实际场景：电商促销活动中的缓存雪崩问题

场景描述

解决方案详解

1. 给不同的 Key 的 TTL 添加随机值

2. 利用 Redis 集群提高服务的可用性

3. 给缓存业务添加降级限流策略

4. 给业务添加多级缓存

总结：多策略协同抵御缓存雪崩

redis数据与mysql数据进行同步

实际场景：电商平台的商品库存与缓存同步

场景描述

核心问题

解决方案详解

一、强一致性业务的解决方法

场景：秒杀商品库存扣减

解决方案：使用分布式锁

实现步骤：

优点：

缺点：

二、允许延时一致的业务解决方法

场景：商品详情页信息同步

解决方案：异步通知 + 延迟补偿

实现步骤：

优点：

缺点：

总结：不同场景的同步策略

选择建议

实际应用中的权衡

redis的持久化：RDB和AOF

实际场景：电商平台的高并发秒杀活动

场景描述

一、RDB（Redis Database）快照持久化

1. 工作原理

2. 在秒杀场景中的表现

3. 优点与缺点

4. 适用场景

二、AOF（Append Only File）日志持久化

1. 工作原理

2. 在秒杀场景中的表现

3. 优点与缺点

4. 适用场景

三、混合持久化（Redis 4.0+）

1. 工作原理

2. 在秒杀场景中的表现

3. 优点与缺点

4. 适用场景

四、场景对比与选择建议

五、总结

redis的数据过期策略：惰性删除和定期删除

实际场景：电商平台的用户会话缓存管理

场景描述

一、Redis的过期策略概述

二、惰性删除（Lazy Expiration）

1. 触发时机

2. 执行流程

3. 优点与缺点

4. 应用场景

三、定期删除（Active Expiration）

1. 触发时机

2. 执行流程

3. 优点与缺点

1. 布隆过滤器（Bloom Filter ）

2. 缓存空值（ Null Caching）