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

冬瓜头

以下纯属虚构如有雷同请对号入座。


某日我去银行存捡来的5块钱，操作员拿着我的卡和现金，鄙视的看着我，我没什么感觉，习惯了。当他刷卡之后，点击输入金额5，点击存入之后，数据发送到应用服务器，应用服务器命令数据库服务器将“余额”改为“余额+5”，并且commit。数据库服务器成功的将记录更新到了磁盘并且受到了文件系统成功写入的应答，该回复应用服务器成功的消息了，commit成功的消息到达了应用服务器的tcp协议栈缓存中，并且tcp成功的返回了一个珍贵的ack应答，数据库服务器还没收到这个ack呢，便Down机了，或者收到ack了，正要往日志里更新commit成功点了，Down机了。重启之后，当然是将这笔操作回退了，数据文件中的“余额+5”变回了“余额”。但是就在几分钟之前，应用服务器早就把成功的消息传回给了操作员终端，我也拿着回执单走了。但是我回去一看，怎么余额没有增加？我气冲冲的找到柜台，依然是鄙视的眼光，操作员说：5块钱，至于么！

兄弟们，你说这5块钱，我是要还是不要呢？

本贴另一个instance：
http://www.itpub.net/viewthread. ... p;extra=&page=1

-------------------------------------------------
例子中有一步是错误的，即db必须commit之后才会返回给操作端。所以在此对这个错误引来的不便表示歉意。而且我绝对不是在对db本身的机制质疑，二是对整体流程方面有疑问。其次，本贴确实不是什么悖论，用这个词只是为了吸引个眼球，如果觉得碍眼，请多担待。

更正一下。
如果是存钱，出现这个问题，你就赚了，相当于拿了一笔现金，操作员重复操作给存了两笔、
如果是取钱，你就亏了，重复操作的结果就是取了两次而你只拿到一笔钱。
初步讨论的结果，这种情况下人的因素很重要，要靠人来解决。
-------------------------------------------------

[ 本帖最后由 冬瓜头 于 2010-1-14 16:01 编辑 ]

mordorwww

sunsroad 发表于 2010-01-13 12:32
我到，明显的概念混乱。

我想问一下：TCP的ack跟数据库的commit之间有什么关系呢？TCP的ack只表示 ...

tcp的ack应用层看不到
需要应用层自己来ack

mordorwww

在灾难面前，原子操作是不存在的。批准冬瓜。

冬瓜头

8年后再将这贴顶起来，依然值得研究。详见鄙人大话存储公众号中的“原子写，什么鬼一文，底层机制非常复杂，数据库本身并不能严格保证数据的一致性，丢数据在所难免，这就是为什么it设备害怕突然把电的原因。不服来辩，注意，没点功力小心被鄙人碾压成抑郁症。

solobaba

呵呵，顶。放假不好过

无牙

原帖由 bbjmmj 于 2010-1-27 12:12 发表


放寒假了。

这回儿有时间了，可以多来灌灌水！

bbjmmj

原帖由 无牙 于 2010-1-27 00:04 发表
大师这么晚还在回帖！

放寒假了。

无牙

大师这么晚还在回帖！

bbjmmj

最简单的银行系统是主机+哑终端结构的，数据库和银行交易软件就在主机上跑，结构很简单。主机上的交易软件通过哑终端读取柜员输入的数据，再通过终端将信息回馈给哑终端以完成主机与终端之间的交互。交易软件直接控制所有的哑终端，收集哑终端上的输入，并将数据写入数据库。为了安全起见，银行主机上的数据库提供一种称为“事务”的功能，柜台上的操作会被转换成一系列的查询语句，这些查询语句以“事务”的形式提交给数据库，数据库将这些查询语句一炮儿跑完。当事务被正确提交并处理后，交易软件将数据回馈给哑终端。在此过程中，如果“事务”不能正常提交，哑终端上将提示交易失败信息。如果“事务”顺利提交的一瞬间终端坏了，柜员可以换一台终端，查查刚才的交易有没有完成。如果数据库在提交“事务”的时候崩溃，可以重新启动数据库，重新启动数据库的过程中，柜员将无法在哑终端上看到正确的交易结果。数据库会在重启后自动进行“崩溃恢复”以确保事务的正确，“崩溃恢复”并顺利启动之后，数据库才可以为用户提供数据库服务，哑终端才能做进一步的操作。如果交易卡住了，无论何种原因，都不用怕，因为你存钱的时候，钱先交进柜台然后柜员才会操作，取钱的时候，柜员小姐是不会给你钱的，我们看，无论存钱取钱，钱都是柜员小姐拿着的，无论交易怎么卡住银行都不会损失金钱。
    复杂一些的银行系统是在前面所述最简单的银行系统之上，有一个集中的数据库为若干主机提供数据库服务，各储蓄所、支行的主机都可以直接读写这个集中的数据库，DBA会为各个主机分配不同的权限，以实现最基本的数据库安全。
    再复杂一些的银行系统就要涉及到跨储蓄所甚至是跨行之间的实时业务了，这时，出于安全性的考虑，工行的数据库绝对不会让建行的主机访问，那怎么跨行？于是一个叫做“中间层”的东西就出来了，每个主机都使用各不相同且不可伪造的数字签名跟中间层通信，那么这样就好了，工行可以直接发个带签名的交易信息给建行的中间层，工行、建行可以互相不用访问对方的数据库而只是访问彼此的中间层即可。中间层的背后既MAINFRAME，MAINFRAME不指大型机，这是个以讹传讹的误称，MAINFRAME是“核心系统”的意思，中间层可以跟“核心系统”直接通信，把数据提交给“核心系统”去处理，这样就多了一层安全屏障，有了中间层这个东西，跨储蓄所、跨行的业务就可以放心搞了。
    当然，还有更复杂、可靠性更高的OLTP架构，银行所用的架构仅仅能够达到关键事务系统中的中等可靠程度。
    最后还要提一下数据库中的“事务”。IBM、甲骨文各自花费天价攒机做性能测试，就专门测这个“事务”的处理速度，也就是TPM（每分钟交易数），他们如此折腾，到底是为了什么呢？因为银行那个业务既要保证不出错误又要降低软件代码量，就非得用“事务”不可。对于开放式的系统，尤其是数据库集群，我个人认为应该尽量避免使用“事务”，因为“事务”执行的时间较长，处理时间具有较大的不确定性，且“事务”造成拥塞的可能性远远高出普通的查询语句，换言之，“事务”降低了系统的可靠性和实时性，这对开放系统可是大大的不利，但是银行用“事务”问题就不大，因为银行那个数据量是可以确定的，而开放系统的数据量是完全无法确定的，一旦拥塞，后果将无法预料。

fhbkyo

无知的群众围观

habyfeng

放心，银行的系统没这么容易挂掉，不就5块钱么，至于吗？

能用钱解决的问题都不是问题