银行存钱悖论探讨！！（慎入，逻辑混乱，请看完所有楼再回帖以免越弄越乱）

sunsroad

原帖由 冬瓜头 于 2010-1-11 23:22 发表
以下纯属虚构如有雷同请对号入座。


某日我去银行存捡来的5块钱，操作员拿着我的卡和现金，鄙视的看着我，我没什么感觉，习惯了。当他刷卡之后，点击输入金额5，点击存入之后，数据发送到应用服务器，应用服 ...

我到，明显的概念混乱。

我想问一下：TCP的ack跟数据库的commit之间有什么关系呢？TCP的ack只表示客户端的TCP包传输到了服务器而已，跟数据库是否commit成功根本没有任何关系。怎么能说收到TCP ack就表明commit成功了呢？

你在客户端所谓的commit只是个commit请求，请求发送之后，他要在这里等待server端的相应结果的，成功与否并不在这里。随后的TCP sent及ack过程只表明你的commit请求已经发送到了服务器端。需要server端进行真正的commit操作。如果成功，server端才会回送成功反馈，这次是client的commit需要的“ack”，此“ack”非彼“ack”，是应用层（或者说是业务层）的ack，是放在tcp有效载荷内的数据信息。这个ack开始发送的时候，client端的应用还在等待commit请求的结果信息呢。之哟client端接受到这个相应，你的存折才会打印出那个可怜的余额＋5来，所以顺序很重要，不要搞颠倒。如果这个时候DB down机，TCP再怎么ack都没有用处，client就会挂在这里等待。应用做的好的话，会在一定的时间之后超时。

过程：


你交了钱
然后等待
client |
         |
app->|->commit request->wait                                       |
         |                TCP->sent                                             |
         |                                                                 recieve |Server
         |                                                             ack<-TCP |
         |                                                             commit     |
____________________________________________你所讲的步骤只到这里，如果不成功就会挂再在这里，根本你的存折没有＋5，这个时间你还在这里等待来。再说如果数据库down机的话，估计你也查不了你的余额了
         |                                                  commit succesful |
         |                                                 sent<-TCP(succ)  |
app<-|recieve                                                                 |
         |TCP->ack                                                              |
         |commit request->commpleted                              |
client|                                                                            |
这个时候，你的余额加那可怜的5块钱才能打印出来,兄弟你现在才能去查余额啊。之前的这段时间让柜台小姐帮你代劳好了。


注：过程中可能还有很多次的TCP ack ，忽略不计了

[ 本帖最后由 sunsroad 于 2010-1-13 12:35 编辑 ]

sunsroad

恢复一个图片，一看就明白了
file:///C:/Documents%20and%20Settings/simple.chen/My%20Documents/%E5%AD%98%E6%AC%BE.jpg
file:///C:/Documents%20and%20Settings/simple.chen/My%20Documents/%E5%AD%98%E6%AC%BE.jpg

solobaba

[quote]原帖由 sunsroad 于 2010-1-13 13:23 发表
恢复一个图片，一看就明白了
file:///C:/Documents%20and%20Settings/simple.chen/My%20Documents/%E5%AD%98%E6%AC%BE.jpg
file:///C:/Documents%20and%20Settings/simple.chen/My%20Documents/%E5%AD%98%E6% ... [/quote】

这样让我思路开阔啊。

unicom_2

银行出错不是很常见的吗 ?

saintdragon

我被北京的工商银行黑了2000大洋的
我存了2000大洋的房贷，通过ATM存入的，打印了凭条。2个月之后，我再次去存房贷，发现余额为0！第二天赶紧带存折去打印，存折上没有这笔存钱交易。而我当时从ATM打印的凭条已经找不到了。根本也无从投诉！
这个不是工行的系统有BUG，就是真的被工行的人黑了。把DB中的交易记录都彻底的删除了！

spook

原帖由 冬瓜头 于 2010-1-13 08:45 发表
例子中的终端一词就是指这个啊，不管是智能终端还是io终端。

那就不存在你说的问题啊……

只可能 存完了，返回时候中间断了，发现没存上，再提交，一样的流水号，chksum ok  返回成功。

spook

楼上很多人 把应用层的数据 拿到 网络层来说……  你们说的是什么啊

xieweihua

对于银行是否每天晚上都会盘点每天的工作。
然后对帐，如果帐帐不服,帐实不服，是会处理的。
以前有一哥们儿，去储蓄所存钱，结果银行就多存了。
你知道银行最后是如何处理的吗。直接没有通知那哥们儿的情况下
在帐上扣了。别忘记还有个中国特色的银行的霸王合同只是针对储户的。

也认为冬瓜头这个说法是有道理的。毕竟系统不能解决所有问题。

冬瓜头

原帖由 spook 于 2010-1-13 19:11 发表


那就不存在你说的问题啊……

只可能 存完了，返回时候中间断了，发现没存上，再提交，一样的流水号，chksum ok  返回成功。

如果此时操作员并未查看余额情况， 只记得刚才断了，再来一次，可能外面排了几十个人，没心思再去仔细核对了，其实刚才已经存成功了，而此时又存了一遍，这依然有问题啊。

wfcjz