设为首页 - 加入收藏 定西365英超体育在线投注_365体育投注分别_365体育投注平台盘口 (http://www.0932zz.com)- 国内知名站长资讯网站,提供最新最全的站长资讯,创业经验,网站建设等!
热搜: 2017 平台 为什么 芯片
当前位置: 首页 > 运营中心 > 建站资源 > 优化 > 正文

一次跨行取款失败,而引发对分布式事务的思考

发布时间:2019-10-11 15:04 所属栏目:[优化] 来源:IT知识课堂
导读:场景 不知道大家有没有遇到这样的情况,就是去自动取款机取钱的时候,比如说你去取1000块钱,这个时候系统会先帮你把1000块钱扣除,然后自动取款机再把钱吐出来。但是如果取款机出现问题,会发现钱被扣了,但是钱没有取出来。我第一次遇到这个问题的时候很

场景

不知道大家有没有遇到这样的情况,就是去自动取款机取钱的时候,比如说你去取1000块钱,这个时候系统会先帮你把1000块钱扣除,然后自动取款机再把钱吐出来。但是如果取款机出现问题,会发现钱被扣了,但是钱没有取出来。我第一次遇到这个问题的时候很担心,当时跨行取取了3000块钱,短信提醒我钱已经被扣了,但是钱没取出来,于是准备去找柜台帮忙处理的时候,手机上又收到一笔交易提醒,提示钱被退回来了!

一次跨行取款失败,而引发对分布式事务的思考

在这个事情中,引发了一个对于数据一致性的思考

基于整个资金处理链路的体验,大概的流程是这样:

一次跨行取款失败,而引发对分布式事务的思考

场景分析

如果真实的场景是如我这个图所画的那样的话, 会存在几个问题

  • A银行同步调用B银行的远程接口来扣款,如果接口处理比较耗时或者出现网络故障时,会导致比较阻塞的时间比较长,那么对于用户的感觉就是取款机页面一直在转圈圈。
  • 当出款失败的时候,A银行的本地交易表状态改成了4出款失败,并且同步调用B银行的接口把扣减的3000元回滚。如果回滚失败,就会导致用户的钱被扣了,但是没有取出现金来。

远程接口的异步调用

对于第三方的调用,并且对性能有一定要求的流程中,一定不能用同步的方式。所以我们通过异步化改造一下第一个流程

异步流程的话,我之前做支付业务的时候,是这么做的

A银行调用B银行的接口,引入了一个异步消息队列,把所有的交易指令直接丢给消息队列异步去处理。B银行收到指令执行完以后,再通过

http协议把结果写回给A银行

一次跨行取款失败,而引发对分布式事务的思考

出款失败的数据回滚

我们先不管方案引入以后会带来哪些问题,我们先把原来的问题解决掉。

当取款机出款失败的时候,这笔交易要回滚。按照上面的图来看,实际上就存在一个数据一致性问题,也就是交易记录表要记录这笔交易是失败的,并且

要把这笔钱退回到账户上。这种一致性问题实际上就是大家所说的分布式事务问题

分布式事务问题也叫分布式数据一致性问题

其实在分布式架构中,分布式事务问题,是非常常见的问题。既然是常见,那肯定会有解决办法。这里我并不打算展开他的各种解决方案,给大家讲讲

架构思维层面的东西

首先我们知道数据库事务会满足ACID特性:

  • 原子性(A);
  • 一致性(C);
  • 隔离性(I);
  • 持久性(D);

而在这四大特性中,一致性是最基本的特性,其它的三个特性都为了保证一致性而存在的!

而在分布式场景中,这种单库事务就没什么意义了。

分布式场景中的事务一致性方案

在分布式架构中,有很多种解决一致性问题的方案,比如TCC(事务补偿)、比如基于可靠性消息的最终一致性、比如基于2pc协议的强一致性、

对于很多中间件里面的一致性协议,有paxos、Raft等算法 ;这些大家都可以自己去看看

我们前面说过,在分布式架构下,分布式事务的问题是很常见的。所以目前市面上提供的解决方案也比较多。那么这里就涉及到两个概念

  • 一个是强一致性、 一个是弱一致性

所谓的强一致性,就是保证跨节点的数据的强一致,要么同时成功,要么同时失败

而所谓的弱一致性,其实就是一种最终一致性,

CAP和BASE

强一致性和弱一致性有什么区别,或者对系统会产生什么样的影响呢?我们来分析一下

CAP 定理,又被叫作布鲁尔定理。对于设计分布式系统(不仅仅是分布式事务)的架构师来说,CAP 就是你的入门理论。

1.C (一致性):对某个指定的客户端来说,读操作能返回最新的写操作。对于数据分布在不同节点上的数据来说,如果在某个节点更新了数据,那么在其他节点如果都能读取到这个最新的数据,那么就称为强一致,如果有某个节点没有读取到,那就是分布式不一致。

2.A (可用性):非故障的节点在合理的时间内返回合理的响应(不是错误和超时的响应)。可用性的两个关键一个是合理的时间,一个是合理的响应。

合理的时间指的是请求不能无限被阻塞,应该在合理的时间给出返回。合理的响应指的是系统应该明确返回结果并且结果是正确的

3.P (分区容错性):当出现网络分区后,系统能够继续工作。打个比方,这里集群有多台机器,有台机器网络出现了问题,但是这个集群仍然可以正常工作。

熟悉 CAP 的人都知道,三者不能共有,因为在分布式系统中,网络无法 100% 可靠,分区其实是一个必然现象。

如果我们选择了 CA 而放弃了 P,那么当发生分区现象时,为了保证一致性,这个时候必须拒绝请求,但是 A 又不允许,所以分布式系统理论上不可能选择 CA 架构,只能选择 CP 或者 AP 架构。

对于 CP 来说,放弃可用性,追求一致性和分区容错性。

对于 AP 来说,放弃一致性(这里说的一致性是强一致性),追求分区容错性和可用性,这是很多分布式系统设计时的选择,后面的 BASE 也是根据 AP 来扩展。

BASE 是 Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent (最终一致性)三个短语的缩写,是对 CAP 中 AP 的一个扩展。

  • 基本可用:分布式系统在出现故障时,允许损失部分可用功能,保证核心功能可用。
  • 软状态:允许系统中存在中间状态,这个状态不影响系统可用性,这里指的是 CAP 中的不一致。
  • 最终一致:最终一致是指经过一段时间后,所有节点数据都将会达到一致。

BASE 解决了 CAP 中理论没有网络延迟,在 BASE 中用软状态和最终一致,保证了延迟后的一致性。

对于互联网公司,用户体验是最重要的,所以为了避免强一致带来的阻塞,会采用最终一致性方案来解决数据一致性问题。而用得比较多的都是基于本地消息表+异步队列 以及基于可靠性消息队列来实现最终一致性方案

出款失败场景改造

【免责声明】本站内容转载自互联网,其相关言论仅代表作者个人观点绝非权威,不代表本站立场。如您发现内容存在版权问题,请提交相关链接至邮箱:bqsm@foxmail.com,我们将及时予以处理。

网友评论
推荐文章