背景

项目中存在「批量接口」和「增量接口」，两个接口都更新DB中的数据。

如存在以下表格，主键为shopId，shopName表示店名。

shopId

shopName

111

info111

222

info222

333

info333

有以下两个接口：

updateShopNameBatch(List shopIdList, String shopName);

updateShopName(Integer shopId, String shopName);

两个接口的功能分别为批量修改门店名称和单个修改门店名称。

忽略接口中的其他操作，主要执行了以下两句sql。

update Shop set shopName = #{shopName} where shopId in

#{shopId}

update Shop set shopName = #{shopName} where shopId = #{shopId}

两个sql可能会修改同个shopId的shopName属性，存在一定的并发问题。

从数据库层看，两个sql的执行过程完全隔离，即先到先执行。

从接口层面看，批量更新接口和增量更新接口的并发执行会遇到以下情况：

批量接口先于增量接口收到请求，然而由于批量接口中执行了一些额外操作，导致增量接口先执行sql。最终结果被批量接口覆盖。

接口调用发起方先调用批量接口，再调用增量接口，然而由于网络问题，增量请求先于批量请求到达服务提供方。

用户先点击批量修改按钮，再修改了单个门店的名称。在分布式系统中，两个请求打到了不同服务器，由于服务器负载不均，导致增量接口的sql先于批量sql执行。

……

这个例子较为常见，由于分布式，网络，处理速度等原因，用户先发起的请求，可能会被延后。

问题

这里就引出请求顺序的问题，请求A和请求B，到底是哪个先发生。

在分布式系统中，一般很少去关注两个请求哪个先发生，因为：

多数接口为查询接口，并不关心请求的先后顺序。

很少存在批量接口和增量接口同时被调用的场景。

当同时使用批量接口和增量接口时，则需要着重关注这个问题。

接口调用示意图如下：

批量接口和增量接口调用顺序

解决思路

考虑到需要区分请求发生的先后，首先想到的是时间戳。

调用发起方在调用批量和增量接口时，增加时间戳入参。

在服务端，将时间戳作为当前sql记录的版本号。

如果库中的版本号小于入参时间戳，则支持更新。

如果库中的版本号大于入参时间戳，则不更新。表示已有后发起的请求更新了数据库。

然而，在分布式环境下，时间校准也是个难题。

因为无法保证批量接口和增量接口从同个服务器发起。

不同服务器之间存在时间误差，则无法保证入参时间戳的准确性。

分布式场景如下：

分布式场景

考虑到时间准确性，想到时间协议。

在网络时间协议中，有一种常用的协议，NTP。

其作用是让服务器时间和源服务器时间对齐。

NTP协议的流程图如下：

NTP协议

NTP协议过程：

客户端向服务器发送请求，并记录客户端时间为T1。

NTP服务器收到请求，记录服务端时间为T2。

服务端做一些处理，响应客户端请求，并记录服务端时间为T3。

客户端收到响应，记录客户端时间为T4。

可得：

NTP服务端处理时间为T3 - T2。

整个过程耗时为T4 - T1。

得到往返网络延时为(T4 - T1) - (T3 - T2)。

假设请求网络延时为delay1，响应网络延时为delay2，客户端和NTP服务端的时差为d。

得到T1 + d + delay1 = T2, T3 - d + delay2 = T4。

使用等式干申大那多，得到(T2 - T1) + (T3 - T4) = 2d + (delay1 - delay2)。

在NTP协议中，默认delay1 = delay2，即d = ((T2 - T1) + (T3 - T4)) / 2。

当网络足够稳定时，delay1约等于delay2。那么，网络越不稳定，误差也就越大。

在分布式中，不同客户端与NTP服务端之间的网络情况不同，将引入另一个误差因素。

采用方案

查看NTP协议之后，发现其误差为毫秒级别。

NTP意图将所有参与计算机的协调世界时时间同步到几毫秒的误差内。 —— 维基百科

正常情况下，批量接口和增量接口的响应时间为毫秒级，所以NTP协议的误差是不能接受的。

最终采用了一种较为粗暴的方案：

每条sql记录都有一个版本号，初始值为0。

在执行批量之前，首先select，查出版本号为verison。

执行update时，将版本作为参数带上，即update Shop set shopName = #{shopName} where shopId = #{shopId} and version = #{version}

如果update语句返回结果为1，则表示执行成功；如果返回为0，则表示在批量select和update过程中，已被增量接口修改，即遇到并发问题。

如遇到并发问题，执行告警操作，并进行人工数据对齐。

因无法确认批量接口和增量借口发生的先后顺序，最终采用了出错告警，人工校对的方案。

该方案low中带着一些粗暴。

换个思维角度，也算是一种乐观并发的思维，乐观地认为批量接口和增量接口很少会出现并发。即使出现并发问题，在服务器之间交错调用后，最终结果有一定概率是正确的。(逃

后记

求比较优雅的，用于解决批量、增量接口并发问题的方案，感激不尽。