【总结】实际业务场景中锁、事务、异常如何考虑使用？

文章目录

锁处理
- 目的：
- 考虑锁控制思路：
- 生命周期接口并发控制解决方案：
- 测试锁是否生效：
- - 模拟多线程并发场景的2种方式：
事务处理
- 目的：
- 考虑事务控制思路：
- 解决方案：
总结

锁处理

目的：

为了避免接口被并发访问，导致业务数据校验（是否正式已存在、是否审批中）被迫通过，导致创建多个流程单据去新增业务数据，造成正式业务数据重复；

*代表采用应用的方案。

应用分布式锁

考虑锁控制思路：

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操作异常、业务数据重复异常时等，进行回滚操作；异常信息暴漏到前端，方便开发运维；

若有错误，烦请评论指正！！！