Skip to content

Commit 7d69842

Browse files
committed
[docs update]完善消息队列的内容
添加常见的消息队列介绍,完善各个消息队列的对比。
1 parent 7f9a642 commit 7d69842

File tree

6 files changed

+165
-54
lines changed

6 files changed

+165
-54
lines changed

Diff for: docs/distributed-system/distributed-lock.md

+3
Original file line numberDiff line numberDiff line change
@@ -29,6 +29,7 @@ category: 分布式
2929

3030
- **互斥** :任意一个时刻,锁只能被一个线程持有;
3131
- **高可用** :锁服务是高可用的。并且,即使客户端的释放锁的代码逻辑出现问题,锁最终一定还是会被释放,不会影响其他线程对共享资源的访问。
32+
- **可重入**:一个节点获取了锁之后,还可以再次获取锁。
3233

3334
通常情况下,我们一般会选择基于 Redis 或者 ZooKeeper 实现分布式锁,Redis 用的要更多一点,我这里也以 Redis 为例介绍分布式锁的实现。
3435

@@ -203,6 +204,8 @@ Redis 集群下,上面介绍到的分布式锁的实现会存在一些问题
203204

204205
针对这个问题,Redis 之父 antirez 设计了 [Redlock 算法](https://redis.io/topics/distlock) 来解决。
205206

207+
![](images/distributed-lock/distributed-lock-redis.io-realock.png)
208+
206209
Redlock 算法的思想是让客户端向 Redis 集群中的多个独立的 Redis 实例依次请求申请加锁,如果客户端能够和半数以上的实例成功地完成加锁操作,那么我们就认为,客户端成功地获得分布式锁,否则加锁失败。
207210

208211
即使部分 Redis 节点出现问题,只要保证 Redis 集群中有半数以上的 Redis 节点可用,分布式锁服务就是正常的。
Loading
Loading
Loading

0 commit comments

Comments
 (0)