三亩地 三亩地SAN MU DI · CODE DIARY
交流投稿
ARTICLE DETAIL

日记详情

真实记录编程学习的某一天，欢迎挑你感兴趣的翻一翻。

首页/学习日记/日记详情

Redis缓存与分布式锁的高并发实践指南

发布时间：2026/8/9 20:18:56 三亩地 编程学习日记
Redis缓存与分布式锁的高并发实践指南

1. Redis缓存与分布式锁的核心价值解析

在当今高并发系统架构中，Redis凭借其内存级读写性能已成为缓存方案的标配选择。我经历过多个日活百万级的电商项目，所有核心业务链路都重度依赖Redis缓存来扛住流量洪峰。但缓存用得好是利器，用不好就是定时炸弹——缓存雪崩、击穿、穿透这"三兄弟"随时可能让系统崩溃。更棘手的是分布式环境下的数据一致性问题，比如库存超卖、重复支付等场景，这时候就需要分布式锁来救场。

2. Redis缓存深度实践指南

2.1 缓存设计的三层架构

典型互联网应用会采用多级缓存架构：

  1. 本地缓存（Caffeine/Ehcache）：纳秒级响应，但容量有限
  2. Redis集群：毫秒级响应，支持TB级数据
  3. 持久化存储（MySQL/MongoDB）：秒级响应
// Spring Boot中多级缓存配置示例 @Bean public CacheManager cacheManager(RedisConnectionFactory factory) { return new CaffeineRedisCacheManager( Caffeine.newBuilder().expireAfterWrite(10, TimeUnit.MINUTES), RedisCacheConfiguration.defaultCacheConfig() .serializeValuesWith(SerializationPair.fromSerializer(new Jackson2JsonRedisSerializer<>(Object.class))) ); }

2.2 缓存失效策略的黄金组合

根据业务场景选择不同的过期策略组合：

  • 定时过期：适合数据变更频率固定的场景
  • 惰性删除：节省内存但可能短期堆积
  • 主动更新：通过消息队列通知变更

重要提示：永远要给缓存设置TTL，哪怕你认为这个数据"永远不会变"。我曾在生产环境因为一个没有TTL的配置缓存导致全网故障。

2.3 缓存穿透的七种武器

  1. 布隆过滤器：空间效率极高的概率型数据结构
  2. 空值缓存：对不存在的key也进行短时间缓存
  3. 互斥锁：防止多个请求同时击穿到DB
  4. 异步加载：后台线程定期预热热点数据
  5. 分级缓存：本地缓存+分布式缓存组合
  6. 请求合并：将多个相同查询合并为单个查询
  7. 熔断降级：当DB压力过大时暂时禁用缓存

3. 分布式锁的工程实践

3.1 Redis分布式锁的正确姿势

以下是基于Redisson的实现方案：

// 获取锁对象 RLock lock = redissonClient.getLock("orderLock"); try { // 尝试加锁，最多等待100秒，上锁后30秒自动解锁 if (lock.tryLock(100, 30, TimeUnit.SECONDS)) { // 处理业务逻辑 processOrder(); } } finally { // 释放锁 lock.unlock(); }

3.2 锁的四大核心参数

  1. 等待时间：避免线程长时间阻塞
  2. 租约时间：防止死锁的关键
  3. 重试策略：失败后的退避算法
  4. 锁粒度：按业务维度拆分锁

3.3 锁竞争优化方案

当出现大量锁竞争时，可以采用：

  • 分段锁：将库存拆分为多个子库存
  • 队列化：通过消息队列顺序处理
  • 乐观锁：配合版本号实现无锁化

4. 生产环境常见问题排查

4.1 缓存一致性难题

采用"先更新数据库再删除缓存"策略时，要注意：

  1. 数据库主从延迟可能导致脏读
  2. 缓存删除失败需要重试机制
  3. 高并发下可能产生竞态条件

解决方案示例：

def update_data(key, value): # 更新数据库 db.update(key, value) # 删除缓存 for i in range(3): # 最多重试3次 try: redis.delete(key) break except Exception as e: if i == 2: mq.send("cache_clean", key) # 最终放入消息队列

4.2 分布式锁的陷阱

  1. 时钟漂移问题：不同服务器时间不一致导致锁提前释放
  2. 锁续期失败：业务处理超时但锁已自动释放
  3. 锁误释放：线程A释放了线程B持有的锁

应对方案：

  • 使用具有看门狗机制的Redisson客户端
  • 为每个锁设置唯一客户端标识
  • 监控锁的平均持有时间

5. 性能优化实战技巧

5.1 Redis内存优化

  1. 使用ziplist编码压缩小数据
  2. 对大数据采用分片存储
  3. 合理设置maxmemory-policy

5.2 热点key发现与处理

通过monitor命令或Redis日志分析热点key，处理方案：

  • 本地缓存备份
  • key拆分（如user:1:info拆分为多个字段）
  • 随机过期时间避免同时失效

5.3 Pipeline批量操作

将多个命令打包发送节省网络开销：

# 不使用pipeline SET key1 value1 SET key2 value2 # 使用pipeline MULTI SET key1 value1 SET key2 value2 EXEC

6. 监控与治理方案

6.1 核心监控指标

  1. 缓存命中率（>90%为健康）
  2. 平均响应时间（<5ms为佳）
  3. 内存使用率（<70%避免swap）
  4. 连接数使用率

6.2 治理工具推荐

  1. RedisInsight：官方可视化工具
  2. Prometheus+Granfa监控体系
  3. 自定义健康检查脚本

我在实际项目中会为每个Redis实例部署一个sidecar容器，定时执行以下检查：

  1. 内存碎片率（info memory）
  2. 持久化状态（info persistence）
  3. 主从同步延迟（info replication）

7. 典型业务场景实现

7.1 秒杀系统设计

关键点：

  1. 库存预热到Redis
  2. 使用分布式锁扣减库存
  3. 订单创建异步化
public boolean seckill(long itemId) { // 1. 校验库存 Integer stock = redisTemplate.opsForValue().get("stock:" + itemId); if (stock == null || stock <= 0) { return false; } // 2. 获取分布式锁 String lockKey = "lock:" + itemId; boolean locked = redisTemplate.opsForValue().setIfAbsent(lockKey, "1", 10, TimeUnit.SECONDS); if (!locked) { return false; } try { // 3. 双重检查 stock = redisTemplate.opsForValue().get("stock:" + itemId); if (stock <= 0) { return false; } // 4. 扣减库存 redisTemplate.opsForValue().decrement("stock:" + itemId); // 5. 创建订单（异步） mqTemplate.send("order_queue", buildOrder(itemId)); return true; } finally { // 6. 释放锁 redisTemplate.delete(lockKey); } }

7.2 会话保持方案

使用Redis存储会话时的注意事项：

  1. 设置合理的TTL（通常30分钟）
  2. 采用hash结构存储会话属性
  3. 实现滑动过期机制

8. 高级特性应用

8.1 Lua脚本原子操作

解决库存扣减的原子性问题：

local key = KEYS[1] local change = tonumber(ARGV[1]) local current = tonumber(redis.call('GET', key) or "0") if current + change < 0 then return 0 end redis.call('INCRBY', key, change) return 1

8.2 Redis Stream消息队列

相比Pub/Sub的优势：

  1. 消息持久化
  2. 消费者组支持
  3. 消息回溯能力

配置示例：

XADD orders * itemId 1234 userId 5678 XGROUP CREATE orders order_group $ MKSTREAM

9. 集群部署方案

9.1 主从复制配置

redis.conf关键参数：

replicaof 192.168.1.100 6379 replica-read-only yes min-replicas-to-write 1

9.2 哨兵模式部署

典型架构：

  • 3个哨兵节点（奇数个）
  • 1主2从的Redis节点
  • 客户端通过哨兵获取主节点地址

9.3 Cluster模式实践

数据分片策略：

  1. 官方推荐16384个slot
  2. 使用CRC16算法计算key所属slot
  3. 支持动态扩容缩容

10. 开发中的实用技巧

10.1 缓存key设计规范

  1. 使用冒号分隔层级（user:123:profile）
  2. 包含业务前缀（order_, product_）
  3. 控制key长度（<100字节）

10.2 连接池优化

Jedis配置示例：

# 最大连接数 spring.redis.jedis.pool.max-active=200 # 最大空闲连接 spring.redis.jedis.pool.max-idle=50 # 最小空闲连接 spring.redis.jedis.pool.min-idle=10 # 最大等待时间(ms) spring.redis.jedis.pool.max-wait=1000

10.3 慢查询分析

通过redis-cli查找慢查询：

# 设置阈值(单位微秒) config set slowlog-log-slower-than 10000 # 查看慢查询 slowlog get 10

在多年使用Redis的过程中，我发现最容易被忽视的是连接泄漏问题。建议所有项目都实现连接使用监控，比如通过AOP记录连接获取/释放日志。当发现连接持有时间异常时（比如超过1秒），要立即告警并排查代码逻辑。

编程学习 学习日记 实战经验
← 返回列表