分布式锁之数据库乐观锁version

分布式锁

1、分布式锁介绍

1.1、为什么用分布式锁

在单机系统中，当多线程访问数据时，为了保证数据的正确性，我们一般都会采用加锁的方式，比较常见的synchronized或者ReentrantLock。他们都是由Java为我们提供的锁实现，能够让多个线程之间只能串行化执行，从而保证数据的正确性。

​ 但是一旦将服务器从单机部署升级为多机部署后，则会发现Java提供的原生锁机制在多机部署下失效了。这是因为Java本身提供的锁，他们只对属于自己JVM里面的线程有效，对于其他JVM的线程是无效的。

1.2 场景示例

​ 现在有一个电商系统，此时只通过一台机器进行部署，当用户下单时，首先会检查库存是否足够，只有当库存足够时，才会允许进行下单。

​ 为了提高系统的并发性能，因此会首先将商品库存信息预热到redis中，当用户下单时，会更新redis中的库存信息。

此时在单线程下执行是没有任何问题的，但是假设现在某一商品库存数量为1，且同时有两个线程同时对该商品执行下单操作，线程A和线程B查询库存结果都为1，此时线程A先执行第三步更新mysql将库存数量由1变为0。但是当线程B再来执行第三步更新mysql时，库存数量会变为-1，此时库存超卖出现。

此时要想解决超卖问题，则可以进行加锁，将2，3，4步利用synchronized或者ReentrantLock进行加锁，从而让线程排队，避免超卖问题的出现。

但是当随着并发量的增大，此时单机部署已经无法承受这么大的并发量了，则会将系统由单机变为多机部署。

此时假设同时有两个用户进行下单，请求分别进入两台机器中，那么这两个请求是可以同时执行的，则仍然会出现超卖问题。

​ 因为不管synchronized或者ReentrantLock都是只作用于自己机器的JVM中，对其他机器的JVM无效。相当于两台不同的机器使用的是不同的两把锁，导致锁失效。

​ 解决该问题的思路则需要保证不同的机器使用的是相同的一把锁，则此时需要使用分布式锁。对于分布式锁的实现，可以基于Mysql、redis、zookeeper、consule等进行实现。

1.3 分布式锁具备的条件

• 互斥性：同一时刻只能有一个服务(或应用)访问资源。
• 原子性：一致性要求保证加锁和解锁的行为是原子性的。
• 安全性：锁只能被持有该锁的服务(或应用)释放。
• 容错性：在持有锁的服务崩溃时，锁仍能得到释放，避免死锁。
• 高可用：获取锁和释放锁 要高可用。
• 高性能：获取锁和释放锁的性能要好。
• 持久性：锁按业务需要自动续约/自动延期。

2、分布式锁的解决方案

2.1 数据库实现分布式锁

1、pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>org.example</groupId>
    <artifactId>mysqlLockDemo</artifactId>
    <version>1.0-SNAPSHOT</version>

    <!-- Spring boot 版本信息 -->
    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.1.6.RELEASE</version>
        <relativePath/>
    </parent