分布式锁

分布式锁的实现方案（详解+使用场景+方案对比）

在分布式架构（如微服务、集群部署）中，多个节点/服务会同时操作共享资源（如数据库数据、缓存、文件），若缺乏有效的并发控制，会出现数据不一致、重复执行等问题（如重复下单、库存超卖）。分布式锁的核心作用是：保证分布式环境中，同一时刻只有一个节点/服务能执行某一临界操作，类比单机环境中的synchronized锁、ReentrantLock，实现跨节点的并发安全。

一个合格的分布式锁，需满足5个核心特性：① 互斥性（同一时刻只有一个持有者）；② 安全性（无死锁，异常时能释放锁）；③ 可用性（集群故障时仍能正常使用）；④ 可重入性（同一节点可多次获取同一把锁）；⑤ 公平性（可选，按请求顺序获取锁）。

结合分布式架构实战，分布式锁的5种主流实现方案分别是：基于Redis的分布式锁、基于ZooKeeper的分布式锁、基于数据库的分布式锁、基于etcd的分布式锁、基于Redisson的分布式锁（Redis封装）。本文将逐一详解每种方案，对比优劣并明确适用场景，重点贴合Java开发实战。

一、5种分布式锁实现方案详解（Java实战视角）

前提说明：所有方案均针对“分布式架构（多节点/多服务）”，核心解决“跨节点并发控制”问题，不同方案的核心差异的在于“实现成本、性能、可靠性、易用性”，需根据业务场景取舍。

方案1：基于Redis的分布式锁（原生API实现）

1. 核心原理

利用Redis的原子性命令（SET NX EX）实现分布式锁，核心逻辑：向Redis中设置一个key（锁标识，如lock:order:123），value为随机字符串（避免误释放他人锁），同时指定过期时间（避免死锁）。若key不存在则设置成功（获取锁），若key已存在则设置失败（获取锁失败）。

核心命令（Redis 2.6.12+支持）：SET key value NX EX seconds，其中：NX（Only set the key if it does not already exist，互斥性）、EX（设置过期时间，避免死锁）。

2. 核心流程

获取锁：调用SET NX EX命令，设置锁key、随机value、过期时间（如30s）；若返回OK，说明获取锁成功；若返回nil，说明锁已被占用，获取失败。
执行业务：获取锁成功后，执行临界业务操作（如扣减库存、创建订单）。
释放锁：业务执行完成后，通过Lua脚本删除锁key（确保原子性，避免误释放），脚本逻辑：判断当前锁的value是否与自己的value一致，一致则删除，不一致则不操作。
异常处理：若业务执行过程中节点宕机，锁key会因过期时间自动删除，避免死锁。

3. Java实现示例（Spring Boot + RedisTemplate）

@Service
public class RedisLockService {
    @Autowired
    private StringRedisTemplate redisTemplate;

    // 锁的过期时间（30s）
    private static final long LOCK_EXPIRE = 30000L;
    // 锁的前缀
    private static final String LOCK_PREFIX = "lock:";

    // 获取锁
    public boolean tryLock(String lockKey, String requestId) {
        // SET NX EX 命令：不存在则设置，过期时间30s
        Boolean success = redisTemplate.opsForValue().setIfAbsent(
                LOCK_PREFIX + lockKey,
                requestId,
                LOCK_EXPIRE,
                TimeUnit.MILLISECONDS
        );
        return Boolean.TRUE.equals(success);
    }

    // 释放锁（Lua脚本，保证原子性）
    public boolean releaseLock(String lockKey, String requestId) {
        String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
        // 执行Lua脚本
        Long result = redisTemplate.execute(
                new DefaultRedisScript<>(script, Long.class),
                Collections.singletonList(LOCK_PREFIX + lockKey),
                requestId
        );
        return 1L.equals(result);
    }

    // 业务方法（使用分布式锁）
    public void doBusiness(String lockKey) {
        // 生成唯一requestId（避免误释放锁）
        String requestId = UUID.randomUUID().toString();
        try {
            // 获取锁
            boolean locked = tryLock(lockKey, requestId);
            if (!locked) {
                throw new RuntimeException("获取分布式锁失败，请勿重复操作");
            }
            // 执行业务逻辑（如扣减库存）
            System.out.println("执行业务操作...");
        } finally {
            // 释放锁（无论业务成功/失败，都要释放）
            releaseLock(lockKey, requestId);
        }
    }
}

4. 优点

性能极高：Redis是内存数据库，SET、DEL命令响应时间极短（毫秒级），支持高并发场景，吞吐量远高于数据库、ZooKeeper。
实现简单：基于Redis原生命令，无需依赖复杂框架，开发成本低，易落地。
高可用：Redis支持集群部署（主从、哨兵、Redis Cluster），即使单个节点故障，锁服务仍能正常提供。

5. 缺点

锁过期问题：若业务执行时间超过锁的过期时间，锁会自动释放，可能导致多个节点同时获取锁（需配合“锁续期”优化，如开启定时任务刷新过期时间）。
不支持可重入：原生SET NX EX命令实现的锁，同一节点多次获取同一把锁会失败（需额外维护重入次数，实现复杂）。
公平性差：默认是“非公平锁”，无法保证按请求顺序获取锁，可能出现饥饿现象。

方案2：基于Redisson的分布式锁（Redis封装，推荐）

1. 核心原理

Redisson是Java生态中最成熟的Redis客户端之一，它对Redis原生分布式锁进行了封装，解决了原生API的痛点（如可重入、锁续期、公平锁），底层仍基于Redis的原子命令，支持多种锁类型（可重入锁、公平锁、读写锁、联锁等）。

核心优化点：① 支持可重入（维护重入次数）；② 自动锁续期（Watch Dog机制，业务未执行完时，自动刷新锁过期时间）；③ 支持公平锁/非公平锁；④ 支持集群环境，适配Redis主从、哨兵、Cluster架构。

2. 核心流程

初始化Redisson客户端：配置Redis集群信息，创建RedissonClient实例。
获取锁：通过RedissonClient获取对应类型的锁（如RLock可重入锁），调用lock()方法（默认非公平锁，可指定公平锁、过期时间）。
执行业务：获取锁成功后，执行临界业务操作，Watch Dog机制自动续期。
释放锁：业务执行完成后，调用unlock()方法释放锁；若节点宕机，锁过期后自动释放，Watch Dog停止续期。

3. Java实现示例（Spring Boot + Redisson）

// 1. 配置Redisson客户端
@Configuration
public class RedissonConfig {
    @Bean
    public RedissonClient redissonClient() {
        Config config = new Config();
        // 配置Redis Cluster（也可配置主从、哨兵）
        config.useClusterServers()
                .addNodeAddress("redis://127.0.0.1:6379", "redis://127.0.0.1:6380")
                .setPassword("123456");
        return Redisson.create(config);
    }
}

// 2. 业务服务（使用Redisson分布式锁）
@Service
public class RedissonLockService {
    @Autowired
    private RedissonClient redissonClient;

    // 业务方法（可重入锁，默认非公平锁）
    public void doBusiness(String lockKey) {
        // 获取可重入锁
        RLock lock = redissonClient.getLock("lock:" + lockKey);
        try {
            // 获取锁，默认过期时间30s，Watch Dog自动续期
            lock.lock();
            // 执行业务逻辑（如扣减库存、创建订单）
            System.out.println("执行业务操作...");
            // 若需指定过期时间（不开启Watch Dog）：lock.lock(30, TimeUnit.SECONDS);
            // 若需公平锁：RLock fairLock = redissonClient.getFairLock("lock:" + lockKey);
        } finally {
            // 释放锁（必须在finally中释放，避免死锁）
            if (lock.isHeldByCurrentThread()) {
                lock.unlock();
            }
        }
    }
}

4. 优点

易用性高：封装完善，API简洁，无需手动处理锁续期、可重入、原子释放等问题，开发成本极低。
功能强大：支持可重入锁、公平锁、读写锁、联锁、红锁等多种锁类型，适配复杂业务场景。
性能优秀：底层基于Redis，继承Redis的高吞吐量，同时优化了锁机制，避免原生API的痛点。
高可用：完美适配Redis各种集群架构，支持故障自动切换，锁服务稳定性高。

5. 缺点

依赖Redis：需部署Redis集群，增加系统复杂度（相对于数据库锁）。
额外依赖：需引入Redisson依赖，虽简化开发，但增加了第三方依赖。
锁过期仍有风险：若Watch Dog机制故障（如JVM宕机），锁会过期，可能出现并发问题（概率极低）。

方案3：基于ZooKeeper的分布式锁

1. 核心原理

利用ZooKeeper的临时有序节点和Watcher机制实现分布式锁，核心逻辑：在ZooKeeper的指定节点（如/lock）下，每个请求锁的节点创建一个临时有序子节点（如/lock/lock-xxx）；通过判断自己的子节点是否为当前最小的子节点，决定是否获取锁；若不是最小节点，则监听前一个子节点，前一个节点释放锁时，当前节点自动尝试获取锁。

核心特性：临时节点（节点创建者宕机后，节点自动删除，避免死锁）、有序节点（保证锁的公平性）、Watcher机制（实现锁的自动唤醒）。

2. 核心流程

创建根节点：在ZooKeeper中创建一个持久根节点（如/lock），用于存储所有锁节点。
创建临时有序子节点：每个请求锁的节点，在根节点下创建一个临时有序子节点（如/lock/lock-1、/lock/lock-2）。
判断是否获取锁：获取根节点下所有子节点，排序后判断自己的子节点是否为第一个（最小）；若是，则获取锁成功；若不是，则监听前一个子节点。
执行业务：获取锁成功后，执行临界业务操作。
释放锁：业务执行完成后，删除自己创建的临时子节点（释放锁）；若节点宕机，临时子节点自动删除，前一个节点的Watcher被触发，自动尝试获取锁。

3. Java实现示例（Curator框架，ZooKeeper客户端）

// 1. 配置Curator客户端（ZooKeeper客户端）
@Configuration
public class ZkConfig {
    @Bean
    public CuratorFramework curatorFramework() {
        // 连接ZooKeeper集群，会话超时时间5s，连接超时时间3s
        CuratorFramework client = CuratorFrameworkFactory.builder()
                .connectString("127.0.0.1:2181,127.0.0.1:2182")
                .sessionTimeoutMs(5000)
                .connectionTimeoutMs(3000)
                .retryPolicy(new ExponentialBackoffRetry(1000, 3)) // 重试策略
                .build();
        client.start(); // 启动客户端
        return client;
    }
}

// 2. 业务服务（使用Curator分布式锁）
@Service
public class ZkLockService {
    @Autowired
    private CuratorFramework curatorFramework;

    // 锁的根节点
    private static final String LOCK_ROOT_PATH = "/lock";

    // 业务方法（公平锁，Curator封装）
    public void doBusiness(String lockKey) {
        // 创建分布式锁（InterProcessMutex是可重入公平锁）
        InterProcessMutex lock = new InterProcessMutex(curatorFramework, LOCK_ROOT_PATH + "/" + lockKey);
        try {
            // 获取锁，最多等待10s，超时则获取失败
            boolean locked = lock.acquire(10, TimeUnit.SECONDS);
            if (!locked) {
                throw new RuntimeException("获取分布式锁失败，请勿重复操作");
            }
            // 执行业务逻辑
            System.out.println("执行业务操作...");
        } catch (Exception e) {
            throw new RuntimeException("业务执行异常", e);
        } finally {
            try {
                // 释放锁
                if (lock.isAcquiredInThisProcess()) {
                    lock.release();
                }
            } catch (Exception e) {
                log.error("释放锁失败", e);
            }
        }
    }
}

4. 优点

公平性强：基于有序节点，严格按请求顺序获取锁，避免饥饿现象，适合对公平性要求高的场景。
无死锁风险：临时节点特性，节点宕机后自动删除，无需担心死锁。
支持可重入：通过Curator框架的InterProcessMutex，可实现可重入锁，适配复杂业务。
高可用：ZooKeeper支持集群部署，单个节点故障不影响锁服务。

5. 缺点

性能一般：ZooKeeper是分布式协调工具，创建节点、监听节点等操作涉及网络通信和磁盘持久化，响应速度比Redis慢（毫秒级到十毫秒级），不适合高并发场景。
实现复杂：原生API需手动处理节点创建、排序、监听等逻辑，推荐使用Curator框架简化开发。
集群依赖：需部署ZooKeeper集群，运维成本高于Redis。

方案4：基于数据库的分布式锁

1. 核心原理

利用数据库的唯一约束或行锁实现分布式锁，核心有两种方式：① 基于唯一索引（插入一条锁记录，唯一索引保证互斥）；② 基于行锁（select for update，锁定某条记录，实现互斥）。

最常用的是“基于唯一索引”的方式：创建一张锁表，包含锁标识（lock_key）、持有者标识（holder_id）、过期时间（expire_time）等字段，lock_key建立唯一索引；获取锁时插入一条记录，插入成功则获取锁，插入失败（唯一约束冲突）则获取失败；释放锁时删除该记录，异常时通过过期时间清理无效锁。

2. 核心流程（基于唯一索引）

创建锁表：创建数据库表distributed_lock，包含id（主键）、lock_key（唯一索引）、holder_id（持有者标识）、expire_time（过期时间）。
获取锁：插入一条锁记录（lock_key为业务标识，holder_id为随机字符串，expire_time为当前时间+过期时间）；若插入成功，获取锁；若因唯一约束冲突插入失败，获取锁失败。
执行业务：获取锁成功后，执行临界业务操作。
释放锁：业务执行完成后，删除lock_key对应的记录；若节点宕机，通过定时任务清理expire_time小于当前时间的无效锁。

3. Java实现示例（Spring Boot + MyBatis）

// 1. 锁表实体
public class DistributedLock {
    private Long id;
    private String lockKey;
    private String holderId;
    private Date expireTime;
    // getter/setter...
}

// 2. Mapper接口
public interface DistributedLockMapper {
    // 插入锁记录（获取锁）
    int insertLock(DistributedLock lock);
    // 删除锁记录（释放锁）
    int deleteLock(String lockKey, String holderId);
    // 清理过期锁
    int cleanExpiredLock();
}

// 3. 业务服务
@Service
public class DbLockService {
    @Autowired
    private DistributedLockMapper lockMapper;
    @Autowired
    private SqlSessionFactory sqlSessionFactory;

    // 锁过期时间（30s）
    private static final long LOCK_EXPIRE = 30000L;

    // 获取锁（基于唯一索引）
    @Transactional(rollbackFor = Exception.class)
    public boolean tryLock(String lockKey) {
        String holderId = UUID.randomUUID().toString();
        DistributedLock lock = new DistributedLock();
        lock.setLockKey(lockKey);
        lock.setHolderId(holderId);
        lock.setExpireTime(new Date(System.currentTimeMillis() + LOCK_EXPIRE));
        try {
            // 插入锁记录，唯一索引冲突则抛出异常
            lockMapper.insertLock(lock);
            // 存储holderId，用于释放锁（可存在ThreadLocal中）
            ThreadLocalUtil.set(lockKey, holderId);
            return true;
        } catch (DuplicateKeyException e) {
            // 唯一约束冲突，获取锁失败
            return false;
        }
    }

    // 释放锁
    @Transactional(rollbackFor = Exception.class)
    public boolean releaseLock(String lockKey) {
        String holderId = ThreadLocalUtil.get(lockKey);
        if (holderId == null) {
            return false;
        }
        // 删除当前holderId对应的锁记录
        int count = lockMapper.deleteLock(lockKey, holderId);
        ThreadLocalUtil.remove(lockKey);
        return count > 0;
    }

    // 定时任务：清理过期锁
    @Scheduled(fixedRate = 60000)
    public void cleanExpiredLock() {
        lockMapper.cleanExpiredLock();
    }

    // 业务方法
    public void doBusiness(String lockKey) {
        try {
            boolean locked = tryLock(lockKey);
            if (!locked) {
                throw new RuntimeException("获取分布式锁失败");
            }
            // 执行业务逻辑
            System.out.println("执行业务操作...");
        } finally {
            releaseLock(lockKey);
        }
    }
}

4. 优点

实现最简单：无需部署额外中间件（Redis、ZooKeeper），利用现有数据库即可实现，开发和运维成本极低。
通用性强：适配所有支持关系型数据库（MySQL、Oracle）的场景，无需学习新的中间件。
无依赖：不依赖任何第三方中间件，系统复杂度低，适合小型分布式项目。

5. 缺点

性能最差：数据库操作涉及磁盘IO，响应速度慢，并发量高时会出现严重阻塞，吞吐量极低。
死锁风险：若业务执行过程中数据库宕机，锁记录无法删除，需依赖定时任务清理，可能出现短暂死锁。
不支持高并发：无法应对高并发场景（如秒杀、高频下单），易造成数据库压力过大。
功能单一：不支持可重入、公平锁等高级特性，适配场景有限。

方案5：基于etcd的分布式锁

1. 核心原理

etcd是一款分布式键值存储系统（类似Redis、ZooKeeper），基于RAFT一致性算法，支持原子操作和监听机制，分布式锁的实现逻辑与ZooKeeper类似：通过创建“临时有序键”实现互斥，通过监听前一个键实现锁的唤醒，同时支持自动过期（TTL），避免死锁。

核心优势：etcd的一致性比Redis强（RAFT算法保证强一致性），性能比ZooKeeper高，适合对一致性和性能要求都较高的场景，常用于K8s集群的协调。

2. 核心流程

创建锁路径：在etcd中指定一个锁路径（如/lock/order），用于存储所有锁键。
创建临时有序键：每个请求锁的节点，在锁路径下创建一个临时有序键（如/lock/order/lock-xxx），并设置TTL（过期时间）。
判断是否获取锁：获取锁路径下所有子键，排序后判断自己的键是否为第一个；若是，获取锁成功；若不是，监听前一个键。
执行业务：获取锁成功后，执行临界业务操作，etcd自动维护TTL，业务未完成可手动续期。
释放锁：业务执行完成后，删除自己创建的临时有序键；若节点宕机，TTL过期后键自动删除，前一个节点的监听被触发，自动尝试获取锁。

3. Java实现示例（etcd-java客户端）

@Service
public class EtcdLockService {
    private final Client client;
    private static final String LOCK_PREFIX = "/lock/";
    private static final long TTL = 30; // 锁过期时间（30s）

    // 初始化etcd客户端
    public EtcdLockService() {
        this.client = Client.builder()
                .endpoints("http://127.0.0.1:2379")
                .build();
    }

    // 获取锁
    public CompletableFuture<Lock> tryLock(String lockKey) {
        String lockPath = LOCK_PREFIX + lockKey;
        // 创建临时有序键，设置TTL
        return client.getLockClient()
                .lock(lockPath, TTL)
                .thenApply(lock -> {
                    System.out.println("获取锁成功，锁路径：" + lockPath);
                    return lock;
                })
                .exceptionally(ex -> {
                    System.err.println("获取锁失败：" + ex.getMessage());
                    return null;
                });
    }

    // 释放锁
    public CompletableFuture<Void> releaseLock(Lock lock) {
        return client.getLockClient()
                .unlock(lock)
                .thenRun(() -> System.out.println("释放锁成功"))
                .exceptionally(ex -> {
                    System.err.println("释放锁失败：" + ex.getMessage());
                    return null;
                });
    }

    // 业务方法（异步获取锁）
    public void doBusiness(String lockKey) {
        tryLock(lockKey).thenAccept(lock -> {
            if (lock == null) {
                throw new RuntimeException("获取锁失败");
            }
            try {
                // 执行业务逻辑
                System.out.println("执行业务操作...");
            } finally {
                // 释放锁
                releaseLock(lock);
            }
        });
    }
}

4. 优点

一致性强：基于RAFT算法，保证分布式环境下的强一致性，适合对数据一致性要求高的场景。
性能优秀：响应速度介于Redis和ZooKeeper之间，支持高并发，吞吐量高于ZooKeeper。
无死锁风险：临时键+TTL机制，节点宕机后锁自动释放，无需手动清理。
支持高级特性：支持可重入、公平锁、读写锁，适配复杂业务场景，同时支持集群部署，高可用。

5. 缺点

生态不完善：Java生态中etcd的客户端（如etcd-java）不如Redis、ZooKeeper成熟，开发资料较少。
运维成本高：需部署etcd集群，运维复杂度高于Redis，适合有etcd部署基础的团队（如K8s集群用户）。
开发成本中等：需熟悉etcd的API和锁机制，比Redisson、数据库锁复杂。

二、5种分布式锁方案多维度对比（选型核心参考）

从“性能、一致性、易用性、功能、运维成本、适用场景”6个核心维度，对5种方案进行对比，明确选型优先级，贴合Java分布式开发实战：

对比维度	Redis原生锁	Redisson锁	ZooKeeper锁	数据库锁	etcd锁
性能	极高（毫秒级）	极高（毫秒级）	中等（十毫秒级）	极低（百毫秒级）	中高（毫秒级）
一致性	最终一致性	最终一致性	强一致性	强一致性（数据库层面）	强一致性（RAFT）
易用性	中等（需手动处理续期、可重入）	极高（封装完善，API简洁）	中等（需依赖Curator）	极高（原生数据库操作）	中等（客户端生态不完善）
功能	基础（仅互斥）	强大（可重入、公平锁、读写锁等）	较强（可重入、公平锁）	简单（仅互斥）	强大（可重入、公平锁、读写锁等）
运维成本	中（Redis集群）	中（Redis集群+Redisson依赖）	高（ZooKeeper集群）	低（现有数据库）	高（etcd集群）
生产推荐度	★★★☆☆（不推荐直接使用，需优化）	★★★★★（首选，适配大多数场景）	★★★☆☆（公平性要求高的场景）	★★☆☆☆（小型项目、低并发场景）	★★★★☆（K8s环境、强一致性场景）

三、分布式锁使用场景及选型指南（落地建议）

选型核心原则：优先根据“并发量”和“一致性要求”选型，其次考虑开发和运维成本，结合Java分布式架构（微服务、集群）的实际场景，给出以下落地建议：

1. 高并发场景（如秒杀、高频下单、库存扣减）

需求：并发量高（万级/十万级QPS），响应速度快，允许最终一致性，功能完善（可重入、锁续期）。

选型：Redisson分布式锁（首选），底层基于Redis，性能极高，封装完善，支持可重入、锁续期、公平锁等，开发成本低，适配大多数高并发场景。

补充：若已部署Redis集群，无需额外增加中间件，直接引入Redisson依赖即可快速落地。

2. 公平性要求高的场景（如任务调度、队列执行）

需求：严格按请求顺序获取锁，避免饥饿现象，一致性要求高，并发量中等。

选型：ZooKeeper分布式锁（基于Curator框架），有序节点保证公平性，临时节点避免死锁，适合任务调度、分布式队列等场景。

3. 强一致性要求高的场景（如金融支付、账务结算）

需求：数据强一致，不允许出现并发安全问题，集群稳定性要求高，并发量中等。

选型：etcd分布式锁（首选），RAFT算法保证强一致性，性能优于ZooKeeper；若已部署ZooKeeper集群，也可选择ZooKeeper锁。

4. 小型分布式项目、低并发场景（如后台管理系统、低频操作）

需求：开发和运维成本低，无需部署额外中间件，并发量低（千级QPS以下），仅需基础互斥功能。

选型：数据库分布式锁，利用现有数据库即可实现，开发简单，无需学习新中间件，适合小型项目快速落地。

5. 已有Redis集群，无需复杂功能的场景

需求：仅需基础互斥功能，并发量中等，无需可重入、公平锁，开发成本低。

选型：Redis原生分布式锁（需手动优化锁续期、幂等性），适合对开发成本敏感、功能需求简单的场景。

四、分布式锁关键注意事项（必看）

避免死锁：无论哪种方案，都必须设置过期时间（TTL），确保节点宕机后锁能自动释放；同时，释放锁必须在finally中执行，避免业务异常导致锁未释放。
防止误释放锁：必须通过“持有者标识”（如随机字符串、线程ID）判断锁的归属，避免释放他人持有的锁（如Redis的Lua脚本、数据库的holder_id）。
锁续期处理：若业务执行时间可能超过锁的过期时间，需实现锁续期机制（如Redisson的Watch Dog、手动定时刷新过期时间），避免锁提前释放。
幂等性配合：分布式锁只能保证“同一时刻只有一个节点执行”，无法避免“重复请求”（如网络重试），需配合幂等性处理（如唯一订单号、请求ID去重），确保业务最终一致性。
集群适配：分布式锁的中间件（Redis、ZooKeeper、etcd）必须集群部署，避免单点故障，确保锁服务高可用。
避免过度设计：无需追求“最强大”的方案，根据并发量和业务需求选择，如低并发场景无需部署Redis、ZooKeeper，用数据库锁即可。

五、总结

分布式锁的5种实现方案，核心取舍在于“性能、一致性、开发/运维成本”，不同方案适配不同场景，无绝对的“最优方案”，只有“最适合的方案”：

Redisson锁：首选方案，适配大多数Java分布式场景，性能高、易用性强、功能完善；
Redis原生锁：适合已有Redis集群、功能需求简单的场景，需手动优化痛点；
ZooKeeper锁：适合公平性要求高、一致性要求高的中等并发场景；
数据库锁：适合小型项目、低并发场景，开发和运维成本最低；
etcd锁：适合K8s环境、强一致性要求高的场景，性能和一致性平衡较好。

实际开发中，多数Java微服务项目优先选择Redisson锁，既能满足高并发需求，又能简化开发；小型项目可选择数据库锁快速落地；特殊场景（公平性、强一致性）可选择ZooKeeper或etcd锁。同时，需注意锁的过期、误释放、续期等问题，配合幂等性处理，确保分布式锁的安全、可靠、高效。

posted @ 2026-03-15 20:08 ConfidentLiu 阅读(1) 评论(0) 收藏举报

刷新页面返回顶部

ConfidentLiu

分布式锁

分布式锁的实现方案（详解+使用场景+方案对比）

一、5种分布式锁实现方案详解（Java实战视角）

方案1：基于Redis的分布式锁（原生API实现）

1. 核心原理

2. 核心流程

3. Java实现示例（Spring Boot + RedisTemplate）

4. 优点

5. 缺点

方案2：基于Redisson的分布式锁（Redis封装，推荐）

1. 核心原理

2. 核心流程

3. Java实现示例（Spring Boot + Redisson）

4. 优点

5. 缺点

方案3：基于ZooKeeper的分布式锁

1. 核心原理

2. 核心流程

3. Java实现示例（Curator框架，ZooKeeper客户端）

4. 优点

5. 缺点

方案4：基于数据库的分布式锁

1. 核心原理

2. 核心流程（基于唯一索引）

3. Java实现示例（Spring Boot + MyBatis）

4. 优点

5. 缺点

方案5：基于etcd的分布式锁

1. 核心原理

2. 核心流程

3. Java实现示例（etcd-java客户端）

4. 优点

5. 缺点

二、5种分布式锁方案多维度对比（选型核心参考）

三、分布式锁使用场景及选型指南（落地建议）

1. 高并发场景（如秒杀、高频下单、库存扣减）

2. 公平性要求高的场景（如任务调度、队列执行）

3. 强一致性要求高的场景（如金融支付、账务结算）

4. 小型分布式项目、低并发场景（如后台管理系统、低频操作）

5. 已有Redis集群，无需复杂功能的场景

四、分布式锁关键注意事项（必看）

五、总结

公告