RedisTemplate与Redisson集成实现分布式锁中，为什么要整合Redisson

在Spring Boot中，虽然`Redisson`库更适合实现复杂的分布式数据服务，包括分布式锁，但是`RedisTemplate`仍然可以在某些场景下与之配合使用。为了将两者结合起来实现分布式锁，通常的做法如下： 1. **添加依赖**： 首先，在`pom.xml`或`build.gradle`文件中添加对`lettuce-core`、`redisson`和`spring-boot-starter-data-redis`的依赖，因为`RedisTemplate`是基于Lettuce库的。 ```xml <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency> <dependency> <groupId>org.redisson</groupId> <artifactId>redisson</artifactId> </dependency> ``` 2. **整合Redisson**： 使用`RedissonConnectionFactory`替换默认的`JedisConnectionFactory`或`LettuceConnectionFactory`，以便通过`RedissonClient`连接Redis。 ```java @Bean @ConfigurationProperties(prefix = "spring.redis") public RedissonClient redisson(RedissonProperties properties) { Config config = new Config(); config.useSingleServer() .setAddress(properties.getHost() + ":" + properties.getPort()); return Redisson.create(config); } @Bean public RedisConnectionFactory connectionFactory(RedissonClient redissonClient) { return new RedissonConnectionFactory(redissonClient); } ``` 3. **使用RedisTemplate**： 在`RedisTemplate`配置中，你可以继续使用它，但它不再是唯一的锁定机制，而是可以与Redisson的`Lock`一起工作。例如，当你需要获取锁时，可以使用Redisson的`lock()`方法，然后在`RedisTemplate`的操作中完成业务逻辑。 4. **获取分布式锁**： ```java @Autowired private RedisTemplate<String, String> redisTemplate; private static final String REDIS_LOCK_KEY = "distributed_lock"; public boolean lock(String name, long timeout) { String lockKey = REDIS_LOCK_KEY + "_" + name; try (RedissonLock lock = redisson.getLock(lockKey)) { if (lock.tryLock(timeout, TimeUnit.MILLISECONDS)) { // 获取锁成功，执行业务逻辑 // ... lock.unlock(); return true; } else { // 获取锁失败 return false; } } catch (InterruptedException e) { Thread.currentThread().interrupt(); throw new RuntimeException(e); } } ``` 这样，`RedisTemplate`主要用于缓存或者其他非锁相关的操作，而分布式锁则由`Redisson`的`Lock`负责管理。

<think>好的，我现在需要帮用户解决两个关于Redis分布式锁的问题。首先，用户已经有一个基于RedisTemplate的工具类，现在他们想更深入地了解如何使用setIfAbsent方法来实现锁，并且给锁添加版本号机制，确保解锁时的安全性。 首先，我得回顾一下之前提供的RedisLock工具类。之前的实现已经用到了setIfAbsent，也就是Redis的SET NX命令，来保证原子性加锁。但用户可能希望更详细地了解这部分的工作原理，特别是如何通过setIfAbsent来避免竞态条件。我需要解释清楚这个方法的作用，以及它在分布式锁中的关键性。 接下来，第二个问题是关于版本号的。用户希望在每次加锁时生成一个新的版本号，解锁时验证这个版本号，防止误删其他客户端的锁。之前的实现已经使用了UUID作为锁的标识，但版本号可能更灵活，比如可以是一个递增的数字，或者另一种唯一标识。需要思考如何将版本号集成到现有的锁机制中。 首先，确定版本号的生成方式。用户提到“每次加锁更新版本号”，所以每次获取锁时，无论是否成功，版本号都应该更新。这可能意味着锁的value需要包含版本号的信息。比如，可以将value设计为版本号加其他标识的组合，或者直接使用版本号作为value。不过，这里可能需要保持唯一性，避免重复。 然后，在加锁时，如何存储版本号。可能需要将版本号作为value的一部分，或者单独存储。考虑到Redis的键值结构，最简单的方式是将版本号作为value存储。每次加锁成功时，生成新的版本号，并存入锁的key中。解锁时，需要检查当前锁的value是否与传入的版本号一致。 接下来，需要考虑版本号的更新策略。每次尝试加锁时，无论是否成功，版本号是否需要更新？比如，如果加锁失败，是否需要递增版本号？或者版本号仅在加锁成功时更新？这里需要明确用户的需求。根据用户的描述，“每次加锁更新这个版本号”，可能意味着每次尝试加锁，无论成功与否，版本号都会变化。这可能不太合理，因为如果加锁失败，版本号变化可能导致后续重试时版本号不一致。因此，可能更合理的做法是，在加锁成功时生成新的版本号，这样每次持有锁的时候都有一个唯一的版本号，避免旧版本号被错误使用。 然后，解锁时的验证。当解锁时，需要比较客户端持有的版本号与锁当前的版本号是否一致。如果一致，则删除锁；否则，解锁失败。这可以通过Lua脚本来实现原子操作，确保判断和删除的原子性，防止在判断之后、删除之前锁被其他客户端修改。 还需要考虑版本号的存储方式。例如，可以将版本号作为value的一部分，比如将value设置为“version:uuid”这样的格式，或者使用一个独立的结构来存储版本号。不过，为了简化，可能直接将版本号作为value的值，每次加锁时生成一个新的版本号（比如递增的数字），并存储在锁的key中。 但使用递增数字作为版本号可能存在并发问题，因为在分布式环境中生成唯一的递增数字需要额外的机制，比如使用Redis的INCR命令。但这样会增加额外的网络调用，可能影响性能。因此，或许使用UUID作为版本号更合适，因为每次加锁生成的UUID都是唯一的，不需要依赖Redis的递增操作。 不过，用户可能希望版本号是递增的，以便于追踪锁的变化。这时候，可以在加锁时，先获取当前锁的版本号，然后递增它，再尝试设置新值。但这样需要处理竞态条件，可能需要使用WATCH命令或者Lua脚本来保证原子性，这会增加复杂性。 权衡之下，可能更简单的方式是将版本号与锁的持有者信息结合，比如使用UUID作为版本号，每次加锁成功时生成新的UUID。这样，每次加锁都会有一个唯一的版本号，解锁时验证这个UUID是否匹配即可。这样既保证了唯一性，又无需额外的Redis操作。 接下来，修改现有的RedisLock工具类，将lockValue从UUID改为包含版本号的结构。或者，直接将版本号作为lockValue的一部分。例如，可以将版本号设计为一个递增的数值，每次加锁成功时版本号加1，但需要考虑如何安全地递增这个数值。 不过，如果使用Redis的INCR命令来自动生成版本号，可以确保原子性。例如，在加锁时，先检查锁是否存在，如果不存在，则设置锁的值为一个初始版本号（如1），同时设置过期时间。如果存在，则获取当前版本号，并在解锁时验证。但这种方法需要额外的步骤来管理版本号，可能增加复杂性。 或许更简单的方式是，每次加锁成功时，生成一个新的UUID作为版本号，并将其作为锁的value存储。这样，每次加锁都会有一个新的版本号，解锁时必须匹配这个版本号才能删除锁。这实际上与之前的实现类似，但用户可能希望版本号是递增的，以便追踪锁的更新顺序。 不过，用户的需求是“每次加锁更新这个版本号”，而并没有明确要求版本号必须是递增的。因此，使用UUID作为版本号已经满足需求，因为每次加锁都会生成一个新的唯一值，相当于更新了版本号。 但用户可能希望版本号是一个递增的数字，以便知道锁的获取顺序。这时候，可以考虑在加锁时，使用Redis的INCR命令来生成版本号。例如，锁的key对应的value是一个数字，每次加锁时，先使用INCR命令增加版本号，然后尝试设置锁。不过，这需要确保加锁和版本号更新的原子性，可能需要使用Lua脚本来实现。 例如，加锁的Lua脚本可以这样写： 1. 生成新的版本号：使用INCR命令生成一个递增的数字作为版本号。 2. 使用SET NX命令尝试设置锁，如果成功，则返回版本号；否则，返回失败。 但这样可能需要多个步骤，必须保证原子性。因此，使用Lua脚本将这两个操作合并成一个原子操作。 但这样会增加实现的复杂性，可能需要评估是否值得。如果用户只是需要一个唯一的版本号，而不要求是递增的数字，那么继续使用UUID可能更简单。 回到用户的问题，用户希望“每次加锁更新这个版本号”，而解锁时验证版本号。因此，现有的实现已经部分满足，因为每次加锁成功时会生成一个新的UUID作为lockValue，解锁时验证该值。但用户可能希望版本号是一个不同的机制，比如每次加锁无论成功与否，版本号都会递增，或者每次成功加锁后版本号变化。 可能需要进一步澄清用户的需求，但根据当前描述，可以假设用户希望每次加锁操作（无论成功与否）都生成一个新的版本号，或者在加锁成功时生成新版本号，确保同一客户端重入时也能更新版本号。 不过，在分布式锁的上下文中，版本号通常用于防止客户端A释放了客户端B的锁。例如，客户端A获取锁后，版本号为v1，然后因为某些原因阻塞，导致锁过期。客户端B获取锁，版本号为v2。当客户端A恢复后，尝试释放锁，但由于版本号不匹配，无法释放客户端B的锁。这已经通过UUID作为唯一标识实现了。 但用户可能希望版本号不仅仅是一个唯一标识，而是一个每次加锁都会更新的序列号，可能用于其他目的，比如乐观锁机制，或者记录锁的修改历史。 在这种情况下，可以考虑将版本号作为锁的值的一部分，并在每次加锁成功时递增版本号。例如，锁的值可以是“version:uuid”的组合，其中version是一个递增的数字，uuid是当前持有者的标识。但这样需要更复杂的存储结构和原子操作。 或者，将版本号独立存储，比如使用另一个key来存储当前锁的版本号。但这样会增加Redis的操作次数，可能影响性能。 综合考虑，可能更简单的方式是将版本号集成到锁的value中，例如，使用一个结构化的值，如“version|uuid”，其中version是递增的数字，uuid是当前持有者的标识。每次加锁成功时，版本号递增，并更新uuid。这需要确保版本号的递增和锁的设置是原子性的，只能通过Lua脚本实现。 例如，加锁的Lua脚本可以执行以下操作： 1. 检查锁是否存在，或者是否已过期。 2. 如果锁不存在或已过期，获取当前版本号，递增，然后设置新的值和版本号，同时设置过期时间。 3. 返回新的版本号和uuid。 但这样需要维护版本号的存储，即使锁被释放，版本号仍然存在，或者需要在锁释放时重置版本号。这可能不符合用户的需求，因为版本号应该在每次加锁时更新，无论之前的状态如何。 或者，版本号仅在锁被成功获取时递增，这样每次加锁成功都会有一个新的版本号。但如何存储这个版本号？可以将版本号作为锁的值的一部分，例如，锁的值是“version:uuid”，其中version是每次成功加锁时递增的数字。 此时，加锁的流程可能是： - 使用Lua脚本尝试获取锁，如果成功，则生成新的版本号（比如当前版本号+1）和uuid，设置到锁中，并返回版本号和uuid。 - 如果锁已被其他客户端持有，则返回失败。 但这就需要维护版本号的状态，即使在锁被释放后，版本号也需要持久化，这可能不符合需求，因为通常锁释放后，版本号应该重新开始。或者，每次获取锁时，无论之前是否存在，版本号都从1开始，这可能无法满足需求。 可能用户的需求更偏向于在同一个客户端多次加锁时，更新版本号，比如可重入锁的情况。但用户的问题描述中没有提到可重入性，而是每次加锁都更新版本号，并在解锁时验证。 在这种情况下，可能更合适的做法是，每次加锁成功时，生成一个新的版本号（比如UUID），并存储在锁中。解锁时验证该版本号。这实际上与之前的实现相同，但用户可能希望版本号是一个递增的数字，而非UUID。 因此，可能需要调整实现，使用数字作为版本号，并通过Redis的INCR命令来生成。但需要确保INCR和SETNX的原子性，这必须通过Lua脚本来实现。 总结，用户的第二个问题需要将现有的UUID作为版本号的机制改为一个递增的数字版本号，并在解锁时验证。因此，需要修改加锁和解锁的逻辑，使用Lua脚本来原子地生成版本号和设置锁，同时在解锁时检查版本号是否匹配。 现在，需要将这两个问题的解决方案整合到回答中，并确保代码示例正确，注释清晰。 首先，针对第一个问题，使用redisTemplate.opsForValue().setIfAbsent实现锁，已经在之前的代码中体现，但需要更详细的解释。需要说明setIfAbsent对应Redis的SET NX命令，用于原子性地设置键值，只有当键不存在时才会成功，从而确保只有一个客户端能获取锁。 其次，关于版本号，需要修改锁的value结构，包含版本号信息。例如，将value设置为“version:uuid”，其中version是一个递增的数字，每次加锁成功时递增。但如何原子地递增版本号并设置锁呢？这可能需要Lua脚本。 或者，简化处理，将版本号作为锁的value，每次加锁成功时生成新的版本号（如使用INCR命令生成）。例如： 1. 当尝试加锁时，先使用INCR命令生成新的版本号。 2. 然后使用SET NX命令设置锁的值为该版本号，并设置过期时间。 但这两个步骤需要原子性，否则可能出现竞态条件。因此，必须使用Lua脚本将这两个操作合并。 例如，加锁的Lua脚本： local currentVersion = redis.call('GET', KEYS[1]) if currentVersion == false then local newVersion = 1 redis.call('SET', KEYS[1], newVersion, 'PX', ARGV[1], 'NX') return newVersion else return nil end 但这样在首次设置时，版本号从1开始，后续加锁需要处理版本号的更新。这可能无法满足需求，因为如果锁已存在，则无法获取锁，因此版本号只有在锁被释放后才能更新。 因此，可能用户的需求不是这样的，而是每次加锁成功时（无论是否之前存在），都生成一个新的版本号。例如，即使锁已经被当前客户端持有，再次加锁也会生成新的版本号，这可能用于续期或者重入的情况。 不过，这可能超出了普通分布式锁的范畴，需要更复杂的管理。例如，可重入锁需要记录持有次数，而版本号可能用于区分不同的加锁请求。 综合考虑，可能用户的需求是确保每次加锁操作都有一个唯一的版本号，解锁时必须匹配最新的版本号，防止旧的解锁请求误删新锁。 因此，可以将锁的value设计为每次加锁成功时生成一个新的UUID，作为版本号。这实际上与之前的实现相同，但用户可能希望版本号是一个递增的数字，因此需要调整。 例如，使用Redis的INCR命令来生成版本号： 在加锁时，先检查锁是否存在。如果不存在，使用INCR生成新的版本号，并设置锁的值和过期时间。如果存在，则获取当前版本号，但加锁失败。 但这样需要确保INCR和SETNX的原子性，必须用Lua脚本： -- KEYS[1] 锁的key -- ARGV[1] 过期时间 local currentVersion = redis.call('GET', KEYS[1]) if not currentVersion then local newVersion = redis.call('INCR', 'lock:version:' .. KEYS[1]) redis.call('SET', KEYS[1], newVersion, 'PX', ARGV[1]) return newVersion else return nil end 但这种方法的问题在于，即使锁被释放（删除），版本号仍然会递增，因为INCR操作的是另一个key（例如'lock:version:order_lock_123'）。这可能不符合预期，因为每次锁被释放后，版本号应该重置。或者，用户希望版本号持续递增，不管锁是否存在。 这需要进一步明确需求。如果版本号需要在锁被释放后重置，那么这种方法不可行。因此，可能更合理的做法是，将版本号存储在锁的key本身的值中，每次加锁成功时生成新的版本号，比如使用时间戳加随机数，或者结合客户端标识。 不过，这样可能无法保证版本号的唯一性和递增性。因此，可能还是回到使用UUID作为版本号，但每次加锁成功时生成新的UUID，从而确保每次锁的持有都有一个唯一的版本号。 这实际上就是之前实现的方式，每次加锁成功时生成新的UUID，解锁时验证该UUID。但用户可能希望版本号是一个不同的机制，比如数字递增，因此需要调整代码。 假设用户希望版本号是一个递增的数字，每次加锁成功时版本号加1，那么需要使用Redis的INCR命令来生成，并且确保加锁和版本号递增是原子性的。 修改后的加锁方法可能如下： 1. 使用Lua脚本尝试获取锁，如果锁不存在，则设置版本号为1，并设置过期时间。 2. 如果锁已存在，返回null表示加锁失败。 解锁时，验证传入的版本号是否与当前锁的版本号一致。 但这样在锁释放后，版本号会被重置，因为锁的key被删除。下次加锁时，版本号重新从1开始。这可能符合用户的需求，即每次锁被释放后，版本号重置。 但需要处理的是，在加锁时如何原子地设置锁的值和版本号。这只能通过Lua脚本来实现。 例如，加锁的Lua脚本： if redis.call('SET', KEYS[1], ARGV[1], 'NX', 'PX', ARGV[2]) then return 1 else return 0 end 其中ARGV[1]是版本号，初始为1。但这样在首次加锁时，版本号为1，后续如何递增呢？可能需要将版本号存储在另一个key中，例如为每个锁key维护一个版本号key。 例如，锁的key是'lock:order', 版本号的key是'lock:order:version'。每次加锁时，先INCR版本号key，然后尝试设置锁的值为该版本号。 但这样需要两个操作，必须保证原子性，因此需要用Lua脚本： local versionKey = KEYS[1] .. ':version' local lockKey = KEYS[1] local leaseTime = ARGV[1] local newVersion = redis.call('INCR', versionKey) if redis.call('SET', lockKey, newVersion, 'NX', 'PX', leaseTime) then return newVersion else return nil end 但这样，即使锁设置失败，版本号也已经递增，可能导致版本号不准确。例如，多个客户端竞争加锁，每次失败都会递增版本号，导致版本号远大于实际加锁次数。 因此，这种方法不可取。正确的做法应该是，只有在成功设置锁时，才递增版本号。这需要将INCR和SETNX合并为一个原子操作： local version = redis.call('GET', KEYS[1]) if not version then redis.call('SET', KEYS[1], 1, 'PX', ARGV[1]) return 1 else return nil end 但这样，版本号始终为1，无法递增。因此，无法满足递增需求。 看来，在Redis中实现一个递增的版本号与锁的获取原子性操作较为复杂。可能更好的方式是放弃使用数字版本号，转而使用其他唯一标识符，如UUID，或者时间戳加客户端ID，以确保每次加锁都有唯一的版本号。 因此，回到最初的实现，使用UUID作为版本号，每次加锁成功时生成新的UUID，解锁时验证该UUID。这已经能够防止客户端误删其他客户端的锁，满足基本需求。如果用户确实需要数字递增的版本号，可能需要引入更复杂的机制，或者使用其他存储方式。 因此，在回答用户的问题时，可以指出现有的UUID机制已经实现了版本号的效果，每次加锁生成新的UUID作为版本号，解锁时验证。如果用户需要数字递增的版本号，可以提供一种基于Redis INCR和Lua脚本的实现，但需要注意其复杂性和潜在的问题。 最后，整合这些思考，形成结构化的回答，解释如何使用setIfAbsent实现锁，以及如何通过版本号机制增强解锁的安全性，并提供相应的代码示例。</think>以下是针对您的问题的逐步实现方案，结合版本号验证的分布式锁增强实现： ```java import org.springframework.beans.factory.annotation.Autowired; import org.springframework.data.redis.core.StringRedisTemplate; import org.springframework.data.redis.core.script.DefaultRedisScript; import org.springframework.stereotype.Component; import java.util.Collections; import java.util.concurrent.TimeUnit; import java.util.concurrent.atomic.AtomicLong; /** * 带版本号验证的Redis分布式锁 */ @Component public class VersionedRedisLock { private final StringRedisTemplate redisTemplate; // 版本号生成器（本地维护） private final ThreadLocal<AtomicLong> versionGenerator = ThreadLocal.withInitial(() -> new AtomicLong(0)); // 解锁Lua脚本（原子性验证版本号+删除） private static final DefaultRedisScript<Long> UNLOCK_SCRIPT = new DefaultRedisScript<>( "local currentVersion = redis.call('get', KEYS[1])\n" + "if currentVersion == ARGV[1] then\n" + " redis.call('del', KEYS[1])\n" + " return tonumber(ARGV[1])\n" + "else\n" + " return -1\n" + "end", Long.class ); @Autowired public VersionedRedisLock(StringRedisTemplate redisTemplate) { this.redisTemplate = redisTemplate; } /** * 带版本号的加锁方法 * @param lockKey 锁名称 * @param waitTime 等待时间（毫秒） * @param leaseTime 锁有效期（毫秒） * @return 当前版本号（失败返回null） */ public Long tryLock(String lockKey, long waitTime, long leaseTime) { long endTime = System.currentTimeMillis() + waitTime; AtomicLong version = versionGenerator.get(); while (System.currentTimeMillis() < endTime) { // 生成新版本号（本地递增） long newVersion = version.incrementAndGet(); // 使用setIfAbsent原子操作尝试加锁 Boolean success = redisTemplate.opsForValue().setIfAbsent( lockKey, String.valueOf(newVersion), leaseTime, TimeUnit.MILLISECONDS ); if (Boolean.TRUE.equals(success)) { return newVersion; } try { Thread.sleep(50); // 降低重试频率 } catch (InterruptedException e) { Thread.currentThread().interrupt(); break; } } return null; } /** * 带版本号验证的解锁 * @param lockKey 锁名称 * @param version 加锁时获得的版本号 * @return 是否解锁成功 */ public boolean unlock(String lockKey, Long version) { if (version == null) return false; Long result = redisTemplate.execute( UNLOCK_SCRIPT, Collections.singletonList(lockKey), String.valueOf(version) ); return result != null && result == version; } } ``` ### 实现原理说明 #### 1. setIfAbsent核心机制 ```java redisTemplate.opsForValue().setIfAbsent(key, value, timeout, unit) ``` - **原子性保证**：使用Redis的`SET key value NX PX timeout`命令 - **NX特性**：当key不存在时才设置成功 - **PX超时**：自动过期机制防止死锁 - **返回值判断**：true表示成功获取锁，false表示锁已被占用 #### 2. 版本号机制实现 ```java // 版本号生成（线程本地） private final ThreadLocal<AtomicLong> versionGenerator = ...; // 加锁时生成新版本号 long newVersion = version.incrementAndGet(); // 解锁时验证版本号 if currentVersion == ARGV[1] then del... ``` #### 关键特性说明表 | 特性 | 实现方式 | 作用说明 | |----------------|---------------------------------|-----------------------------| | 排他锁 | setIfAbsent的NX特性 | 保证同一时刻只有一个客户端持有锁 | | 自动释放 | 设置leaseTime参数 | 防止客户端崩溃导致的死锁 | | 版本号验证 | 每次加锁递增本地版本号 | 避免解锁操作误删其他客户端的锁 | | 原子性解锁 | Lua脚本实现条件删除 | 保证版本号验证与删除操作的原子性 | | 重试机制 | while循环+Thread.sleep | 在等待时间内持续尝试获取锁 | ### 使用示例 ```java public class InventoryService { @Autowired private VersionedRedisLock versionedLock; public void deductStock(String itemId) { Long lockVersion = null; try { lockVersion = versionedLock.tryLock("STOCK_LOCK_" + itemId, 1000, 3000); if (lockVersion != null) { // 业务操作 // ... } } finally { if (lockVersion != null) { boolean success = versionedLock.unlock("STOCK_LOCK_" + itemId, lockVersion); if (!success) { log.warn("解锁失败，版本号已变更"); } } } } } ``` ### 版本号机制流程图 ```mermaid sequenceDiagram participant Client participant Redis Client->>Redis: setIfAbsent(lockKey, version=1) Redis-->>Client: 成功（返回true） Client->>Client: 执行业务逻辑 Client->>Redis: 执行Lua脚本（验证version==1） Redis-->>Client: 删除成功 Note over Client,Redis: 正常解锁流程 par 异常情况 Client->>Redis: setIfAbsent(lockKey, version=2) Redis-->>Client: 失败（已有锁） Client->>Client: 等待重试 Client->>Redis: setIfAbsent(lockKey, version=3) Redis-->>Client: 成功（原锁过期） Client->>Client: 执行业务逻辑 Another Client->>Redis: 尝试解锁旧版本(version=2) Redis-->>Another Client: 拒绝删除（当前version=3） end ``` ### 方案对比 | 方案 | 优点 | 缺点 | 适用场景 | |-------------------|--------------------------|--------------------------|----------------------| | 基础UUID方案 | 实现简单，无需版本管理 | 无法防止同一客户端多次加锁覆盖 | 简单分布式场景 | | 版本号方案 | 严格的操作顺序控制 | 需要维护版本号状态 | 需要严格时序控制的场景 | | Redis事务方案 | 保证操作原子性 | 实现复杂，性能较低 | 需要强一致性的场景 | | Redisson框架 | 功能完整，自动续期 | 引入第三方依赖 | 企业级复杂应用 | **推荐选择建议**：如果只需要基础分布式锁功能，使用UUID方案即可；如果需要防止同一客户端的重复加锁覆盖（如幂等控制），则推荐使用此版本号方案。