LRU / LFU 不是全量排序
Redis 从少量候选中抽样比较，因此这里也采用 5 个候选的近似选择。它能趋近理想结果，但不会保证每次都淘汰“绝对最旧”或“绝对最低频”的键。
Redis memory pressure lab
内存满了，究竟牺牲谁？
把同一批确定性请求交给不同的 maxmemory-policy。水位线会告诉你内存是否真的被缓存占满，淘汰队列则揭示“命中率更高”背后牺牲了哪些键。
内存水位
0 / 24 MB键块宽度代表约 1 MB0 keys
带 TTL，可被 volatile 策略挑选无 TTL，volatile 下不入候选池
最近淘汰
最多显示 8 个读取命中率—
成功写入—
写入失败—
淘汰 / 自然过期—
无 TTL 键占用—
等待模拟
调整参数后运行，观察相同请求在不同策略下如何改变结果。
volatile 只认带 TTL 的键
即便内存里还有很多永久键，volatile 策略也不会碰它们。候选池一旦为空，新的写命令会直接失败，而不是自动改淘汰永久键。
别把两类数据塞进同一锅
可丢缓存和不可丢状态共享同一个实例时，allkeys 可能淘汰业务状态；volatile 又可能让永久状态挤占全部空间。更稳妥的边界是分实例、分内存预算。
教学模型：每个键占 1 MB；TTL 为 28～92 个时间步；80% 请求为读、20% 为写；热点池占初始键的 20%。模型省略对象编码、碎片率与 Redis 内部开销，适合比较策略，不用于容量估算。