- Redis的DEL命令居然没删干净数据？这个坑我爬了半天*
引言
Redis作为高性能的内存数据库，被广泛应用于缓存、消息队列、会话存储等场景。其简洁的命令集和高效的性能让开发者爱不释手，但其中也隐藏着一些"坑"。最近，我在生产环境中遇到了一个看似简单的问题：使用DEL命令删除数据时，发现数据并未完全删除干净。这个问题让我折腾了大半天，最终发现背后涉及Redis的底层实现和配置细节。本文将详细剖析这一现象的原因，并提供解决方案，帮助大家避免踩坑。
主体
1. 问题现象
某天，我在清理Redis中的某些缓存数据时，执行了如下命令：
bash
DEL user:1001随后，我通过GET user:1001验证，发现返回了nil，看起来数据已经被删除。然而，当我使用SCAN命令遍历所有键时，却意外发现user:1001仍然存在！更诡异的是，直接GET它却无法获取值。这种不一致的现象让我感到困惑。
2. 初步排查
首先，我怀疑是Redis的异步删除机制导致的。Redis 4.0之后引入了UNLINK命令作为DEL的异步替代品，但我在代码中明确使用的是DEL，理论上应该是同步删除。
接着，我检查了Redis的配置：
bash
config get lazyfree-lazy-server-del发现其值为no，说明并未启用异步删除。那么，问题可能出在别的地方。
3. 深入研究Redis的删除机制
Redis的DEL命令在删除数据时，会直接释放内存并移除键值对。但以下情况可能导致"删除不彻底"：
3.1 键的过期和惰性删除
Redis的过期键删除策略包括：
- 主动删除：定期随机检查并删除过期键。
- 惰性删除：当访问某个键时，发现其已过期才删除。
如果键设置了过期时间，且过期后未被访问，它可能仍然存在于内存中，直到被主动删除或惰性删除触发。此时，SCAN可能仍然能看到它，但GET会返回nil。
3.2 内存淘汰策略
如果Redis配置了maxmemory-policy为volatile-*或allkeys-*，当内存不足时，Redis会按策略淘汰键。但淘汰过程可能不完全同步，导致部分键"残留"。
3.3 持久化与复制的影响
如果Redis启用了AOF或RDB持久化，删除操作可能因为持久化延迟或复制延迟而未完全生效。例如：
- AOF缓冲区未刷盘时，服务器崩溃可能导致删除操作丢失。
- 主从复制时，从库可能因延迟尚未同步删除操作。
4. 问题的根源
回到我的场景，经过进一步排查，发现以下原因：
- 键
user:1001曾经设置了过期时间，但过期后未被主动删除。 SCAN命令会遍历所有键，包括已过期但未被删除的键。GET命令会触发惰性删除，因此返回nil。
这种不一致是因为Redis的惰性删除机制导致的。SCAN不会触发键的过期检查，因此能看到"幽灵键"（已过期但未删除的键）。
5. 解决方案
为了避免这种现象，可以采取以下措施：
5.1 显式删除而非依赖过期
对于需要立即删除的键，直接使用DEL或UNLINK，而不是依赖过期时间。
5.2 调整过期键删除频率
通过调整hz参数（默认10），可以增加主动删除的频率：
bash
config set hz 100但需要注意，更高的频率会增加CPU开销。
5.3 使用SCAN时过滤过期键
可以通过TTL命令检查键是否过期：
bash
SCAN 0 MATCH user:* | xargs -L 1 redis-cli TTL | grep -v "^-2"注：-2表示键不存在或已过期。
5.4 启用异步删除
如果性能允许，可以启用异步删除以减少阻塞：
bash
config set lazyfree-lazy-server-del yes5.5 监控与告警
通过INFO命令监控过期键数量：
bash
info stats | grep expired_keys如果expired_keys长期不为0，可能需要调整删除策略。
总结
Redis的DEL命令看似简单，但背后涉及复杂的删除机制，尤其是惰性删除和过期键处理。当发现数据"删除不干净"时，通常是因为过期键未被及时清理或持久化/复制延迟导致。通过调整删除策略、增加主动删除频率或显式过滤过期键，可以避免这一问题。
作为开发者，理解Redis的底层机制至关重要。只有深入原理，才能更好地应对生产环境中的各种"坑"。希望本文的分享能帮助大家少走弯路！