用MySQL数据库，实现简单的分布式锁

背景

系统采用SpringBoot开发，双节点部署，nginx负载均衡代理。

服务层存在10多个后台调度接口，现存有三种定时调度类型：@Schedule注解、Schedule服务、LTS平台。
因业务扩展，需要增加分布式锁，保障某些业务流程的数据一致性。而系统未使用redis等中间件，目前最便捷的方式是采用MySQL数据库来实现分布式锁。

MySQL自带的get_lock(‘key’, timeout)和release_lock(‘key’)，因锁持有周期内，需要一直占用数据库连接，不适用于大多数场景，因此模仿JVM的内存模型CAS机制，建立一个“调度锁”表，提供简单的分布式锁场景。

实现

1、实现目的

为多个调度接口，提供数据库级别的锁，在并发访问时，实现分布式场景下的互斥性。
1、不考虑可重入性，同一线程不可多次获得锁。
2、判断锁过期时间，防止系统异常时锁被一直占用，接口无法再启用。

2、实现思路

• 以锁名称(topic)区分不同的锁
• 通过版本号(version)，实现CAS控制，以避免出现ABA问题
• 多个线程抢锁，获得锁时owner记录为线程ID
• 抢锁过程为先尝试(try_lock)，后校验是否抢到(recheck)
• 记录加锁时间(lock_time)，用于校验过期时间(expire_on)
• 避免过多update，先查询query，再try_lock

3、流程说明

3.1 整体流程

抢锁尝试三次，每次等待5s，若失败或发生异常，释放锁。
抢锁成功，进入业务执行，完成或异常，释放锁。

3.2 抢锁：查询->抢锁

并发抢锁的核心是CAS操作，确保只有一个线程能获得锁。
在做抢锁操作之前，为避免频繁写操作，先做条件判断，若锁已占用且未达到过期时间，则结束本轮，等待5s再进行下一次抢锁。

3.3 释放

比对当前owner是否是自己，是则释放，否则不释放

4、详细实现

4.1 数据库字段

name	desc
topic	锁名称
owner	线程TraceId
version	版本号-CAS校验
lock_time	加锁时间
expire_on	过期时间 int,min

4.2 加锁

加锁时，version+1，并设置owner为currThread：

update table
set owner = ‘currThread-TraceId’ and version = ‘version +1’
where topic = ‘topic’ and (version = 'version ’ or (now() - lock_time > expire_on))

4.3 解锁

解锁时，设置owner为null：
update table
set owner = null
where topic = ‘topic’ and owner = ‘currThread-TraceId’

附：完整流程