网站建设资讯

NEWS

网站建设资讯

分布式事务该如何理解

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

创新互联-专业网站定制、快速模板网站建设、高性价比杭州网站开发、企业建站全套包干低至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://cdweb.net/article/gogdoh.html