面试官问分布式事务，我这样回答，他当场想给40k，分享核心知识点

有一次我去面试，面试官问了我一个挺常见但很重要的问题：分布式事务。我把我了解的东西讲了一遍，结果面试官听完后，直接说如果我愿意，可以给到40k的月薪。我后来回想，可能是因为我讲得比较实在，没有用太多专业名词，而是把核心道理说清楚了。今天我就把这些干货分享出来，希望能帮到大家。

分布式事务到底是什么

想象一下，你在一家电商网站买东西。你下单后，系统需要做几件事：从你的账户里扣钱，给商家的账户加钱，还要记录这笔订单。如果这些操作都在同一台电脑上的同一个数据库里完成，那很简单，要么全成功，要么全失败。但现实中，这些操作可能分散在不同的电脑上，甚至在不同的地方：扣钱的服务在一台服务器，加钱的服务在另一台，订单服务又在第三台。这就是分布式系统。分布式事务，就是要保证这一系列分散的操作，要么全部成功，要么全部失败，就像它们是一个整体一样。

核心的解决思路

要解决这个问题，人们想出了几种主要的办法。第一种叫两阶段提交。这就像一群人要一起做决定，有一个协调者。协调者先问大家：“你们准备好了吗？”每个人都检查自己能不能做，然后回复“准备好了”或“不行”。如果所有人都说准备好了，协调者就说：“好，那现在大家一起执行！”然后大家各自执行操作，再告诉协调者“完成了”。如果中间有人失败，协调者就让所有人撤销之前做的。这个方法比较可靠，但速度慢，而且如果协调者出问题，整个系统可能会卡住。

第二种思路叫补偿事务，也叫TCC。TCC是Try、Confirm、Cancel的缩写。它把每个操作分成三步：先尝试，再确认，如果不行就取消。还以买东西为例，第一步Try：先暂时冻结你的钱，暂时锁定商家的收款，暂时生成一个订单草稿。如果都成功了，第二步Confirm：正式扣钱，正式加钱，正式生成订单。如果中间任何一步失败，第三步Cancel：解冻你的钱，解锁商家的收款，删除订单草稿。这样每一步都是可控的，但需要每个服务都实现这三个接口，开发起来麻烦一些。

第三种思路是基于消息队列的最终一致性。这种方法不强求立刻一致，而是保证最终会一致。比如，下单后，先扣钱，然后发一个消息到消息队列，说“钱已扣，请处理后续”。加钱服务和订单服务监听这个消息，收到后再去处理。即使加钱服务暂时挂了，消息会留在队列里，等它恢复了再处理。这样系统更灵活，能应对部分故障，但会有一段时间的数据不一致（比如钱扣了，但订单还没生成），需要业务能接受这种短暂的不一致。

我的回答为什么打动了面试官

我当时没有直接背概念，而是结合了一个实际的例子。我说，比如做一个转账功能，从A银行转100块到B银行。如果用两阶段提交，就像两个银行的柜员通过一个中间人通电话，步骤严格但慢。如果用TCC，就像A银行先开一张支票，B银行确认能入账，然后双方再正式办理。如果用消息队列，就像A银行先扣钱，然后寄一封信给B银行通知它加钱，信可能晚点到，但最终会到。我强调，选哪种方法要看业务场景：对钱要求绝对准的，可以用TCC；对速度要求高、能接受短暂延迟的，可以用消息队列。

我还提到，现在很多公司其实会混着用。比如，核心的支付用TCC保证强一致性，而后续的送积分、发通知这些非核心操作，就用消息队列异步处理，保证系统整体高效。最后我说，理解分布式事务，关键是要明白没有完美的方案，都是在一致性、可用性、速度之间做权衡。面试官可能觉得我抓住了问题的本质，而且能结合实际去思考，所以给了不错的评价。