做后端开发这些年Redis和Memcached几乎每次聊到缓存都绕不开特别是涉及“Redis与Memcached的区别”这种经典问题。这俩名字经常同时出现但真被问到“具体差在哪业务上怎么选”能说清楚的人其实不多。作为一个跟缓存打过多年交道的从业者我觉得这篇内容值得你花几分钟看完至少在下一次技术评审被问到“为什么用Redis不用Memcached”的时候你能给出有理有据的答案而不是含糊地用“Redis更强”对付过去。这篇文章会从数据模型、持久化、高可用、并发模型、分布式锁、缓存治理这几个维度拆开讲最后给出一份我自己实际踩坑总结的选型建议。适合正在做技术选型、准备从Memcached迁移到Redis、或者面试前想系统梳理缓存知识的同学也适合运维和架构师参考其中的参数与配置经验。1. 核心定位同为内存缓存为何风格迥异1.1 诞生背景与设计初心Memcached诞生在2003年当时LiveJournal的数据库屡屡被高并发访问压垮团队就写了一个分布式的内存对象缓存系统把数据库查询结果、页面渲染片段等塞进内存用极其简单的方式扛住流量。它的核心设计目标就一句话做一个极致的缓存。所以它把“简单”刻进了骨子里多加一台服务器就多一份缓存容量代码简单、协议简单、运维也简单。Redis是2009年由Salvatore Sanfilippo开发的当时他的出发点不只是“缓存”而是想做一个更通用的内存数据存储。他发现很多业务逻辑里数据结构不止“字符串到字符串”这么简单经常需要list、set、hash这种原生操作如果每次都靠客户端用字符串硬拼序列化代码很难维护性能也有损耗。Redis最初就是为解决这些“麻烦数据”而生的这也是它后来长出几十种数据类型、持久化、集群、脚本等一系列能力的基础。1.2 一句话概括各自定位用大白话讲Memcached是一块非常快的内存你往里扔什么它就存什么Redis则更像是一个住在内存里的多功能工具箱内置各种数据结构还能把数据落地到磁盘断电重启后把数据找回来。这两种定位直接决定了后续所有差异。Memcached把“简单、快、可水平扩展”做到极致代价是功能少、数据不安全Redis把“功能丰富、数据可靠、玩法多样”做到极致代价是内部机制更复杂部署运维要懂的东西更多。这里没有绝对谁比谁强只取决于你的业务到底需要哪种能力。2. 数据结构Redis抛离Memcached的第一道分水岭2.1 Memcached的数据模型Memcached在协议层面只认一种数据key-value其中key是字符串value是一段不透明的字节序列。你在客户端把一个对象序列化成JSON或者二进制存进去取出来的时候再反序列化。它自己完全没有“列表”“集合”“哈希”的概念你要排序、去重、统计全得在客户端自己用代码完成。还有一个很现实的上限单条value默认最大1MB。一旦超过这个尺寸要么优化存储方案要么换工具。这个1MB限制是编码在设计时就写死的后续版本即便可以调整也需要编译时配置实际并不建议破坏默认值。2.2 Redis数据类型的“武器库”Redis从第一天起就不满足于保存“字符串”它现在能提供的核心数据结构包括String、Hash、List、Set、Sorted Set、Bitmap、HyperLogLog、Geo、Stream。每种类型底层还有不同的编码方式比如List在元素少时用压缩列表元素多了会转成快速链表zset在数据量小时用压缩列表量大之后换跳表加哈希表。这些优化是Memcached完全不存在的概念。比如String内部的int编码、embstr编码、raw编码对包含整数的小字符串用更紧凑的存储Hash和zset在字段数少于128个且每个字段长度小于64字节时会用ziplist压缩存储内存占用大幅降低。这些底层编码对开发者透明但不理解它们就可能在内存优化和大key分析时一头雾水。2.3 数据结构差异如何影响业务设计我们拿真实业务来看假设要做一个排行榜。Memcached的做法是把所有用户ID和分数序列化成一个大字符串存进去每次更新分数就要全量读出来、改、再写回去并发一高就乱套而且每次读写都传整个榜单网络开销同样感人。Redis只需要一个zsetZADD一条命令就可以更新某个成员的分数ZREVRANGE一条命令取出前N名接口语义清晰性能稳定还不占用额外内存。再比如计数器电商里“浏览量1”这种需求Memcached只能用incr/decr命令它支持原子加减但只能在单一key上操作Redis的incr不仅可以做单key计数还可以配合Hash对多个字段分别计数配合过期时间做自然衰减的防刷逻辑灵活性高不少。消息队列更典型Memcached根本没有队列概念而Redis的List的LPUSH/RPOP/LBRPOP带阻塞弹出的语义配上Stream还能实现正式的消费组模式。这些差异看起来是“数据类型多少”的问题实际是“业务逻辑放在服务端做还是客户端做”的问题。Redis把更多通用、常用、要保证原子性的逻辑下沉到了服务端代码写起来简洁出错概率也低得多。3. 持久化与架构演进从“缓存”到“数据服务”3.1 只有内存与可落盘的差别Memcached的所有数据都在内存里进程一退出、机器一重启、内存一换就全没了。对缓存场景来说这可以接受反正缓存丢了再回源数据库即可。但如果你的业务里有些热点数据回源代价很大比如聚合计算几亿条日志生成的结果集一旦缓存全丢数据库瞬间压力飙升很容易把平台打死。Redis默认也把所有数据放内存但它提供了持久化能力能在崩溃重启后恢复数据。这就让Redis在用起来的时候定位完全不同它既可以当“缓存”也可以当一个轻量级的内存数据库承担一些对持久化要求不那么极致的存储任务。3.2 RDB/AOF与数据恢复策略Redis持久化有两种主流方式。RDB是定期把内存数据生成一份二进制快照文件恢复极快适合备份、灾难恢复但它是“按时间点快照”遇到最后一次快照之后的数据变更会丢。AOF是追加日志每一条写命令都记录下来可以在重启时重放命令恢复数据AOF有几种刷盘策略比如appendfsync everysec表示每秒刷盘数据最多丢一秒平衡了可靠性和性能。实际生产里我比较推荐把两种机制结合RDB做定期备份AOF做增量恢复这是我在恢复过好几次误删数据后总结出来的稳妥方案。补充一个高频问题Redis持久化会阻塞主线程吗RDB用的方式是fork子进程来生成快照主线程继续处理命令但fork瞬间需要复制页表内存大时仍可能造成毫秒级卡顿AOF的重写也是类似思路利用子进程后台重写再合并。使用容器或者超大内存数据集时尤其要关注fork耗时不要让Redis跑在内存吃紧的机器上。3.3 主从复制、Sentinel与ClusterRedis自带的主从复制能很大程度上提升可用性。主节点写、从节点读数据异步同步主节点挂掉之后可以通过Sentinel哨兵自动把某个从节点提升为主节点业务侧几乎无感知。Redis Cluster则更进一步把数据按16384个槽位水平分片到多个主节点每个主节点还可以配从节点做故障转移达到“容量可扩展、高可用自治”。Memcached在官方层面没有主从、没有哨兵、没有数据分片方案。你在生产环境里部署多台Memcached本质上是客户端把key hash到不同机器上某台挂了它上面那一部分缓存就瞬间全没客户端需要容忍“部分key找不到”并回源。这种简单模型在中小规模够用但在对可用性要求高的核心链路里会很被动这也是很多团队从Memcached迁移到Redis的关键原因。4. 并发模型与内存管理底层机制和性能边界4.1 多线程与单线程的取舍Memcached从很早的版本就使用多线程模型主线程负责接收连接工作线程负责处理命令。多线程的好处是能更好地利用多核CPU在Linux下通常能跑到比较高的并发吞吐。代价是必须处理锁竞争、线程安全、连接队列等复杂问题如果读过memcached源码会发现它的内存分配和命令处理流程里到处是锁和原子操作。Redis长时间内是单线程事件循环模型所有命令按顺序执行不存在锁竞争因此单个Redis实例的行为可以预测多个客户端同时操作一个key的时候天然串行不用费心考虑并发安全。你可能会疑问单线程怎么顶得住高并发答案在于Redis的命令都是内存操作速度极快真正耗时的地方往往是网络IO和解析命令而这些恰好可以由epoll多路复用高性能处理。实测中绝大多数业务的瓶颈根本不在Redis单线程的处理能力上而在网络带宽、客户端连接数、大key的传输成本上。注意Redis 6.0开始引入了多线程IO处理网络读写但命令的执行还是单线程。也就是说网络包的解析、发送可以多线程辅助但核心的数据操作、脚本执行仍保持严格串行。这种设计既改善了高并发场景下网络IO导致的CPU瓶颈又保留了“单线程命令原子性”的优势。很多人被“Redis单线程”这个旧概念误导以为Redis无法利用多核实际上官方早就针对这个做了增强只是你使用的方式要对。4.2 内存分配与淘汰策略Memcached的内存管理非常有特色它把内存按固定大小划分成多个slab每个slab里再切成固定大小的chunk。对象存进来时系统按对象大小找一个合适的chunk放进去。这样做的好处是几乎不产生传统malloc/free的碎片性能稳定坏处也很明显——如果value大小分布不均匀一个200字节的对象和一个1KB的对象可能都被塞进同一个slab浪费空间或者被迫占用更大的chunk内存利用率反而不高。Redis则直接使用内存分配器默认是jemalloc也可以选tcmalloc或libc。它没有slab分区内存按需分配灵活性好配合丰富的数据结构编码比如Hash的小字段用压缩存储在存相似逻辑的数据时Redis的内存利用率通常比Memcached高。比如同样存一千个用户资料Memcached要存一千个序列化字符串Redis可以用一个Hash存一千个字段头部开销小很多。4.3 实践中的性能测试记录我之前给一个活动系统做过压测同样一批热点商品数据分别放在Memcached和Redis里单机8核16G。Memcached在纯GET场景下能跑到约12万QPSRedis在纯GET场景下约10万QPS差距其实很小但如果业务是“排行榜实时更新读取”这种复杂操作Memcached几乎无法支撑因为队列、排序逻辑在客户端做光网络来回就多得惊人。结论是如果你的场景只是一对一的KV缓存Memcached的优势确实存在场景稍微带点数据结构要求Redis的架构优势就是压倒性的。5. 分布式锁与高并发场景Memcached很难替代的差距5.1 先看一个真实的分布式锁需求微服务架构里经常有这种需求多个实例同时处理订单同一个用户同一时刻只能有一个单子被创建否则会重复下单。大家想到的方案基本就是“用分布式锁”。选型时很多团队第一反应是Redis因为Redis有原生的原子命令可以用来加锁但也有人问“Memcached不也可以吗它有add和cas啊”。这个问题还真值得掰开讲。5.2 Redis实现分布式锁的正确姿势Redis实现分布式锁最常见的方式是SET key value NX EX seconds。NX表示key不存在时才设置成功EX表示过期时间。这样一条命令同时保证了“并发只有一个客户端能拿到锁”和“锁不会永远不释放”。释放锁的环节有个经典坑必须先确认value是当初自己设置的再删除否则可能出现A的锁还没到时间被B覆盖A执行完后把B的锁删了。正确做法是配合Lua脚本原子地做“GET比对DEL”。如果要求更高的安全性官方还有RedLock算法在多个Redis节点上分别加锁超过半数成功才算加锁成功。具体要不要上RedLock业界也有争议但至少单体Redis的SET NX EX方案已经能覆盖绝大多数需求。5.3 Memcached为什么不好做分布式锁Memcached也有原子操作比如add只有key不存在时才放入等于抢锁成功但它缺少“带自动过期且能安全释放”的完整组合。你可以先用add抢锁然后靠过期时间兜底但释放时用delete又会误删别人的锁要用cas来保证“只有版本相同的才删除”但cas要额外维护一个版本令牌跨语言的客户端实现还得各自封装一套复杂度远高于Redis的Lua脚本。更麻烦的是Memcached没有持久化也没有主从复制锁所在的那台机器一旦宕机锁数据随内存一起蒸发整个分布式锁机制直接瘫痪。所以即便Memcached理论上有能力实现一个简单的锁工程上也很少有人真的这么干。6. 缓存治理穿透、击穿、雪崩的关键应对6.1 缓存穿透的两种常规解法缓存穿透指的是客户端大量请求一个“缓存里没有、数据库里也不存在”的key导致每次请求都打到数据库。数据库虽然能扛住一部分但在恶意刷接口或构造不存在的ID场景下压力很快失控。常见解法一个是空值缓存当查到数据库结果为空时也把这个“空结果”缓存成空值并给一个较短的过期时间防止同一ID反复穿透另一个是布隆过滤器把所有可能存在的ID预先放入一个超大的位图里请求进来先问“这个ID在不在位图里”不在就直接拦截不再查库。布隆过滤器可以用Redis的bitmap实现也可以直接用Redisson等客户端封装好的接口。6.2 缓存击穿与雪崩的处理缓存击穿是“某个热点key过期瞬间海量请求同时打向数据库”。处理思路有几种互斥锁缓存没有时先抢锁抢到锁的人才允许查数据库并回填缓存其他人等待逻辑过期缓存里保存一个逻辑过期时间线程发现逻辑过期后尝试拿锁重新加载下次读取时再给旧数据。这两种方案我都实际用过取舍还不小。缓存雪崩则是“大量key同时过期”或“缓存节点整体宕机”导致数据库被巨量请求淹没。应对手段包括给缓存过期时间加随机偏移让过期时间分散开开启Redis高可用避免单点服务端做限流降级把最低限度的流量放进系统。6.3 日常缓存治理的监控与优化这里分享一下我的日常运维清单第一监控Redis的慢日志slowlog get会暴露哪些命令耗时异常通常是大key或者复杂命令第二监控内存和键数量增长趋势防止key无限堆积导致内存暴涨第三定期分析大key和热key大key可以用redis-cli --bigkeys来扫描热key则要依靠客户端记录访问频率或使用代理层统计。找到热key后可以考虑在本地内存加一层二级缓存或者把这个key复制到多台主从实例中分散读压力。Memcached在这方面的治理手段就简单很多没有慢日志、没有脚本分析基本只能靠外部监控工具去采集stats数据管控粒度粗很多。7. 选型建议与踩坑实录7.1 什么时候继续用Memcached说了这么多Redis的强势我也要客观地说如果业务足够简单Memcached依然是很好的选择。缓存数据是纯KV、value是简单的字符串或字节数组、不需要排序聚合、数据丢了无所谓、团队只想要一个“速度快且好维护的缓存”那Memcached完全够用而且它多线程模型在某些纯读场景下吞吐确实可观部署和配置也简单。特别是你已经有一套成熟的Memcached集群和维护经验贸然迁移Redis如果只是图心理安慰反而可能引入新风险。7.2 什么时候应该上Redis业务里出现下列任何一种需求都建议认真考虑Redis需要Hash/List/Set/zset这类原生数据结构需要持久化恢复需要主从复制、哨兵或Cluster高可用需要分布式锁、消息队列、发布订阅等能力有缓存治理、慢查询分析、数据淘汰策略细粒度控制的需求。现在的Redis生态比Memcached完整太多客户端库、可视化工具、监控平台、中间件都是现成的开发效率放在那里。7.3 实际踩坑记录与常见问题速查我整理几个自己亲身踩过或者帮别人救过场的案例。第一个是“Windows上装Redis”热词里也高频出现。官方其实不提供Windows发行版网上能下的要么是微软老版本维护分支要么是第三方编译包。我一般测试环境直接改用Docker跑redis官方镜像生产更是建议Linux。Windows下如果你想随手玩一下可以用RedisDesktopManager这类可视化工具连接远程实例而不是折腾Windows本地服务。第二个是“redis incr不准”。很多人发现自己用incr做计数结果值不是预期。多半是并发下多个实例同时incr之后又做了一次set覆盖或者对过期时间设置不合理其实incr本身是原子的只是上游代码没有把“读-改-写”收敛成一条命令。建议检查是否有先读再写回的逻辑统一改用incr/incrby这类原子操作。第三个是“可视化客户端连不上”。遇到redis desktop manager或another redis desktop manager连不上redis我记得最常见的三种原因bind配置只绑定了127.0.0.1protected-mode开启导致拒绝外部连接Redis 6之后的ACL权限没配置。解决方法是根据环境修改bind、关闭protected-mode或在配置里设置requirepass密码连接时打开TLS选项如果服务端启用了TLS。当然生产环境不要随意关闭保护安全底线还是要守住。第四个是“docker安装redis主从”。很多教程简单映射两个redis容器就完事实际容易踩的坑是主从复制的bind和replicaof配置不对。我习惯用一个docker-compose文件把主从服务和哨兵服务组织起来主容器暴露端口从容器里配replicaof master host port哨兵里配sentinel monitor master 主服务名 端口 1。测试时记得容器网络要互通不然从节点一直连不上主节点日志里全是-NOMASTERLINK。还有一个比较有意思的问题是“redis哨兵模式和集群模式的区别”。简单说哨兵模式解决的是“高可用”它本身不存数据只负责监控主从节点主挂了自动把从提升为主对外始终只有一个写入口集群模式解决的是“扩展性”它把数据分片到多个主节点每个主节点还可以配从节点实现分片内的高可用。小规模高可用可以只上哨兵数据量大、对写入扩展有要求才需要集群。最后聊聊迁移从Memcached迁移到Redis其实不是换个连接串就完事。协议不同客户端必须重写持久化数据的迁移也要设计常见做法是启动双写一段时间先让Redis承担读逐步切换写流量最后断开Memcached。我试过一次比较急的全量迁移一个大key列表迁移完第二天就发现内存涨得飞快排查半天发现是原本Memcached里那些超大value对象在Redis里保存成了一个大String完全没有发挥Hash在字段维度上的压缩优势。后来我按业务模型拆成Hash字段内存占用直接降了一半还多。做这套选型和技术对比我自己最大的体会是技术工具没有绝对的“更好的那个”只有“更适合你这个业务的那个”。Redis确实在很多维度上更强大但强大也意味着复杂如果业务只需要一个简单的KV缓存你用Redis反而可能要处理持久化、淘汰策略、集群拓扑这些额外心智负担。反之如果业务已经把Memcached罩不住的需求摆在桌面上了也别犹豫早点切换拖着只会让技术债越滚越大。
Redis与Memcached选型指南：从数据结构到缓存治理的全面对比
做后端开发这些年Redis和Memcached几乎每次聊到缓存都绕不开特别是涉及“Redis与Memcached的区别”这种经典问题。这俩名字经常同时出现但真被问到“具体差在哪业务上怎么选”能说清楚的人其实不多。作为一个跟缓存打过多年交道的从业者我觉得这篇内容值得你花几分钟看完至少在下一次技术评审被问到“为什么用Redis不用Memcached”的时候你能给出有理有据的答案而不是含糊地用“Redis更强”对付过去。这篇文章会从数据模型、持久化、高可用、并发模型、分布式锁、缓存治理这几个维度拆开讲最后给出一份我自己实际踩坑总结的选型建议。适合正在做技术选型、准备从Memcached迁移到Redis、或者面试前想系统梳理缓存知识的同学也适合运维和架构师参考其中的参数与配置经验。1. 核心定位同为内存缓存为何风格迥异1.1 诞生背景与设计初心Memcached诞生在2003年当时LiveJournal的数据库屡屡被高并发访问压垮团队就写了一个分布式的内存对象缓存系统把数据库查询结果、页面渲染片段等塞进内存用极其简单的方式扛住流量。它的核心设计目标就一句话做一个极致的缓存。所以它把“简单”刻进了骨子里多加一台服务器就多一份缓存容量代码简单、协议简单、运维也简单。Redis是2009年由Salvatore Sanfilippo开发的当时他的出发点不只是“缓存”而是想做一个更通用的内存数据存储。他发现很多业务逻辑里数据结构不止“字符串到字符串”这么简单经常需要list、set、hash这种原生操作如果每次都靠客户端用字符串硬拼序列化代码很难维护性能也有损耗。Redis最初就是为解决这些“麻烦数据”而生的这也是它后来长出几十种数据类型、持久化、集群、脚本等一系列能力的基础。1.2 一句话概括各自定位用大白话讲Memcached是一块非常快的内存你往里扔什么它就存什么Redis则更像是一个住在内存里的多功能工具箱内置各种数据结构还能把数据落地到磁盘断电重启后把数据找回来。这两种定位直接决定了后续所有差异。Memcached把“简单、快、可水平扩展”做到极致代价是功能少、数据不安全Redis把“功能丰富、数据可靠、玩法多样”做到极致代价是内部机制更复杂部署运维要懂的东西更多。这里没有绝对谁比谁强只取决于你的业务到底需要哪种能力。2. 数据结构Redis抛离Memcached的第一道分水岭2.1 Memcached的数据模型Memcached在协议层面只认一种数据key-value其中key是字符串value是一段不透明的字节序列。你在客户端把一个对象序列化成JSON或者二进制存进去取出来的时候再反序列化。它自己完全没有“列表”“集合”“哈希”的概念你要排序、去重、统计全得在客户端自己用代码完成。还有一个很现实的上限单条value默认最大1MB。一旦超过这个尺寸要么优化存储方案要么换工具。这个1MB限制是编码在设计时就写死的后续版本即便可以调整也需要编译时配置实际并不建议破坏默认值。2.2 Redis数据类型的“武器库”Redis从第一天起就不满足于保存“字符串”它现在能提供的核心数据结构包括String、Hash、List、Set、Sorted Set、Bitmap、HyperLogLog、Geo、Stream。每种类型底层还有不同的编码方式比如List在元素少时用压缩列表元素多了会转成快速链表zset在数据量小时用压缩列表量大之后换跳表加哈希表。这些优化是Memcached完全不存在的概念。比如String内部的int编码、embstr编码、raw编码对包含整数的小字符串用更紧凑的存储Hash和zset在字段数少于128个且每个字段长度小于64字节时会用ziplist压缩存储内存占用大幅降低。这些底层编码对开发者透明但不理解它们就可能在内存优化和大key分析时一头雾水。2.3 数据结构差异如何影响业务设计我们拿真实业务来看假设要做一个排行榜。Memcached的做法是把所有用户ID和分数序列化成一个大字符串存进去每次更新分数就要全量读出来、改、再写回去并发一高就乱套而且每次读写都传整个榜单网络开销同样感人。Redis只需要一个zsetZADD一条命令就可以更新某个成员的分数ZREVRANGE一条命令取出前N名接口语义清晰性能稳定还不占用额外内存。再比如计数器电商里“浏览量1”这种需求Memcached只能用incr/decr命令它支持原子加减但只能在单一key上操作Redis的incr不仅可以做单key计数还可以配合Hash对多个字段分别计数配合过期时间做自然衰减的防刷逻辑灵活性高不少。消息队列更典型Memcached根本没有队列概念而Redis的List的LPUSH/RPOP/LBRPOP带阻塞弹出的语义配上Stream还能实现正式的消费组模式。这些差异看起来是“数据类型多少”的问题实际是“业务逻辑放在服务端做还是客户端做”的问题。Redis把更多通用、常用、要保证原子性的逻辑下沉到了服务端代码写起来简洁出错概率也低得多。3. 持久化与架构演进从“缓存”到“数据服务”3.1 只有内存与可落盘的差别Memcached的所有数据都在内存里进程一退出、机器一重启、内存一换就全没了。对缓存场景来说这可以接受反正缓存丢了再回源数据库即可。但如果你的业务里有些热点数据回源代价很大比如聚合计算几亿条日志生成的结果集一旦缓存全丢数据库瞬间压力飙升很容易把平台打死。Redis默认也把所有数据放内存但它提供了持久化能力能在崩溃重启后恢复数据。这就让Redis在用起来的时候定位完全不同它既可以当“缓存”也可以当一个轻量级的内存数据库承担一些对持久化要求不那么极致的存储任务。3.2 RDB/AOF与数据恢复策略Redis持久化有两种主流方式。RDB是定期把内存数据生成一份二进制快照文件恢复极快适合备份、灾难恢复但它是“按时间点快照”遇到最后一次快照之后的数据变更会丢。AOF是追加日志每一条写命令都记录下来可以在重启时重放命令恢复数据AOF有几种刷盘策略比如appendfsync everysec表示每秒刷盘数据最多丢一秒平衡了可靠性和性能。实际生产里我比较推荐把两种机制结合RDB做定期备份AOF做增量恢复这是我在恢复过好几次误删数据后总结出来的稳妥方案。补充一个高频问题Redis持久化会阻塞主线程吗RDB用的方式是fork子进程来生成快照主线程继续处理命令但fork瞬间需要复制页表内存大时仍可能造成毫秒级卡顿AOF的重写也是类似思路利用子进程后台重写再合并。使用容器或者超大内存数据集时尤其要关注fork耗时不要让Redis跑在内存吃紧的机器上。3.3 主从复制、Sentinel与ClusterRedis自带的主从复制能很大程度上提升可用性。主节点写、从节点读数据异步同步主节点挂掉之后可以通过Sentinel哨兵自动把某个从节点提升为主节点业务侧几乎无感知。Redis Cluster则更进一步把数据按16384个槽位水平分片到多个主节点每个主节点还可以配从节点做故障转移达到“容量可扩展、高可用自治”。Memcached在官方层面没有主从、没有哨兵、没有数据分片方案。你在生产环境里部署多台Memcached本质上是客户端把key hash到不同机器上某台挂了它上面那一部分缓存就瞬间全没客户端需要容忍“部分key找不到”并回源。这种简单模型在中小规模够用但在对可用性要求高的核心链路里会很被动这也是很多团队从Memcached迁移到Redis的关键原因。4. 并发模型与内存管理底层机制和性能边界4.1 多线程与单线程的取舍Memcached从很早的版本就使用多线程模型主线程负责接收连接工作线程负责处理命令。多线程的好处是能更好地利用多核CPU在Linux下通常能跑到比较高的并发吞吐。代价是必须处理锁竞争、线程安全、连接队列等复杂问题如果读过memcached源码会发现它的内存分配和命令处理流程里到处是锁和原子操作。Redis长时间内是单线程事件循环模型所有命令按顺序执行不存在锁竞争因此单个Redis实例的行为可以预测多个客户端同时操作一个key的时候天然串行不用费心考虑并发安全。你可能会疑问单线程怎么顶得住高并发答案在于Redis的命令都是内存操作速度极快真正耗时的地方往往是网络IO和解析命令而这些恰好可以由epoll多路复用高性能处理。实测中绝大多数业务的瓶颈根本不在Redis单线程的处理能力上而在网络带宽、客户端连接数、大key的传输成本上。注意Redis 6.0开始引入了多线程IO处理网络读写但命令的执行还是单线程。也就是说网络包的解析、发送可以多线程辅助但核心的数据操作、脚本执行仍保持严格串行。这种设计既改善了高并发场景下网络IO导致的CPU瓶颈又保留了“单线程命令原子性”的优势。很多人被“Redis单线程”这个旧概念误导以为Redis无法利用多核实际上官方早就针对这个做了增强只是你使用的方式要对。4.2 内存分配与淘汰策略Memcached的内存管理非常有特色它把内存按固定大小划分成多个slab每个slab里再切成固定大小的chunk。对象存进来时系统按对象大小找一个合适的chunk放进去。这样做的好处是几乎不产生传统malloc/free的碎片性能稳定坏处也很明显——如果value大小分布不均匀一个200字节的对象和一个1KB的对象可能都被塞进同一个slab浪费空间或者被迫占用更大的chunk内存利用率反而不高。Redis则直接使用内存分配器默认是jemalloc也可以选tcmalloc或libc。它没有slab分区内存按需分配灵活性好配合丰富的数据结构编码比如Hash的小字段用压缩存储在存相似逻辑的数据时Redis的内存利用率通常比Memcached高。比如同样存一千个用户资料Memcached要存一千个序列化字符串Redis可以用一个Hash存一千个字段头部开销小很多。4.3 实践中的性能测试记录我之前给一个活动系统做过压测同样一批热点商品数据分别放在Memcached和Redis里单机8核16G。Memcached在纯GET场景下能跑到约12万QPSRedis在纯GET场景下约10万QPS差距其实很小但如果业务是“排行榜实时更新读取”这种复杂操作Memcached几乎无法支撑因为队列、排序逻辑在客户端做光网络来回就多得惊人。结论是如果你的场景只是一对一的KV缓存Memcached的优势确实存在场景稍微带点数据结构要求Redis的架构优势就是压倒性的。5. 分布式锁与高并发场景Memcached很难替代的差距5.1 先看一个真实的分布式锁需求微服务架构里经常有这种需求多个实例同时处理订单同一个用户同一时刻只能有一个单子被创建否则会重复下单。大家想到的方案基本就是“用分布式锁”。选型时很多团队第一反应是Redis因为Redis有原生的原子命令可以用来加锁但也有人问“Memcached不也可以吗它有add和cas啊”。这个问题还真值得掰开讲。5.2 Redis实现分布式锁的正确姿势Redis实现分布式锁最常见的方式是SET key value NX EX seconds。NX表示key不存在时才设置成功EX表示过期时间。这样一条命令同时保证了“并发只有一个客户端能拿到锁”和“锁不会永远不释放”。释放锁的环节有个经典坑必须先确认value是当初自己设置的再删除否则可能出现A的锁还没到时间被B覆盖A执行完后把B的锁删了。正确做法是配合Lua脚本原子地做“GET比对DEL”。如果要求更高的安全性官方还有RedLock算法在多个Redis节点上分别加锁超过半数成功才算加锁成功。具体要不要上RedLock业界也有争议但至少单体Redis的SET NX EX方案已经能覆盖绝大多数需求。5.3 Memcached为什么不好做分布式锁Memcached也有原子操作比如add只有key不存在时才放入等于抢锁成功但它缺少“带自动过期且能安全释放”的完整组合。你可以先用add抢锁然后靠过期时间兜底但释放时用delete又会误删别人的锁要用cas来保证“只有版本相同的才删除”但cas要额外维护一个版本令牌跨语言的客户端实现还得各自封装一套复杂度远高于Redis的Lua脚本。更麻烦的是Memcached没有持久化也没有主从复制锁所在的那台机器一旦宕机锁数据随内存一起蒸发整个分布式锁机制直接瘫痪。所以即便Memcached理论上有能力实现一个简单的锁工程上也很少有人真的这么干。6. 缓存治理穿透、击穿、雪崩的关键应对6.1 缓存穿透的两种常规解法缓存穿透指的是客户端大量请求一个“缓存里没有、数据库里也不存在”的key导致每次请求都打到数据库。数据库虽然能扛住一部分但在恶意刷接口或构造不存在的ID场景下压力很快失控。常见解法一个是空值缓存当查到数据库结果为空时也把这个“空结果”缓存成空值并给一个较短的过期时间防止同一ID反复穿透另一个是布隆过滤器把所有可能存在的ID预先放入一个超大的位图里请求进来先问“这个ID在不在位图里”不在就直接拦截不再查库。布隆过滤器可以用Redis的bitmap实现也可以直接用Redisson等客户端封装好的接口。6.2 缓存击穿与雪崩的处理缓存击穿是“某个热点key过期瞬间海量请求同时打向数据库”。处理思路有几种互斥锁缓存没有时先抢锁抢到锁的人才允许查数据库并回填缓存其他人等待逻辑过期缓存里保存一个逻辑过期时间线程发现逻辑过期后尝试拿锁重新加载下次读取时再给旧数据。这两种方案我都实际用过取舍还不小。缓存雪崩则是“大量key同时过期”或“缓存节点整体宕机”导致数据库被巨量请求淹没。应对手段包括给缓存过期时间加随机偏移让过期时间分散开开启Redis高可用避免单点服务端做限流降级把最低限度的流量放进系统。6.3 日常缓存治理的监控与优化这里分享一下我的日常运维清单第一监控Redis的慢日志slowlog get会暴露哪些命令耗时异常通常是大key或者复杂命令第二监控内存和键数量增长趋势防止key无限堆积导致内存暴涨第三定期分析大key和热key大key可以用redis-cli --bigkeys来扫描热key则要依靠客户端记录访问频率或使用代理层统计。找到热key后可以考虑在本地内存加一层二级缓存或者把这个key复制到多台主从实例中分散读压力。Memcached在这方面的治理手段就简单很多没有慢日志、没有脚本分析基本只能靠外部监控工具去采集stats数据管控粒度粗很多。7. 选型建议与踩坑实录7.1 什么时候继续用Memcached说了这么多Redis的强势我也要客观地说如果业务足够简单Memcached依然是很好的选择。缓存数据是纯KV、value是简单的字符串或字节数组、不需要排序聚合、数据丢了无所谓、团队只想要一个“速度快且好维护的缓存”那Memcached完全够用而且它多线程模型在某些纯读场景下吞吐确实可观部署和配置也简单。特别是你已经有一套成熟的Memcached集群和维护经验贸然迁移Redis如果只是图心理安慰反而可能引入新风险。7.2 什么时候应该上Redis业务里出现下列任何一种需求都建议认真考虑Redis需要Hash/List/Set/zset这类原生数据结构需要持久化恢复需要主从复制、哨兵或Cluster高可用需要分布式锁、消息队列、发布订阅等能力有缓存治理、慢查询分析、数据淘汰策略细粒度控制的需求。现在的Redis生态比Memcached完整太多客户端库、可视化工具、监控平台、中间件都是现成的开发效率放在那里。7.3 实际踩坑记录与常见问题速查我整理几个自己亲身踩过或者帮别人救过场的案例。第一个是“Windows上装Redis”热词里也高频出现。官方其实不提供Windows发行版网上能下的要么是微软老版本维护分支要么是第三方编译包。我一般测试环境直接改用Docker跑redis官方镜像生产更是建议Linux。Windows下如果你想随手玩一下可以用RedisDesktopManager这类可视化工具连接远程实例而不是折腾Windows本地服务。第二个是“redis incr不准”。很多人发现自己用incr做计数结果值不是预期。多半是并发下多个实例同时incr之后又做了一次set覆盖或者对过期时间设置不合理其实incr本身是原子的只是上游代码没有把“读-改-写”收敛成一条命令。建议检查是否有先读再写回的逻辑统一改用incr/incrby这类原子操作。第三个是“可视化客户端连不上”。遇到redis desktop manager或another redis desktop manager连不上redis我记得最常见的三种原因bind配置只绑定了127.0.0.1protected-mode开启导致拒绝外部连接Redis 6之后的ACL权限没配置。解决方法是根据环境修改bind、关闭protected-mode或在配置里设置requirepass密码连接时打开TLS选项如果服务端启用了TLS。当然生产环境不要随意关闭保护安全底线还是要守住。第四个是“docker安装redis主从”。很多教程简单映射两个redis容器就完事实际容易踩的坑是主从复制的bind和replicaof配置不对。我习惯用一个docker-compose文件把主从服务和哨兵服务组织起来主容器暴露端口从容器里配replicaof master host port哨兵里配sentinel monitor master 主服务名 端口 1。测试时记得容器网络要互通不然从节点一直连不上主节点日志里全是-NOMASTERLINK。还有一个比较有意思的问题是“redis哨兵模式和集群模式的区别”。简单说哨兵模式解决的是“高可用”它本身不存数据只负责监控主从节点主挂了自动把从提升为主对外始终只有一个写入口集群模式解决的是“扩展性”它把数据分片到多个主节点每个主节点还可以配从节点实现分片内的高可用。小规模高可用可以只上哨兵数据量大、对写入扩展有要求才需要集群。最后聊聊迁移从Memcached迁移到Redis其实不是换个连接串就完事。协议不同客户端必须重写持久化数据的迁移也要设计常见做法是启动双写一段时间先让Redis承担读逐步切换写流量最后断开Memcached。我试过一次比较急的全量迁移一个大key列表迁移完第二天就发现内存涨得飞快排查半天发现是原本Memcached里那些超大value对象在Redis里保存成了一个大String完全没有发挥Hash在字段维度上的压缩优势。后来我按业务模型拆成Hash字段内存占用直接降了一半还多。做这套选型和技术对比我自己最大的体会是技术工具没有绝对的“更好的那个”只有“更适合你这个业务的那个”。Redis确实在很多维度上更强大但强大也意味着复杂如果业务只需要一个简单的KV缓存你用Redis反而可能要处理持久化、淘汰策略、集群拓扑这些额外心智负担。反之如果业务已经把Memcached罩不住的需求摆在桌面上了也别犹豫早点切换拖着只会让技术债越滚越大。
