图 1：本文封面，点明两款缓存组件的选型主题。
先说明属性：这是一篇经典题解析，题目出自本地历史面试资料，与任何公司的当前招聘无关。「Redis 和 Memcached 的区别」是缓存选型的经典题，很多人只背出一句「Redis 数据结构多」，面试官顺着持久化、集群、线程模型一路追问，就接不住了。
面试现场的场景往往是：让你给一个新业务选缓存组件，然后观察你的决策维度够不够全。
核心结论一句话：Memcached 是纯粹的内存缓存，Redis 是带缓存能力的数据结构服务器。
维度一：数据结构。
Memcached 只有简单的键值对——官方文档说得很直白：服务端不理解数据结构，你存的必须是预序列化好的数据。Redis 原生提供字符串、哈希、列表、集合、有序集合等结构：排行榜用有序集合，队列用列表，计数器直接自增。这些需求在 Memcached 里都要应用层自己拼，拼出来还没有原子性保证。
维度二：持久化。
Memcached 没有持久化，重启即丢——它从设计上就只做缓存。Redis 官方提供 RDB 快照（按间隔做时间点镜像）和 AOF 日志（记录每条写操作，默认每秒刷盘，最多丢一秒数据），两者可以混用，也可以全关当纯缓存。要不要把会话、计数这类「丢了心疼」的数据放进缓存层，是两家的第一道分水岭。
维度三：集群与扩展。
Memcached 的服务端之间互不感知——没有复制、没有通信，官方文档明确「servers are disconnected from each other」，分片靠客户端的一致性哈希，加机器就是加内存。Redis 有官方 Cluster：槽位分片、主从复制、自动故障转移，服务端自己知道每个 key 在哪。
维度四：线程模型。
Memcached 是多线程 worker 模型，官方配置文档写明默认 4 个线程，可以吃满多核。Redis 从命令执行的角度基本是单线程——官方基准文档的原话是「mostly a single-threaded server from the POV of commands execution」，现代版本用线程做 IO 与后台任务辅助。单线程意味着没有锁竞争、单命令天然原子，单核吞吐已经极高；要吃多核，官方的建议是起多个实例。
维度五：功能集。
Memcached 官方把自己的哲学写成「遗忘是特性」：LRU 过期淘汰、惰性回收、协议极简，只做一件事并做到最快。Redis 在此之外还有过期策略、事务、Lua 脚本、发布订阅等——能力面宽得多，复杂度也由此而来。
选型决策。
只要简单 KV 缓存、数据丢得起、想把多核大内存机器吃满——Memcached 够用，而且更简单。需要复杂结构、持久化、高可用、原子操作——直接 Redis。这也是当下绝大多数团队的默认答案：Redis 覆盖了 Memcached 的几乎所有场景，反过来不成立。
落到 AI 工程场景，分水岭问题变得更具体。
会话状态缓存：多轮对话的上下文要跨实例共享、丢了用户立刻有感——需要共享存储加可接受的持久化，Redis。推理结果缓存：同 prompt 的生成结果缓存起来省钱，丢了无非重算一次——纯 KV 就够，两家都能干。热点排行榜、任务队列、限流计数器：复杂结构加原子操作，Memcached 直接出局。把业务的每类数据按「结构复杂度、丢不丢得起、要不要共享高可用」三个问题过一遍，选型结论往往自己走出来。
图 2：五个维度的横向对比与选型决策。
常见误区。
一，只答「数据结构多」，其余四个维度全哑——等于只背了结论。二，以为 Redis 单线程所以慢：单线程避免了锁与上下文切换，配合 IO 多路复用，官方基准页面上的示例单实例轻松跑到每秒十万次以上的请求，真正的瓶颈通常在内存和网络。三，把 Memcached 当持久层用，重启之后追悔莫及。四，以为 Memcached 有服务端集群方案，上线才发现扩缩容要自己在客户端处理一致性哈希的迁移。
答题建议。
先给一句话定位（纯缓存 vs 数据结构服务器），再按数据结构、持久化、集群、线程、功能五个维度展开，最后落到具体场景做决策。如果能补一句「我们当时因为要排行榜和会话持久化选了 Redis」，这道题就稳了——选型题的高分在决策依据，不在参数罗列。
你的团队现在还留着 Memcached 吗？是历史遗留还是有意选型？欢迎分享。