事實上有經驗的工程師,即使沒有寫過票務系統,一聽到座位會重複劃位 應該可以馬上就知道問題出在哪,舉個簡單的例子: 一個pool裡有20個 不重複的號碼,現在要從pool裡拿出不重複的號碼排在桌子上,跟高鐵的 售票系統就很類似,(這是Critical Section的問題),一個junior的 工程師,很可能使用select 的方式由table裡拿出未註記的座位號碼, 訂位後把座位做標記,然而;這樣完全沒有transaction的觀念,由訂位 前取號到訂位後註記,多工(多人連線)系統可能同時處理2以上的程序, 於是可能發生同時取得相同號碼的問題,這是很嚴重的系統規劃問題,取 號應該是同時只能容許一個程序進入(lock),訂位前到訂位後為同一個 transaction,應該要有成功與倒回的做法,然而;這些機制卻是很少人 會去注意,難怪;高鐵的系統會出現這麼可笑的問題,我想或許高鐵的開 發人員連如何lock 都不知道,這就是只會使用db 開發程式的RD會發生 的事,另一個有趣的問題發生在,為何系統上線前的測試沒發現這麼嚴重 的問題?我想做上線前系統測試的工程師絕對也是一個初級生,單工的測 試,怎麼可能測試出多人連線的狀況,或許這些工程師還在想,不可能阿! 我之前都有測試過,沒問題怎麼會這樣?呵呵..這句話應該是programmer 常說的話之一;這問題跟使用 db使用自動編號(or oracle內的serial 使用) 或是直接SELECT MAX(number)+1 ... 寫入db 所會發生的問題 很類似,只要是稍微有經驗的工程師就知道,確實的原因絕對與高鐵發佈的 消息完全無關,系統的規劃 撰寫 全是一群非常資淺的工程師所組成,這才 是主因,我相信這個系統與台灣彩券系統一樣,還有很多潛在的問題沒被挖 掘出來,這個基礎的設計問題事前都沒注意,何況是更深層的系統問題,而 這些目前看不到的問題才是真正可怕的地方