主流缓存中间件对比：Redis vs Memcached

一、核心维度对比

1. 数据结构支持

特性	Redis	Memcached
基础KV	✅ 支持	✅ 支持
字符串	✅ 支持（可做计数器、位图）	✅ 支持（仅字节数组）
列表（List）	✅ 支持（双向链表，支持阻塞操作）	❌ 不支持
集合（Set）	✅ 支持（无序不重复，支持交集并集）	❌ 不支持
有序集合（Sorted Set）	✅ 支持（带分数排序，适合排行榜）	❌ 不支持
哈希表（Hash）	✅ 支持（适合存储对象）	❌ 不支持
位图（Bitmap）	✅ 支持（二进制操作，适合布隆过滤器）	❌ 不支持
HyperLogLog	✅ 支持（基数统计，适合UV统计）	❌ 不支持
地理空间（Geo）	✅ 支持（地理位置计算，适合附近的人）	❌ 不支持
流（Stream）	✅ 支持（消息队列，适合事件流）	❌ 不支持

2. 持久化机制

特性	Redis	Memcached
持久化支持	✅ 支持	❌ 不支持
RDB快照	✅ 支持（定时生成内存快照）	❌ 不支持
AOF日志	✅ 支持（记录所有写操作，可重放恢复）	❌ 不支持
混合持久化	✅ 支持（RDB+AOF结合，平衡性能和安全性）	❌ 不支持
数据恢复能力	强（可从RDB/AOF恢复）	弱（重启后数据丢失）

3. 集群支持

特性	Redis	Memcached
集群模式	✅ 支持（Redis Cluster，自动分片）	✅ 支持（客户端分片，如一致性哈希）
节点数量	最大1000节点	无限制（取决于客户端实现）
自动故障转移	✅ 支持（主从复制+哨兵/Cluster）	❌ 不支持（需客户端处理）
分片策略	哈希槽分片（16384个槽）	客户端一致性哈希
跨节点操作	✅ 支持（部分命令，如MGET需在同一槽）	❌ 不支持（客户端需手动处理）

4. 性能对比

维度	Redis	Memcached
QPS	单节点约10万-15万	单节点约10万-20万
读写性能	读略快于写，支持批量操作	读性能略优于Redis，写性能相当
延迟	亚毫秒级（平均0.1-1ms）	亚毫秒级（平均0.1-0.5ms）
连接数	支持10万+并发连接	支持10万+并发连接
内存使用	支持多种数据结构，内存利用率高	仅支持KV，内存利用率较低（每个键值对约48字节元数据）

5. 内存管理

特性	Redis	Memcached
内存分配	jemalloc/tcmalloc（高效内存分配器）	简单的内存池（slab分配）
内存碎片	较低（jemalloc优化）	较高（slab分配可能导致碎片）
内存上限	支持最大64GB（32位系统4GB）	支持最大64GB（32位系统4GB）
过期策略	支持多种（TTL、惰性删除、定期删除）	仅支持LRU（最近最少使用）
内存淘汰	支持8种策略（如LRU、LFU、Random）	仅支持LRU

6. 线程模型

特性	Redis	Memcached
线程模型	单线程（核心逻辑单线程，I/O多线程）	多线程（工作线程+监听线程）
CPU利用率	单CPU核心（可通过集群利用多核）	支持多核CPU（工作线程数=CPU核心数）
阻塞操作影响	单线程下阻塞操作会影响整体性能（如KEYS命令）	多线程下单个操作阻塞不影响其他线程
并发模型	基于事件循环（epoll/kqueue）	基于多线程+事件驱动

二、面试题：Redis与Memcached的区别？

结构化回答模板：

数据结构支持：
- Redis支持多种数据结构（String、List、Set、Sorted Set、Hash等），可实现复杂业务场景（如排行榜、消息队列）。
- Memcached仅支持简单KV存储，适合基础缓存场景。
持久化机制：
- Redis支持RDB快照、AOF日志和混合持久化，数据可恢复。
- Memcached不支持持久化，重启后数据丢失。
集群支持：
- Redis自带Cluster集群模式，支持自动分片和故障转移。
- Memcached需依赖客户端实现一致性哈希分片，无自动故障转移。
内存管理：
- Redis使用高效的jemalloc内存分配器，内存碎片低，支持多种过期和淘汰策略。
- Memcached使用slab分配，内存碎片较高，仅支持LRU淘汰。
线程模型：
- Redis核心逻辑单线程（I/O多线程），利用事件循环，适合CPU密集型操作。
- Memcached多线程模型，支持多核CPU，适合高并发读场景。
适用场景：
- Redis适合复杂业务场景（分布式锁、消息队列、计数器、排行榜等）。
- Memcached适合简单KV缓存（如静态资源、高并发读场景）。

三、Redis适用场景

1. 缓存系统（最核心场景）

热点数据缓存：如电商商品详情、新闻列表、用户信息。
多级缓存：结合本地缓存（Caffeine）+ Redis，提高系统容错性。
缓存穿透/击穿/雪崩防护：利用布隆过滤器、互斥锁、随机过期时间等机制。

2. 分布式锁

实现原理 ：使用SET key value NX PX milliseconds命令，原子性设置锁。
适用场景：秒杀系统、分布式事务、资源竞争场景。

代码示例 ：

java 复制代码

// 获取分布式锁
public boolean tryLock(String key, long expireTime) {
    return redis.setIfAbsent(key, "locked", expireTime, TimeUnit.MILLISECONDS);
}

3. 消息队列

实现方式 ：
- 基于List：适合简单的消息队列（如生产消费模型）。
- 基于Stream：适合复杂的消息队列（支持消费者组、消息持久化）。
适用场景：异步任务处理、事件通知、日志收集。

4. 计数器与统计

实现原理 ：使用INCR/DECR命令，原子性增减计数。
适用场景 ：
- 文章阅读数、视频播放量。
- 实时UV统计（结合HyperLogLog）。
- 接口调用频率限制。

代码示例 ：

java 复制代码

// 文章阅读数+1
redis.incr("article:123:views");

5. 排行榜系统

实现原理 ：使用Sorted Set（带分数排序），支持实时更新排名。
适用场景 ：
- 游戏排行榜（如分数、等级）。
- 电商销量榜、热门商品榜。
- 社交平台点赞榜、关注榜。

代码示例 ：

java 复制代码

// 添加用户分数到排行榜
redis.zadd("leaderboard:game1", 1000, "user:123");
// 获取Top10排行榜
redis.zrevrange("leaderboard:game1", 0, 9, withScores());

6. 地理位置服务

实现原理 ：使用Geo命令，存储和计算地理位置。
适用场景 ：
- 附近的人（LBS应用）。
- 地理位置距离计算。
- 地理围栏（如配送范围）。

代码示例 ：

java 复制代码

// 添加商家位置
redis.geoadd("shops:beijing", 116.40, 39.90, "shop:123");
// 查询附近5公里的商家
redis.georadius("shops:beijing", 116.40, 39.90, 5, "km");

四、Memcached适用场景

1. 简单KV缓存

适用场景 ：
- 静态资源缓存（如图片URL、CSS/JS文件路径）。
- 数据库查询结果缓存（如商品列表、用户信息）。
- 会话缓存（如Session Store，替代Tomcat集群Session）。

2. 高并发读场景

核心优势 ：
- 多线程模型，充分利用多核CPU。
- 简单设计，无复杂数据结构，读操作性能优异。
- 适合读多写少的场景，如电商首页商品列表、新闻热点。

3. 大规模分布式缓存

适用场景 ：
- 大型网站的全局缓存层（如Facebook、Twitter早期使用）。
- 客户端分片，可线性扩展节点数量。
- 无状态服务的缓存层，便于水平扩展。

4. 内存敏感型场景

核心优势 ：
- 内存分配简单，无复杂数据结构，内存占用可预测。
- 适合对内存使用有严格控制的场景。
- 可通过调整slab大小优化内存利用率。

五、选型决策依据

决策维度	优先选择Redis	优先选择Memcached
业务复杂度	复杂业务场景（需要多种数据结构）	简单KV缓存场景
数据持久化需求	需要数据可恢复（如用户会话）	数据丢失可接受（如临时缓存）
集群规模	需要自动分片和故障转移	简单集群，客户端分片即可
并发模型	CPU密集型操作（如复杂计算）	高并发读场景（如静态资源）
开发成本	可实现复杂功能，减少代码量	简单API，学习成本低
运维复杂度	需维护持久化、集群配置，运维成本高	配置简单，运维成本低

六、总结

Redis：功能强大，支持多种数据结构和复杂业务场景，适合需要持久化、分布式锁、消息队列等高级功能的场景。
Memcached：设计简单，性能优异，适合高并发读场景和简单KV缓存，运维成本低。

选型建议：

大多数现代应用优先选择Redis，因其丰富的数据结构和强大的功能支持。
对于简单的高并发读场景（如静态资源缓存），Memcached仍有其优势。
可根据业务场景组合使用，如Redis处理复杂业务，Memcached处理简单KV缓存。

通过理解两者的核心差异和适用场景，可根据实际业务需求选择合适的缓存中间件，构建高效、可靠的缓存系统。