1. 分布式锁的核心价值与挑战在当今的互联网架构中分布式系统已经成为标配。当多个服务实例需要同时操作共享资源时如何保证数据一致性就成了必须解决的问题。上周我们线上就出现过因为促销活动导致库存超卖的事故最后排查发现就是并发控制没做好。传统单机环境下的synchronized或ReentrantLock在分布式场景下完全失效这时候就需要引入分布式锁。Redis凭借其高性能和丰富的数据结构成为实现分布式锁的首选方案之一。但真正要用好Redis分布式锁里面有不少门道。2. Redis分布式锁的实现原理2.1 基础实现方案最基础的Redis锁实现非常简单就是利用SETNX命令SETNX lock_key unique_value当返回1表示获取锁成功0则表示锁已被占用。释放锁时直接DEL key即可。但这种实现有几个致命缺陷如果客户端崩溃锁永远不会释放死锁非阻塞式获取需要自己实现重试逻辑不具备可重入性没有超时机制2.2 改进版实现Redis 2.6.12之后我们可以用更完善的命令SET lock_key unique_value NX PX 30000这个命令一次性解决了原子性设置和超时问题。其中NX表示只有key不存在时才设置PX设置过期时间毫秒unique_value用于标识锁的持有者3. Spring Boot中的最佳实践3.1 基础集成方案在Spring Boot中集成Redis锁非常简单Bean public RedisTemplateString, Object redisTemplate(RedisConnectionFactory factory) { RedisTemplateString, Object template new RedisTemplate(); template.setConnectionFactory(factory); template.setKeySerializer(new StringRedisSerializer()); template.setValueSerializer(new GenericJackson2JsonRedisSerializer()); return template; } public boolean tryLock(String lockKey, String clientId, long expireTime) { return redisTemplate.opsForValue() .setIfAbsent(lockKey, clientId, expireTime, TimeUnit.MILLISECONDS); }3.2 高级封装方案对于生产环境建议使用Redisson客户端Bean public RedissonClient redissonClient() { Config config new Config(); config.useSingleServer() .setAddress(redis://127.0.0.1:6379); return Redisson.create(config); } public void doWithLock(String lockKey) { RLock lock redissonClient.getLock(lockKey); try { if(lock.tryLock(5, 30, TimeUnit.SECONDS)) { // 业务逻辑 } } finally { lock.unlock(); } }Redisson提供了更多高级特性自动续期可重入锁公平锁联锁MultiLock红锁RedLock4. 开发者常踩的坑及解决方案4.1 锁过期时间设置不当很多开发者设置的过期时间太短导致业务还没执行完锁就自动释放了。建议评估业务方法的最长执行时间设置过期时间 预估最长时间 * 2考虑使用Redisson的看门狗自动续期机制4.2 未正确处理锁释放常见错误包括忘记在finally块中释放锁释放了其他客户端的锁没有校验value释放锁时网络异常导致锁残留正确的释放方式public void unlock(String lockKey, String clientId) { String value redisTemplate.opsForValue().get(lockKey); if (clientId.equals(value)) { redisTemplate.delete(lockKey); } }4.3 锁重入问题如果同一个线程需要多次获取同一个锁简单的Redis锁实现会阻塞自己。解决方案使用Redisson的可重入锁自己实现计数器记录重入次数4.4 集群环境下的特殊问题在Redis集群模式下主从切换可能导致锁失效。解决方案使用RedLock算法需要多个独立Redis实例考虑使用Zookeeper等CP系统实现锁5. 性能优化与监控5.1 锁粒度控制锁的粒度越细性能越好。建议不要锁整个方法只锁关键资源根据业务ID分段加锁避免锁嵌套5.2 监控指标需要监控的关键指标锁等待时间锁持有时间锁获取失败率死锁发生次数可以通过AOP统一采集这些指标Aspect Component public class LockMonitorAspect { Around(annotation(distributedLock)) public Object monitor(ProceedingJoinPoint pjp, DistributedLock distributedLock) throws Throwable { long start System.currentTimeMillis(); try { return pjp.proceed(); } finally { long cost System.currentTimeMillis() - start; Metrics.timer(lock. distributedLock.value()).record(cost, TimeUnit.MILLISECONDS); } } }6. 替代方案对比虽然Redis锁很流行但并不是所有场景都适用方案优点缺点适用场景Redis性能高实现简单可靠性依赖Redis高并发允许偶尔失败Zookeeper可靠性高性能较差强一致性要求数据库无需额外组件性能最差简单系统低并发在实际项目中我们通常会根据业务特点选择最合适的方案。对于大多数互联网应用来说Redis锁在可靠性和性能之间取得了很好的平衡。