“Redis 还是 Memcached”这句话我在面试里被问到过无数次也在架构评审会上被翻来覆去比较过。从大概十年前开始“Redis 能秒杀 Memcached”就成了技术圈流传最广的判断之一但它到底赢在哪、边界在哪不少人的理解其实一直很模糊。如果从数据结构丰富度、持久化能力、高可用体系和周边生态来看Redis 确实把 Memcached 甩开了一大截说“秒杀”并不过分但如果把场景拉窄到“纯 KV 缓存、海量读多写少、丢了数据也无所谓”这类业务上Memcached 的多线程模型依然有它存在的空间。这篇文章不打算给哪个产品站台我想把两者从底层设计到业务能力完整拆一遍讲清楚 Redis 赢在哪儿也给 Memcached 一个公道的位置最后分享一套我自己在选型和部署中会用的判断方法。这篇文章适合谁看后端开发、系统架构师、运维以及正在准备缓存相关面试的人应该都能找到用得上的内容。我先把两者最本质的定位差异放在最前面然后逐步展开数据类型、持久化、高可用、分布式锁、性能实测这些维度最后落到选型建议和部署踩坑。整个过程尽量用真实业务场景说话少讲空泛概念。1. 先弄清二者最本质的分野内存KV vs 数据结构服务器1.1 同样在内存里存数据两者的设计目标完全不一样从表面看Redis 和 Memcached 都常驻在内存里都支持过期时间都能扛住高并发读这也是为什么很多人一开始只把它们当成“缓存的两个候选”。但往底层看Memcached 本质是一个“内存缓存服务”它的一切设计都围绕一个目标把 get/set 做到最简单、最快、最省内存。它不关心你存的是什么value 对它来说就是一段字节流最大默认 1MB没有二级结构。这意味着你想要一个排行榜、一个去重集合、一个哈希表的局部更新Memcached 都帮不上忙只能由应用层把整个 value 取出来、改完再塞回去——这对大对象和高频更新场景几乎就是灾难。Redis 的定位完全不同。它官方的口径是 in-memory data structure store这是一个数据结构服务器。它把 String、Hash、List、Set、ZSet 这些数据模型直接放到了服务端客户端只需要发一条命令就能在近乎原子、不需要传输整个对象的前提下完成一次局部更新。这个差异不只是“多一些 API”的程度而是架构层级的差异Memcached 把复杂度留给应用Redis 把复杂度收进了引擎。我常跟团队说一句话Memcached 是一个“放东西的柜子”Redis 则是一台“能在内存里做计算的小型服务器”。同一个缓存选型问题一旦你意识到自己需要的是“柜子”还是“服务器”结论基本就呼之欲出了。1.2 单线程 Redis 为什么还能跑那么快很多刚接触 Redis 的同学都会有一个经典疑问Memcached 是多线程的Redis 是单线程的凭什么说 Redis 更快这里需要把“快”拆开看。Redis 的命令执行确实是单线程但它使用了基于 epoll 的事件循环也就是 I/O 多路复用把网络读写阶段的阻塞成本压到了极低。单线程还有一个隐性收益没有锁、没有线程切换、不需要考虑并发安全问题所以每个命令天然具备原子性。Redis 能轻松跑出十万级 QPS很大程度上是省掉了并发同步开销换来的。Memcached 的多线程在压满多核后确实有不错的扩展性但它必须面对线程之间的连接分配和内存访问锁开销这部分恰好是“快”的重点消耗点。单线程也不是没有代价。如果某条命令很慢比如一次没加限制的 KEYS *或者对一个超大集合做阻塞型操作后面排队的命令都得等着这就是大家常说的“Redis 延迟毛刺”。社区的解法从 Redis 6.0 开始很明确I/O 层引入多线程网络读写交给多线程并行处理命令执行仍然保持单线程。这是一招很聪明的折中既吃到了多核处理网络请求的红利又不破坏命令执行顺序和原子性。到了 Redis 7.x持久化、主从同步、内部数据结构编码也做了大量优化。所以在大多数业务场景下Redis 的吞吐能力不但不输 Memcached而且因为命令集更丰富更容易设计出高性能的复合操作。2. 数据类型差异一张 ZSet 就能把 Memcached 甩开几个身位2.1 String 之外的标准库是两者最直观的差距Memcached 只有一种 value 类型字节串。JSON、序列化对象、图片、HTML 片段对它来说都是同一回事。Redis 则在 String 之外提供了 Hash、List、Set、ZSet、BitMap、HyperLogLog、Geo、Stream 这些结构每一类都对应一组专门的命令。这些结构的意义不只是“能保存更多格式”而是“服务端直接完成业务逻辑”。我简单列一下实际价值。Hash 让 Redis 能存对象同时支持 HGET/HSET 单独读写某个字段不用每次把整个对象序列化塞进 StringList 配合 LPUSH/RPOP 甚至带阻塞语义的 BRPOP早期很多项目就是拿它当轻量任务队列用的Set 天然去重SADD、SISMEMBER、SPOP 可以直接做集合运算ZSet 是带分数的排序集合排行榜、实时热点、延迟队列都是它的经典场景BitMap 用 1 个比特位记录一个用户状态做签到、在线统计时内存占用小得可以忽略HyperLogLog 用不到 12KB 的内存就能统计海量 UV误差大概在 0.81% 左右Geo 直接干掉了很多团队早期做 LBS 业务时“自己写距离计算”的工作量Stream 则是一个完整的基础消息队列原语。Memcached 能干什么get、set、add、replace、append、incr/decr。它的 incr/decr 确实能做计数器但只有纯数字的自增自减。你想实现“取当前值、和某个阈值比较、再更新”这类操作它没有原子命令要么用 CAS token 自己做乐观锁要么接受竞态然后在应用层补偿。至于布隆过滤器、排行榜、附近的人、UV 去重Memcached 一个都接不住。我不是说这些需求非得用 Redis 才能实现而是说用 Memcached 实现它们的成本会陡增——你会发现自己不是在写业务而是在造轮子。顺便补一个和日常开发强相关的点应用层往 Redis 里写对象时序列化方案的选择很影响可读性和体积。Spring 生态里很多人习惯用默认的 JDK 序列化结果缓存里全是 \xAC\xED 开头的二进制排查问题时人眼根本读不了性能也差。单机开发调试用 JSON 可读性最好追求性能和体积可以用 protobuf或者将公共字段拆进 Hash 而不是整个对象塞 String。这一步设计得不好后面“缓存治理”会难受很多。2.2 一个真实案例排行榜在两种引擎上的实现成本我讲一个很典型的业务实时排行榜。需求是按分数降序展示 Top 100 用户分数变化频繁一个用户一秒钟可能变动好几次。如果基于 Memcached 实现你首先得有一个有序数据源比如 MySQL 里的分数表再来设计缓存 key 缓存整个排行榜结果。用户每次分数变动你会面临两个选择要么直接删掉排行榜缓存让下一次请求重新查库这个操作在高流量下很容易引发缓存击穿要么后台异步重算那客户端看到的 Top 100 永远滞后几秒甚至几十秒重算时还要处理并发写的问题。要是想用 incr 去更新用户分数那更麻烦——Memcached 在服务端没有“按分数维护有序集合”的能力只能把整个列表取出来、改完再塞回去数据量稍大成本就完全失控。换成 Redis只需要一张 ZSet。分数变动时执行 ZADD leaderboard 100 user_id排序由服务端维护要拿 Top 100 就执行 ZREVRANGE leaderboard 0 99 WITHSCORES分数加多少用 ZINCRBY 一行命令搞定原子且天然支持并发。实现复杂度从“后端团队设计一套缓存一致性方案”直接降到“两三行 Redis 命令”。这种差距不是调优能补回来的是数据模型层面的代差。每次有人跟我争论“Memcached 也够用”我都会拿这个例子问你确定你们团队能把排行榜这类需求的缓存一致性做好很多时候对方沉默问题就已经有答案了。3. 持久化与高可用缓存重启之后数据还在吗3.1 RDB 与 AOFRedis 为什么敢说自己不止是缓存Memcached 对重启的态度很坦率数据丢了就丢了反正上层还有数据库缓存本来就是可失的。这个“精致懒汉”的设计在不少场景下完全合理。但问题在于不是所有放进缓存的数据都能接受“丢了重新拉”。举个例子实时榜单可能算了两个小时机器一重启就全没了限流计数器统计了一个时段的数据丢了整个统计就失真还有一些被当作临时存储使用的业务数据一旦丢失会造成业务异常。这些场景里持久化不是可有可无而是刚需。Redis 提供了两条持久化路径。RDB 是定期做全量快照默认配置下 60 秒内如果有超过 1 万次写就会自动触发 BGSAVE由子进程 fork 出来后异步写盘。优点是恢复快、文件紧凑缺点是快照间隔期间的数据可能丢。AOFAppend Only File则是把每次写命令追加到日志文件配合 fsync 策略来控制丢失窗口always 每次写都刷盘最安全但慢everysec 每秒刷盘最多丢约 1 秒数据no 交给操作系统。官方从 Redis 4.0 开始支持 RDB AOF 混合持久化用 RDB 保存某一时刻的完整状态再用 AOF 记录后续增量文件既有 RDB 的紧凑高效又有 AOF 的最小丢失保证。生产环境的主流配置是开启 AOF 并设置 appendfsync everysec极端宕机时最多丢约 1 秒的写数据绝大多数业务都可以接受。3.2 主从、哨兵、Cluster从单机到生产集群的进化路径Memcached 本身没有主从或集群能力。多节点部署通常靠客户端一致性哈希把请求分散到不同机器一台机器挂了它负责的那部分数据直接失效由客户端把流量重新路由到其他节点。因为没有数据复制每台机器都是“无状态”的这其实是 Memcached 在纯缓存定位下的一种优势——简单不背数据一致性的锅。但对 Redis 使用者来说单点永远不够所以官方把高可用做成了一套完整的体系。主从复制解决读扩展和故障时的数据冗余写主库、读从库从库异步同步主库的 RDB 快照加后续命令流。Sentinel哨兵在主库宕机时通过投票选举新主库并自动通知客户端切换连接把故障恢复时间从人工干预的分钟级压缩到自动切换的秒级。Cluster 则把 16384 个槽位分配给多个主节点每个主节点又能带若干从节点既实现了分片扩容又能在主节点故障时由从节点自动接管。相比 Memcached 靠客户端散列的方案Redis Cluster 把数据分布、重分片、故障转移都收敛到了服务端运维心智负担小很多。这里也顺带回答一个高频面试题Redis 集群的 key 是怎么分布的答案就是哈希槽而不是一致性哈希这和 Memcached 的客户端一致性哈希方案有本质区别。3.3 主从复制里容易被忽视的坑高可用不等于开了复制就万事大吉。最容易踩的坑之一是全量同步风暴主库宕机重启后多个从库同时连上来要求全量同步主库要同时 fork 子进程生成 RDB 并发送内存和网络瞬间被打满主库可能出现短暂的不可用。另一个坑是复制积压缓冲区 repl-backlog-size 设置太小从库短暂网络抖动就会导致复制中断断开后又要重新全量同步。我见过一个小项目从库每次网络波动都全量重连主库频繁 fork最后是调大 backlog 并限制同时重连的从库数量才稳定下来。Redis 的高可用比 Memcached 复杂不少复杂本身换来的是数据安全和自动故障转移但代价是团队必须投入相应的运维能力。别指望不学习、不配置就把哨兵集群搭起来那种“开箱即用”的幻想在 Redis 上是不存在的。4. 业务利器分布式锁与缓存治理的晋升之路4.1 用 Redis 实现分布式锁的正确姿势以及它的边界聊到分布式锁业界默认想到的就是 Redis。原理大家都熟在 Redis 中 set 一个带过期时间、带唯一标识的 key谁设置成功谁拿到锁。但正确姿势比很多人想象中严格得多。第一必须使用 SET key value NX PX 3000 这样的原子命令不能拆成 SETNX 再 EXPIRE 两步——两步之间如果进程崩溃就会出现“锁永远不释放”的死锁问题。第二value 要携带唯一标识比如 UUID释放锁时用 Lua 脚本先比对再删除防止线程 A 因为业务执行时间过长导致锁过期线程 B 拿到新锁后A 又把 B 的锁误删。第三过期时间不能拍脑袋要评估业务临界耗时设太长服务挂了锁要等半天设太短业务没执行完锁就提前释放。我给过一个经验值参考如果业务内没有外部 RPC锁的过期时间至少留业务平均耗时的 3 到 5 倍如果业务内有外部调用那要重新设计尽量把外部调用移出临界区。还要强调一点分布式锁的可靠性是有边界的。如果在主库上加了锁但主库还没同步给从库就宕机了新主库上这把锁就丢了另一个节点就可能同时拿到锁。Redlock 算法试图用多节点投票来解决这个问题但业界对这个算法本身有不少反对声音核心争议是它依赖时钟和锁过期时间不是绝对安全的。我的观点是如果业务对“同一时刻只能有一个执行者”有强一致要求推荐直接考虑数据库唯一约束或 ZooKeeper 这类带强一致模型能力的组件而不是硬把 Redis 当成强一致锁来用。如果业务能接受极低概率的并发重复Redis 分布式锁是性价比极高的方案。这个定位要先摆正才不会被面试官一句话问倒。4.2 穿透、击穿、雪崩为什么缓存治理的方案几乎都围绕 Redis 设计缓存治理的三个经典问题——穿透、击穿、雪崩业内沉淀的成熟手段大多和 Redis 深度绑定。缓存穿透是大量请求访问不存在的 key每次都打到数据库最直接的方案是“空值缓存”把不存在的 key 也写进缓存带一个很短的过期时间同时加布隆过滤器前置拦截。布隆过滤器在 Redis 里可以用 BitMap 逐位实现也可以用 Redis Stack 的 BF 模块几条命令完成初始化、写入和查询这在 Memcached 里是完全没有落点的。缓存击穿是某个热点 key 过期瞬间流量全部打到数据库Redis 场景的常见解法是互斥锁重建缓存重建缓存的线程先抢分布式锁其他线程短暂等待或直接返回旧值配合逻辑过期时间做后台异步刷新。缓存雪崩是大面积 key 同时过期除了给过期时间加随机基础抖动还可以用 Redis 的 Lua 脚本在服务端原子化完成“查缓存、查库、回填”的动作减少多轮网络往返。你会发现这些方案里Redis 的角色不只是存储层更是计算层。它靠 Lua 脚本、BitMap、过期策略和分布式锁把本来要写在应用代码里的一致性逻辑收敛到了缓存服务内部。Memcached 的 get/set 模型在这些场景下只能当“透明储物柜”所有判断、回填、原子操作都要应用自己写业务复杂度直线上升。这也是为什么很多团队做缓存设计时模板直接默认为 Redis——不是因为大家都在用而是因为它的能力边界确实覆盖了这些治理需求。5. 性能实测与“秒杀”结论的边界5.1 多线程 Memcached 在纯 KV 场景并不弱聊到这里我还是得给 Memcached 说几句公道话。Redis 的功能碾压不代表它在所有性能指标上都碾压。早年国内外有不少压测对比结论相似在纯粹 get/set 的大流量场景Memcached 的多线程模型在多核机器上经常能和 Redis 打平甚至在连接数较多、读请求占主导的情况下还能略胜一点点。原因不复杂Memcached 从架构上就把“多线程、无持久化、直接操作内存 slab”这件事做到了极致每个线程独立处理一部分连接命令语义简单不需要考虑复杂数据结构的执行开销也没有 AOF 日志写入带来的磁盘扰动。Redis 在单条命令处理上极其高效但单线程终究只吃一个核心一旦 CPU 有多余的核心Memcached 的多线程模型是实实在在能吃到的多核红利。有人可能追问Redis 不是也有 6.0 的多线程 I/O 吗对但它的多线程主要用于网络读写命令执行仍然单线程整体扩展性和 Memcached 那种“每个线程完全独立处理连接”的模型仍有区别。如果你真的在做一个极致简单的 KV 缓存层流量巨大且多核充足Memcached 不该被无脑淘汰。5.2 Redis 的版本演进单线程的瓶颈正在被一点点解决Redis 这边也没有坐以待毙。Redis 6.0 引入 I/O 多线程后高连接数场景下的瓶颈明显缓解虽然默认关闭但开启后收益可观。Redis 7.0 在数据结构编码上做了大优化Hash、List、ZSet 的少量元素默认采用 listpack 紧凑存储内存占用显著下降碎片问题也得到改善AOF 重写机制演进为多部分 AOF崩溃恢复粒度更细重启加载更快。这些年 Redis 的演进思路非常清晰命令执行保持单线程的确定性同时把网络、持久化、数据编码这些可以并行的环节逐步多线程化。你可以把 Redis 理解为一辆单座赛车——驾驶员永远不换但进站加油、换轮胎这些环节越来越快。实际生产中Redis 在典型业务负载下跑出几十万 QPS 并不稀奇真实压测中单机四万连接的场景也能保持十万级 QPS这已经覆盖了绝大多数公司的业务压力。5.3 把“秒杀”说得准确一点所以回到“Redis 秒杀 Memcached”这句话我会这样拆解它的适用范围对比维度RedisMemcached数据结构String/Hash/List/Set/ZSet/Geo/Stream 等仅字节串持久化RDB/AOF/混合无故障转移Sentinel/Cluster 自动切换客户端自行处理分布式锁/原子流程天然支持不支持或极难超纯 KV 场景性能很强单线程有边界多核下有优势运维复杂度较高低功能维度、业务覆盖维度、生态维度上Redis 是碾压级的“秒杀”但在“纯内容缓存”这个狭窄的性能赛道里Memcached 仍有自己的一亩三分地。你做的是一个只有 KV 读写的 cache layer流量大到需要多核并行都算不过来那 Memcached 是值得继续服役的老兵你要做排行榜、分布式锁、限流、消息队列、布隆过滤器、附近的人、UV 统计那 Memcached 一个都接不住Redis 的组合能力是代际差距。选型的时候别听口号要根据业务模型找发力点。6. 选型建议与部署踩坑记录6.1 什么样的业务才值得继续用 Memcached给一个可以落地的判断框架满足以下条件里至少三条用 Memcached 不算错业务里只有 String 内容缓存比如会话信息、渲染片段、API 响应快照对数据重启丢失完全无感丢了重新查库即可主要性能压力在高并发读对多核扩展有明确要求团队没有精力维护持久化、主从、哨兵这套体系。相反只要业务出现下面任一特征我会果断选 Redis需要除字节串外的任何数据结构任何一点数据丢失都会导致业务异常需要主从或哨兵自动故障转移需要做分布式锁或复杂原子操作需要 ACL 权限控制和更细粒度的安全能力甚至只是“以后可能会用到”这些能力——Redis 的迁入成本远低于你后面从 Memcached 改造过来的代价。这里多说一句如果你已经用了 Memcached 且系统很稳没必要为了追新强行迁移但如果要建新系统我不建议再从 Memcached 起步了相当于在现代工程里选择了一台功能受限的发动机。6.2 部署与日常运维高频踩坑的几个点第一个绕不开的是 Windows 安装 Redis。官方一直没有正式支持 Windows最常见的开发环境方案是下载微软早期的旧版本分支或者开源社区维护的 tporadowski/redis它基于 5.0.x日常开发够用。但 Windows 下想跑接近生产级的 Redis建议直接用 WSL2 装 Linux 版或者用 Docker Desktop 起 Redis 容器能少踩很多兼容性的坑。第二个是设置密码。生产环境务必在 redis.conf 里配置 requirepass主从或哨兵模式下还要给节点间通信配置 masterauth别只在单机测试时想到密码等上了主从才发现从库连不上主库、反复断连重连才回头补。这个问题我实际遇过从库日志刷了一堆验证失败排查了好久才发现是 masterauth 没填。第三个是 Docker 部署。不少人在 Docker Desktop 上执行 docker search redis 时报 internal server error提示 server 不支持请求的 API 版本。这个通常不是镜像仓库本身的问题而是 Docker Desktop 引擎版本和仓库 API 版本不匹配或者本地代理环境异常。升级 Docker Desktop、清理引擎缓存、检查代理配置多数能解决。如果只是想起一个 Redis 容器直接 docker pull redis:7 再 docker run 就行完全不需要依赖 search 命令。第四个是可视化工具。老牌的 Redis Desktop Manager 免费版后来不再对外发布开源社区里 Another Redis Desktop Manager 用得比较多跨平台、支持集群和哨兵、自带内存分析和 key 过期扫描日常调缓存比纯命令行舒服太多。你至少应该装一个排查线上 key 分布和过期情况时效率完全不一样。6.3 Redis 底层部署容易忽视的操作系统参数再往下Redis 的性能发挥很依赖操作系统。这里特地说三个容易被忽略的参数都是线上出过事故的vm.overcommit_memory 要设置为 1。BGSAVE 需要 fork 子进程如果内存分配策略过严fork 可能直接失败Redis 的后台保存会静默出问题这是很多“明明 set 了持久化配置却一直没有 RDB 文件”的隐藏原因。关闭 Transparent Huge PagesTHP。THP 在 fork 和内存复制时会引入明显的延迟波动生产环境建议 echo never /sys/kernel/mm/transparent_hugepage/enabled否则压测时能看到不规律的耗时毛刺。调大 net.core.somaxconn。Redis 的 tcp-backlog 默认 511但内核默认的 somaxconn 很多时候只有 128连接峰值时大量连接会被内核直接丢弃客户端会报 “cannot assign requested address” 一类连接异常先查这个参数往往一查一个准。结尾这里说点个人习惯每次搭建新的 Redis 环境我都会把上面三个参数先固化到初始化脚本里而不是等线上炸了再去排查。缓存和中间件层面的坑大多是细节堆出来的像 Windows 安装版本混乱、Docker 动不了 search、主从 masterauth 忘配、THP 没关这种问题反复出现在不同团队的不同项目里。你把常见坑提前堵住后面能省下的排查时间远比刚开始那几分钟配置时间多。Redis 和 Memcached 之争还会持续很多年但真正拉开差距的从来不是某个口号而是你对底层机制和数据模型的把控程度。