锁处理
目的:
为了避免接口被并发访问,导致业务数据校验(是否正式已存在、是否审批中)被迫通过,导致创建多个流程单据去新增业务数据,造成正式业务数据重复;
*代表采用应用的方案。
应用分布式锁
考虑锁控制思路:
1.分析并发场景(相同应用、不同应用访问)、给出解决方案
如:客户上市接口
并发访问场景:
-
同一外部应用系统,同一个用户创建一个客户,连续快速点击2次(2个线程同时访问同一接口,数据已在审批中代码校验被迫通过)
解决办法:clientID 外部应用标识 -
同一外部应用系统,不同用户同时创建同一个客户(2个线程同时访问同一接口,数据已在审批中代码校验被迫通过)
解决办法:clientID 外部应用标识
-
不同外部应用,同时创建相同客户标识的客户(2个线程同时访问同一接口,数据已在审批中代码校验被迫通过)
解决办法:客户唯一识别标识
2.取用最适配所有场景方案
客户上市最终方案:通过客户唯一识别标识来加锁处理(身份证号+纳税人识别号)
即能控制并发场景1、2,又能控制并发场景3
生命周期接口并发控制解决方案:
1. 客户上市接口并发控制:
方案1:(粗粒度)clientId控制同一外部应用并发访问,缺点:不能控制不同应用并发创建同一个客户时场景
方案2*:(细粒度)不同外部应用,同一个客户不能并发创建(同一个客户识别标识:身份证号 + 纳税人识别号)
2. 客户变更(基础变更、客户调整)接口并发控制:
方案1:(粗粒度)clientId控制同一外部应用并发访问,缺点:不能控制不同应用并发更新同一个客户时场景
方案2*:(细粒度)同一个客户不能并发进行基础信息变更、客户调整,缺点:牺牲了同一个客户实际场景中是可以同时进行基础变更、客户调整操作,造成的结果就是A客户变更、B客户调整,AB同时发起,线程快的会先进入方法,后进入的被锁住,失败访问,需要等待1-2s后进行访问
3. 客户扩充、冻结解冻、地址变更接口并发控制:
方案1*:(粗粒度)clientId控制外部应用并发访问,缺点:不能控制不同应用并发扩充、冻结解冻同一个客户时场景,回调处理新增数据时,先去校验扩充插入条目是否存在,弥补了并发导致重复扩充同一业务范围条目这种场景
方案2:(细粒度)由于是批量客户处理,无法通过客户编码等业务字段来限制并发访问
测试锁是否生效:
// 这里是对外部应用加锁,控制同一应用并发访问改接口方法
@Lock4j(keys = {"#request.clientId"})
@Override
public ServiceResponse testLock(ExtendsCustomerBusinessScopeTaskDto request) {
System.out.println("开始处理: " + request.getClientId() + " - " + LocalDateTime.now());
try {
// 模拟处理时间
Thread.sleep(2000);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("处理完成: " + request.getClientId() + " - " + LocalDateTime.now());
return ServiceResponse.success();
}
/**
预期结果1:如果加锁无效,开始处理和结束处理之间间隔2s,但同一clientid调用时间不联系,几乎是同时进行的,类似这样:
开始处理: client001 - 2024-07-13T14:31:58.451154700
处理完成: client001 - 2024-07-13T14:32:00.459919200
2024-07-13 14:32:00.549 INFO 21864 ---[tag 客户端ID:client001-]
开始处理: client001 - 2024-07-13T14:32:00.550816300
处理完成: client001 - 2024-07-13T14:32:02.555654400
2024-07-13 14:32:02.636 INFO 21864 ---[tag 客户端ID:client001-]
开始处理: client001 - 2024-07-13T14:32:02.636094400
处理完成: client001 - 2024-07-13T14:32:04.639228400
2024-07-13 14:32:04.700 INFO 21864 ---[tag 客户端ID:client001-]
开始处理: client001 - 2024-07-13T14:32:04.701772900
处理完成: client001 - 2024-07-13T14:32:06.717138300
2024-07-13 14:32:06.799 INFO 21864 ---[tag 客户端ID:client001-]
开始处理: client001 - 2024-07-13T14:32:06.799141500
处理完成: client001 - 2024-07-13T14:32:08.803225
预期结果2:如果加锁有效,开始处理和结束处理之间间隔2s,且同一clientid调用时间是连续的,类似这样
开始处理: client001 - 2024-07-13T14:23:48.889049800
处理完成: client001 - 2024-07-13T14:23:50.894638100
2024-07-13 14:23:50.984 INFO 16064 --- [tag 客户端ID:client001-]
开始处理: client001 - 2024-07-13T14:23:50.992565800
处理完成: client001 - 2024-07-13T14:23:52.994213800
2024-07-13 14:23:53.088 INFO 16064 --- [tag 客户端ID:client001-]
开始处理: client001 - 2024-07-13T14:23:53.095387900
处理完成: client001 - 2024-07-13T14:23:55.096247500
2024-07-13 14:23:55.170 INFO 16064 --- [tag 客户端ID:client001-]
开始处理: client001 - 2024-07-13T14:23:55.178764600
处理完成: client001 - 2024-07-13T14:23:57.184177900
2024-07-13 14:23:57.269 INFO 16064 --- [tag 客户端ID:client001-]
开始处理: client001 - 2024-07-13T14:23:57.335996600
处理完成: client001 - 2024-07-13T14:23:59.341987300
实际测试结果:预期结果2,加锁有效
*/
模拟多线程并发场景的2种方式:
方式1:postman多线程并发测试
方式2:代码对任务多线程同时调用
// 应用启动main方法
@EnableOpenApi("matrix-mdm")
@EnableMatrixFeignClients
@EnableDiscoveryClient
@EnableMatrixResourceServer
@SpringBootApplication
public class App {
public static void main(String[] args) {
SpringApplication.run(App.class, args);
// lock4j分布式锁控制方法并发有效前提:线程必须通过Spring管理的bean来访问方法,否则加锁无效
TnCustomerManagementService tnCustomerManagementServiceImpl = (TnCustomerManagementService) SpringReflectUtils.getBean("tnCustomerManagementServiceImpl");
ExtendsCustomerBusinessScopeTaskDto request = new ExtendsCustomerBusinessScopeTaskDto();
request.setClientId("client001");
Runnable task = () -> tnCustomerManagementServiceImpl.customerBusinessScopeExtendsTask(request);
new Thread(task).start();
new Thread(task).start();
new Thread(task).start();
new Thread(task).start();
new Thread(task).start();
}
}
// spring管理的bean的内部方
// 请求超时时间设置为30s, 多线程并发时,第一个线程拿到锁,执行中,第二个线程获取不到锁,直接报错,reqire fail, 想要看到完整5个线程并发控制后,串行打印出梳理时间信息,就需要放大点请求超时时间 >= 5个并发线程处理时间总和
@Lock4j(keys = {"#request.clientId"}, acquireTimeout = 30000L)
@Override
public ServiceResponse customerBusinessScopeExtendsTask(ExtendsCustomerBusinessScopeTaskDto request) {
System.out.println("Thread " + Thread.currentThread().getName() + "开始处理: " + request.getClientId() + " - " + LocalDateTime.now());
try {
// 模拟处理时间
Thread.sleep(2000);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("Thread " + Thread.currentThread().getName() + "处理完成: " + request.getClientId() + " - " + LocalDateTime.now());
return ServiceResponse.success();
}
事务处理
目的:
为了避免多条数据库SQL操作中间异常时,数据已被插入正式表,但是业务已经执行不下去,再次执行时,就会发生数据已存在的代码校验死锁卡住。
考虑事务控制思路:
- 多个SQL操作要么都发生,要么都不发生
- 不数据回滚导致业务重复校验死锁、业务不能操作下去
解决方案:
异常回滚处理场景:
-
扩充、地址新增:
插入正式表新条目时,根据数据条目唯一标识校验是否存在(弥补客户扩充是批量扩充接口,导致锁控制粒度只能控制在 相同应用 clientId 中,不同 clientId 并发扩充同一个业务范围数据场景控制不住),
如果存在,(原因:可能历史数据已存在、锁未并发控制不同ClientId导致审批中数据代码校验失效),直接抛出异常,将之前可能执行的新增、更新操作回滚,
这时候操作人员看到报错,去检查处理异常已存在数据后(检查记录被创建原因,处理删除数据),再次点击时业务正常进行下去
-
扩充、地址新增、变更:
执行多条SQL操作方法时,中间出现字段过长等导致插入失败时,抛出异常,事务回滚,返回操作人员看到报错,去检查处理异常(放大字段)后,继续执行下去
总结
锁控制、事务控制、异常处理,必须分析场景,再采用最优处理方案
-
sychronized 同步锁在分布式系统中不生效,需要用到分布式锁
-
加锁时,需要考虑锁的粒度。
判断条件:如果接口访问场景并发量大,考虑细粒度锁控制;如果接口访问场景并发量小,考虑粗粒度锁控制;
粗粒度锁:如访问接口的外部应用
细粒度锁:如具体接口业务功能数据判定(客户上市:身份证号、纳税人识别号来锁定唯一客户,控制类似重复点击、同一时刻创建同一客户并发访问接口,导致同一客户被创建审批数据)
-
事务控制,需要考虑到多SQL操作异常、业务数据重复异常时等,进行回滚操作;异常信息暴漏到前端,方便开发运维;
若有错误,烦请评论指正!!!