集成Redis分布式锁

态的对象)，如果不加任何控制的话，变量A同时都会在分配一块内存，三个请求发过来同时对这个变量操作，显然结果是不对的!即使不是同时发过来，三个请求分别操作三个不同内存区域的数据，变量A之间不存在共享，也不具有可见性，处理的结果也是不对的!

如果我们业务中确实存在这个场景的话，我们就需要一种方法解决这个问题!

为了保证一个方法或属性在高并发情况下的同一时间只能被同一个线程执行，在传统单体应用单机部署的情况下，可以使用并发处理相关的功能进行互斥控制。但是，随着业务发展的需要，原单体单机部署的系统被演化成分布式集群系统后，由于分布式系统多线程、多进程并且分布在不同机器上，这将使原单机部署情况下的并发控制锁策略失效，单纯的应用并不能提供分布式锁的能力。为了解决这个问题就需要一种跨机器的互斥机制来控制共享资源的访问，这就是分布式锁要解决的问题!

分布锁的基本原理

分布式环境下，多台机器上多个进程对同一个共享资源(数据、文件等)进行操作，如果不做互斥，就有可能出现“余额扣成负数”，或者“商品超卖”的情况。

为了解决这个问题，需要分布式锁服务。首先，来看一下分布式锁应该具备哪些条件。

• 互斥性：在任意时刻，对于同一个锁，只有一个客户端能持有，从而保证一个共享资源同一时间只能被一个客户端操作;
• 安全性：即不会形成死锁，当一个客户端在持有锁的期间崩溃而没有主动解锁的情况下，其持有的锁也能够被正确释放，并保证后续其它客户端能加锁;
• 可用性：当提供锁服务的节点发生宕机等不可恢复性故障时，“热备” 节点能够接替故障的节点继续提供服务，并保证自身持有的数据与故障节点一致。
• 对称性：对于任意一个锁，其加锁和解锁必须是同一个客户端，即客户端 A 不能把客户端 B 加的锁给解了。

目前市面上，分布式锁的实现方案大致有三种：

1. 数据库乐观锁;
2. 基于分布式缓存实现的锁服务，典型代表有 Redis 和基于 Redis 的 RedLock;
3. 基于分布式一致性算法实现的锁服务，典型代表有 ZooKeeper、Chubby 和 ETCD。

项目中，使用的最多的是后两种，其实每种方案都各有利弊。

预防死锁

我们看下面这个典型死锁场景。

一个客户端获取锁成功，但是在释放锁之前崩溃了，此时该客户端实际上已经失去了对公共资源的操作权，但却没有办法请求解锁(删除 Key-Value 键值对)，那么，它就会一直持有这个锁，而其它客户端永远无法获得锁。

（编辑：漯河站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!