从光大证券的软件设计缺陷想到的。
8月16中国股市出现名震历史的乌龙事件，导致该事件的原因今天被证监会调查后，确定是软件系统的设计问题：
光大证券自营的策略交易系统存在程序调用错误、额度控制失效等设计缺陷,并被连锁触发,导致生成巨量市价委托订单,累计申报买入234亿元,实际成交72.7亿元。
根据这条信息我个人瞎胡乱猜测一下出错场景：
交易员发出买单以后，由于锁问题，无论是语言内存锁或数据库锁，导致买入状态没有更新，或者交易员点按“买入”按钮时，没有响应，不由自主多按了几下，结果，这些命令恰恰全部被计算机系统都接受，只是因为锁堵塞，没有及时处理，没有及时更新状态，等系统稍微空闲，这些被锁住的交易全部被执行。
这个问题有点类似“重复提交”问题，打个简单比喻，在本论坛发言，按发布键后，没有反应，或者查询主题列表没有看到，然后就再多按一次，结果同一个贴重复发表了两次。
个人观点：出现这种问题其实真正体现了用计算机提供的锁等ACID机制并不能真正解决业务上的高一致性。
有一篇文章：弱一致性在现实世界中到处存在 http://www.jdon.com/43246：
过去，所有的一切都是写在纸上的假象，至少过去几十年一直如此，即时一致性是IT人发明的，他们纸上谈兵地认为：不同组织不同地方的数据如果没有即时一致性(高一致性)几乎不可能的。
其实，现实生活中也并不是不存在高一致性，只是可能比较少，这里我想提出一个新观点：高一致性是个好东西，但是好东西是不是一定是缺省配置呢？比如有钱是个好东西，那么是不是让每个人一生下来都有很多钱呢？实际相反，每个人生下来缺省是没有钱的，赤条条降生。
既然高一致性是好东西，当然不能随便缺省配置，但是实际中却相反，当我们使用关系数据库，或者使用事务机制等ACID时，这些机制都缺省让我们的程序变成高一致性，高一致性不是稀罕物，可以无偿获得，那么无疑结果是，当系统负载增加时，每个无偿得到高一致性的处理程序都要付出代价，那就是堵塞。
相反，如果我们缺省是弱一致性，对于需要高一致性的业务，我们通过业务分析会辨识发现，然后给予充分的业务重视和业务设计，那么也许能够将计算机提供ACID服帖地为我们业务高一致性服务。
在DDD分析需求过程中，这个问题得到高度重视，以DDD书籍中订单为案例，该订单有一个额度限制，也就是所有订单下条目Item总额不能超过订单设定的额度限制，这个限制其实是一种逻辑一致性限制，而且必须是实时高一致性的，因为每增加一个订单条目，都必须检查这一逻辑一致是否被破坏，如果是，立即不能加入。
比如Oder限制是1000元，订购了三件商品，总金额是1200元，超过了1000元限制，那么这个订单是无法生成的，这属于即时一致性检查。
这种检查我们采取什么方式实现呢？传统是采取锁的方法，将Oder这个对象或表锁住，因为在统计总金额时是不允许其他人有操作的，当你锁住这个对象或表时，堵塞的可能性就会到来。
如何突破这种锁方式的限制呢？那就是Actor模型，也就是说，Oder检查自己总金额，不用在被外界访问时被锁住，而是永远无法被外界锁住可能，因为Actor模型无法被外界直接使用方法调用，只能象发QQ消息一样与外界交互。
具体可见这个贴：事件驱动编程:
http://www.jdon.com/45436
所以，对于这起事件，我个人观点是：这次光大事件问题核心直指系统连锁，应该是状态锁问题，不是内存锁，就是数据库锁等出错，依赖计算机提供的acid等锁机制其实不是百分百安全，只有用业务方法解决业务问题才是根本解决之道。
[该贴被banq于2013-08-18 22:05修改过]