00-Redis 你真的了解吗?

本文将探讨Redis的数据类型及其底层实现,包括选择数据类型的最佳实践,解析Redis的高性能原因及单线程设计背后的考量。同时,我们将详细解析Redis的持久化机制、主从同步过程、哨兵模式以及集群分布。此外,还将讨论Redis的淘汰策略、一致性问题、作为消息队列的角色、Key监听、数据倾斜解决方案、分布式锁的实现以及库存扣减、限流和聚合统计的方法。通过本文,你将对Redis有更全面深入的理解。

大家好 ,我是飓风
redis是大家用的非常广泛的分布式缓存系统,我相信大家都能熟练的去使用它,因为他有丰富的数据类型供我们去使用,以及主从模式、哨兵模式、集群模式、持久化等丰富功能。但是你知道:
- 数据类型的底层数据结构是什么吗? 
- 什么样的场景应该选择什么数据类型? 
- 为什么要这么选择? 
- redis 快速的原因是什么? 
- redis 为什么要采用单线程?
- reids 都包含哪些线程?各自的职责是什么?
- redis 持久化的原理是什么?持久化会影响redis性能吗?
- redis 主从同步过程中都发生了什么? 如果网关抖动或者断开了,redis 会采用什么措施?
- redis 哨兵模式是怎么监听节点实例的?怎么选主的? 
- redis cluster 是怎么确定一个key 到 实例的?
- redis 淘汰策略?
- redis 能够保证原子性吗?
- redis 雪崩 、穿透、击穿 到底怎么解决?
- reids 和 数据库的 一致性,到底是删除缓存 还是更新缓存 等等?
- redis 能做消息队列吗?
- redis 如何做key 的 监听?
- redis 如果出现数据倾斜了怎么办?
- redis 如何实现分布式锁? 分布式锁应具备哪些特征?
- redis 如何实现库存的扣减?
- redis 如何做分布式限流?
- redis 如何做聚合统计?

接下来的文章 我们来一起学习吧。

<think>嗯,用户问的是Redis过期键是否会在过期时间到达时立刻删除。这个问题看似简单,但背后涉及Redis的核心机制,需要结合内存管理和性能优化来解释。用户可能正在开发需要精确控制内存的应用程序,或者遇到了内存异常增长的问题。从问题表述看,用户对Redis有一定了解,但可能被“立刻删除”的直觉概念迷惑了。需要帮ta区分理论上的过期时间和实际删除时机的差异。参考引用材料,Redis确实不会立刻删除过期键。引用[2]提到Redis采用“定时删除+惰性删除”双策略,引用[3]的惰性删除代码示例显示删除动作实际发生在键被访问时。引用[5]更明确指出定时删除会消耗过多CPU,因此Redis选择折中的定期删除。用户可能没意识到的深层问题是:为什么Redis不采用实时删除?这需要解释设计权衡——引用[3]提到时间轮和优先级队列的局限性,引用[5]强调CPU与内存的平衡。比如电商系统每秒百万请求的场景,实时删除会导致性能骤降。还应该补充用户没问但重要的点:过期键对持久化的影响。引用[5]提到RDB和AOF的处理差异,比如RDB文件不会保存过期键,但主从复制时从库会等待主库的DEL命令。最后用场景化说明会更直观:假设用户设置了session键10分钟过期,如果该键之后从未被访问,可能要到定期删除轮询时才清理。但这对业务通常无害,因为新请求自然会触发惰性删除。</think>Redis 过期键**不会在过期时间到达时立刻被删除**。它采用惰性删除和定期删除两种策略协同工作,确保在内存回收和性能之间取得平衡[^2][^3][^5]。 --- ### Redis 过期键删除机制详解 #### 1. **惰性删除(Lazy Expiration)** - **触发时机**:仅当客户端尝试访问某个键时(如 `GET key`)。 - **执行逻辑**: 1. 检查该键是否在过期字典(`expires`)中且过期时间已到。 2. 若过期则立即删除,返回空值;否则返回键值。 - **伪代码逻辑**: ```python def get_key(key): if key in expires_dict and expires_dict[key] < current_time: delete_key(key) # 删除过期键 return None return data_dict[key] # 返回键值 ``` - **优点**:对 CPU 友好,无额外开销。 - **缺点**:若过期键长期不被访问,会持续占用内存(内存泄漏风险)[^3][^5]。 #### 2. **定期删除(Active Expiration)** - **触发时机**:Redis 周期性执行(默认每秒 10 次,由 `hz` 参数控制)。 - **执行流程**: 1. 从过期字典中**随机抽取 N 个键**(默认 `N=20`)。 2. 检查并删除其中已过期的键。 3. 若本轮过期键占比 **>25%**,则重复步骤 1-2,直到比例 **<25%** 或达到时间上限。 - **优点**:主动清理内存,减少未访问过期键的堆积。 - **缺点**:需平衡频率(高频增加 CPU 负载,低频导致内存浪费)[^2][^3][^5]。 #### 3. **为什么不立刻删除?** - **性能考量**:实时删除需为每个键维护定时器,当海量键过期时,会严重消耗 CPU。 - **设计折衷**: - 惰性删除:确保操作触发时键必然过期。 - 定期删除:通过概率抽样控制 CPU 开销,避免全表扫描。 - **替代方案对比**: - **时间轮(Timing Wheel)**:适合高频精确任务,但维护海量键时内存占用过高。 - **优先级队列(Heap)**:插入/删除复杂度 O(logN),不如随机抽样高效[^3]。 --- ### 持久化与主从复制中的处理 - **RDB 持久化**: - 生成 RDB 文件时,会跳过过期键。 - 加载 RDB 时,主节点会删除过期键,从节点则保留(等待主节点同步 DEL 命令)[^5]。 - **AOF 持久化**: - 键过期后,Redis 会追加一条 `DEL` 命令到 AOF 文件。 - **主从复制**: - 从节点的过期键删除**依赖主节点**:主节点删除后会发送 `DEL` 命令同步到从节点[^5]。 --- ### 总结:何时实际删除? | 场景 | 删除时机 | |--------------------|-----------------------------| | 客户端访问过期键 | 立刻删除(惰性删除) | | 键过期后未被访问 | 等待定期删除轮询 | | 内存不足时 | 触发内存淘汰策略(如 LRU)[^4] | > 例如:设键 `session:1001` 在 12:00:00 过期: > - 若用户在 12:00:05 访问它,**立刻删除**(惰性删除)。 > - 若无人访问,则在后续**定期删除任务中随机抽查时删除**(可能延迟数秒)。 --- ### 相关问题 1. **Redis 的定期删除频率如何配置?调整 `hz` 参数对性能有何影响?** 2. **内存淘汰策略(如 LRU、LFU)与过期键删除策略有何区别?** [^4] 3. **主从复制场景下,从节点如何处理已过期的键?** 4. **大量键同时过期会导致什么问题?如何优化?** [^1]: Redis 过期键(expires)机制详解 [^2]: Redis 过期策略:定时删除与惰性删除 [^3]: Redis 惰性删除与定期删除的协同机制 [^4]: Redis 内存淘汰策略与过期键的区别 [^5]: 过期键的持久化与主从同步处理
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

程序员Shark

感谢打赏,thanks

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值