赞美 memcached

原文 ↗ Hacker News 讨论 ↗

AI 写成的指控与元讨论

  • 几位评论者反对那种条件反射式的“这是 AI 写的”说法，认为这类评论价值很低，而且如今在 HN 上很常见。
  • 也有人觉得这篇文章“读起来像 AI 写的”，或者至少经过了 LLM 润色，但并没有共识或证据；还有人指出某些不太正式的措辞不太像 LLM 会写出来的。

Redis vs Memcached 作为缓存技术

  • 很多人同意 Redis 作为缓存很好，但需要仔细配置：强制过期、禁用或分离持久化、设置 maxmemory 和淘汰策略，并避免把复杂结构用于缓存对象。
  • 一个主要主题是：Redis ცდილ于同时扮演持久化存储和易失缓存；这种双重身份让误用很容易发生（例如把它当作持久数据库，忘记淘汰）。
  • Memcached 被称赞为“无聊”、简单、纯粹短暂，而且更难被误用为存储。它缺少集群和高级功能，对一些人来说这是优点，对另一些人来说则是限制。

运维问题和故障模式

  • 报告中的 Redis/Valkey 事故包括：没有淘汰导致 OOM、AOF 因磁盘写满而失败、应用假设 Redis 总是可用且已填充数据且没有回退方案。
  • 有些人喜欢 memcached 的“fail open”模式（失败时返回 null → 重新计算），另一些人则认为静默失败很危险，更偏好显式错误。
  • Memcached 的 slab 分配可能导致“slab starvation”，而且需要调优；这被视为一种隐藏的复杂性。

性能、复杂性与替代方案

  • 有人声称 memcached 在简单 KV 场景下明显更快；反方则认为现实中的差异可能很小，网络延迟才是主导因素。
  • 有人认为带有自身缓存机制的 RDBMS（例如 Postgres/MariaDB）足以应付大多数工作负载；也有人指出 Redis 比完整数据库更简单，并且在同机部署时表现出色。
  • 单线程 Redis 与多线程 memcached 的争论也在继续；Redis 在复杂操作上可能会停顿，而 memcached 从设计上就面向 O(1) 操作。

更广泛的用例与生态偏移

  • Redis 的用途早已超出缓存：限流、功能开关、发布/订阅、WebSocket 后端、任务队列、分布式任务协调。
  • 有些人更喜欢分离职责：用 memcached（或 DB + 文件系统）做缓存，用带持久化的 Redis 来承载更偏数据结构的功能。
  • 评论中也批评了 Redis 的功能膨胀和营销（包括 AI 定位），并提到了 Valkey 和其他系统，但并没有明确共识认为某个工具整体“胜出”。