这篇文章给大家介绍分布式事务该如何理解，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。

创新互联-专业网站定制、快速模板网站建设、高性价比杭州网站开发、企业建站全套包干低至880元,成熟完善的模板库,直接使用。一站式杭州网站制作公司更省心,省钱,快速模板网站建设找我们，业务覆盖杭州地区。费用合理售后完善，十多年实体公司更值得信赖。

1.先上场景：压力测试，同时1万个买家在店铺Shang1购买东西，每个买家账户向shang1账户付钱。
      这个例子中，有这么几个步骤：买家创建商品订单=>发送到交易系统=>交易收到支付请求创建交易订单=>判断买家账户余额是否足够=>扣除买家余额=>增加商户shang1账户余额=>记账=>返回支付成功信息。
     压力测试后，调出oracle等待事件，发现瓶颈在扣除客户余额这个步骤，明显，只有一个店铺，余额更新必须排队。1万个客户买东西可以并发买东西，扣除客户余额可以并发，但是更新店铺余额只能一个个来。怎么解决？
     解决办法：分两个步骤，第一步骤，扣除买家余额后同时增加买家冻结资金，然后马上返回提示，返回支付成功信息。但是商户没有收到钱。第二步骤，在系统低峰时期，扣除买家冻结资金=>增加商户shang1账户余额=>记账=>返回更新成功。只要提前告知商户，高峰期交易资金不是实时到账，但保证在一定时间之内结算完成，商户应该也是可以理解的。
2.场景：一台oracle数据库最多能支撑多少个连接？4000个。如果超出这些连接后怎么办还需要连接，怎么办？
       解答：把系统分成2个业务，变成2oracle 实例提供业务，就变成8000个连接，就可以了。

3.机票代理商的机票预订服务

该机票服务提供多程机票预订服务，可以同时预订多趟行程航班机票，比如从北京到圣彼得堡，需要第一程从北京到莫斯科，以及第二程从莫斯科到圣彼得堡。

当用户预订机票时，肯定希望能同时预订这两趟航班的机票，只预订一趟航班对用户来说没有意义。因此，对于这样的业务服务同样提出了原子性要求，如果其中一趟航班的机票预订失败，另外一趟需要能够取消预订。

但是，由于航空公司相对于机票代理商来说属于外部业务，只提供订票接口和取消预订接口，想要推动航空公司改造是极其困难的。因此，对于此类业务服务，可以使用补偿型 TCC 分布式事务解决方案，如下：

网关服务在原有逻辑基础上增加 Compensate 接口，负责调用对应航空公司的取消预订接口。

在用户发起机票预订请求时，机票服务先通过网关 Do 接口，调用各航空公司的预订接口，如果所有航班都预订成功，则整个分布式事务直接执行成功；一旦某趟航班机票预订失败，则分布式事务回滚，由 TCC 事务框架调用各网关的 Compensate 补偿接口，其再调用对应航空公司的取消预订接口。通过这种方式，也可以保证多程机票预订服务的原子性。

4. 场景：网站每个商品页面有个计数器，用于计算每次访问量，买家每访问一次加1.变成数据库更新的话，就会直接拖垮数据库，但是使用cache数据的话，轻松解决这个问题。

5.场景： 账务拆分的业务场景如下，分别位于三个不同分库的帐户A、B、C，A和B一起向C转帐共80元：
(1)Try：尝试执行业务。

• (2)Confirm：确认执行业务。

• (3)Cancel：取消执行业务

• 小结：到底要不要使用TCC到底要不要使用TCC事务，取决于以下几点：

• • 是否真正有保证跨应用业务操作的原子性需求。

  • 研发上能否投入资源开发相对应的TCC接口。

  • 当然还有最后一点，能否搞定一个稳定的、高可用的、扩展性强的TCC事务管理器。

         一个问题，如果TCC事务在Try阶段所有参与方(从业务服务)成功了，但是Confirm阶段部分参与方(从业务服务)成功，如何处理？

6.支付宝是怎么诞生的？
在架构的进化过程中，业务的进化也非常迅猛。最早的时候，买家打钱给卖家都是通过银行转账汇款，有些骗子收了钱却不发货，干脆逃之夭夭。这是一个很严重的问题，一个人这么干了之后，很快就有更多的人学会了（这就是传说中的“病毒传播”）。然而魔高一尺，道高一丈，淘宝网这伙人开始研究防骗子的解决方案，他们看了PayPal的支付方式，发现不能解决问题。研究了类似QQ币的东西，想弄个“淘宝币”出来，发
现也不行。后来这几个聪明的脑袋把这些想法糅合起来，突然想到了“担保交易”这种第三方托管资金的办法。于是在2003年10月，淘宝网上线了一个功能，叫做“安全交易”，卖家如果选择支持这种功能，买家就会把钱交给淘宝网，等他收到货之后，淘
宝网再把钱给卖家，这就是现在的“支付宝”。这个功能最早是让卖家可选的，因为这会延迟他收款的周期。但一旦卖家用了这个之后，就发现交易量猛增，一年之后，几乎所有的卖家都选择担保交易，到后来干脆所有的交易都必须走担保交易。在2012年
支付宝的年会上，支付宝公布2011年的交易笔数已经是PayPal的两倍。这个划时代的创新，其实就是在不断思索过程中的一个灵光乍现.

7.我看这张图，来来回回研究好多次，终于明白了分布式事务全局


关于分布式事务该如何理解就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。


网页题目：分布式事务该如何理解
当前链接：http://mzwzsj.com/article/gogdoh.html