Redis分布式缓存，就是用Redis将数据分散在多个节点上，通过内存读写大幅降低数据库压力，这一方案在多数高并发场景下已被验证为最有效的解耦手段。 无论是电商秒杀、社交时间线，还是实时排行榜，Redis都扮演着核心加速角色，但要用好它，不能只搭个集群数据一致性、方案选型、成本控制,每一步都藏着实务细节。参考2
为什么Redis在分布式缓存中如此流行
Redis能成为分布式缓存的首选，不仅因为快，更因为它提供丰富的数据结构和灵活的分片机制,这与传统缓存方案形成了鲜明对比。
核心优势：远超内存的高性能
Redis单机QPS通常能达到10万+，通过集群扩展可以轻松支撑百万级并发，相比传统数据库，Redis的响应时间维持在微秒级别,这对延迟敏感的业务至关重要。
与Memcached的对比
| 特性 | Redis | Memcached |
|---|---|---|
| 数据结构 | 字符串、哈希、列表、集合、有序集合等 | 仅支持字符串 |
| 持久化 | 支持RDB和AOF | 不支持 |
| 集群模式 | 原生Cluster、哨兵、Proxy | 客户端分片 |
| 内存管理 | 多种淘汰策略 | LRU算法 |
Memcached虽简单，但Redis的扩展性和功能丰富度明显更胜一筹，行业共识认为，在大多数分布式缓存场景里,Redis是更稳妥的选择。
选对Redis分布式缓存部署方案
部署方案直接关联成本和运维复杂度,你得根据业务规模和数据量来决定从哪套方案切入。
主从模式：快速起步
主从模式是最简单的分布式形态，一个Master负责写，多个Slave负责读，适合读多写少的场景，但Master故障时需要手动切换,可用性不够高。
哨兵模式：自动故障转移
Redis 2.8引入的哨兵（Sentinel）机制，可以监控主从状态，在Master宕机时自动选举新Master，大多数业务量不大的团队会优先考虑这个方案,因为它兼顾了简单和基本的高可用。
Cluster模式：真正水平扩展
Redis Cluster在3.0版本正式发布，采用无中心化架构，数据自动分片到16384个槽中，每个节点承担一部分槽，你可以在集群中动态加人或减压节点,实现在线扩容。
实操步骤：搭建一个最小Redis Cluster
- 下载Redis（以6.2为例）,解压并编译。
- 准备6个实例配置文件（3主3从），每个文件修改端口、集群启用、节点文件路径。
- 分别启动6个实例：
redis-server redis_7000.conf（依次修改端口）。 - 使用redis-cli创建集群：
redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 ... --cluster-replicas 1。 - 验证集群状态：
redis-cli -p 7000 cluster nodes。
这套方案在华东地区的部署中，很多中型企业用于支撑日均千万级请求，如果你在北京地区搭建类似的集群,需要额外关注网络延迟带来的跨机房同步问题。
如何应对缓存和数据库一致性问题
任何使用Redis分布式缓存的团队，都会面临缓存与数据库同步的挑战,这也是百度上搜索量很大的长尾词。
常见更新策略
- Cache Aside：读时先查缓存，缓存miss则查DB并回写，写时先更新DB，再删除缓存（或更新）,这是最常用的模式。
- Read/Write Through：缓存层代理DB,数据读写都通过缓存组件完成。
- Write Behind：异步批量写入DB,适合写低频场景。
业界实践：最终一致性
业内专家指出，在分布式系统中，强一致性几乎无法同时保证高性能，通常的做法是接受最终一致性,并通过消息队列或延时双删机制来缩小不一致窗口。
具体操作
：写操作先更新DB，再删除缓存，并发一条延时消息（如1秒后）再次删除缓存，确保即使第一次删除失败，也能补偿，多数情况下,这种方式能将不一致窗口压缩到1秒以内。
Redis分布式缓存性能优化技巧
性能优化是永恒的话题，从数据结构选择到内存配置,都直接影响Redis的表现。参考1
内存淘汰策略
当内存不足时，Redis根据配置的淘汰策略（maxmemory-policy）处理,常用策略包括：
- allkeys-lru：对所有key使用近似LRU算法,多数场景够用。
- volatile-ttl：对设置了过期时间的key优先淘汰即将过期的。
- noeviction：不淘汰，直接返回写入错误,适合严格不淘汰的场景。
使用Pipeline减少网络开销
客户端一次发送多条命令，Redis集中处理，返回结果，可以大幅减少RTT（往返时间），在批量操作时，Pipeline能提升5-10倍吞吐量，你可以通过 redis-cli --pipeline 指令快速测试效果。
连接池优化
对于Redis分布式缓存，客户端连接池的大小需要根据并发量调整，太小会导致请求排队，太大会增加Redis负载，一般建议在100-300个连接之间，根据压测结果微调，在Spring Boot中配置 spring.redis.jedis.pool.max-active=200。
业务场景实战
电商秒杀：库存扣减
秒杀的核心是极致的查库存和扣库存，利用Redis的原子操作（DECR），可以高效完成库存扣减，但需注意超卖问题：通过Redis的Lua脚本或事务保证原子性,一个典型脚本如下：
local key = KEYS[1]
local stock = redis.call('GET', key)
if stock and tonumber(stock) > 0 then
redis.call('DECR', key)
return 1
else
return 0
end这种方式能避免在并发扣减时出现负数。参考2
社交Feed：时间线缓存
用户关注的人发布内容，通常需要聚合后展示，使用Redis的
Sorted Set，以时间戳为分数，存储朋友圈内容ID，可以快速分页查询，用 ZREVRANGE user:timeline 0 9 获取最新10条。
地域性优化：多机房部署
对于服务华东、华南等多地域用户，可以在各区域部署Redis集群，通过读写分离和就近访问，降低延迟。北京地区的某金融客户，就通过这种方案将平均响应时间降低了40%左右。
Redis分布式缓存，说到底是在内存和速度之间做权衡，选对部署方案、处理好一致性问题、持续优化性能,你就能让Redis成为业务抗住高并发的重要保障。
Redis分布式缓存常见问题解答
Redis分布式缓存和本地缓存（如Caffeine）怎么选？
本地缓存快但容量小，且数据不共享；分布式缓存慢一点但容量大、可扩展，通常做法是：本地缓存做一级，Redis做二级，兼顾速度与容量，本地缓存命中后直接返回，miss时查Redis，再miss才查数据库,这种组合在多数微服务架构中已成标配。
搭建一个Redis分布式缓存集群最少需要几台机器？
如果使用Redis Cluster，最少需要3个主节点，建议每个主节点配一个从节点，共6台机器（或实例），但如果你只是测试，可以用3台机器，各启动两个实例（一个主一个从），但端口不同，硬件成本方面，内存是关键，单机内存建议不低于32GB，具体取决于缓存数据量，预算紧张时，先从3主3从起步,后期再扩容。
如何解决Redis缓存穿透问题？
缓存穿透是指查询一个不存在的数据，导致请求直接打到数据库，解决方案：布隆过滤器，将可能存在的key提前加载到布隆中，对不存在的数据直接拦截；或者缓存空值（设置较短过期时间），避免重复穿透，两种方法结合使用效果更好，布隆过滤器通常能拦截90%以上的无效请求,空值缓存作为兜底。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/531434.html
