4. noeviction 淘汰策略：原理、适用场景、风险与限制
noeviction 是 Redis 默认的淘汰策略，也是唯一一种不主动驱逐任何已有键的策略。当内存达到 maxmemory 限制时，所有写入操作（如 SET、LPUSH、SADD 等）都会返回错误，而读取操作（如 GET、LRANGE）仍然正常执行。理解 noeviction 的机制与边界，是微服务缓存架构中避免“静默数据丢失”的关键前提。
4.1 核心原理
noeviction 的行为逻辑非常简单：Redis 在每次执行写入命令前检查当前内存使用量。如果已超过 maxmemory 阈值，则直接拒绝写入并返回 OOM 错误。Redis 不会扫描、采样或删除任何现有键。
关键行为对比： 其他淘汰策略（如 allkeys-lru、volatile-ttl）在内存满时会主动删除键以腾出空间；noeviction 则完全依赖外部机制（如应用层降级、手动删除或扩容）来释放内存。
4.2 适用场景
noeviction 并非“无用策略”，在特定场景下它反而是最安全的选择：
| 场景 | 说明 | 典型示例 |
|---|---|---|
| 缓存作为“有损加速层” | 业务允许缓存未命中时回源数据库，但绝不允许缓存数据被静默删除 | 用户会话缓存、配置缓存 |
| 数据一致性要求极高 | 淘汰策略可能导致“缓存中部分数据消失”，业务无法接受 | 金融交易风控规则缓存 |
| 内存容量规划严格 | 运维团队通过监控和告警确保内存永远不会达到上限 | 预分配内存的专用缓存集群 |
| 测试/开发环境 | 避免测试过程中因淘汰策略导致数据意外丢失，干扰问题定位 | 本地开发 Redis 实例 |
微服务架构建议： 对于核心业务缓存（如用户登录态、订单状态），推荐使用 noeviction + 主动 TTL 过期 + 内存告警的组合。这样既能保证数据不丢失，又能通过 TTL 控制数据生命周期。
4.3 风险与限制
noeviction 策略在微服务高并发场景下存在以下主要风险：
- 写入失败导致业务中断： 当内存达到上限时，所有写入操作都会返回
OOM command not allowed when used memory > 'maxmemory'。如果应用层未捕获此异常，可能导致缓存更新失败、数据不一致甚至请求链路中断。 - 无自动内存回收机制： 即使设置了 TTL 的键过期，Redis 的惰性删除和定期删除仍然需要内存空间来执行。在内存满且无淘汰策略的情况下，过期键可能无法被及时清理，形成“假满”状态。
- 扩容响应滞后： 依赖人工或自动扩容来释放内存，但扩容操作（如增加节点、调整 maxmemory）通常需要分钟级时间，期间写入请求持续被拒绝。
- 与微服务弹性伸缩的矛盾： 微服务实例频繁扩缩容时，缓存流量波动较大，noeviction 无法自动适应内存压力变化，容易触发 OOM 边界。
⚠ 生产环境警告： 不要在未配置内存告警和写入异常捕获的情况下，将 noeviction 用于高写入量的生产缓存集群。一次突发的流量尖峰就可能导致大量写入失败，引发缓存雪崩效应。
4.4 与其他策略的对比
| 对比维度 | noeviction | allkeys-lru | volatile-ttl |
|---|---|---|---|
| 内存满时行为 | 拒绝写入 | 淘汰最近最少使用的键 | 淘汰 TTL 最短的键 |
| 数据丢失风险 | 无（写入失败） | 高（静默删除） | 中（仅淘汰带 TTL 的键） |
| 适用写入密度 | 低～中 | 高 | 中～高 |
| 运维复杂度 | 高（需严格监控） | 低 | 中 |
| 微服务推荐度 | 核心数据缓存 | 通用查询缓存 | 有时效性要求的缓存 |
4.5 配置与监控建议
在微服务中使用 noeviction 策略时，必须配套以下措施：
# redis.conf 配置示例
maxmemory 4gb
maxmemory-policy noeviction
# 监控指标（Prometheus/Grafana）
redis_memory_used_bytes / redis_memory_max_bytes > 0.8 → 告警
redis_memory_used_bytes / redis_memory_max_bytes > 0.95 → 紧急告警
redis_rejected_connections_total > 0 → 立即响应
最佳实践： 在应用层使用 Redis 客户端时，务必捕获 OOM 异常并实现降级逻辑。例如，使用 Spring Data Redis 时，可以配置
RedisTemplate 的异常处理器，在写入失败时回退到本地缓存或直接查询数据库。
4.6 总结
noeviction 是一把“双刃剑”：它保证了缓存数据的完整性，但将内存管理的责任完全交给了运维和开发团队。在微服务架构中，建议仅在以下条件全部满足时使用：
- 缓存数据丢失会直接导致业务逻辑错误或数据不一致；
- 已配置完善的内存监控和告警机制；
- 应用层已实现 OOM 异常的捕获与降级处理；
- 缓存写入流量相对平稳，或具备快速扩容能力。
如果以上条件无法全部满足，建议优先考虑 volatile-lru 或 allkeys-lru 策略，并结合合理的 TTL 设置来平衡数据可用性与内存利用率。