- 论坛徽章:
- 0
|
原帖由 冬瓜头 于 2010-1-11 23:22 发表 ![]()
某日我去银行存捡来的5块钱，操作员拿着我的卡和现金，鄙视的看着我，我没什么感觉，习惯了。当他刷卡之后，点击输入金额5，点击存入之后，数据发送到应用服务器，应用服务器命令数据库服务器将“余额”改为“余额+5”，并且commit。数据库服务器成功的将记录更新到了磁盘并且受到了文件系统成功写入的应答，该回复应用服务器成功的消息了，
先假定银行系统的实际内部细节是如此吧,在你这个基础上来展开讨论。
commit成功的消息到达了应用服务器的tcp协议栈缓存中，并且tcp成功的返回了一个珍贵的ack应答，数据库服务器还没收到这个ack呢，便Down机了，或者收到ack了，正要往日志里更新commit成功点了，Down机了。
你这里讨论的是TCP建立连接的三次握手吧？在你提到的以上场景，两端的Socket都还没有进入ESTABLISHED的状态，应用服务器怎么能够收到“成功”的消息呢？至少要先建立连接，然后才能传输和交互业务数据啊。
应用之间传输信息并交互，对于TCP而言，是建立在连接之上的。
如果你这里是讨论业务处理过程中的问题，那么应用协议必须要有确认报文，而不能只是依赖于底层TCP。
重启之后，当然是将这笔操作回退了，数据文件中的“余额+5”变回了“余额”。
但是就在几分钟之前，应用服务器早就把成功的消息传回给了操作员终端，我也拿着回执单走了。但是我回去一看，怎么余额没有增加？我气冲冲的找到柜台，依然是鄙视的眼光，操作员说：5块钱，至于么！
你提到的这个问题之所以有可能出现，是应用流程设计的问题：
你隐含的操作是数据库先告诉应用系统已经commit成功了然后再写日志。如果业务处理流程真如你前面所言，那么设计者实际上就应该考虑到以上可能存在的不一致的问题，那么先写日志，日志写成功以后再告诉应用不就行了？这个业务流程是你假想的，或者说是你设计的，只能说是设计上有问题。
其实你只要在端到端之间都提供可靠的应用协议，是不可能出现你说的问题。
后台数据库<-------->应用系统<-------->操作员<-------->用户
每一个环节的业务处理流程都有不可靠的因素存在，需要良好的业务设计来满足。
其实你提到的问题其本质不是机器的问题，而是你所假想的流程本身的问题，或者说是人的问题，而不是机器的问题。
[ 本帖最后由 wuqing 于 2010-1-13 08:57 编辑 ] |
|
免费注册
楼主: 冬瓜头
发表于 2010-01-12 15:29
