分布式事务之TCC方案实践

矫情吗；* 2024-04-19 06:52 88阅读 0赞

## 摘要 ##

分布式系统间交互主要有同步的远程调用和异步的消息传递。本位主要讨论**同步远程调用**的方式中，如何保证调用系统A和被调用系统B间状态的最终一致。

### 最终一致性理论 ###

CAP理论是分布式计算领域的公认定义，2007年由加州伯克利分校的Eric Brewer教授首次提出。内容是：

> 一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。

*  一致性：更新操作完成后，所有节点在同一时间数据是一致的
 *  可用性：服务一直可用，而且是正常响应时间
 *  分区容错性：分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务

如果你想搞明白CAP理论的正确性，参考[CAP理论证明][CAP]

三选二需要做出取舍，eBay的架构师Dan Pritchett提出的BASE理论是目前分布式系统主流的取舍方式。BASE理论是对CAP中一致性和可用性权衡的结果，核心思想是：即使无法做到强一致性，每个应用可以根据自身业务特点采用合适方式，达到最终一致性。主要三个特性：

*  基本可用(Basically Available): 允许损失部分可用性，即保证核心可用
 *  软状态(Soft State): 允许系统数据有中间状态，并认为中间状态不影响可用性，即允许系统中不同节点的数据副本在同步时存在延时
 *  最终一致性(Eventual Consistency): 所有数据副本在经过一段时间的同步过程，最终能在某个时间达到一致性

## 分布式事务的TCC方案 ##

TCC方案是通过补偿机制来达到最终一致性的，核心思想是：针对每个操作，都要提供与之对应的确认和补偿（撤销）操作。它分为三个阶段：

*  Try: 对系统做检测及资源预留
 *  Confirm: 业务系统确认提交
 *  Cancel: 业务操作执行错误，需要回滚是执行的撤销操作

## TCC方案实践 ##

### 场景描述 ###

我所在团队开发的一个客服系统中有一个销户功能，热线客服可以帮助有销户需求的客户执行销户操作。我司远程调用使用DUBBO，完成这个功能客服系统需要调用另一个团队的账户系统的注销账户服务。

### TCC方案设计 ###

账户系统的注销账户服务定义如下接口：

public class CloseAccountService { 
    	// 校验能否注销(try)
    	public CloseAccountResponse validate(CloseAccountRequest request);
    	// 冻结账户（try）
    	public CloseAccountResponse freeze(CloseAccountRequest request);
    	// 注销账户（confirm）
    	public CloseAccountResponse close(CloseAccountRequest request);
    	// 解冻账户(cancel)
    	public CloseAccountResponse release(CloseAccountRequest request);
    }

补偿的逻辑在客服系统中实现：

public class CustomAccountService { 
    	@Autowired
    	private CloseAccountService closeAccountService;
    	//...
    	public OperationResponse handleCloseAccountOperation(String custId, String operatorId) { 
    		//省略准备Request
    		...
    		// 先校验能否注销，主要看账户有无欠款或余额
    		try{ 
    			CloseAccountResponse response = closeAccountService.validate(request);
    		}catch(Exception e){ 
    			log.error('销户失败，validate过程出现异常',e);
    			return OperationResponse.builder().errMsg("销户失败，请联系管理员");
    		}
            if(!response.canClose) { 
            	return OperationResponse.builder().errMsg(response.message);
            }
    
    		// 账户满足销户条件，先冻结账户
    		try { 
    			closeAccountService.freeze(request);
    		}catch(Exceptino e) { 
    			log.error('销户失败，freeze过程出现异常',e);
    			return OperationResponse.builder().errMsg("销户失败，请联系管理员");
    		}
    		
    		// 确认销户
    		try{ 
    			closeAccountService.close(request);
    			// 销户成功
    			return OperateResponse.builder().success(true);
    		}catch(Exceptino e) { 
    			// 销户失败,解冻账户
    			log.error("销户失败，close过程出现异常",e);
    			try{ 
    				closeAccountService.release(request);
    			}catch(Exception e1) { 
    				// 解冻失败，需要人工干预
    				log.error("release过程出现异常",e);
    				return OperationResponse.builder().errMsg("销户失败，账户当前状态冻结，请联系管理员处理");				
    			}
    		}
    	}
    }

### 局限性 ###

上面的实现是一个简易版的TCC实现，前提是不考虑在执行上面TCC逻辑的时候不会出现客服系统宕机，如果要考虑这个则需要更复杂的TCC状态日志记录及恢复功能；或者参与销户的业务除了客服系统以来账户系统，账户系统还依赖第三个系统，则逻辑就更复杂了。这事你就需要引入TCC框架，国内开源的有[ByteTCC][]、[tcc-transaction][]等。

## 总结 ##

TCC方案使用补偿的思想来实现分布式事务，达到最终一致性的目的。需要将某个业务操作拆成3个阶段，各阶段要求如下：

Try阶段：尝试执行业务

> 1，完成所有业务检查  
> 2，预留必须业务资源

Confirm阶段： 确认执行业务

> 1，不做任何业务检查，真正执行任务  
> 2，只使用Try阶段预留的业务资源  
> 3，保证confirm操作的幂等性

Cancel阶段：取消执行（补偿、回滚）

> 1，释放try阶段预留的资源  
> 2, 保证cancel操作的幂等性

[CAP]: http://www.hollischuang.com/archives/666
[ByteTCC]: https://github.com/liuyangming/ByteTCC
[tcc-transaction]: https://github.com/changmingxie/tcc-transaction