redistemplate使用_集群环境中使用Redis实现分布式锁两种方式

一、介绍

互联网的应用场景中，为了支持高并发的请求，服务都是执行的分布式部署，相同的任务可以在集群中不同的服务器上执行，并且现在的服务容器都是支持多线程，相同的任务也可能会被同一个容器多次执行，都要求执行结果都满足幂等性的设计原则。

分布式锁，就是为了确保在分布式的环境下，相同任务只会执行成功的执行一次，后续的执行不会对这些已经产生了变化的业务再次产生影响。

分布式锁的实现有不少的方式，如：

1. 使用RDBMS数据库本身的表锁或行锁特性；
2. 使用Redis做为分布式锁；
3. 使用Zookeeper做为分布式锁；

使用RDBMS数据库做为锁不是笔者要讨论的范畴，因为其本身的特性，不太符合在高并发下锁的应用场景，这里以Redis作为分布式锁做为介绍。

二、Redis

Redis本身有一些命令组支持原子性的操作，如getset、setns，这些命令可以用于分布式锁的场景中。

1、使用getset作为分布式锁控制实现

getSet本身是支持原子性的，在写入新值的同时会返回旧的值，用这个写入新值并获取旧值做为分布式锁的控制实现，如果返回的值不为空，那就说明前面已经有其它线程(这里的其它线程可以指当前容器中当前服务的其它线程，也指由部署在其它服务器上的应用中的线程)修改了该值，则可以认为已经有线程在对该请求正在处理，因而可以放弃后面的处理逻辑。

可以将当前系统的时间作为分布式锁key的值，后续其它线程的请求时，将其请求的时间与获取到的锁对应的key的旧值进行比较，比较是否已经超过了一定的时间控制阀值，如果超过了则可以认为(这里存在误判的可能性，因为后续逻辑的数据处理，恰好超过了这个时间比较阀值，就会导致重复执行，因而这里时间控制阀值要设置的比较合理，另外也需要合适的熔断机制用于保证)前面的交易处理失败(如服务恰好在设置了用于分布式锁的key后，立即就挂了，没有执行到后面的删除操作)导致用于分布式锁的key没有被删除掉，可以继续处理该请求的后续交易逻辑。

这个是非常轻量级的事务控制，不会对Redis产生外部事务(应用与Redis之间的交互事务)，只是需要对Redis多进一次getset操作，流程图如下：

​

其中蓝色部分表示获取锁的逻辑。

Java代码实现如下：

@Resourceprivate RedisTemplate redisTemplate;// 超时时间，以毫秒为单位private final long timeout = 2000;@Testpublic void testLock() { // 用于判断交易唯一性和合法性的Token，在交易执行之前先保存在服务端， // 并且下发给客户端，客户端会在执行交易之前把Token带上，没带Token的 // 请求、Token不存在的服务端的请求、Token不正确的请求都视为非法请求 String token = "..."; String key = MD5Util.md5Of32(token); String lockKey = new StringBuilder(key).append("_lock").toString(); boolean isGetKey = getLock(lockKey); if (!isGetKey) { log.warn("当前交易正在被处理中"); } boolean handleSuccess = false; try { log.info("处理交易开始"); String storedToken = redisTemplate.opsForValue().get(key); // 判断Token是否存在且合法 if (!token.equals(storedToken)) { log.warn("指定的Token不存在."); return; } handleSuccess = true; log.info("处理交易结束"); } catch (Exception e) { log.info("处理发生异常