Redis是当前分布式缓存领域的事实标准，凭借其丰富的数据结构和高性能，成为绝大多数高并发系统的首选。
Redis分布式缓存与Memcached对比：谁更适合你的业务
很多团队在选型时都会纠结于Redis和Memcached，两者虽然都是内存缓存，但设计理念和功能差异巨大，下面从几个核心维度展开,帮你快速判断。
数据结构与功能差异
Redis支持String、Hash、List、Set、Sorted Set等5种基本数据结构，还提供了HyperLogLog、Geo、Bitmap等扩展类型，Memcached仅支持简单的key-value结构，且value必须是字符串，这意味着如果你想实现排行榜、计数器、社交关系等功能，Redis可以直接用原生数据结构完成，而Memcached需要业务层自行组装。
持久化与可靠性
Redis内置RDB和AOF两种持久化机制，重启后数据可恢复，适合对数据一致性要求较高的场景，Memcached纯粹是内存缓存，一旦进程重启或服务器宕机，所有数据立即丢失，行业共识认为，在需要缓存数据可恢复的系统中，Redis是更稳妥的选择。
集群与扩展性
Redis 3.0之后推出了原生集群方案（Redis Cluster），通过分片自动扩展，客户端无需关心路由，Memcached没有原生集群，只能依赖客户端一致性哈希，节点增减时需要手动处理重新分布，很多实际案例表明，Redis Cluster在运维便捷性上明显优于Memcached的客户端方案。
性能对比概览
| 对比维度 | Redis | Memcached |
| --- | --- | --- |
| 数据结构 | 丰富（5种基础+
多种扩展） | 简单key-value |
| 持久化 | 支持RDB/AOF | 不支持 |
| 集群方案 | 原生Cluster，自动分片 | 客户端一致性哈希 |
| 典型延迟 | 1ms以内（单机） | 1ms以内（单机） |
| 适用场景 | 复杂缓存、计数器、分布式锁 | 简单KV缓存，对持久化无要求 |
如果你需要灵活的数据操作和一定程度的数据可靠性，优先选Redis；如果业务极其简单且对数据丢失不敏感，Memcached在纯key-value场景下仍有性能优势。
Redis分布式缓存实战场景：从缓存穿透到分布式锁
理论说再多不如动手做一遍，下面几个高频场景,直接给出可落地的操作步骤。
缓存穿透：布隆过滤器拦截无效请求
当大量请求查询一个根本不存在的数据时，请求会直接穿透缓存落到数据库，造成数据库压力，解决方案是使用布隆过滤器预先判断key是否存在，操作路径：
- 连接Redis（假设启用了RedisBloom模块）
- 执行 `BF.RESERVE bloom_key 0.01 1000000` 创建过滤器（误差率1%，预计容量100万）
- 查询前先执行 `BF.EXISTS bloom_key user:123`，若返回0则直接返回空，不再查询数据库
- 写入数据时同步执行 `BF.ADD bloom_key user:123`
缓存雪崩：错峰过期与互斥锁
大量缓存同时过期，导致请求全部落库，预防措施：
- 设置过期时间时加入随机偏移，`EXPIRE key 3600 + random(0,600)`
- 热点数据使用互斥锁控制重建：当缓存失效时，先尝试获取锁，成功后才能查询数据库并更新缓存，其他请求等待或直接返回旧值（降级）
- 命令示例：`SET lock_key user:lock NX PX 30000`，成功则执行 `SET user:123 value EX 3600`，执行完后 `DEL lock_key`
分布式锁：基于Redis的可靠实现
分布式锁是最常见的缓存衍生应用，推荐使用Redisson框架，它封装了锁的自动续期和重试机制，如果你需要手动实现，核心步骤：
- 加锁：`SET lock_key ${uuid} NX PX 30000`（30秒自动过期）
- 解锁：用Lua脚本保证原子性，检查value是否等于自己的uuid，是则删除
- 业务代码需要在锁过期前完成，否则需要续期（Redisson的Watchdog自动处理）
业内专家指出，基于Redis的分布式锁在大多数微服务场景下已经足够可靠，除非对一致性要求极高才需要考虑ZooKeeper方案。
Redis分布式缓存选型：成本与地域因素
部署Redis不仅涉及技术选择，还直接关系到预算和网络延迟，自建和云服务各有优劣,地域分布也会影响用户体验。
自建Redis vs 云服务Redis成本对比
自建需要购买服务器、带宽、磁盘，还要承担运维人力成本，据统计，一台中等配置的云服务器（4核8G）月成本约几百元，但Redis集群需要多台，加上主从复制，成本会成倍增加，云服务Redis实例（如简米云Redis标准版）按规格计费，1GB内存实例月费在百元左右，且包含自动备份、监控、故障切换，如果你没有专职DBA，云服务Redis在总体拥有成本上往往更低。
地域部署最佳实践
多地域部署时，推荐使用云服务商提供的全球分布式缓存方案（如简米云全球数据库Redis版），自动就近读取，减少跨地域延迟，自建的话，可以采用主从复制，主节点写本地，从节点同步到其他区域，但写入延迟会增大，关键原则：
读多写少的场景，多用从节点分散读压力；写密集场景，优先保证主节点所在区域延迟最低，对于金融、电商等敏感业务，通常会在同城双机房部署主从，异地再放一个只读节点做灾备。
分布式缓存Redis常见问题解答
Redis分布式缓存如何保证数据一致性？
Redis默认使用异步主从复制，主节点写入后立即返回，从节点异步同步，属于最终一致性，如果需要强一致性，可以启用WAIT命令等待从节点确认，但会牺牲部分性能，实际业务中，多数场景允许短暂不一致，因此异步复制是主流选择。
Redis分布式缓存集群最多支持多少节点？
Redis Cluster理论节点数上限为16384个（因为槽位数量是16384），但实际生产环境建议不超过1000个节点，节点过多会导致通信开销剧增，Gossip协议同步变慢，官方推荐合理规模在几十到几百个节点之间。
Redis分布式缓存和本地缓存如何搭配使用？
多级缓存架构是常见做法：本地缓存（如Caffeine）作为一级，Redis作为二级，数据库作为三级，查询时先查本地缓存，命中则直接返回，未命中再查Redis，仍未命中才查数据库并回填两级缓存，这样能大幅减少Redis的请求量，同时利用本地缓存极低的延迟优势，需要重点关注本地缓存的数据一致性，通常设置较短过期时间或主动失效机制。