在解决并发安全问题的时候，思路其实就是将并发执行控制为串行执行，这就是锁的具体表现。
在传统的单机模式下，synchronized关键字、ReentrantLock、CAS等方案的单机锁是可行的，但是分布式架构的微服务，一个服务多个节点的场景就需要Redisson等分布式锁来处理。
经典的秒杀场景下，订单服务的某个接口被大量并发请求访问，如何控制商品超卖问题？
通过Redisson锁住商品的sku或主键ID，至此同一时间只能有一个服务节点的一个线程来执行该接口的后续代码，执行完毕后释放锁，就能实现需求了。
这是Redisson分布式锁的常规用法，其底层实现是怎样的呢？
-
基于Redis命令的实现： Redisson利用了Redis的单线程特性和原子操作的特点。它通过调用Redis的SETNX（SET if Not Exists）命令来尝试获取锁，当锁不存在时，才能获取到锁。同时，Redisson还可以设置锁的自动过期时间，以防止因为某些原因导致锁一直被持有而无法释放。
-
心跳续约机制： 为了防止因为持有锁的进程意外宕机而导致锁无法释放，Redisson在获取锁之后会启动一个定时任务来周期性地续约锁的有效时间。这样即使持有锁的进程意外宕机，锁也会在一定时间后自动释放。
-
实现可重入锁： Redisson支持可重入锁，保证同一线程在持有锁的情况下能够多次获取锁，而不会因为自己已经持有锁而被阻塞。
-
分布式锁释放的安全性保证： Redisson通过Lua脚本来释放锁，保证了释放锁的原子性。使用Lua脚本可以保证释放锁的操作是原子的，避免了在执行释放锁逻辑时出现的并发问题。
假设有两个服务节点order1和order2，order1在释放锁时宕机，心跳续约机制的定时任务在order1节点上执行的话，Reddison的看门狗机制是如何避免死锁的呢？
如果一个节点持有锁的同时发生宕机，而心跳续约机制的定时任务也运行在该节点上，那么由于宕机，这个定时任务将无法继续执行，也就无法续约锁，而其他节点将无法获取到这个被持有的锁。
为了应对这种情况，Redisson通常会使用分布式锁的看门狗（Watchdog）机制。看门狗机制会在一个独立的线程中定期检查锁是否仍然有效，并尝试续约锁。当一个节点宕机时，其他节点上的看门狗会继续监视该锁，并尝试获取到锁的控制权，然后开始续约。这样可以确保即使某个持有锁的节点宕机，其他节点仍然可以通过看门狗机制获取到锁的控制权并继续续约，从而避免死锁的发生。