Redis

可以查看我的 redis 相关博客 ，当前主要讲述 redis 的部署方式：单机、主从、哨兵、集群、缓存删掉的时机，可视化工具推荐 Redis-Insight(windows 版本)

单机

• 简单易用：配置简单，运维成本低
• 性能优秀: 无网络开销，响应速度快
• 资源占用少: 只需要一台服务器

场景

• 开发测试环境
• 小型应用或个人项目对可用性要求不高的场景
• 缓存数据可以接受丢失的业务

局限性

• 单点故障: 服务器宕机导致服务不可用
• 效据丢失: 硬件故障可能导致数据永久丢失
• 维护窗口: 升级维护时服务必须停止
• 内存限制: 受单机内存容量限制
• CPU 瓶颈: 单线程模型在高并发下性能受限
• 网络带宽: 单机网络 10 成为瓶颈
• 扩展性差: 无法水平扩展，只能垂直扩展

主从模式

• 读写分离: 主节点处理写操作，从节点处理读接作
• 数据冗余: 多个节点保存相同数据
• 故障恢复: 主节点故障时可手动切换到从节点
• 主从复制
  • 节点连接主节点
  • 主节点生成 RDB 快照发送给从节点
  • 从节点加载 RDB 文件
  • 主节点将写命令同步给从节点

适用场景 : 读多写少的业务，对可用性有一定要求但可接受短暂停服。

特点

• 优点
  • 提升读性能: 多个从节点分担读请求
  • 数据备份: 从节点作为数据备份
  • 故障恢复: 主节点故障时可切换到从节点
• 缺点
  • 手动故障转移: 需要人工介入进行主从切换
  • 数据一致性: 异步复制可能导致数据丢失
  • 写性能瓶颈: 所有写操作仍集中在主节点

哨兵模式

• Redis 主从节点：数据存储和处理
• Sentinel 节点：监控、通知、故障转移
• 客户端：通过 Sentinel 获取主节点信息

特点

• 监控: 检查主从节点是否正常工作
• 通知: 通过 API 通知管理员故障信息
• 故降转移: 自动进行主从切换
• 配置提供: 为客户端提供当前主节点信息

工作原理

• 故障检测
  • 哨兵定期 ping 主节点
  • 超时未响应标记为主观下线
  • 多个哨兵确认后标记为客观下线
• 故障转移
  • 选举领导者哨兵
  • 从从节点中选择新的主节点
  • 将其他从节点指向新主节点
  • 通知客户端新的主节点信息

优缺点

• 优点
  • 自动故障转移: 无需人工干预
  • 高可用性: 故障恢复时间短
  • 配置简单: 相对容易部署和维护
• 缺点
  • 资源开销: 需要额外的哨兵节点
  • 脑裂风险: 网络分区可能导致多个主节点
  • 写性能限制: 仍然是单主架构

cluster 集群

核心特性

• 数据分片: 将数据分布到多个节点
• 无中心架构: 节点间直接通信，无需代理
• 自动故障转移: 内置高可用机制
• 水平扩展: 支持动态添加和删除节点
• 分片算法
  • 使用 CRC16 算法计算 key 的哈希值
  • 将哈希值对 16384 取模得到 slot
  • 每个节点负责一部分 slot

适用场景 : 大规模、高并发、对可用性要求极高的业务系统。

优缺点

• 优点
  • 水平扩展: 可以线性扩展到 1000 个节点
  • 高可用性: 自动故障检测和转移
  • 高性能: 读写操作分布到多个节点
  • 无单点故障: 去中心化架构
• 缺点
  • 复杂性高: 部署和运维复杂
  • 功能限制:: 不支持多 key 操作和事务
  • 网络开销: 节点间通信增加延迟
  • 数据倾斜: 可能出现热点数据问题

项目部署选择

• 阶段一: 单机部署 (用户量 <1 万)
  • 开发、测试简单缓存场景，主要缓存用户会话和热点数据
  • 配置: 单台 4 核 8G 服务器，Redis6.0
• 阶段二: 主从 + 哨兵 (用户量 1 -10 万)
  • 主从：小型项目，哨兵：中型项目
  • 业务增长，对可用性要求提高
  • 配置:1 主 2 从 + 3 哨兵，读写分离
• 阶段三:RedisCluster(用户量 >10 万)
  • 大型项目
  • 数据量激增，单机内存不足
  • 配置:6 节点集群 (3 主 3 从)，每节点 16G 内存

运维

• 监控内存使用率、连接数、命令执行时间
• 定期备份数据
• 合理设置过期策略
• 做好容量规划

总结: 选择合适的 Redis 部署架构是系统设计的重要环节，需要根据业务特点和发展阶段来决策。

内存缓存删除机制

• 惰性删除
  • 只有在读取 key 时才检查是否过期，过期则删除并返回 nil，未过期则返回真实值，优点是省 CPU，缺点是可能导致内存泄露。
• 定期删除
  • 定期检查过期 key 并删除，优点是能清理大部分赖着不走的 key，缺点是随机且不能太频繁，否则会消耗 CPU
• 内存淘汰机制
  • 当内存达到最大值时，触发淘汰策略，牺牲部分 key 给新数据腾地方，具体策略可选择，如 volatile rlu、LRU 或 Random

有 1 亿个 key，如何找出特定前缀的 key

测试环境使用 KEYS “prefix:*”

• KEYS 命令的执行机制:Redis 是单线程模型，KEYS 命令会全量遍历 Redis 库中所有 key，1 亿 key 的遍历会导致数十秒甚至数分钟的卡顿
• 生产环境风险: 依赖 Redis 的服务会因 KEYS 命令的阻塞超时，甚至引发服务雪崩，造成生产级事故
• 适用场景限制: 仅可在调试或 key 总量很少的情况下使用

SCAN O MATCH “prefix:*”

• SCAN 命令的特点: 非阻塞式、渐进式迭代，不会一次性返回所有结果
• SCAN 的执行方式: 通过游标分批次返回结果 (如每次取 100 条，下一次用前一次返回的游标继续)，对业务影响可忽略
• SCAN 是安全可靠的标准答案，解决了 KEYS 命令的阻塞问题

用 Set 做索引

Redis 中查询特定前缀 key 的加分方案是使用 Set 维护前缀索引

• 实现方式: 写入 key 时，除存储原始 key-value 外，将前缀作为 key 创建 Set 索引 (如用 SADD 命令将 key 添加到 index:prefix 的 Set 中) —– SADD “index:prefix”“key1”
• 查询优势: 直接使用 SMEMBERS 命令查询 Set 索引，无需扫描全库，性能极高 —— SMEMBERS “index:prefix“
• 优缺点: 优点是查询高效，缺点是增加了写入 / 删除的复杂度，需额外内存存储索引