缓存方案大盘点
概述
缓存是系统性能优化的核心手段之一，在互联网后端架构中扮演着"加速器"的角色。从单机内存缓存到分布式缓存集群，从纯内存方案到持久的缓存数据库，业界涌现了众多成熟方案。本文对 9 种主流缓存方案进行系统性对比，涵盖Redis、Redisson、Caffeine、Ehcache、Hazelcast、Memcached、Ignite、Redis Cluster、Codis，从读写性能、数据结构、集群模式、持久化、分布式锁、Spring 集成度、客户端生态及商业授权等多个维度展开分析，帮助团队在不同场景下做出合理的技术选型。
一、Redis
简介
Redis（Remote Dictionary Server）是一个开源的高性能键值存储系统，基于内存运行并支持多种数据结构。它由 Salvatore Sanfilippo 开发，长期位居 DB-Engines 键值存储排行榜首位，是目前使用最广泛的缓存中间件。
核心特性
- 纯内存 + 异步 I/O：单线程事件循环模型，避免并发竞争，在普通服务器上可达到 10万+ QPS。
- 丰富的数据结构：String、Hash、List、Set、Sorted Set、Bitmap、HyperLogLog、Geo、Stream 等。
- 支持持久化：RDB（快照）和 AOF（追加日志），可灵活配置。
- 发布/订阅：支持基于 channel 的消息通信。
- Lua 脚本：服务端原子化脚本执行。
- 事务：基于 MULTI/EXEC 的乐观批量执行（不支持回滚）。
- 高可用方案：主从复制 + Sentinel 哨兵模式，实现自动故障转移。
适用场景
- 通用缓存加速（热点数据、session 共享）
- 计数器、排行榜、时间窗口限流
- 分布式锁（基于 SETNX + Lua）
- 消息队列（基于 List 或 Stream）
- 实时数据分析（HyperLogLog、Bitmap）
二、Redisson
简介
Redisson 是 Redis 的 Java 客户端之一，但定位远不止客户端——它是一个基于 Redis 的 Java In-Memory Data Grid，提供了丰富的分布式对象和服务抽象。
核心特性
- 分布式对象：
RMap、RSet、RList、RQueue、RAtomicLong等，使用体验类似 JDK 集合。 - 分布式锁和服务：可重入锁、公平锁、读写锁、信号量、
RCountDownLatch等。 - 分布式远程调用（RPC）：基于 Redis 的远程服务调用。
- 分布式调度器：
RScheduledExecutorService。 - Spring 深度集成：完美融入 Spring Cache、Spring Session、Spring Boot 自动配置。
适用场景
- Java 项目中需要以对象化方式操作 Redis
- 对分布式锁、分布式计数等高级功能有刚性需求
- Spring 生态下的缓存与 Session 管理
注意
Redisson 本身不存储数据，它是对 Redis 服务端的封装增强，因此其性能上限取决于底层的 Redis 集群或单机 Redis。
三、Caffeine
简介
Caffeine 是目前 Java 生态中性能最高的本地缓存库，受 Guava Cache 启发但做了大量优化，是 Spring Boot 2.x 以上版本的默认本地缓存实现。
核心特性
- 基于 Window-TinyLFU 淘汰算法：结合 LRU 和 LFU 优点，命中率极高。
- 异步加载：
asyncLoading支持异步刷新。 - 自动刷新：可在过期前异步重新加载。
- 统计与监控：命中率、加载时间等指标。
- 内存敏感：支持基于权重的淘汰策略。
- 零依赖：轻量级，仅 500KB 左右。
性能表现
- 读性能是 Guava Cache 的 2～3 倍。
- 单线程下可达 2000 万+ TPS（纯内存操作，无网络开销）。
- 延迟通常在微秒级。
适用场景
- 本地热点缓存（如配置信息、字典数据、用户基础信息）
- 配合 Redis 做多级缓存（一级本地 Caffeine + 二级 Redis）
- 对延迟极度敏感的低延时系统
四、Ehcache
简介
Ehcache 是老牌的 Java 本地缓存框架，早在 2003 年诞生，曾经是 Hibernate 的默认二级缓存实现。目前最新版本为 Ehcache 3.x。
核心特性
- 多层缓存架构：堆内（Heap）、堆外（Off-Heap）、磁盘（Disk）三级架构。
- JSR-107（JCache）兼容：标准 Java 缓存 API 实现。
- 支持持久化：基于磁盘的可重启持久化。
- 事务支持：与 JTA 集成，支持 XA 事务。
- 高可用：通过 Terracotta 集群实现分布式缓存（但配置复杂）。
适用场景
- Hibernate/JPA 二级缓存
- 需要本地磁盘持久化的缓存场景
- 对 JCache 标准有强制要求的项目
对比 Caffeine
| 维度 | Ehcache | Caffeine |
|---|---|---|
| 性能 | 较好，但不如 Caffeine | 业界最高 |
| 堆外/磁盘 | 原生支持 | 不支持 |
| 淘汰算法 | LFU/LRU/FIFO | Window-TinyLFU |
| 配置复杂度 | 相对复杂（XML 配置） | API 简洁 |
五、Hazelcast
简介
Hazelcast 是一个开源的 In-Memory Data Grid（IMDG），既可作为本地缓存使用，也可通过成员发现机制自动组成分布式缓存集群。
核心特性
- 分布式数据结构：
IMap、ISet、IList、IQueue、MultiMap等。 - 自动集群：基于 Multicast 或 TCP/IP 的自动发现，零配置即可组成集群。
- CP Subsystem：基于 Raft 协议的强一致性组件，提供分布式锁。
- 分布式计算：支持 Distributed Executor Service、Entry Processor。
- 持久化：支持 MapStore/MapLoader 接口对接外部存储。
- WAN 复制：跨数据中心的数据同步。
适用场景
- 需要嵌入式分布式缓存的 Java 应用
- 对自动集群有要求的场景
- 需要分布式计算 + 缓存一体化的平台
商业版
- 开源版：核心 IMDG 功能免费
- Hazelcast Enterprise：增加安全认证、WAN 复制增强、滚动升级、Hot Restart 持久化等
六、Memcached
简介
Memcached 诞生于 2003 年，是经典的分布式内存缓存系统，广泛应用于 Web 应用的数据库查询缓存和 session 共享。
核心特性
- 极简设计：仅支持 String/Binary 键值对，不支持复杂数据结构。
- 多线程架构：自 1.4 版本起引入多线程，充分利用多核 CPU。
- LRU 淘汰：内存满时按 LRU 策略淘汰。
- 无持久化：纯内存方案，重启丢失数据。
- 无认证机制：默认无访问控制（需通过 SASL 或网络隔离）。
- 分布式逻辑在客户端：通过一致性哈希等算法由客户端实现 Sharding。
性能表现
- 读写在 10万～20万 QPS 量级（取决于机器和网络），延迟约 0.5～1ms。
- 多线程在超高并发场景下相较单线程 Redi 有一定优势。
- 但受限于无数据结构、无持久化、无高可用机制，总体能力远弱于 Redis。
适用场景
- 简单键值缓存（如 HTML 片段、数据库查询结果）
- 对数据结构无要求的极简缓存场景
- 遗留系统迁移成本敏感的团队
为何被 Redis 取代
近年来 Memcached 的使用率持续下降，主要原因是 Redis 在数据结构丰富度、高可用方案、持久化等方面全面超越 Memcached，而性能差距不大。
七、Ignite（Apache Ignite）
简介
Apache Ignite 是一个分布式内存计算平台，具备缓存、计算网格、SQL 查询、流处理等多种能力，可视为 SQL 化的 Hazelcast。
核心特性
- SQL 查询：支持 ANSI SQL，可直接对缓存数据进行 SQL 查询，JDBC/ODBC 兼容。
- 内存文件系统：基于内存的 Hadoop 加速。
- ACID 事务：支持跨分区的事务。
- 持久化：Native Persistence 可将数据持久化到磁盘，重启后恢复。
- 多种集群模式：分区模式、复制模式、分布式缓存。
- 计算网格：集群内分布式执行计算任务。
适用场景
- 需要 SQL 查询缓存的场景
- 既要用缓存又需要计算网格的平台级应用
- 从关系型数据库迁移到内存数据层的数据密集场景
注意事项
- Ignite 功能庞大，学习曲线较陡。
- 集群配置较复杂，运维成本高于 Redis。
- 内存占用较高，需要仔细规划堆内存和堆外内存比例。
八、Redis Cluster
简介
Redis Cluster 是 Redis 官方提供的分布式集群方案，自 Redis 3.0 起引入。通过 16384 个哈希槽（Hash Slot）将数据自动分片到多个节点，支持在线扩缩容。
核心特性
- 自动分片：客户端请求可路由至正确的分片节点。
- 高可用：主节点故障时从节点自动提升为主。
- 去中心化：节点之间通过 Gossip 协议通信，无中心代理。
- P2P 架构：每个节点都保存完整的集群元数据。
- 最终一致性：跨主从复制采用异步方式（可配置 WAIT 等待同步）。
性能表现
- 线性扩展读/写吞吐量，集群规模理论可达 1000 节点。
- 单节点性能与单机 Redis 一致。
- 跨分片操作（如 mset/mget 涉及多个 key）需要客户端支持。
适用场景
- 大规模缓存场景（TB 级数据量）
- 需要自动分片和高可用的生产环境
- 对去中心化架构有偏好的团队
局限
- 不支持多数据库（仅 db0）。
- 跨 Slot 的事务和 Lua 脚本有限制。
- 客户端需支持 Cluster 协议，部分旧客户端不兼容。
九、Codis
简介
Codis 是豌豆荚开源（后由商业化公司支持）的 Redis 集群代理方案，通过中间层 Proxy 对 Redis 节点进行分片和管理。它在 Redis Cluster 成熟前被广泛使用。
核心特性
- 代理层分片：客户端连接 Codis Proxy，无需感知后端节点拓扑。
- 兼容 Redis 协议：对客户端透明，旧客户端零改造。
- 在线扩缩容：基于 Dashboard 和 ZooKeeper 进行 Slot 迁移。
- 支持多 DB：不像 Redis Cluster 限制 db0。
- 图形化管理界面：提供 Codis FE 管理控制台。
适用场景
- 对客户端透明性要求高，希望零代码迁移的场景
- 已大量使用 Redis 2.x/3.x、客户端不兼容 Cluster 协议
- 需要 Web 管理界面的运维团队
Codis vs Redis Cluster
| 维度 | Codis | Redis Cluster |
|---|---|---|
| 架构 | Proxy 中心化 | P2P 去中心化 |
| 客户端兼容 | 完全兼容任何 Redis 客户端 | 需 Cluster 协议客户端 |
| 多 DB | 支持 | 不支持 |
| 维护状态 | 社区停滞 | 官方持续演进 |
| 性能损耗 | Proxy 层约 5%~10% | 无中间层损耗 |
现状
随着 Redis Cluster 的成熟和 Codis 社区维护的逐步停滞，新项目已不推荐采用 Codis。但存量的 Codis 集群仍有较大用户基础。
综合对比
读写性能
| 方案 | 读写性能（参考值） | 延迟（P99） | 备注 |
|---|---|---|---|
| Redis | 10万～12万 QPS（单机） | ~0.5ms | 单线程模型 |
| Redisson | 同底层 Redis | 同 Redis | 客户端开销极小 |
| Caffeine | 2000万+ TPS（单机本地） | ~0.01ms | 无网络开销 |
| Ehcache | 500万+ TPS（堆内），堆外依赖大小 | ~0.05ms（堆内） | 堆外/磁盘性能下降 |
| Hazelcast | 5万～10万 QPS/节点 | ~1ms | 受网络和序列化影响 |
| Memcached | 10万～20万 QPS（多线程） | ~0.5ms | 多线程模型在高并发下占优 |
| Ignite | 3万～8万 QPS/节点 | ~2ms | 功能丰富导致开销较大 |
| Redis Cluster | 随节点数线性扩展 | ~0.5ms（单跳） | 跨节点操作有额外开销 |
| Codis | 同 Redis 但减 Proxy 损耗 | ~1ms | 中间层增加一跳 |
数据结构丰富度
| 方案 | 数据结构丰富度 |
|---|---|
| Redis | ★★★★★（String/Hash/List/Set/ZSet/Stream/Geo/Bitmap/HLL） |
| Redisson | ★★★★★（同上 + 分布式对象封装） |
| Caffeine | ★☆☆☆☆（仅键值对，Value 为任意对象） |
| Ehcache | ★☆☆☆☆（仅键值对） |
| Hazelcast | ★★★★☆（Map/Set/List/Queue/MultiMap/AtomicLong） |
| Memcached | ★☆☆☆☆（仅 String/Binary） |
| Ignite | ★★★★★（Map + SQL 表 + 计算原语） |
| Redis Cluster | ★★★★★（同 Redis） |
| Codis | ★★★★★（同 Redis） |
集群模式与高可用
| 方案 | 集群/高可用方案 |
|---|---|
| Redis | 主从复制 + Sentinel 哨兵 |
| Redisson | 依赖底层 Redis，支持 Sentinel / Cluster |
| Caffeine | 不支持集群（本地缓存） |
| Ehcache | Terracotta 集群（配置复杂） |
| Hazelcast | 自动发现 + 分区集群 + CP Subsystem |
| Memcached | 无原生集群，靠客户端一致性哈希 |
| Ignite | 分区/复制模式 + 故障检测 |
| Redis Cluster | 自动分片 + 主从切换 |
| Codis | Proxy + ZooKeeper + Dashboard |
持久化能力
| 方案 | 持久化机制 |
|---|---|
| Redis | RDB + AOF（成熟可靠） |
| Redisson | 同 Redis |
| Caffeine | 不支持（纯内存） |
| Ehcache | 磁盘持久化（可重启恢复） |
| Hazelcast | MapStore/MapLoader 对接外部存储 |
| Memcached | 不支持 |
| Ignite | Native Persistence（持久化到磁盘，支持 SQL） |
| Redis Cluster | 同 Redis（RDB + AOF） |
| Codis | 同 Redis |
分布式锁支持
| 方案 | 分布式锁 |
|---|---|
| Redis | SETNX + Lua（基础锁）/ Redlock（推荐谨慎使用） |
| Redisson | ★★★★★（RLock + 看门狗自动续约 + 可重入/公平/读写锁） |
| Caffeine | 不支持 |
| Ehcache | 不支持 |
| Hazelcast | ★★★★☆（基于 CP Subsystem 的 ILock，Raft 一致性） |
| Memcached | 不支持 |
| Ignite | ★★★★☆（基于分布式原语的锁） |
| Redis Cluster | 同 Redis（跨 Slot 锁需注意） |
| Codis | 同 Redis |
与 Spring 集成度
| 方案 | Spring 集成度 |
|---|---|
| Redis | ★★★★☆（Spring Data Redis + Lettuce/Jedis） |
| Redisson | ★★★★★（Spring Cache + Spring Session + Spring Boot 自动配置） |
| Caffeine | ★★★★★（Spring Boot 2.x 默认缓存实现） |
| Ehcache | ★★★★☆（Spring Boot 支持，Ehcache 3 + JCache） |
| Hazelcast | ★★★★☆（Spring Data Hazelcast + Cache 注解） |
| Memcached | ★★★☆☆（需第三方 xmemcached 或 spymemcached 集成） |
| Ignite | ★★★☆☆（Spring Cache 支持，但使用不广泛） |
| Redis Cluster | ★★★★☆（Spring Data Redis 已原生支持 Cluster） |
| Codis | ★★★★☆（兼容 Redis 协议，同 Spring Data Redis） |
客户端成熟度
| 方案 | 客户端生态 |
|---|---|
| Redis | Java：Jedis/Lettuce/Redisson；多语言：几乎全语言覆盖 |
| Redisson | 仅 Java（功能最丰富） |
| Caffeine | 仅 Java |
| Ehcache | 仅 Java |
| Hazelcast | Java、.NET、Node.js、Python、C++ |
| Memcached | 几乎所有语言都有客户端 |
| Ignite | Java、.NET、C++、REST |
| Redis Cluster | 同 Redis（需支持 Cluster 协议的客户端） |
| Codis | 兼容任何 Redis 客户端 |
商业版 vs 开源版
| 方案 | 开源版本 | 商业版本 | 关键差异 |
|---|---|---|---|
| Redis | BSD 许可，功能完整 | Redis Stack / Redis Enterprise | 企业版提供多租户、Active-Active、自动分级存储 |
| Redisson | Apache 2.0 | 无独立商业版 | 全部开源 |
| Caffeine | Apache 2.0 | 无商业版 | 全部开源 |
| Ehcache | Apache 2.0 | Terracotta DBA（需付费） | 企业版提供分布式集群增强 |
| Hazelcast | Apache 2.0 | Hazelcast Enterprise | 安全、WAN 复制、Hot Restart |
| Memcached | BSD 许可 | 无商业版 | — |
| Ignite | Apache 2.0 | GridGain（基于 Ignite 的商业发行版） | 企业支持、安全增强、管理工具 |
| Redis Cluster | BSD（核心代码部分） | Redis Enterprise | 全托管自动化集群管理 |
| Codis | MIT 许可（已停更） | 无商业版 | — |
选型建议
按场景推荐
| 场景 | 推荐方案 | 理由 |
|---|---|---|
| Java 本地热点缓存 | Caffeine | 性能最高，Spring Boot 原生支持 |
| 通用分布式缓存 | Redis + Redisson | 生态成熟，功能全面，社区活跃 |
| 大容量缓存集群（TB 级） | Redis Cluster | 官方分片方案，稳定性高，持续演进 |
| 对客户端透明的集群 | Codis（存量项目）/ Redis Cluster（新项目） | Codis 已停更，新项目首选 Redis Cluster |
| Hibernate/JPA 二级缓存 | Ehcache | 历史绑定，成熟稳定 |
| 需要 SQL 查询缓存 | Ignite | 唯一支持 ANSI SQL 的缓存方案 |
| 嵌入式分布式缓存 | Hazelcast | 零配置自动集群，与 Java 应用同进程 |
| 简单键值缓存（极简场景） | Memcached | 够用，但建议直接选 Redis |
| Java 分布式锁场景 | Redisson | 锁功能最完善，看门狗机制可靠 |
| 超低延迟（微秒级） | Caffeine + Redis 多级缓存 | 本地命中微秒级，穿透 Redis 毫秒级 |
推荐组合
在现代微服务架构中，单一缓存方案往往无法满足所有需求，推荐以下分层组合：
┌──────────────────────────────────────┐
│ 应用进程内缓存 │
│ Caffeine（一级，微秒级） │
├──────────────────────────────────────┤
│ 分布式缓存 │
│ Redis / Redis Cluster（二级，毫秒级） │
├──────────────────────────────────────┤
│ 持久化层 │
│ MySQL / 数据库（三级） │
└──────────────────────────────────────┘- 一级缓存：Caffeine，存放热点数据，TTL 较短（秒/分钟级），用于抵挡绝大多数请求。
- 二级缓存：Redis / Redis Cluster，存放全量可缓存数据，TTL 较长（分钟/小时级），用于跨服务共享。
- 分布式锁：Redisson RLock，保障分布式临界区同步。
- 缓存击穿防护：Caffeine 配合布隆过滤器，或 Redis 配合互斥锁/mutex 机制。
总结
缓存选型没有"银弹"，每种方案都有其最优适用区间：
- 追求极致性能：Caffeine（本地） + Redis（分布式）是最稳健的黄金组合。
- 追求功能全面：Redis + Redisson 提供数据结构、锁、计数器等一站式能力。
- 追求零运维：云托管 Redis（如阿里云 Redis、AWS ElastiCache）减少自建负担。
- 追求统一计算平台：Ignite 和 Hazelcast 更适合数据网格需求。
- 拥抱云原生：Redis Cluster 配合 Kubernetes Operator 可实现自动化运维。
在技术快速迭代的今天，Redis 凭借其生态和社区优势已成为缓存领域的事实标准。对于大多数新项目而言，Caffeine（本地）+ Redis/Redis Cluster（分布式）+ Redisson（客户端） 是性价比最高、生态最成熟的组合方案。
本文撰写于 2026 年，所有版本信息以各项目官方发布为准。