原帖由 xdsnet 于 2010-1-14 14:28 发表 http://bbs.chinaunix.net/images/common/back.gif
这样一个场景：
服务器端已经提交，刚开始打印存单时柜员机掉电怎么办？
或者
自动取款机取钱时，服务器已经提交，刚准备数钱给你时，atm机断电怎么办？
或者
......
这个是很很很常见的，
第一个，柜员再次签到都会核对上笔账务正确处理与否，如果是本行内业务，直接查看客户交易流水，如果是异地或者跨行业务，请清算中心帮忙查询交易是否成功。成功的话，补打单据，不成功的话，再次交易。作为数据处理中心，因为没有收到客户端的应答，虽然交易成功，也会记录下log备查。
第二个，ATM和前置服务器都必须同步后才会数钱，否则，不吐钞。你说的这种情况一般会自动冲账。
先顶在看
lz的问题其实就是简单确认方式无法保证数据完整性的问题
三次确认是可以保证完整性问题的
三次确认也是银行系统、数据库系统等事务机制的基础
A->QUEST->B
B->ASK->A
A->ASK FOR ASK ->B
B->EXEC
你认为银联终端会直接操作数据库么。
我认为不会。
所以，这种情况，不会发生。
银联终端如果发生网络问题，那应该有数据同步机制。
总而言之：
1、后端只负责数据验证、数据保存及数据同步的工作。
2、前后端有相当好的容错处理，甚至有临时业务的处理机制，待前台业务真正成功时，该笔业务才从临时业务转入业务表中。
坑王！^_^
这贴子越看越乱。封拉吧
呼呼:em09:
原帖由 冬瓜头 于 2010-1-12 08:57 发表 http://bbs.chinaunix.net/images/common/back.gif
不管是哑终端还是智能终端，哑终端就能避免这个问题了么？请教楼上怎么避免的呢？
有人在另一个论坛说："或者收到ack了，正要往日志里更新commit成功点了，Down机了" 这个不可能，数据库把commit写入日至之前不可能给app发出成功的消息。
我的回答：
呵呵，首先感谢各位的关注，这确实不是什么悖论，只是吸引点眼球罢了，不必太多心。
至于步骤有错，3楼和5楼的结论是因果关系，如果我能退出3楼结论也一样会造成问题的话呢？如果说db在没有给app回复的情况下就先写入commit点，那么如果是取钱，我取走了，你余额降低了，但是打算给app回复的瞬间，链路中断或者db down，那么操作员就会认为钱没有取走，db重启后，操作员再次重试，由于操作员刚才和现在都没有对余额的变化关注过，所以再次取走了钱，也就是说，db中钱被降低数值两次，而你拿到手的钱和回执单却只有一次，损失谁来给？
而且这是银行，有回执单可以作证，如果是没有回执单的应用呢？down个机就丢一些数据，链路中断也可能丢一些数据，真不知道这样怎么行呢？
各位，这个问题我是演绎了很长时间的，我是来请大家帮忙推翻我的结论的，如果能推翻万事大吉，如果不能推翻，现实中是如何解决这的问题的呢？多谢多谢！
重复事务不做控制吗？
我是进来被洗脑的。@_@
= =如果设备本身不可靠的话 那我们现在做的很多应用 都是不可靠的
像银行这种系统肯定还是要靠 人为来干预的