Skip to content

Commit b68f9ed

Browse files
yanglbmeyanglbme
committed
docs(distributed-lock): add distributed-lock-redis-vs-zookeeper.md
Redis 和 Zookeeper 两种分布式锁的实现方式与优劣比较
1 parent 7a7ca66 commit b68f9ed

File tree

4 files changed

+344
-3
lines changed

4 files changed

+344
-3
lines changed

‎README.md

+1-3
Original file line numberDiff line numberDiff line change
@@ -24,9 +24,7 @@
2424

2525
### 分布式锁
2626
- [Zookeeper 都有哪些应用场景？](/docs/distributed-system/zookeeper-application-scenarios.md)
27-
- 使用 Redis 如何设计分布式锁？
28-
- 使用 zk 来设计分布式锁可以吗？
29-
- 以上两种分布式锁的实现方式哪种效率比较高？
27+
- [使用 Redis 如何设计分布式锁？使用 Zookeeper 来设计分布式锁可以吗？以上两种分布式锁的实现方式哪种效率比较高？](/docs/distributed-system/distributed-lock-redis-vs-zookeeper.md)
3028

3129
### 分布式事务
3230
- 分布式事务了解吗？

‎docs/distributed-system/Solution.java

Whitespace-only changes.

‎docs/distributed-system/distributed-lock-redis-vs-zookeeper.md

+343
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,343 @@
1+
## 面试题
2+
一般实现分布式锁都有哪些方式？使用 redis 如何设计分布式锁？使用 zk 来设计分布式锁可以吗？这两种分布式锁的实现方式哪种效率比较高？
3+
4+
## 面试官心理分析
5+
其实一般问问题，都是这么问的，先问问你 zk，然后其实是要过度到 zk 关联的一些问题里去，比如分布式锁。因为在分布式系统开发中，分布式锁的使用场景还是很常见的。
6+
7+
## 面试题剖析
8+
### redis 分布式锁
9+
10+
官方叫做 `RedLock` 算法，是 redis 官方支持的分布式锁算法。
11+
12+
这个分布式锁有 3 个重要的考量点：
13+
14+
- 互斥（只能有一个客户端获取锁）
15+
- 不能死锁
16+
- 容错（只要大部分 redis 节点创建了这把锁就可以）
17+
18+
#### redis 最普通的分布式锁
19+
20+
第一个最普通的实现方式，就是在 redis 里创建一个 key，这样就算加锁。
21+
22+
```r
23+
SET my:lock 随机值 NX PX 30000
24+
```
25+
26+
执行这个命令就 ok。
27+
28+
- `NX`：表示只有 `key` 不存在的时候才会设置成功。（如果此时 redis 中存在这个 key，那么设置失败，返回 `nil`）
29+
- `PX 30000`：意思是 30s 后锁自动释放。别人创建的时候如果发现已经有了就不能加锁了。
30+
31+
释放锁就是删除 key ，但是一般可以用 `lua` 脚本删除，判断 value 一样才删除：
32+
33+
```lua
34+
-- 删除锁的时候，找到 key 对应的 value，跟自己传过去的 value 做比较，如果是一样的才删除。
35+
if redis.call("get",KEYS[1]) == ARGV[1] then
36+
return redis.call("del",KEYS[1])
37+
else
38+
return 0
39+
end
40+
```
41+
42+
为啥要用随机值呢？因为如果某个客户端获取到了锁，但是阻塞了很长时间才执行完，比如说超过了 30s，此时可能已经自动释放锁了，此时可能别的客户端已经获取到了这个锁，要是你这个时候直接删除 key 的话会有问题，所以得用随机值加上面的 `lua` 脚本来释放锁。
43+
44+
但是这样是肯定不行的。因为如果是普通的 redis 单实例，那就是单点故障。或者是 redis 普通主从，那 redis 主从异步复制，如果主节点挂了（key 就没有了），key 还没同步到从节点，此时从节点切换为主节点，别人就可以 set key，从而拿到锁。
45+
46+
#### RedLock 算法
47+
这个场景是假设有一个 redis cluster，有 5 个 redis master 实例。然后执行如下步骤获取一把锁：
48+
49+
1. 获取当前时间戳，单位是毫秒；
50+
2. 跟上面类似，轮流尝试在每个 master 节点上创建锁，过期时间较短，一般就几十毫秒；
51+
3. 尝试在**大多数节点**上建立一个锁，比如 5 个节点就要求是 3 个节点 `n / 2 + 1`；
52+
4. 客户端计算建立好锁的时间，如果建立锁的时间小于超时时间，就算建立成功了；
53+
5. 要是锁建立失败了，那么就依次之前建立过的锁删除；
54+
6. 只要别人建立了一把分布式锁，你就得**不断轮询去尝试获取锁**。
55+
56+
![redis-redlock](/img/redis-redlock.png)
57+
58+
### zk 分布式锁
59+
60+
zk 分布式锁，其实可以做的比较简单，就是某个节点尝试创建临时 znode，此时创建成功了就获取了这个锁；这个时候别的客户端来创建锁会失败，只能**注册个监听器**监听这个锁。释放锁就是删除这个 znode，一旦释放掉就会通知客户端，然后有一个等待着的客户端就可以再次重新加锁。
61+
62+
```java
63+
/**
64+
* ZooKeeperSession
65+
*
66+
* @author bingo
67+
* @since 2018/11/29
68+
*
69+
*/
70+
public class ZooKeeperSession {
71+
72+
private static CountDownLatch connectedSemaphore = new CountDownLatch(1);
73+
74+
private ZooKeeper zookeeper;
75+
private CountDownLatch latch;
76+
77+
public ZooKeeperSession() {
78+
try {
79+
this.zookeeper = new ZooKeeper("192.168.31.187:2181,192.168.31.19:2181,192.168.31.227:2181", 50000, new ZooKeeperWatcher());
80+
try {
81+
connectedSemaphore.await();
82+
} catch (InterruptedException e) {
83+
e.printStackTrace();
84+
}
85+
86+
System.out.println("ZooKeeper session established......");
87+
} catch (Exception e) {
88+
e.printStackTrace();
89+
}
90+
}
91+
92+
/**
93+
* 获取分布式锁
94+
*
95+
* @param productId
96+
*/
97+
public Boolean acquireDistributedLock(Long productId) {
98+
String path = "/product-lock-" + productId;
99+
100+
try {
101+
zookeeper.create(path, "".getBytes(), Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL);
102+
return true;
103+
} catch (Exception e) {
104+
while (true) {
105+
try {
106+
// 相当于是给node注册一个监听器，去看看这个监听器是否存在
107+
Stat stat = zk.exists(path, true);
108+
109+
if (stat != null) {
110+
this.latch = new CountDownLatch(1);
111+
this.latch.await(waitTime, TimeUnit.MILLISECONDS);
112+
this.latch = null;
113+
}
114+
zookeeper.create(path, "".getBytes(), Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL);
115+
return true;
116+
} catch (Exception ee) {
117+
continue;
118+
}
119+
}
120+
121+
}
122+
return true;
123+
}
124+
125+
/**
126+
* 释放掉一个分布式锁
127+
*
128+
* @param productId
129+
*/
130+
public void releaseDistributedLock(Long productId) {
131+
String path = "/product-lock-" + productId;
132+
try {
133+
zookeeper.delete(path, -1);
134+
System.out.println("release the lock for product[id=" + productId + "]......");
135+
} catch (Exception e) {
136+
e.printStackTrace();
137+
}
138+
}
139+
140+
/**
141+
* 建立zk session的watcher
142+
*
143+
* @author bingo
144+
* @since 2018/11/29
145+
*
146+
*/
147+
private class ZooKeeperWatcher implements Watcher {
148+
149+
public void process(WatchedEvent event) {
150+
System.out.println("Receive watched event: " + event.getState());
151+
152+
if (KeeperState.SyncConnected == event.getState()) {
153+
connectedSemaphore.countDown();
154+
}
155+
156+
if (this.latch != null) {
157+
this.latch.countDown();
158+
}
159+
}
160+
161+
}
162+
163+
/**
164+
* 封装单例的静态内部类
165+
*
166+
* @author bingo
167+
* @since 2018/11/29
168+
*
169+
*/
170+
private static class Singleton {
171+
172+
private static ZooKeeperSession instance;
173+
174+
static {
175+
instance = new ZooKeeperSession();
176+
}
177+
178+
public static ZooKeeperSession getInstance() {
179+
return instance;
180+
}
181+
182+
}
183+
184+
/**
185+
* 获取单例
186+
*
187+
* @return
188+
*/
189+
public static ZooKeeperSession getInstance() {
190+
return Singleton.getInstance();
191+
}
192+
193+
/**
194+
* 初始化单例的便捷方法
195+
*/
196+
public static void init() {
197+
getInstance();
198+
}
199+
200+
}
201+
```
202+
203+
204+
也可以采用另一种方式，创建临时顺序节点：
205+
206+
如果有一把锁，被多个人给竞争，此时多个人会排队，第一个拿到锁的人会执行，然后释放锁；后面的每个人都会去监听**排在自己前面**的那个人创建的 node 上，一旦某个人释放了锁，排在自己后面的人就会被 zookeeper 给通知，一旦被通知了之后，就 ok 了，自己就获取到了锁，就可以执行代码了。
207+
```java
208+
public class ZooKeeperDistributedLock implements Watcher {
209+
210+
private ZooKeeper zk;
211+
private String locksRoot = "/locks";
212+
private String productId;
213+
private String waitNode;
214+
private String lockNode;
215+
private CountDownLatch latch;
216+
private CountDownLatch connectedLatch = new CountDownLatch(1);
217+
private int sessionTimeout = 30000;
218+
219+
public ZooKeeperDistributedLock(String productId) {
220+
this.productId = productId;
221+
try {
222+
String address = "192.168.31.187:2181,192.168.31.19:2181,192.168.31.227:2181";
223+
zk = new ZooKeeper(address, sessionTimeout, this);
224+
connectedLatch.await();
225+
} catch (IOException e) {
226+
throw new LockException(e);
227+
} catch (KeeperException e) {
228+
throw new LockException(e);
229+
} catch (InterruptedException e) {
230+
throw new LockException(e);
231+
}
232+
}
233+
234+
public void process(WatchedEvent event) {
235+
if (event.getState() == KeeperState.SyncConnected) {
236+
connectedLatch.countDown();
237+
return;
238+
}
239+
240+
if (this.latch != null) {
241+
this.latch.countDown();
242+
}
243+
}
244+
245+
public void acquireDistributedLock() {
246+
try {
247+
if (this.tryLock()) {
248+
return;
249+
} else {
250+
waitForLock(waitNode, sessionTimeout);
251+
}
252+
} catch (KeeperException e) {
253+
throw new LockException(e);
254+
} catch (InterruptedException e) {
255+
throw new LockException(e);
256+
}
257+
}
258+
259+
public boolean tryLock() {
260+
try {
261+
// 传入进去的locksRoot + “/” + productId
262+
// 假设productId代表了一个商品id，比如说1
263+
// locksRoot = locks
264+
// /locks/10000000000，/locks/10000000001，/locks/10000000002
265+
lockNode = zk.create(locksRoot + "/" + productId, new byte[0], ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL_SEQUENTIAL);
266+
267+
// 看看刚创建的节点是不是最小的节点
268+
// locks：10000000000，10000000001，10000000002
269+
List<String> locks = zk.getChildren(locksRoot, false);
270+
Collections.sort(locks);
271+
272+
if(lockNode.equals(locksRoot+"/"+ locks.get(0))){
273+
//如果是最小的节点,则表示取得锁
274+
return true;
275+
}
276+
277+
//如果不是最小的节点，找到比自己小1的节点
278+
int previousLockIndex = -1;
279+
for(int i = 0; i < locks.size(); i++) {
280+
if(lockNode.equals(locksRoot + “/” + locks.get(i))) {
281+
previousLockIndex = i - 1;
282+
break;
283+
}
284+
}
285+
286+
this.waitNode = locks.get(previousLockIndex);
287+
} catch (KeeperException e) {
288+
throw new LockException(e);
289+
} catch (InterruptedException e) {
290+
throw new LockException(e);
291+
}
292+
return false;
293+
}
294+
295+
private boolean waitForLock(String waitNode, long waitTime) throws InterruptedException, KeeperException {
296+
Stat stat = zk.exists(locksRoot + "/" + waitNode, true);
297+
if (stat != null) {
298+
this.latch = new CountDownLatch(1);
299+
this.latch.await(waitTime, TimeUnit.MILLISECONDS);
300+
this.latch = null;
301+
}
302+
return true;
303+
}
304+
305+
public void unlock() {
306+
try {
307+
// 删除/locks/10000000000节点
308+
// 删除/locks/10000000001节点
309+
System.out.println("unlock " + lockNode);
310+
zk.delete(lockNode, -1);
311+
lockNode = null;
312+
zk.close();
313+
} catch (InterruptedException e) {
314+
e.printStackTrace();
315+
} catch (KeeperException e) {
316+
e.printStackTrace();
317+
}
318+
}
319+
320+
public class LockException extends RuntimeException {
321+
private static final long serialVersionUID = 1L;
322+
323+
public LockException(String e) {
324+
super(e);
325+
}
326+
327+
public LockException(Exception e) {
328+
super(e);
329+
}
330+
}
331+
}
332+
```
333+
334+
### redis 分布式锁和 zk 分布式锁的对比
335+
336+
- redis 分布式锁，其实**需要自己不断去尝试获取锁**，比较消耗性能。
337+
- zk 分布式锁，获取不到锁，注册个监听器即可，不需要不断主动尝试获取锁，性能开销较小。
338+
339+
另外一点就是，如果是 redis 获取锁的那个客户端 出现 bug 挂了，那么只能等待超时时间之后才能释放锁；而 zk 的话，因为创建的是临时 znode，只要客户端挂了，znode 就没了，此时就自动释放锁。
340+
341+
redis 分布式锁大家没发现好麻烦吗？遍历上锁，计算时间等等......zk 的分布式锁语义清晰实现简单。
342+
343+
所以先不分析太多的东西，就说这两点，我个人实践认为 zk 的分布式锁比 redis 的分布式锁牢靠、而且模型简单易用。

‎img/redis-redlock.png

8.84 KB
Loading

0 commit comments

Comments
 (0)