018.京东金融是如何通过乐观锁解决并发数据冲突的.md · 独立团二营营长张大彪/Architecture

# $018$.京东金融是如何通过乐观锁解决并发数据冲突的？

***

## 目录

- [$018$.京东金融是如何通过乐观锁解决并发数据冲突的？](#018京东金融是如何通过乐观锁解决并发数据冲突的)
  - [目录](#目录)
  - [为什么会产生并发冲突？](#为什么会产生并发冲突)
  - [悲观锁解决方案](#悲观锁解决方案)
  - [悲观锁并发性太差，高并发场景用户体验差](#悲观锁并发性太差高并发场景用户体验差)
  - [实现目标：既要保证用户体验，也要实现数据可靠](#实现目标既要保证用户体验也要实现数据可靠)

***

## 为什么会产生并发冲突？

> 以当前为例，如下的两段伪代码含义都是相同的。都是先获取 $1001$ 这个账户，然后在这个账户上去增加一点钱，然后将增加后的金额再更新回去。就是这样一个在平时开发时最常见的场景，就会产生并发更新的问题。为什么？
>
> 来看一下执行过程，如果按照单独来执行的话，是没有任何问题的。但是假设第一个线程在执行的时候，$select\ * from\ acc\ where\ id=1$ 拿到了 $1001$ 账户的余额为$400$,从获取账户信息到更新账户账户的这段代码之间必然或多或少有一个时间的缝隙，也就是说这段时间中可能数据状态就会发生变化。假设在这段时间间隔中又进来了一个线程$2$，线程$2$的操作是将原始的金额从$400$加$100$变成了$500$。因为在线程$1$中从$select$到$update$语句之间，数据已经发生了变化，但是在更新的时候还是按照原始数据的$400+500$，在更新时就变成了$900$。
>
> 实际情况因该是在线程$2$更新以后，在这个基础上再加上$500$，它的正确值应该是$1000$，但是由于并发问题这里只有$900$。对于这种涉及到钱的问题是绝对不允许产生的，为了解决这个问题，怎么办呢？

## 悲观锁解决方案

> 来看一下传统的解决方案，其实比较简单，就是在我们原有的 $select$ 语句上面增加一个 $for\ update$。$for\ update$ 子句代表执行前面 $SQL$ 语句的时候为查询到的数据来附加一个行锁，也就是 $1001$ 这条数据在被 $for\ update$ 执行了以后，这条记录就会被上锁，所有其他线程要获取这个 $1001$ 都会处于阻塞等待状态。这种情况下，其实就可以保证数据的操作是有序的。
> 回到刚才的例子，在执行了 $for\ update$ 以后也就意味着在当前的事务中才能对 $1001$ 进行操作，其他事务访问 $1001$ 的数据的时候都会处于阻塞等待的状况。在操作完更新为 $500$ 了以后进行数据提交，一旦提交，行锁就会被释放。此时线程 $1$ 也就开始处理了，同样的过程，获取到 $1001$ 的行锁，然后在原有的 $500$ 基础上再加 $500$，预期结果就是正确的了。
>
> 以上就是我们以前在实际开发中一种常用的方式，这种方式是采用悲观锁的方式。悲观锁就是指将数据先行锁定，其他任何访问到这个数据的线程都会处于阻塞等待的情况，直到锁释放再进行后续的处理。

> 但是悲观锁有一个严重的问题，尤其是在互联网项目中，悲观锁的场景使用的越来越少了，为什么呢？

## 悲观锁并发性太差，高并发场景用户体验差

> 试想一下，现在对上面的 $1001$ 进行锁定，高并发场景下，任何一个对 $1001$ 账户进行操作的线程都会进入阻塞状态，此时并发性就会变得非常差。
> 你可能会认为 $1001$ 账户可能是一个个人账户，它被并发的情况应该可能会很小吧。但是，不能用业务的方式去设计架构的问题。如果当前的账户是一个统一的结算账户，一旦结算账户被锁，所有的其他线程都会处于阻塞状态。一旦处于阻塞状态还会衍生出一个新问题，一旦线程阻塞太多，产生积压就有可能让 $web$ 容器中线程池处于爆满的状态，轻则系统失去响应，重则系统直接就挂掉了。
> 这也是我们在日常高并发项目中不怎么去使用悲观锁的一个原因所在。
> 还有就是高并发场景下用户的体验是比较差的，因为一直处于阻塞状态，用户就一直在等待处理，这种情况对用户体验是不太好的。
>
> 因此，悲观锁虽然能解决同步的问题，但是并不是一个最好的方案。那怎么办？

## 实现目标：既要保证用户体验，也要实现数据可靠

> 与悲观锁相对的另外一种解决方案——乐观锁出现了，乐观锁其实没什么复杂的，它也需要底层数据表来进行一些调整。因为乐观锁的实现通常是由程序或者其他的一些机制来实现，而非数据库自带的一种方案。
>
> 以下面的图为例，在这张账户表里，增加了额外的一个字段 $\_version$ 代表版本号。在初始状态下，这个版本号为$1$，我们通过版本号来进行并发控制。那么如何做到并发控制呢？

> 如下图，还是按照原始的规则，开始事务。首先进行 $select$ 查询，把 $1001$ 账户取出来，因为增加了 $\_version$ 字段，所以在这里一并也会取出来。当获取到账户对象以后，在原始余额 $400+100$，这是正常操作。接下来，就要执行 $update$ 语句，这里 $update$ 语句有一个重大的变化，就是在 $where$ 条件中增加了 $\_version=1$，这个$1$ 就来自于刚才在查询时候获取到的版本号，把它代入到条件中。与此同时，如果 $update$ 执行成功，则对 $\_version$ 实行自增操作。也就是说上面这一整段程序执行完以后，余额更新为 $500$，版本号更新为 $2$。

> 上面的处理是如何避免并发冲突的呢？假设线程$2$还是先执行，当线程$2$执行完以后，当前的余额就被更新成了$500$，同时 $\_version$ 自增变为 $2$，这是一个正常的操作。
>
> 但是在并发环境下，如果线程$1$是并发执行的，他在线程$2$更新之前先执行了 $select\ *\ from\ acc\ where\ id=1001$。由于线程$2$的 $update$ 还没有执行，所以他取出来的这个版本号 $\_version=1$。如果在线程$1$ 的两条 $SQL$ 语句之间，线程$2$已经变更了数据的状态，把原有账户余额已经调整为了$500$，同时版本号变为了$2$，试想一下，按照刚才的规则，线程$1$再执行 $update$ 语句的时候还能进行更新吗？答案是否定的，因为这里还需要满足条件 $\_version=1$，但此时此刻，由于线程$2$的原因，$\_version$ 已经变成了$2$，但是线程中的 $update$ 的条件还是 $\_version=1$，这样就会产生因为 $where$ 条件没有查询到任何数据，所以本次更新的操作就会返回 $0$，$0$代表没有做任何实质的数据更新，最后程序提交。
>
> 这里你可能会有疑惑——难道线程$1$他没有做任何事情，刚才的操作不就作废了吗？是的，如果单从并发冲突解决的方案来说，把它作废最起码数据是不会报错的，但是用户体验就会变得非常差。那如何解决呢？

<div align=center>
    <img src="./img/018/Optimistic-lock-solution.png">
    <p>避免并发冲突</p>
</div>

- **如果遇到冲突后该怎么办？**
  - **前端应用提示"数据正在处理，请稍后重试！"** 
  - **附加 $spring-retry$ 在 $service$ 上进行方法重试**

> 来看一下 $spring-retry$ 的用法，其实并不复杂，首先在 $Maven$ 中引入 $spring-retry$ 这个组件，这个组件就是用来进行方法重试的。然后在原有的方法上只需要增加一个注解 $@Retryable$，当方法抛出什么异常的时候来进行当前方法的重试，最多重试三次。
> 就以下伪代码来说，首先查询 $Account$ 信息，然后通过 $setBal()$ 进行余额的增加，紧接着执行更新操作，如果更新的结果是$1$代表执行成功，如果是$0$就可以认为产生了数据的并发异常，去抛出自定义的 $VersionException$。当抛出异常以后，就会被捕捉到，并进行方法的重试。
>
> 但是这里可能衍生出一个新问题，对于 $count=0$ 的情况，不一定是并发异常产生的，还有一些其他的情况，也会产生 $count=0$。比如余额没有产生实质的更新，原始余额是多少，更新还是多少，因为数据没有发生变化，这样可能导致$count=0$，所以需要做好前置判断，保证 $count=0$ 的时候就是并发性问题抛出异常。

```java
@Transactional
@Retryable(value = {VersionException.class}, maxAttempts = 3)
public void updateBal(){
    Account acc = 执行:"select id,bal,_version from acc where id = 1001";
    acc.setBal(acc.getBal() + 400);
    int count= 执行:"update acc set bal = ${acc.bal},_version = _version + 1 where id = 1001 and _version = ${acc.version}";
    if(count == 0){throw new VersionException("产生并发异常")};
}
```

> 通过上面的方式可以保证 $web$ 容器的线程池连接处于一个低水位的情况，对于系统的健壮性来说是有好处的。

***

独立团二营营长张大彪/Architecture

简介

发行版

贡献者

近期动态

独立团二营营长张大彪/Architecture .gitee-modal { width: 500px !important; }

简介

发行版

贡献者

近期动态

搜索帮助

独立团二营营长张大彪/Architecture