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

冬瓜头

我动嘴之前都动脑的，你还是自己提醒自己吧。

bbjmmj

原帖由 冬瓜头 于 2010-1-19 20:01 发表
我动嘴之前都动脑的，你还是自己提醒自己吧。

你根本就没动脑子，你到现在还没理解我前面提到的“交易”是个什么东西。我打个简单点的比方，可能有助于你理解什么是“交易”。
假如，你要娶媳妇了，要买房子，我正巧有闲房，还很便宜，于是你决定跟我做一笔交易，买下我的房子，然后我也同意买给你了，我们可以进行这笔交易了。然后，我带着房本儿你带着钱，咱俩就见面了，你把钱给我，我把房本儿给你。
你觉得这样交易可以吗？我要是忘了给你房本可就白拿你房钱了，你可一定得想好了，此外你还得小心我拿身份证去挂失房本，那你可就钱房两空了。
真正的房屋交易要到房地产市场去办理，至少要有三方参加：你、我、还有房管局，然后还需要N多手续并且这些手续都得没问题了才可以交易，房管局还要给你发新的房本儿，你这房子才算买下。这就是我所说的“交易”。
你可以想象这样一笔交易，如果其中的若干环节出了问题，比如你忘了带钱，或者我忘了带房本儿，又或者咋俩谁去房管局的途中丢了身份证，再或者赶上双休日人家房管局放假，等等，随便哪个状况，你我之间的交易都无法完成。
银行也是这么干的，多个环节确保交易正确。
“交易”是本贴内容最基础的概念，再多动点脑筋想明白了再做评判不迟。

sky-鹏

我是看热闹的～

bbjmmj

此论坛号称中国最高水平的存储论坛，应该说这里有全国最优秀的技工，但是楼主提出的却是一个需要工程师来解决的问题。工程师常因为单项技能不如技工而被技工嘲笑，所以工程师跟技工的沟通也就经常出现问题，这也就是我在本版被当成胡乱说话的外行的原因。

如果能同时了解OLTP系统的流程设计、软件开发和运行维护三个部分，冬瓜头这个问题就不难解决，一个交易程序性的问题，交易流程怎么制定的，冬瓜头只是看到了柜台部分，对电脑部分的流程一无所知，难免会产生偏差。一般来说，能够同时接触到OLTP这三个部分的人主要是当过基层网管，做过OLTP，并且能深入探究OLTP可靠性问题的人。

从我对银行系统了解的信息来看，银行系统那个架构，对于小单位应用系统，它成本太高，对于稍大些的开放型系统，它又不够安全，所以本贴内容应该跟我的工作范围无关，我看热闹，你们聊。

为什么删我号

来学习的飘过   此帖要火

无牙

已经过100了！

habyfeng

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

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

fhbkyo

无知的群众围观

bbjmmj

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

无牙

大师这么晚还在回帖！