從光大證券的軟體設計缺陷想到的。

banq發表於2013-08-18
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修改過]

相關文章