==> 在 SmallBee.bbs@binary.csie.ncu.edu.tw (喵～～～ 的文章中提到:
> 其實這種東西一定早就有寫好的了
> 訂票系統又不是第一次出現...
> 在我的想法裡, 我認定所有訂票機器都是固定的
> 也因此，每一台訂票機都擁有一個唯一識別碼
> 流程1
> 讀取空位, 這個動作由訂票機直接向資料庫請求完整的空位資料
> 在使用者確認的過程中, 訂票機以一定不影響系統效能的頻率確認空位還空著
> 流程2
> 使用者下訂單, 此時不是直接寫入資料庫, 而是向一個唯一服務程式送出空位註冊
> 該服務程式使用UDP+CRC Check+單執行緒確保不會有兩個請求同時到達
> 資料內容包含訂票機識別號碼
> 由於只有唯一的程式負責寫入訂位, 自然沒有重複畫位問題
"唯一的服務程式" 並不能解決一位多賣的問題.
去年在"非科班出身的人有辦法走Programer這條路嗎", 我就提出
這種高鐵一位多賣的問題, 很不幸地高鐵真的有這樣的問題, 而且
信譽受損.
;比如資料庫裡某個產品剩餘 m 個, 我們打算取出 n 個, 若庫存量不
;足則 print error message, 否則把剩餘量減 n 再存回資料庫。
;如果這是多人多工系統, 一般沒受過良好訓練的 programmer
;在某些狀況下即使庫存量不足也會讓 user 取出 n 個。這就是
;bug, 而這 bug 一般自己測試測不出來, 只有在流量大的時候會
;發生, 流量大的時候可能公司忙得不可開交卻要撥人力來處理這
;種問題, 而且公司聲譽可能大受影響。這問題我所見過的 programmer
;有下面幾種處理:
;1. 根本不知有這種問題(這最可怕, 他的程式好像不知哪裡埋了地雷)
;2. 知道有這問題, 但程式不處理, 因為覺得機率太小
;3. 知道有這問題, 會想辦法多加程式碼處理, 但問題還是存在
;4. 從一開始就知道這問題, 而且用正確的寫法寫, 所以沒這 bug。
這在計算機科系是常識, 四年的課程裡常會提到這樣的問題.
解決的方法不是用程式技巧, 而是系統要提供解決這程問題的機制,
因為用程式技巧通常可以減少發生的機率, 但不能徹底解決. 高鐵
的售票系統如果是用資料庫, 那麼在資料庫系統裡就有 lock 的機
制可以解決這種問題.
> 流程3
> 訂票機自行向資料庫確認定位是否成功, 藉由確認該空位的註冊者是不是自己
> 流程4
> 若失敗, 回到流程1
> 若成功, 但使用者放棄付款, 則刪除空位註冊資料
> 若成功, 且付款成功, 則向資料庫寫入完整定位資訊
> =======================
> 其實高鐵總共也才(19(北上)+19(南下))*6(站間)*(923(標準)+66(商務))=225492
> 要紀錄所有空位資料才880KB(我相信訂票機不會超過1023台...)
> 這種大小連資料庫都不需要動用, 直接作成矩陣就好...
--
* Origin: ★ 交通大學資訊科學系 BBS ★ <bbs.cis.nctu.edu.tw: 140.113.23.3>