分布式锁

分布式锁

Redis

基于setnx实现分布式锁

1. 获取锁的时候，使用 setnx

2. 使用 expire 命令为锁添加一个超时时间，超过该时间则自动释放锁

3.  获取锁的时候调用 setnx

4. 释放锁的时候，通过 UUID 判断是不是该锁，若是该锁，则执行 delete 进行锁释放

基于Redission实现分布式锁

流程

1. 客户端C1申请加锁，key为myLock

2. 如果key不存在，通过hset设置值，通过pexpire设置过期时间。同时开启Watchdog任务，默认每隔10秒中判断一下，如果key还在，重置过期时间到30秒

3. 客户端C1相同线程再次加锁，如果key存在，判断Redis里Hash中的lockName跟当前线程lockName相同，则将Hash中的lockName的值加1，代表支持可重入加锁

4. 客户单C2申请加锁，如果key存在，判断Redis里Hash中的lockName跟当前线程lockName不同，则执行pttl返回剩余过期时间

5. 客户端C2线程内不断尝试pttl时间，此处是基于Semaphore信号量实现的，有许可立即返回，否则等到pttl时间还是没有得到许可，继续重试

Zookeeper

基于Zookeeper实现分布式锁

特性

数据节点

顺序临时节点

Watch机制

加锁流程

解锁流程

优缺点

优点

锁的模型健壮、简单易用、适合做分布式锁

如果获取不到锁，只需要添加一个监听器就可以了，不用一直轮询，性能消耗较小

如果客户端宕机，也没关系，临时节点会自动删除，触发监听器通知下一个节点

缺点

若有大量的客户端频繁的申请加锁、释放锁，对于ZK集群的压力会比较大

etcd

架构

HTTP Server

用于处理客户端发送的 API 请求以及其它 Etcd 节点的同步与心跳信息请求

Store

Etcd 对用户提供的大多数 API 功能的具体实现

Raft

Raft 强一致性算法的具体实现，是Etcd 的核心

WAL（预写式日志）

Etcd 的数据存储方式

包含

Snapshot

为了防止数据过多而进行的状态快照

核心机制

租约机制

租约、续约、解约

前缀机制（目录机制）

前缀机制

Revision 机制

全局唯一、对于实现公平锁，队列十分有益

应用场景

服务发现

原理

存在一个高可靠、高可用的中心配置节点：基于 Ralf 算法的 Etcd 天然支持

服务提供方会持续的向配置节点注册服务

服务的调用方会持续的读取中心配置节点的配置并修改本机配置，然后 reload 服务

通过 Watch 机制，服务调用方还可以监测服务的变化

消息发布和订阅

集群监控与 Leader 竞选

集群监控

通过 Etcd 的 Watch 机制，当某个 key 消失或变动时，Watcher 会第一时间发现并告知用户

Leader 竞选

使用分布式锁，可以很好的实现 Leader 竞选（抢锁成功的成为 Leader）

分布式锁基本原理

条件

互斥性

在任意时刻，对于同一个锁，只有一个客户端能持有，从而保证只有一个客户端能够操作同一个共享资源

安全性

不会形成死锁，一个客户端持有锁期间发生宕机没有主动解锁的情况下锁可以正常被释放

可用性

当提供锁服务的节点发生宕机等不可恢复性故障时，“热备” 节点能够接替故障的节点继续提供服务，并保证自身持有的数据与故障节点一致

对称性

对于任意一个锁，其加锁和解锁必须是同一个客户端

好文

更为健壮的分布式锁实现之Etcd

不为人所知的分布式锁实现全都在这里了

分布式锁选型背后的架构设计思维

基于CAP模型设计企业级真正高可用的分布式锁