分布式缓存（Redis）的实现，核心在于根据业务规模选择主从、哨兵或集群模式，并配合合理的分片、高可用及一致性策略，从而在保证数据可靠性的前提下最大化读写性能。
Redis分布式缓存实现方案：主从、哨兵与集群
谈到分布式缓存,Redis 是绕不开的基础设施，业界公认，Redis 的分布式实现主要依赖三种架构：主从复制、哨兵模式和 Redis Cluster 集群，三者分别对应不同的场景和成本，选择哪个方案直接决定了缓存层的稳定性和扩展能力。
主从复制：最基础的读写分离
主从复制是 Redis 高可用的起点，一个主节点负责写，多个从节点同步数据并承担读请求，这种架构简单，适合读多写少、数据量不大的场景，但缺点也很明显：主节点宕机时需要手动切换，无法自动故障转移，行业共识认为，主从复制更适合作为集群的补充，而不是独立的高可用方案。
哨兵模式：自动故障转移
在主从基础上增加哨兵进程,监控主节点状态，当主节点挂掉时自动选举新主，哨兵模式解决了高可用问题，但存储能力仍然受限于单机内存，无法横向扩展写能力，据统计，多数中小型项目在初期会选择哨兵，随着数据量增长再迁移到集群。
Redis Cluster：真正的分布式缓存
Redis Cluster 是官方推荐的分布式方案，采用无中心架构，数据自动分片到 16384 个槽位，每个节点负责一部分槽，客户端直接连接任意节点即可读写，节点间通过 Gossip 协议通信，Cluster 天然支持水平扩展，增加节点后槽位自动迁移，读写性能线性提升，业内专家指出，Redis Cluster 是分布式缓存实现的主流选择，尤其适合需要高吞吐和动态扩容的场景。
| 方案 | 扩展性 | 高可用 | 数据分片 | 适用场景 |
|---|---|---|---|---|
| 主从复制 | 差，只读扩展 | 手动切换 | 无 | 小型应用，读多写少 |
| 哨兵模式 | 差，存储受限 | 自动故障转移 | 无 | 中等规模，需要高可用 |
| Redis Cluster | 强，水平扩展 | 自动故障转移+分片 | 自动 16384 槽位 | 大规模，高并发 |
选择哪一种,取决于你的数据量和并发需求，如果只是单机几 GB 且允许短暂不可用，主从足够；如果要求自动切换但数据量不大，哨兵合适；一旦数据量超过几十 GB 或并发超万，直接上 Cluster 是最省心的长期方案。
缓存雪崩与缓存穿透的解决方案
缓存层最怕的两件事：雪崩和穿透，雪崩时大量缓存同时失效，请求直接打到底层数据库，可能导致系统崩溃；穿透则是恶意请求绕开缓存，直接查询不存在的数据，同样会压垮数据库，针对这两个问题，业内有一套成熟的应对策略。
缓存雪崩的预防措施
缓存雪崩通常发生在缓存集中过期或 Redis 节点宕机时，解决方案分为提前预防和熔断降级。
- 过期时间随机化：不要在同一个时间点设置大量 key 的过期时间，可以在基础过期时间上添加一个随机值，1–5 分钟，避免集体失效。
- 多级缓存架构：本地缓存（如 Guava Cache）作为第一级，Redis 作为第二级，数据库作为第三级，即使 Redis 挂掉，本地缓存也能扛住一部分流量。
- 限流与降级：在 Redis 集群前方增加限流组件，当缓存命中率低于阈值时，直接返回默认值或错误信息，避免所有请求穿透。
- Redis 高可用：使用哨兵或 Cluster 确保 Redis 节点不单点故障。
缓存穿透的布隆过滤器
穿透的本质是查询一个不存在的数据,最简单的方法是把空结果也缓存起来，但容易被恶意攻击者利用不同的 key 绕过，更好的做法是使用布隆过滤器。
布隆过滤器是一个二进制向量,可以快速判断一个 key 是否存在于集合中，如果布隆过滤器说 key 不存在，那一定不存在；如果它说存在，则可能存在小概率误判，将合法的 key 预先加载到布隆过滤器中，请求到来时先检查过滤器，只有命中时才查询 Redis，这样，不存在的 key 在第一步就被拦截，不会到达缓存层和数据库。
缓存击穿的互斥锁
击穿不同于雪崩：它是一个热点 key 在过期瞬间被大量并发请求访问，解决方法是互斥锁，即当 key 过期时，只允许一个线程去数据库加载数据，其他线程等待，可以使用 Redis 的 SETNX 命令实现分布式锁，或者使用 Redisson 等封装库，注意锁的超时时间要设置合理，防止死锁。
保证缓存一致性的策略
缓存和数据库的数据一致性问题,是所有分布式缓存实现的核心难点，Redis 作为缓存，通常只保证最终一致性，但在某些场景下需要尽可能接近强一致。
先更新数据库再删除缓存
业界公认的最标准做法：更新数据时先操作数据库，成功后再删除缓存，下次读取时缓存缺失，加载新数据到缓存，这种方案在大多数情况下工作良好，但存在短暂的不一致窗口（数据库更新后、缓存删除前，其他线程可能读到旧缓存），如果业务能接受秒级延迟，这是首选。
延时双删策略
对一致性要求更高的场景,可以使用延时双删，先删除缓存，再更新数据库，等待几百毫秒后再删除一次缓存，目的是删除数据库更新期间可能被其他线程写入的旧缓存，虽然增加了少量的删除开销，但能显著降低不一致概率。Redis分布式缓存如何保证数据一致性，业内专家指出，延时双删是应对并发写比较成熟的做法。
监听 binlog 同步
如果数据库是 MySQL，可以通过 Canal 等组件监听 binlog 变更，然后异步更新 Redis，这种方式解耦了业务代码，把一致性逻辑下沉到数据层，但需要额外维护 Canal 服务，适合对一致性要求极高且团队有运维能力的场景。
实操：Redis Cluster 集群搭建步骤
下面按步骤说明如何搭建一个最简单的 Redis Cluster（3 主 3 从），假设你已经有多台机器或本地端口，以下命令基于 Redis 6 以上版本。
- 准备 6 个实例配置文件，每个实例端口不同（如 7000–7005），开启 cluster-enabled yes，指定 cluster-config-file。
- 启动每个实例：
redis-server redis_7000.conf，重复 6 次。 - 使用 redis-cli 创建集群：
redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 --cluster-replicas 1
- 输入 yes 确认槽位分配，集群创建成功后，会自动分配 16384 个槽给三个主节点，每个主节点带一个从节点。
- 测试集群：
redis-cli -c -p 7000连接，set 一个 key，观察是否自动重定向。
注意：生产环境建议使用相同配置的机器，槽位迁移时带宽和内存要留有余量。
性能优化与监控
搭建好集群只是第一步,后续的优化和监控决定缓存层能否长期稳定，重点关注几个方面：
- 内存碎片：使用
info memory查看碎片率，如果超过 1.5，考虑重启或调整内存分配策略。 - 大 key 问题：避免存储超过 10 MB 的字符串或元素数量巨大的集合，大 key 会导致集群迁移缓慢、阻塞其他命令，使用
redis-cli --bigkeys扫描。 - 慢查询日志：设置
slowlog-log-slower-than 10000，定期检查慢查询，优化对应命令（如减少keys命令，改用 scan）。 - 连接数限制：根据业务估算最大连接数，调整
maxclients参数，避免连接耗尽。
分布式缓存（Redis）实现问答
缓存穿透和缓存雪崩有什么区别？
穿透是访问不存在的数据,导致每次请求都绕过缓存查数据库；雪崩是大量缓存同时失效，导致请求集中打向数据库，穿透的根源是 key 不存在，雪崩的根源是 key 集体过期或节点宕机，解决方案也不同：穿透常用布隆过滤器，雪崩常用过期时间随机化加多级缓存。
Redis 集群如何进行数据分片？
Redis Cluster 采用一致性哈希的变体哈希槽，整个 keyspace 被分为 16384 个槽，每个节点负责一部分槽，当客户端 set 一个 key 时，对 key 进行 CRC16 运算再取模 16384，得到槽号，然后定位到对应的节点，集群的扩容和缩容本质上是槽位迁移，不影响客户端映射逻辑。
缓存更新时先删缓存还是先更新数据库？
先更新数据库后删缓存,如果先删缓存，在更新数据库期间，其他线程可能读到旧数据并写入缓存，导致数据不一致，先更新数据库再删缓存，虽然存在短暂不一致（缓存删除前有旧值），但窗口极小，且删除操作幂等，是多数场景下的最佳实践。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/542374.html
