在用户注册、登录保护以及敏感操作确认等场景中，验证码是最基础的安全屏障之一。传统的做法是将验证码明文或者简单加密后写入MySQL这类磁盘型数据库，但验证码本身生命周期极短，通常只有几分钟有效，却要在短时间内承受大量写入与读取请求。这种高频且临时的数据如果长期占用关系型数据库的连接与表空间，会明显拖慢核心业务查询。Redis作为内存键值数据库，提供了毫秒级响应和自动过期能力，非常适合承担验证码的临时存储与校验工作。
验证码的键结构与写入策略
使用Redis存储验证码，第一步是设计合理的键名。键名需要唯一定位到某个用户在某类业务下的验证码，同时方便批量清理与问题排查。常见的格式是采用冒号分隔的层级结构，例如vc:13800000000:login，其中vc表示验证码业务前缀，中间是手机号，最后是业务类型。这样的设计在Redis可视化工具中能够自然归类，也避免了不同业务验证码互相覆盖。
写入时通常调用SET命令并附带过期时间。如果验证码需要携带更多信息，比如创建时间、尝试次数，可以用哈希结构存储。但对于绝大多数场景，直接存字符串更简单。下面示例展示用Redis命令行设置一分钟有效的登录验证码：
# 设置手机号13800000000的登录验证码为834521，60秒后自动过期 SET vc:13800000000:login 834521 EX 60
在后端代码中，我们往往使用相应语言的Redis客户端来完成同样的逻辑。以Java的Spring Data Redis为例，可以清晰地控制序列化方式与过期时间，避免默认序列化器把键名变成乱码。良好的写入策略还包括对验证码生成做随机性增强，拒绝使用连续数字或时间戳片段，从而降低被猜测的风险。
校验流程与并发安全问题
校验环节最核心的原则是“取后即删”或“取后标记”。如果不删除已使用的验证码，攻击者可能截获一次验证码后反复重放完成多次操作。基础校验代码先通过GET取出值比对，再调用DEL删除。但这两个操作之间存在时间窗口，高并发下可能出现同一验证码被两个线程同时校验通过的情况。
为解决该问题，可以把读取与删除合并为原子操作。Redis的GETDEL命令在较新版本中直接支持取回并删除，而在老版本中可用Lua脚本保证原子性。以下Lua脚本实现了安全校验：先比对传入验证码，匹配则返回1并删除键，不匹配返回0且不删除，从而防止误删其他请求刚写入的验证码。
-- KEYS[1]为验证码键名，ARGV[1]为用户传入的验证码
local val = redis.call('GET', KEYS[1])
if val == ARGV[1] then
redis.call('DEL', KEYS[1])
return 1
else
return 0
end
除了原子性，还要考虑校验失败次数限制。可以在Redis中为同一手机号维护一个失败计数器，例如vc:fail:13800000000:login，每次失败自增，达到阈值后锁定一段时间。这样既能拦住暴力破解，也不会因为频繁写数据库而影响性能。实践中建议把锁定时间设为指数退避，让恶意脚本成本越来越高。
过期机制与资源清理优化
Redis的键过期并不是精准到毫秒的实时删除，而是采用惰性删除加定期采样删除的混合策略。这意味着一个过期验证码可能仍短暂存在于内存中，但GET时会返回空。对于验证码场景这完全可接受，因为业务层只关心能否取到有效值。不过若业务量极大，大量短命键会让Redis定期删除任务产生轻微延迟，因此键名设计应尽量简短。
另一种优化思路是使用Redis的命名空间与单机多库。将验证码统一放入独立逻辑库（如DB 2），当需要做全量清理或压测时，直接FLUSHDB该库即可，不影响缓存会话等其他数据。同时配合监控命令INFO keyspace观察验证码库的键数量与命中率，能及时发现是否有接口被刷导致键暴涨。
# 查看各库键统计，关注db2中验证码增长是否异常 INFO keyspace # 切换并清空验证码专用库 SELECT 2 FLUSHDB
最后要注意的是，验证码属于敏感数据，即便在Redis中也不建议明文存储核心关联信息。可以对验证码值做一次服务端哈希后再存入，校验时同样哈希比对，这样即使Redis被非法访问，攻击者也无法直接拿到可用验证码。结合网络层白名单与Redis自身的密码鉴权，整体方案才能在便利与安全间取得平衡。