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

开发 前端 分布式
不知道大家有没有遇到这样的情况,就是去自动取款机取钱的时候,比如说你去取1000块钱,这个时候系统会先帮你把1000块钱扣除,然后自动取款机再把钱吐出来。但是如果取款机出现问题,会发现钱被扣了,但是钱没有取出来。在这个事情中,引发了一个对于数据一致性的思考

场景

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

[[278573]]

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

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

 

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

场景分析

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

  • 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 中用软状态和最终一致,保证了延迟后的一致性。

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

出款失败场景改造

基于理论的铺垫,我们可以思考并改造一下取款的逻辑

 

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

这个环节到这里就结束了吗?其实还没有

仅仅利用可靠性消息队列来保证数据的最终一致性还是不够的,如果消息队列本身的可靠性出现问题也会带来数据不一致问题。

所以一般的做法是,在A银行端做一个本地消息表,记录这笔消息的处理状态。然后通过定时任务来轮询消息表,来实现数据最终一致性

 

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

消息表设计

消息表中有交易必须要用到的业务字段,也有设计到消息重发的辅助字段

  • Id 交易流水号
  • status 交易状态
  • lastUpdateTime 最后更新时间

 

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

 

 

责任编辑:未丽燕 来源: 今日头条
相关推荐

2019-06-25 14:44:11

分布式事务数据库

2022-05-19 12:14:22

分布式开发框架

2017-10-24 11:39:29

银行转账数据库分布式事务

2021-07-07 10:28:09

分布式架构系统

2018-12-27 09:09:35

2019-11-04 10:37:53

MongoDB宕机日志

2022-11-29 21:26:26

跨域配置

2015-07-17 10:05:03

面试思考

2022-06-27 08:21:05

Seata分布式事务微服务

2022-11-24 17:34:04

TCC分布式

2018-08-14 09:28:40

分布式事务 ACID

2022-06-21 08:27:22

Seata分布式事务

2017-07-26 15:08:05

大数据分布式事务

2019-10-10 09:16:34

Zookeeper架构分布式

2021-11-01 17:29:02

Windows系统Fork

2021-09-29 09:07:37

分布式架构系统

2009-09-18 15:10:13

分布式事务LINQ TO SQL

2009-06-19 15:28:31

JDBC分布式事务

2022-06-27 08:36:27

分布式事务XA规范

2017-08-24 17:37:18

DNS缓存分析
点赞
收藏

51CTO技术栈公众号