Code Bye

银行取款机的事务问题

 

你们是否遇到过去银行取款机取款的时候被扣除钱但是没有吐钱的情况.我没有遇到过这种情况,但是我听说有人遇到这种情况。
外行人看热闹,内行人看门道,一般人骂银行不负责任,咱们是搞开发的,就从开发角度分析这个问题.
其实这涉及到一个物理事务问题。通常的事务是基于数据逻辑上的,我们可以使用普通的提交 回滚方式处理它.例如转账一个减去100元,一个加上100元,提交,回滚保证它们同时进行。
但是当涉及到物理方面效果的时候就不是这么简单了,比如取款行为由下面2个事件组成:
(1)取款机吐出100元.
(2)扣除100元
假如执行过程是先1后2
第二个当然能够像普通情况下进行提交和回滚,但是关键在于第一点,那是物理效果,所谓的生米煮成了熟饭是无法被改变的。当钱被用户取走的时候,你怎么回滚?让取款机变成机器人从用户手中抢回钱?如果不回滚的话那么结果就是银行损失了100元。
当然银行喜欢调换一下顺序,变成了:
(1)扣除100元
(2)取款机吐出100元
好了取款机扣除了100元,实打实的再吐钱,对于银行那是当然没有问题了,对于用户就不妙了,如果执行了第一条,取款机突然发生故障,怎么保证第二条也被执行.
当然对于中国的一些银行来说它们的利益是必须被得到保证的,很多自然是选择了第二种顺序.不过这个顺序问题也看出了银行的态度问题,对自己责任和用户利益地对待问题。
那么怎么解决呢。我觉得没有办法完全解决这个问题,因为这个涉及到物理问题,外部物理世界是你不能改变的.
但是可以尽量减少问题发生。怎么办呢?关键在于吐出钱的过程,因为取款需要数钱需要一个时间过程,操作数据库也需要时间。不过提交事务也许不需要长时间,至少单独提交事务比执行后提交时间短,如果我们先扣钱但是不提交扣钱事务,然后吐钱,这个时候要卡住钱,用户看得见钱,但是不能取钱,只有系统提交数据改变以后,取款机才能放手。这个过程唯一有可能出错的地方就是当吐出钱以后如果断电怎么办,关键是否还能卡住钱,如果取款机松手,那么如果没有提交数据银行损失,如果取款机不松手,银行提交数据之后用户损失,感觉后者发生在最后一步,概率小,但是从责任公平角度应当由银行设计系统承担前者情况的风险.


10分
的确有道理,另外一个角度,银行要保证资金的安全,可以牺牲用户的体验。所以在出现少吐钞的情况下,能给与一定的补偿,当然是极好的

10分
做做梦就好了,你们不是生活在资本主义国家。

10分
我几年遇到过扣钱不吐钱的情况,扣钱之后我拔卡再查,钱仍然扣掉了.说明扣钱的事物已经提交.
几分钟后钱返回到卡里了,看来吐钱是另一个事物.

10分
还有种 存钱 存不上 吞钱的 。。。  这种就只能靠监控手段和小票去找回
引用 4 楼 sdweiziyu 的回复:

还有种 存钱 存不上 吞钱的 。。。  这种就只能靠监控手段和小票去找回

你说的事务应当怎么被处理?存钱估计钱是放在一个专门用于识别假钞的地方正在数钱,但是问题是识别的过程中如果出现故障,实际上钱应该是被卡在那里,还没有完全进入取款机,没有加钱,但是已经进入那里,对于用户来说就是钱已经被拿走了.我觉得数钞票的过程应当在用户面前进行,如果出现问题,用户心里还好受点,钱就在眼前。就算拿不出来,也可以通知银行。
顺便银行应当随时有值班的人员.


CodeBye 版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权 , 转载请注明银行取款机的事务问题