有谁知道银行的跨行转帐是怎么保证交易的原子性和一致性？

最近在看《Java Transaction Design Strategies》，想到了对事务要求比较严格的银行间转帐这种事务，夸行转帐是怎么保证事务的原子性和一致性呢？首先我能想到的就是使用JTA，用两阶段提交，可是仔细一想，发现还是不能完整保证：
假设转帐步骤如下：
begin jta transaction
从A行A用户扣款 －－>命名为A操作
往B行B用户存款 －－>命名为B操作
commit or rollback

由于使用了两阶段提交，所以提交事务时，将发生
prepared commit A
prepared commit B
commit A
commit B

假如在prepared都没有任何问题，然后commit A成功，commitB时发生网络故障，失败，然后试图rollback A，发现与A数据库服务器网络也在这一瞬间发生故障，那就造成了从A扣款成功，但没能往B帐号存款。


我没有任何银行项目经验，当然这都是我的想象和假设

评论

21 楼 balaschen 2007-05-10  

看来正如xiaoyu所说，最终还是要靠人来解决异常的问题

20 楼 抛出异常的爱 2007-05-10  

balaschen 写道

抛出异常的爱 写道

ATM也不是inter网。

如果在柜台操作就是内网了，柜台操作应该一样存在上面说的情况吧。

以太与ATM是两种不同的底层传输过程。。。。
不清楚柜台用的是否以太。。。。
不过ATM的帧要求比以太高的多。

19 楼 xiaoyu 2007-05-10  

关于转帐这个事, 其实更多的是法律上, 或者规范上规定得很严格(这些都是对人的, 对于失败后, 人为的处理).

所以一般转帐的系统都是挺简单的.

没有哪个系统是能保证事务完整的, 总有一些极少的情况会失败. 很多完美的词语只不过是广告.

18 楼 yumeyume 2007-05-10  

一般都用Tuxedo这种中间件去处理吧

17 楼 balaschen 2007-05-10  

抛出异常的爱 写道

ATM也不是inter网。

如果在柜台操作就是内网了，柜台操作应该一样存在上面说的情况吧。

16 楼 balaschen 2007-05-10  

lane_cn 写道

不可能靠数据库来保持事务的，一个用户转账需要好几分钟，占用一个事务，别的用户都要等，这是不可能的，数据库也没有能力支持这么多的并发连接。
只能在系统设计的时候尽量多的考虑到各种异常情况，留下记录，制定一个尽量保险的对账策略和异常处理方式，然后严格的对操作岗位进行管理。解决了这些问题，最终的正确性是有保证的。
不仅银行，电信、电力的账务也是这么干的，他们与银行的接口，还有系统内部都要考虑异常情况，每天进行对账。

是不可能靠数据库保持事务，可JTA不仅仅是数据库事务，只要支持XA的资源，就可以实现事务管理。

15 楼 抛出异常的爱 2007-05-10  

ATM也不是inter网。

14 楼 lane_cn 2007-05-10  

不可能靠数据库来保持事务的，一个用户转账需要好几分钟，占用一个事务，别的用户都要等，这是不可能的，数据库也没有能力支持这么多的并发连接。
只能在系统设计的时候尽量多的考虑到各种异常情况，留下记录，制定一个尽量保险的对账策略和异常处理方式，然后严格的对操作岗位进行管理。解决了这些问题，最终的正确性是有保证的。
不仅银行，电信、电力的账务也是这么干的，他们与银行的接口，还有系统内部都要考虑异常情况，每天进行对账。

13 楼 balaschen 2007-05-10  

抛出异常的爱 写道

出现这种可能在百万分之一以下。。。

这个数据是怎么来的 ，貌似遇到失败的兄弟还不少啊

12 楼 rainlife 2007-05-10  

balaschen 写道

也就是没办法完全保证事务的完整性喽？那是否会出现转帐失败，自己帐号上的钱也被扣了，要等银行对帐完才能恢复？我自己是没碰到过，有人碰到这种情况吗

这个我碰到过，结果只有等到银行对帐后才返回的。

11 楼 balaschen 2007-05-10  

即使是这样，银行对中心的转帐依然会失败，比如：
begin jta transaction
从A行A用户扣款 －－>命名为A操作
往中心发转帐操作请求文件 －－>命名为B操作
commit or rollback

由于使用了两阶段提交，所以提交事务时，将发生
prepared commit A
prepared commit B （发送转帐请求文件到中心，并接收到中心回应收到文件信息)
commit A
commit B （发送确认信息到中心）

在这个操作中，依然会发生 commitA成功，commitB失败

中心和各个银行间事务应该也是类似。

10 楼 抛出异常的爱 2007-05-10  

出现这种可能在百万分之一以下。。。

9 楼 balaschen 2007-05-10  

多设了个中心，主要简化的是各个银行间的协调，由多点变为单点，但中心依然是需要面对多点，也就是事务依然可能会失败，需要人工干预

8 楼 xiaoyu 2007-05-10  

至于那个中心怎么样保证它的事务完整性, 应该要看它的事务设计了.

不过有很多事都不是能完美的. 只能说99%可能就够了. 1%让人工去干预.

7 楼 balaschen 2007-05-10  

哦，原来是这样，那国内估计也是通过银联之类的第三方机构来调度吧.

6 楼 xiaoyu 2007-05-10  

5楼说的是对的. 像在美国那边, 我们是通过ACH文件来转账的, 发这个ACH文件到某个中心去, 这个中心会帮你调度等等一些东西(真正转钱的,和各银行联系的), 如果出错了, 会在几天内发一个文件回来, 如果过了这么多天都没有收到什么消息, 就默认成功了. 如果出错了, 系统之间(你的转帐系统与中心)无法配合(就是各不认错)一定的次数, 这个事就要用法律解决, 系统这间再也不会理这件事了.

5 楼 balaschen 2007-05-10  

那银行是怎么对帐的，假如说，ATM机上剩下的现钞比银行对帐的结果多，可银行不认，消费者怎么办？或者ATM机上多出来的钱被银行管ATM机的人黑了

4 楼 qingyujingyu427 2007-05-10  

我有两个同事，都曾经从中国银行的ATM机取钱，结果卡上的钱扣了，可是钱没出来。
都是等银行对完帐以后，然后再还给他们。
连本行都没保证，别说跨行了，只是失误率比较低吧。

3 楼 balaschen 2007-05-10  

也就是没办法完全保证事务的完整性喽？那是否会出现转帐失败，自己帐号上的钱也被扣了，要等银行对帐完才能恢复？我自己是没碰到过，有人碰到这种情况吗

2 楼 rtdb 2007-05-10  

握手-确认-再确认

BTW，总归会有出错的时候，一般是每天要对一次帐。