先确认Redis是否只存可重建缓存，再选择内存上限和淘汰策略。不同策略决定哪些键能被移除，设置不合适可能导致写入失败或其他业务数据丢失。不能把缓存推荐值直接套到同时存队列、会话或持久数据的实例。
先区分缓存与业务事实
WordPress对象缓存中的多数对象可以从数据库重建，但同一Redis实例未必只承担对象缓存。盘点是否还有会话、任务或其他应用写入，确认每类数据允许的失效行为。若语义不同，优先评估资源隔离，不用一种淘汰规则混合承担冲突目标。
全键与到期键并不一样
淘汰策略可能面向所有键，也可能仅面向设置了过期时间的键。如果可淘汰集合不足，即使配置了策略，也可能无法释放足够空间。不同策略的近似访问频率或最近使用判断不是业务重要性排名，不能保证某个关键对象永远保留。
上限不等于整机内存预算
Redis进程实际占用还受连接、复制、持久化和内存分配等影响，不能把主机全部可用内存都写成maxmemory。与PHP、数据库共机时还要留出系统和峰值余量。记录内存曲线、淘汰与写入错误，再判断是容量不足还是异常大对象。
更改后观察冷数据成本
淘汰增加会带来缓存未命中和数据库回源，网页速度可能随业务分布变化。用相同页面和相近请求条件比较命中、淘汰、数据库负载与延迟，不只看内存是否下降。若写入失败持续出现，应先恢复可用性，再分析容量与策略的匹配。
关键区别
内存上限：缓存容量边界；不是整机预算。
淘汰策略：选择移除对象；不理解业务重要性。
写入失败：可能无法腾空间；不能只看命中率。
怎样确认处理到位
验证应包含正常写入、达到容量边界时的行为和数据库回源表现。若实例还有不可丢失数据，必须先确认其保护方式，不能用生产数据做随意淘汰试验。
容易误判的边界
不要把noeviction理解为不会出故障，也不要认为allkeys策略总适合所有业务。淘汰解决容量压力的一部分，不能代替异常键增长与内存泄漏诊断。
