缓存为什么会被污染？

有缓存过期时间和缓存淘汰机制，为什么还会出现缓存污染？极客时间《Redis 核心技术与实战》专栏学习笔记 13，部分已经作为留言发布，但是留言太多，排在后面的一般很难被大家看到，所以集中发布在这里，欢迎讨论。

题图来自《Redis 核心技术与实战》专栏

27 | 缓存被污染了，该怎么办？

有缓存过期时间和缓存淘汰机制，为什么还会出现缓存污染？

这一讲算是补上了之前留下来的一个坑——前面讲过了 LRU 算法，但是对于 LFU 一直留到这里才讲。我之前望文生义的以为 LFU，就是按照访问频次来淘汰，但是没有考虑到如果次数相同，那么还是要看访问时间；另外就是巧妙的拆分了 RedisObject 里面的 lru 字段，用 ldt 和 counter 来实现算法。

能看懂计数器规则的公式，但是不理解为什么要这么计算。还有那个 衰减因子配置项 lfu_decay_time 的相关计算也比较有意思，但是不知所以然，此处必有蹊跷。

之前看 LRU 和 LFU 比较多，忽略了 volatile-ttl 策略，这次正好补上了。

使用了 LFU 策略之后，应该还是会有缓存污染的情况，但是被污染的比例，或者说造成的影响应该小很多。假设 Redis 每次收到的请求都是全量扫描或接近于，那么 LFU 是不是就会失效，或者说缓存污染就会比较严重？

28 | Pika：如何基于 SSD 实现大容量 Redis？

其实有一点不理解，为什么会有 Pika？从专栏的内容来看，Pika 更像是一个实现了 Redis 类似接口的键值数据库。文章里面并没有介绍 Pika 是否有与 SSD 结合的优化，仅仅是利用了 SSD 的读写高性能特性么？

在知乎上看到了 Pika 开发者的一些帖子，说明了 Pika 是有特定的应用场景的。从 Github 的主页上来看，国内互联网还是有不少大厂使用了 Pika。虽然 Starts 和 forks 的数目没那么多，但是应该也是国内开源软件做的比较好的了，最新的 Release 是 2020 年 12 月份的 3.4.0，最近的代码更新是在 2021 年 1 月。

如果把 Pika 部署在磁盘上呢？

跳到课后题，用机械硬盘来作为实例容量扩展，从技术上似乎没什么问题，就是操作性能没那么好（甚至更差）。