分布式事务之TCC方案实践

本文深入探讨了分布式系统中的最终一致性理论,包括CAP和BASE理论。接着,详细介绍了TCC(Try-Confirm-Cancel)方案,阐述其在确保分布式事务最终一致性中的作用,以及在一个具体的客服系统销户功能中的实践案例。文章最后提到了TCC方案的局限性和实施时的注意事项,强调了幂等性和资源管理的重要性。
摘要由CSDN通过智能技术生成

摘要

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

最终一致性理论

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

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

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

如果你想搞明白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(CloseAcc
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值