Embed Notice

@kt
最后附上我折腾 Caddy cache 的经历。

--------

Caddy 2 目前可以使用的缓存模块有两个 http.handlers.cache （ https://github.com/caddyserver/cache-handler ）、http.handlers.http_cache （ https://github.com/sillygod/cdp-cache ），但均是非官方模块，Caddy 2 自身并不支持缓存。
如果你因为一些需求，比如说反代S3媒体库，需要用到缓存功能，Caddy 2 就……
一个反向代理，连缓存都不支持，多少有一点嘈点满满。

下面再说一说这两个非官方的缓存模块。

http.handlers.cache 基于 Souin cache，存储后端支持 Badger、NutsDB、Etcd、Olric、Redis，值得注意的一点是该模块并不支持像 Nginx 那样的 filesystem cache。

后三个都是 in-memory cache ，内存消耗巨大，本人只尝试使用过 Olric （因为支持 embedded olric 无需额外安装软件）。
embedded olric 不知道为什么，内存消耗特别大，测试时缓存 nitter 媒体文件，请求了大约1000个文件，传输流量140MB，Caddy的内存占用就已经达到了1.5GB。继续测试，发现Caddy的内存占用基本上是按请求流量十倍大小来算的。

前面两个 Badger 与 NutsDB 都是KV数据库，算是 filesystem+memory 的 hybrid cache 。
但实际使用下来，问题多多。
Badger 存在缓存污染问题，模块开发者自己都建议不要使用 Badger （ https://github.com/caddyserver/cache-handler/issues/27 ）。
NutsDB 倒确实没有缓存污染问题，但却存在内存占用的问题。将 EntryIdxMode 设为 HintBPTSparseIdxMode，按 NutsDB 官方的说法『HintBPTSparseIdxMode 是专门节约内存的设计方案，单机10亿条数据，只要80几M内存』。但实际使用中却存在内存占用持续增长的问题。反代 img.bgme.me ，大约8个小时后，便 OOM Kill 了，OOM kill 时 total-vm:26129016kB, anon-rss:9457364kB。

此外 http.handlers.cache 配置相当的复杂，一点都和简单易用沾不上边。

再说一说 http.handlers.http_cache 模块。
http.handlers.http_cache 倒确实是简单易用，也完全是基于文件的 filesystem cache。
在实际使用中发现存在部分请求超时的问题。这是一个老问题，之前也有人提过 issue https://github.com/sillygod/cdp-cache/issues/24 ，按理来说应该也修复了，但在实际使用中我确实是又遇到了这个问题（caddy v2.7.0-beta.1 、cdp-cache v0.5.0）。感觉可能与请求并发有关，本地环境测试时并没有那么容易出问题，但放到生产环境中，便经常出现请求超时。
另外，重启服务后该插件会令之前缓存的Key丢失，遇到相同请求时会再次请求上流。 https://github.com/sillygod/cdp-cache/issues/38
此外，该插件并不支持 Nginx 那样设置最大存储大小。

总之，目前 Caddy 并不存在靠谱的 Cache 方案。如果你因为一些需求，比如说反代S3媒体库，需要用到缓存功能，并不非常推荐使用 Caddy。