背景
项目中存在「批量接口」和「增量接口」，两个接口都更新DB中的数据。
如存在以下表格，主键为shopId，shopName表示店名。
| shopId | shopName |
|---|---|
| 111 | info111 |
| 222 | info222 |
| 333 | info333 |
有以下两个接口：
updateShopNameBatch(List<Integer> shopIdList, String shopName);
updateShopName(Integer shopId, String shopName);
两个接口的功能分别为批量修改门店名称和单个修改门店名称。
忽略接口中的其他操作，主要执行了以下两句sql。
update Shop set shopName = #{shopName} where shopId in
<foreach collection="shopIdList" item="shopId" index="index" open="(" separator="," close=")">
#{shopId}
</foreach>
update Shop set shopName = #{shopName} where shopId = #{shopId}
两个sql可能会修改同个shopId的shopName属性，存在一定的并发问题。
从数据库层看，两个sql的执行过程完全隔离，即先到先执行。
从接口层面看，批量更新接口和增量更新接口的并发执行会遇到以下情况：
- 批量接口先于增量接口收到请求，然而由于批量接口中执行了一些额外操作，导致增量接口先执行sql。最终结果被批量接口覆盖。
- 接口调用发起方先调用批量接口，再调用增量接口，然而由于网络问题，增量请求先于批量请求到达服务提供方。
- 用户先点击批量修改按钮，再修改了单个门店的名称。在分布式系统中，两个请求打到了不同服务器，由于服务器负载不均，导致增量接口的sql先于批量sql执行。
- ……
这个例子较为常见，由于分布式，网络，处理速度等原因，用户先发起的请求，可能会被延后。
问题
这里就引出请求顺序的问题，请求A和请求B，到底是哪个先发生。
在分布式系统中，一般很少去关注两个请求哪个先发生，因为：
- 多数接口为查询接口，并不关心请求的先后顺序。
- 很少存在批量接口和增量接口同时被调用的场景。
当同时使用批量接口和增量接口时，则需要着重关注这个问题。
接口调用示意图如下：
解决思路
考虑到需要区分请求发生的先后，首先想到的是时间戳。
调用发起方在调用批量和增量接口时，增加时间戳入参。
在服务端，将时间戳作为当前sql记录的版本号。
- 如果库中的版本号小于入参时间戳，则支持更新。
- 如果库中的版本号大于入参时间戳，则不更新。表示已有后发起的请求更新了数据库。
然而，在分布式环境下，时间校准也是个难题。
因为无法保证批量接口和增量接口从同个服务器发起。
不同服务器之间存在时间误差，则无法保证入参时间戳的准确性。
分布式场景如下：
考虑到时间准确性，想到时间协议。
在网络时间协议中，有一种常用的协议，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中带着一些粗暴。
换个思维角度，也算是一种乐观并发的思维，乐观地认为批量接口和增量接口很少会出现并发。即使出现并发问题，在服务器之间交错调用后，最终结果有一定概率是正确的。(逃
后记
求比较优雅的，用于解决批量、增量接口并发问题的方案，感激不尽。
