Redis 和 Memcached 怎么选？先看数据类型与持久化需求
缓存选型时，Redis 和 Memcached 经常被放在一起比较。
结论可以概括为：需要丰富数据结构、持久化、主从复制或 Lua 脚本时选 Redis；
只做简单字符串键值缓存、并且希望利用多核处理大并发读取时，Memcached 依然合适。
下面按实际判断条件展开，不堆概念。
两者最根本的区别在数据模型
Memcached 只支持字符串键值，值就是一段字节。
Redis 除了字符串，还提供 List、Hash、Set、Sorted Set、Bitmap、HyperLogLog 等结构。
举个例子：你要缓存用户购物车。
用 Redis 可以直接对 Hash 字段做增减，不需要读出整个对象再写回；
用 Memcached 通常只能把购物车序列化成字符串整体读写，并发修改时容易互相覆盖。
如果缓存内容始终是「一个 key 对应一段 JSON 或 HTML 片段」，两者都能胜任，Memcached 的简单模型反而少一层抽象。
持久化和高可用决定了故障后的恢复方式
Memcached 设计上就是纯内存缓存，进程重启或机器故障后数据全部丢失，也没有内置主从复制。
Redis 支持 RDB 快照和 AOF 日志，可以按策略把数据落到磁盘，并提供主从复制、哨兵和集群模式。
判断条件：
- 缓存丢失后可以回源数据库、且回源压力可控，Memcached 的纯内存模型可以接受。
- 缓存里存了会话、排行榜、计数器等重建成本高的数据，或者希望故障后快速恢复，Redis 的持久化更稳妥。
- 需要读写分离或自动故障转移，Redis 有成熟方案，Memcached 通常要靠客户端做一致性哈希分片。
要注意，Redis 持久化不是免费的：AOF everysec 在高写入时可能带来额外磁盘压力，RDB 快照 fork 时也会占用内存。
选 Redis 不等于可以把它当数据库用，缓存该设的过期时间仍然要设。
线程模型和内存管理影响压测表现
Memcached 使用多线程处理网络请求，能利用多核 CPU；
Redis 处理命令的主线程是单线程的，单实例吞吐受单核限制，但通过多实例或集群可以横向扩展。
内存管理上，Memcached 使用 slab 分配器，内存按固定大小的 chunk 划分，长期运行后可能出现内存碎片；
Redis 使用 jemalloc 等分配器，并支持 maxmemory 配合淘汰策略。
实际判断时，不要只看「谁更快」的笼统说法。
小 value、多连接、纯读场景，Memcached 多线程有优势；
需要复杂操作、事务或脚本时，Redis 的单线程模型反而减少了锁竞争。
按场景给出选择建议
- 会话共享、排行榜、计数器、消息队列轻量替代：选 Redis，数据结构和原子操作更直接。
- 页面片段缓存、数据库查询结果缓存，value 是整段字符串，且已有成熟分片客户端：Memcached 可以继续用。
- 团队已有 Redis 运维经验：优先 Redis，减少技术栈。
- 内存成本敏感、缓存可完全丢失、追求简单：Memcached 部署和排错更轻。
如果现有系统已经在用 Memcached 且运行稳定，没有出现数据结构或持久化需求，不必为了「新」而迁移。
迁移本身会带来客户端改造和双写验证成本。
验证选型是否合理
上线前至少确认三件事：缓存命中率是否达到预期、单实例内存上限是否设置、淘汰策略是否符合业务。
Redis 可以用 INFO stats 看命中率，用 CONFIG GET maxmemory-policy 确认淘汰策略；
Memcached 可以用 stats 命令查看 get_hits 和 get_misses。
无论选哪个，都要给缓存设置合理的过期时间，并评估缓存击穿时数据库能否承受回源压力。
选型没有绝对优劣，关键是匹配当前的数据类型、持久化要求和运维能力。
