Redis分布式锁的原理是什么？如何续期？

在传统单体应用单机部署的情况下，并发问题可以通过使用Java并发相关的锁如synchronized，但是当规模上升到分布式集群的情况下，要控制共享资源访问，就需要通过分布式锁来实现。常见的分布式锁方案如数据库乐观锁，Redis锁，zk锁等。

Redis分布式锁可以有多种方式实现但是其核心就是通过以下三个Redis命令组合实现。

上面为Redis的一个最简单的锁实现原理，实际中还需要考虑更多具体的情况作出相应的调整。如

实际开发环境中不确定的因素有很多，需要慢慢地去调整实践达到理想状态，可以考虑使用redisson框架来实现。

这个情况比较独特，出现这个问题的根本原因在于锁失效的时间小于业务处理的时间导致业务还没处理完毕锁就释放了。那么解决方案是合理地结合业务去设置锁失效的时间。

但是也有更好的方案就如前文提到的redisson，其中的可重入锁概念。

默认情况下,加锁的时间是30秒.如果加锁的业务没有执行完,那么到 30-10 = 20秒的时候,就会进行一次续期,把锁重置成30秒。

分布式锁的需求产生

分布式锁的需求是伴随着应用分布式部署而来的，在单体应用，且只部署一台服务器的情况下，通过java的同步锁即可实现。同步锁，即是一个原子性的操作。

那么当应用进行了分布式部署，应用有多个服务，这个时候应用服务端就没有一个可提供原子性操作的地方了，Redis性能高，且是单线程，因此可提供一个原子性操作的地方，利用它，就可以实现分布式锁。

用场景说话，使用Redis分布式锁的场景如下图所示：

如下图所示，随后会根据场景说明分布式锁及续期相关问题的来龙去脉。

1. 图中序号1：进来一个请求，这个请求要求我们保存一个“订单A”；
2. 图中序号2：2.1 步，请求进来，首先去尝试设置一个Redis 值，他的键就是订单号“订单A”，如果尝试成功，则代表我这个线程是第一次设置，相当于我拿到了这个锁；如果尝试失败，那么，可以抛出异常或者等待一段时候后再次重试，这里可以根据业务场景的不同采取不同的策略。这里的关键是在Redis中的操作是单线程的，因此该操作是原子性的。2.2步，为了防止应用服务意外中断，Redis中的数据一直存活，消耗资源，需要设置一个超时时间。（如果为了严谨，可以将2.1, 2.2 两步封装成一个lua脚本部署在Redis服务器上）
3. 图中序号3：情况A，这个时候是当Redis的key还未失效，程序就已经执行完成，且删除了Redis中的数据，一切正常；情况B：就是需要续期的场景，如果要避免这个场景的出现，可以将Redis key的失效时间设置长一点，可以应对大多数业务。如果要彻底解决，可以在应用端添加一个Redis锁的注册中心，然后起一个监听线程去监听这个注册中心，发现有锁还在被持有，但是Redis 已经快过期了，则修改相应key的失效时间，进行续期。

到此，以上就是小编对于redis如何设置不过期时间和日期的问题就介绍到这了，希望这1点解答对大家有用。

网站栏目：redis如何设置不过期时间
网页路径：http://www.jxjierui.cn/article/cdsshch.html