Memcached 与 Redis 都是常见的内存缓存方案，但一位系统管理员在博客中分享了为什么他如今更倾向选择 memcached——不是因为功能少，而是因为「简单」本身就是优势。
Redis 容易变成「假数据库」
这位作者指出，Redis 引入项目时通常作为缓存层，运维也按缓存的方式管理它：数据丢失可以接受，不需要持久化，宕机也不需要告警。但时间一长，开发团队逐渐把 Redis 当成存储来用——缓存 set/get 的操作比 INSERT 简单太多，于是关键数据就这么留在了内存里。
问题是：运维不知道这层错位。直到某次升级、迁移或服务器故障，Redis 数据丢了，业务才发现依赖方根本没有任何降级方案。作者将这种情况形容为「像养宠物一样维护它」——需要时刻关注它的状态，而不是把它当成随时可替换的基础设施。
memcached 的三个运营优势
作者认为，memcached 的简单性反而解决了上述问题：
故障处理简单：客户端库通常会忽略连接异常，get 操作在服务器宕机时直接返回默认值（None），而不是抛出错误。这意味着业务代码无需额外编写降级逻辑，缓存不可用时自动回源到数据库。
集群模式天然客户端实现：memcached 本身不提供集群功能，客户端通过哈希算法将 key 分布到多个实例，检测到某节点不可用后自动摘除，一段时间后再次尝试连接。这种方式不需要额外的集群协调层，运维也更透明。
无持久化 = 真正的无状态：memcached 不写磁盘，设计上就是纯内存缓存，可以随时重启或替换，不会有人误以为数据「应该」保留在上面。这使得它非常适合容器化或 Kubernetes 环境下的无状态部署。
作者也强调，如果性能问题根源在于慢查询或缺失索引，引入缓存只是治标——先帮开发团队优化 SQL 才是真正的善意。
（文中提到 memcached 官方博客近期有一篇关于响应时间的分析文章，感兴趣的读者可进一步阅读。）
编注：信源为个人技术博客，作者以运维视角阐述 Redis 与 memcached 的使用差异，观点基于实际经验，读者可作参考。