1. 一些概念

分布式锁的要求：互斥（同一时刻只能一个服务实例的一个线程持有），高可用（单节点挂了其他结点顶上），高性能（读取速度快），安全性（避免死锁）

分布式锁的实现：mysql（本身具备互斥性，具备高可用，读写性能一般，断开连接自动释放锁），redis（使用setnx实现互斥，具备高可用，读写性能高，使用过期时间来释放锁），zookeeper（使用结点唯一性或者顺序性实现互斥，具备高可用，读写性能一般，断开连接释放锁）。综合来看redis性能好可用性高，安全性略差，mysql和zookeeper安全性好，性能略差。

2. MySQL方案

2.1 方案一：事务特性

MySQL默认开启自动提交模式，即客户端执行的每一条 SQL 语句都会被当作一个独立的事务，一旦语句执行完毕，就会自动提交。事务具有ACID特性，因而可以使用MySQL实现分布式锁。

create table lock_table
(id int auto_increment comment 'primary key',value varchar(64) null comment 'resource which need be locked',constraint lock_table_pk primary key (id)
);create unique index lock_table_value_uindex
on lock_table (value);-- 注意：value字段是临界资源。插入成功则获得锁，删除记录则释放锁。一个事务在执行插入时，其他事务插入时失败。
update lock_table set value = #{newValue} where id = #{id};

2.1.1 存在的问题

1. 锁不可重入。可重入锁的场景：在递归代码中访问临界资源会重复请求锁，可重入锁可以重复请求锁阻塞；在复杂的调用关系中使用可重入锁来防范死锁问题。
2. 没有过期时间，当释放锁失败时会带来死锁问题。
3. 申请锁失败时不会阻塞。
4. 高度依赖数据库的可用性。

2.1.2 解决方案

1. 可重入：给表lock_table新增count字段和请求id字段，当同样的请求到来时只增加count而不是新增记录。
2. 给表lock_table新增expire_time字段，通过定时任务定期清理过期的lock
3. 使用while循环来创造阻塞效果。
4. 创建备用数据，避免单节点数据库，提高可用性。

评价：大量事务经常竞争锁影响性能，一般不使用这个方法。

2.2 方案二：乐观锁

乐观锁：假设取数据时其他人不会修改数据，修改数据时检查是否已经有人修改数据。乐观锁可以使用CAS（Compare And Set）算法实现。

create table lock_table
(id int auto_increment comment 'primary key',value varchar(64) null comment 'locked resource',version int default 0 null comment 'version'constraint lock_table_pk primary key (id)
);
/*
update loss
MySQL默认隔离等级为repeatable read，同一事务内并发的其他事务不能修改数据，因而可以多次读出相同的数据。但是修改数据时，其他并发事务可能抢先一步修改了数据（已经提交），这导致从"old_value"到“new_value”的修改实际上是从"unkonwn_value"到"new_value"的修改。
*/-- 乐观锁应对update loss
update lock_table set value = #{newValue}, version = #{version} + 1 where id = #{id} and version = #{version};

评价：不依赖数据库本身的设计，性能差；需要version字段，造成数据库冗余设计；高并发场景下version字段频繁变动，系统可用性受到影响。适合于多读少些低并发的场景。

2.3 方案三：悲观锁

# 注意关闭自动提交：autocommit=0# 实现1：使用S锁，并发事务可以通过加S锁实现共读，临界资源上有S锁则不许加X锁。并发事务更新临界资源时需要加X锁(update操作默认加X锁)，只有有一个事务得到X锁。允许共读，有读不写，写不可读，只有一写。
select id, value from lock_table where id = #{id} lock in share mode;
update lock_table set value = #{newValue} where id = #{id};# 实现2：使用X锁，只有拿到X锁才能读，只有拿到X锁才能写。每次只许一个事务读写。
select id, value from lock_table where id = #{id} for update;
update lock_table set value = #{newValue} where id = #{id};

评价：每个数据请求都加锁，高并发环境下大量请求获取不到锁会陷入阻塞，影响系统性能。表数据量小，MySQL查询不走索引，因而可能触发表锁而不是行锁，影响并发性能。

3. Redis

3.1 实现原理

setnx只有在key不存在的时候才执行，key存在则执行失败。这意味着多个并发执行只会有一个成功，这个特点适合用来实现分布式锁。

# Set the string value of a key only when the key doesn't exist.
SETNX key value# setnx and set expire time are two operations, use set command instead can do all stuff with one operation
SET key value [EX seconds][PX milliseconds][NX|XX]# parameter type
EX seconds: Set expiration time in seconds
PX milliseconds: Set expiration time in milliseconds
NX: Set the value only when the key does not exist
XX: Set the value only when the key exists# release lock
DEL key

3.2 实现细节

3.2.1 问题1：持有期间锁过期问题

例如，线程1获取了锁，其因业务阻塞而长时间持有，结果锁超时释放，线程2随后成功获取锁，线程1业务指向完毕会释放线程2的锁。

解决1：延长锁的expire time。使用redis工具Redisson，它可以使用watchdog技术来延时释放锁。

解决2：线程释放锁时先判断要释放的锁是否是自己的锁，是再释放。

KEY_PREFIX = 'lock'
ID_PREFIX = uuid;
LOCK_NAME = bussiness_name  # 和业务相关key = KEY_PREFIX + ':' + LOCK_NAME  # lock和业务相关，建议key为lock:name形式def get_current_reqt_id():cur_reqt_id = get_thread_id()reqt_id = ID_PREFIX + '-' + thread_iddef try_lock(key):reqt_id= get_current_reqt_id(reqt_id)  # value为持有者唯一标识，此处用uuid + 线程id作为值r = redis_client.get(key)if r:return Truereturn Falsedef unlock(key):cur_reqt_id = get_current_reqt_id()reqt_id = redis_client.get(key)result = Falseif cur_reqt_id == reqt_id:redis_client.del(key)result = Truereturn result

3.2.2 问题2：判断和释放锁间隙中锁过期

例如，线程1要释放锁，先判断锁是否为线程1持有，判断为真，然后线程1执行释放锁操作。判断操作和释放操作间隔较长，锁自动释放。线程2在线程1判断操作后，且锁被自动释放后成功获取了锁。接着线程1执行释放锁操作，则线程1释放掉线程2的锁。

解决：使用lua脚本将判断锁和释放锁打包成原子操作。注意最好将lua脚本加载到内存，方便每次调用直接使用而不是读文件后再操作。

# 使用redis的EVAL命令来执行lua脚本
# Executes a server-side Lua script.
EVAL script numkeys [key [key ...]] [arg [arg ...]]'''
脚本中
KEYS[1] 代表传递给脚本的第一个键名参数
ARGS[1] 代表传递给脚本的第一个参数值
命令中
1 指示参数个数
name 实际传递给脚本的第一个键名参数
xxx 实际代表传递给脚本的第一个
'''
EVAL "return redis.call('set', KEYS[1], ARGS[1])" 1 name xxx# 释放锁lua脚本
if(redis.call('get', KEYS[1]) == ARGS[1]) thenreturn redis.call('del', KEYS[1])
end
return 0

4. Zookeeper

待更新