銀行存錢悖論探討！�。ㄉ魅�，邏輯混亂，請看完所有樓再回帖以免越弄越亂）

冬瓜頭

原帖由 sunsroad 于 2010-1-13 12:32 發(fā)表
我到，明顯的概念混亂。

我想問一下：TCP的ack跟數(shù)據(jù)庫的commit之間有什么關系呢？TCP的ack只表示客戶端的TCP包傳輸?shù)搅朔�務器而已，跟�?shù)據(jù)庫是否commit成功根本沒有任何關系。怎么能說收到TCP ack就表明commit成功了呢？

你在客戶端所謂的commit只是個commit請求，請求發(fā)送之后，他要在這里等待server端的相應結果的，成功與否并不在這里。隨后的TCP sent及ack過程只表明你的commit請求已經(jīng)發(fā)送到了服務器端。需要server端進行真正的commit操作。如果成功，server端才會回送成功反饋，這次是client的commit需要的“ack”，此“ack”非彼“ack”，是應用層（或者說是業(yè)務層）的ack，是放在tcp有效載荷內的數(shù)據(jù)信息。這個ack開始發(fā)送的時候，client端的應用還在等待commit請求的結果信息呢。之喲client端接受到這個相應，你的存折才會打印出那個可憐的余額＋5來，所以順序很重要，不要搞顛倒。如果這個時候DB down機，TCP再怎么ack都沒有用處，client就會掛在這里等待。應用做的好的話，會在一定的時間之后超時。

過程：


你交了錢
然后等待
client |
         |
app->|->commit request->wait                                       |
         |                TCP->sent                                             |
         |                                                                 recieve |Server
         |                                                             ack<-TCP |
         |                                                             commit     |
____________________________________________你所講的步驟只到這里，如果不成功就會掛再在這里，根本你的存折沒有＋5，這個時間你還在這里等待來。再說如果數(shù)據(jù)庫down機的話，估計你也查不了你的余額了  
         |                                                  commit succesful |
         |                                                 sent<-TCP(succ)  |
app<-|recieve                                                                 |
         |TCP->ack                                                              |
         |commit request->commpleted                              |
client|                                                                            |
這個時候，你的余額加那可憐的5塊錢才能打印出來,兄弟你現(xiàn)在才能去查余額啊。之前的這段時間讓柜臺小姐幫你代勞好了。

很多時候的問題其實都是溝通問題，就像本貼中的例子。非常感謝這位兄弟的回帖，還畫了圖，我都不知道說什么好了，哎，浪費您勞動力了，是在感覺非常慚愧，不過你真的誤會我的意思了，或者是我表達有問題。其實1樓里之所以用了tcp什么ack的，只是想表達db只要收到了這個ack，就可以放心的認為成功通知到了app，但是db沒有收到。（這是原例子中的假設，后來被指出是錯誤的，db是先自己做commit之后，即便沒有成功的通知app，也不會回退了，這一點我原來搞錯了的，后面帖子都糾正了）。所以這里大可不必再纏繞在tcp層了。

bbjmmj

原帖由 冬瓜頭 于 2010-1-11 23:22 發(fā)表
以下純屬虛構如有雷同請對號入座。


某日我去銀行存撿來的5塊錢，操作員拿著我的卡和現(xiàn)金，鄙視的看著我，我沒什么感覺，習慣了。當他刷卡之后，點擊輸入金額5，點擊存入之后，數(shù)據(jù)發(fā)送到應用服務器，應用服 ...

金融交易出錯的幾率是非常高的，我自己就遇到過，前段時間買股票，不小心全倉吃進，交易無法撤銷。銀行存取款也一樣會出錯，而且錯誤還遠不止你所描述的，我記得前段時間看過一個報道，說某二人合伙利用銀行轉賬時差套現(xiàn)被抓。
但是銀行可以采用特定的“程序”來避免出錯，比如你存款的時候柜員跟你要反復核對數(shù)次才可以完成一個存單，這就等于把錯誤的概率乘方好幾次，這樣鼓搗幾下，錯誤的概率就會變得很小很小。前幾天我匯款幾萬塊錢，走了四個窗口才辦完，手續(xù)相當繁瑣，算上我等于5個人去核實這個金額，假如每人出錯的概率為百分之一，5個人都錯的概率就只有百億分之一了，這個概率甚至低于最可靠的計算機出錯的概率，所以保證正確的是人而不是電腦。
計算機不能保證交易的正確性，交易的處理需要人工核實其正確性。

hansion3406

1.調用存錢交易
2.update數(shù)據(jù)
3.commit..
4.交易收到成功
5.返回前臺
---------
6.前臺打單


沒有COMMIT成功之前,前臺是不會收到交易成功的...

興行做法....

hansion3406

如果是數(shù)據(jù)庫CORE了..
兩個機子的數(shù)據(jù)是同步的...
直接啟備機...
兩個服務器是F5做流量...

感覺像沒有出過這種問題...


其它行的做法我不知道...

但是興行的交易存錢取錢,我還沒有聽過有出現(xiàn)你這種情況的..
PS:數(shù)據(jù)庫CORE掉是不具備什么殺傷力的...

WTO432

我只知道有一個朋友在柜員機上取了一千元，吐出了一萬元，后來銀行找上門來了

morinson

別想好事

depthblue_xsc

原帖由 saintdragon 于 2010-1-13 16:40 發(fā)表
我被北京的工商銀行黑了2000大洋的
我存了2000大洋的房貸，通過ATM存入的，打印了憑條。2個月之后，我再次去存房貸，發(fā)現(xiàn)余額為0！第二天趕緊帶存折去打印，存折上沒有這筆存錢交易。而我當時從ATM打印的憑條已 ...

還有這種事情��？？太可怕了，銀行的人按理不能直接操作數(shù)據(jù)庫，流程是很嚴格的。

sunable

不見更新，不讓打票。

糊精

我覺得如果能夠接受數(shù)據(jù)庫的COMMIT機制就應當能夠理解業(yè)務的COMMIT機制。
既然顯示器、內存能夠和硬盤同步為什么遠程設備就不行了呢。

問題在于……數(shù)據(jù)庫的COMMIT機制也未必是完全原子的……

Lordaeron

DB commit 表示transaction已經(jīng)處理好了, 回應AP server 跟transaction就無關了
就算當下DB crash, 也無關於transaction,  front end 沒收到入帳成功的message 而已.
並不影響帳目. DB recover 會在check point 中找回所有已commit  的data.

so 是你的觀念有問題, 並不是存在著這樣的問題.