Redis 和 Memcached 有哪些区别？

🏛 业务架构师

两者定位不同，我按业务能力边界对比：

维度	Redis	Memcached
数据结构	String/List/Hash/Set/ZSet 等丰富结构	纯 KV 字符串
持久化	RDB/AOF，重启可恢复	无，重启全丢
高可用	主从、哨兵、集群原生	客户端哈希分片，无自动故障转移
线程模型	命令单线程	多线程
附加能力	事务、Lua、发布订阅、过期策略精细	简单

业务视角的结论：

Redis 是"数据结构服务器"：排行榜（ZSet）、计数器（incr）、去重（Set/HyperLogLog）、延迟队列、分布式锁——它能承载业务逻辑，不只是缓存。纯缓存只是它的一小部分用途；
Memcached 是"纯缓存"：多线程在超大 value（几百 KB 级）场景有吞吐优势，纯 KV 缓存它依然称职。但"重启丢光"意味着只能做可再生数据的缓存，任何带业务状态的东西放上去都是风险。

选型判断三问：

只有简单 KV 缓存需求？两者都行，但生态默认选 Redis（人才、工具、社区、云产品全占优）；
需要结构、持久化、高可用、Lua 原子性？只有 Redis；
需要的是不是其实是个"轻量数据库"？ 那要警惕——Redis 持久化的可靠性（AOF everysec 仍可能丢 1 秒）不能替代 MySQL 作为事实源，我的红线：缓存与计数可以 Redis，交易事实必须数据库。

一句话：Memcached 是缓存工具，Redis 是数据能力平台——今天的默认答案几乎是 Redis，但"别把它当唯一事实源"这条边界比选型本身更重要。

我按"架构模型"对比，Redis 的功能面远大于 Memcached：

数据结构：Memcached 只有纯 KV 字符串；Redis 有 String/Hash/List/Set/ZSet/Bitmap/HyperLogLog/Stream，能直接支撑排行榜、去重、队列等场景——数据结构能力是最大分水岭；
持久化：Redis 有 RDB/AOF，重启不丢数据，可当轻量存储；Memcached 纯内存，重启全丢，只能当缓存；
高可用与扩展：Redis 有主从 + 哨兵 + Cluster（16384 槽分片）；Memcached 集群靠客户端一致性哈希分片，无复制无自动容灾，节点挂了该节点数据全丢（靠上层容错）；
线程模型：Redis 命令单线程（6.0 多线程仅网络 IO），保证原子性；Memcached 多线程，吞吐在纯 KV 大 value 场景更猛；
内存管理：Redis 有淘汰策略（LRU/LFU 等 8 种），Memcached 用 slab 分配 + LRU（早期惰性失效）；
附加能力：Redis 支持 Lua 脚本、事务、发布订阅、过期精度更高。

我的选型结论：99% 场景直接 Redis——一个组件同时覆盖缓存、计数、锁、队列、排行榜，运维收敛。Memcached 只在"纯 KV、超大 value（MB 级）、极端纯缓存吞吐"的窄场景仍有优势，如今基本退场。技术选型看生态与场景覆盖度，Redis 赢在数据结构抽象层。

维度	Redis	Memcached
数据结构	String/List/Hash/Set/ZSet/Bitmap 等	纯 KV（string→string）
持久化	RDB/AOF，重启不丢	无，重启全丢
高可用	主从/哨兵/Cluster 原生	客户端分片，一致性哈希
线程模型	单线程执行 + 6.0 多线程 IO	多线程
value 上限	512MB	1MB（slab 分配）
附加能力	Lua、事务、发布订阅、过期策略	纯缓存

我的选型结论：现在基本无脑 Redis。理由：

Memcached 依然合理的场景：纯 KV 纯缓存、value 均匀且小、要求极限多线程吞吐的极端场景（比如老系统 session 共享）。

一个实战细节： Memcached 的 slab 分配在 value 大小不均时浪费严重（slab 碎片），Redis 的 jemalloc 更精细——这种内存层面的差别在容量规划和成本核算时会真实体现。