事實上有經驗的工程師,即使沒有寫過票務系統,一聽到座位會重複劃位
應該可以馬上就知道問題出在哪,舉個簡單的例子: 一個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 所會發生的問題
很類似,只要是稍微有經驗的工程師就知道,確實的原因絕對與高鐵發佈的
消息完全無關,系統的規劃 撰寫 全是一群非常資淺的工程師所組成,這才
是主因,我相信這個系統與台灣彩券系統一樣,還有很多潛在的問題沒被挖
掘出來,這個基礎的設計問題事前都沒注意,何況是更深層的系統問題,而
這些目前看不到的問題才是真正可怕的地方
應該可以馬上就知道問題出在哪,舉個簡單的例子: 一個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 所會發生的問題
很類似,只要是稍微有經驗的工程師就知道,確實的原因絕對與高鐵發佈的
消息完全無關,系統的規劃 撰寫 全是一群非常資淺的工程師所組成,這才
是主因,我相信這個系統與台灣彩券系統一樣,還有很多潛在的問題沒被挖
掘出來,這個基礎的設計問題事前都沒注意,何況是更深層的系統問題,而
這些目前看不到的問題才是真正可怕的地方
留言