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

场景

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

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

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

 

场景分析

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

1. A银行同步调用B银行的远程接口来扣款，如果接口处理比较耗时或者出现网络故障时，会导致比较阻塞的时间比较长，那么对于用户的感觉就是取款机页面一直在转圈圈。

2. 当出款失败的时候，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 最后更新时间