我对分布式事务理解--创新就在遇到看似不可解决问题时候的灵关闪现

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：尝试执行业务。

• 完成所有业务检查(一致性)：检查A、B、C的帐户状态是否正常，帐户A的余额是否不少于30元，帐户B的余额是否不少于50元。
  
• 预留必须业务资源(准隔离性)：帐户A的冻结金额增加30元，帐户B的冻结金额增加50元，这样就保证不会出现其他并发进程扣减了这两个帐户的余额而导致在后续的真正转帐操作过程中，帐户A和B的可用余额不够的情况。

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

• 真正执行业务：如果Try阶段帐户A、B、C状态正常，且帐户A、B余额够用，则执行帐户A给账户C转账30元、帐户B给账户C转账50元的转帐操作。
  
• 不做任何业务检查：这时已经不需要做业务检查，Try阶段已经完成了业务检查。
  
• 只使用Try阶段预留的业务资源：只需要使用Try阶段帐户A和帐户B冻结的金额即可。

(3)Cancel：取消执行业务

• 释放Try阶段预留的业务资源：如果Try阶段部分成功，比如帐户A的余额够用，且冻结相应金额成功，帐户B的余额不够而冻结失败，则需要对帐户A做Cancel操作，将帐户A被冻结的金额解冻掉。

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

• 是否真正有保证跨应用业务操作的原子性需求。
• 研发上能否投入资源开发相对应的TCC接口。
• 当然还有最后一点，能否搞定一个稳定的、高可用的、扩展性强的TCC事务管理器。

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

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

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

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/30393770/viewspace-2151635/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/30393770/viewspace-2151635/