并发场景下的幂等问题——分布式锁详解

简介：本文从钉钉实人认证场景的一例数据重复问题出发，分析了其原因是因为并发导致幂等失效，引出幂等的概念。针对并发场景下的幂等问题，提出了一种实现幂等可行的方法论，结合通讯录加人业务场景对数据库幂等问题进行了简单分析，就分布式锁实现幂等方法展开了详细讨论。分析了锁在分布式场景下存在的问题，包括单点故障、网络超时、错误释放他人锁、提前释放锁以及分布式锁单点故障等，提出了对应的解决方案，介绍了对应方案的具体实现。

作者 | 百书
来源 | 阿里技术公众号

写在前面：本文讨论的幂等问题，均为并发场景下的幂等问题。即系统本存在幂等设计，但是在并发场景下失效了。

一 摘要

本文从钉钉实人认证场景的一例数据重复问题出发，分析了其原因是因为并发导致幂等失效，引出幂等的概念。

针对并发场景下的幂等问题，提出了一种实现幂等可行的方法论，结合通讯录加人业务场景对数据库幂等问题进行了简单分析，就分布式锁实现幂等方法展开了详细讨论。

分析了锁在分布式场景下存在的问题，包括单点故障、网络超时、错误释放他人锁、提前释放锁以及分布式锁单点故障等，提出了对应的解决方案，介绍了对应方案的具体实现。

二 问题

钉钉实人认证业务存在数据重复的问题。

1 问题现象

正常情况下，数据库中应该只有一条实人认证成功记录，但是实际上某用户有多条。

2 问题原因

并发导致了不幂等。

我们先来回顾一下幂等的概念：

幂等（idempotent、idempotence）是一个数学与计算机学概念，常见于抽象代数中。
在编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。
--来自百度百科

实人认证在业务上有幂等设计，其一般流程为：

1）用户选择实人认证后会在服务端初始化一条记录；
2）用户在钉钉移动端按照指示完成人脸比对；
3）比对完成后访问服务端修改数据库状态。

在第3步中，在修改数据库状态之前，会判断「是否已经初始化」、「是否已经实人认证」以及「智科是否返回认证成功」以保证幂等。仅当请求首次访问服务端尝试修改数据库状态时，才能满足幂等的判断条件并修改数据库状态。其余任意次请求将直接返回，对数据库状态无影响。请求多次访问服务端所产生的结果，和请求首次访问服务端一致。因此，在实人认证成功的前提下，数据库应当有且仅有一条认证成功的记录。

但是在实际过程中我们发现，同一个请求会多次修改数据库状态，系统并未按照我们预期的那样实现幂等。究其原因，是因为请求并发访问，在首次请求完成修改服务端状态前，并发的其他请求和首次请求都通过了幂等判断，对数据库状态进行了多次修改。

并发导致了原幂等设计失效。

并发导致了不幂等。

三 解决方案

解决并发场景下幂等问题的关键，是找到唯一性约束，执行唯一性检查，相同的数据保存一次，相同的请求操作一次。

一次访问服务端的请求，可能产生以下几种交互：

1. 与数据源交互，例如数据库状态变更等；
2. 与其他业务系统交互，例如调用下游服务或发送消息等；

一次请求可以只包含一次交互，也可以包含多次交互。例如一次请求可以仅仅修改一次数据库状态，也可以在修改数据库状态后再发送一条数据库状态修改成功的消息。

于是我们可以得出一个结论：并发场景下，如果一个系统依赖的组件幂等，那么该系统在天然幂等。

以数据库为例，如果一个请求对数据造成的影响是新增一条数据，那么唯一索引可以是幂等问题的解法。数据库会帮助我们执行唯一性检查，相同数据不会重复落库。

钉钉通讯录加人就是通过数据库的唯一索引解决了幂等问题。以钉钉通讯录加人为例，在向数据库写数据之前，会先判断数据是否已经存在于数据库之中，如果不存在，加人请求最终会向数据库的员工表插入一条数据。大量相同的并发的通讯录加人请求让系统的幂等设计失效成为可能。在一次加人请求中，（组织ID，工号）可以唯一标记一个请求，在数据库中，也存在（组织ID，工号）的唯一索引。因此我们可以保证，多次相同的加人请求，只会修改一次数据库状态，