Re: [問題]台灣高鐵的票務系統是誰做程式設計的?

※ 引述《[e-mail] (try or test)》之銘言：
: > 流程1
: > 讀取空位, 這個動作由訂票機直接向資料庫請求完整的空位資料
: > 在使用者確認的過程中, 訂票機以一定不影響系統效能的頻率確認空位還空著
: > 流程2
: > 使用者下訂單, 此時不是直接寫入資料庫, 而是向一個唯一服務程式送出空位註冊
: > 該服務程式使用UDP+CRC Check+單執行緒確保不會有兩個請求同時到達
: > 資料內容包含訂票機識別號碼
: > 由於只有唯一的程式負責寫入訂位, 自然沒有重複畫位問題
: > 流程3
: > 訂票機自行向資料庫確認定位是否成功, 藉由確認該空位的註冊者是不是自己
: > 流程4
: > 若失敗, 回到流程1
: > 若成功, 但使用者放棄付款, 則刪除空位註冊資料
: > 若成功, 且付款成功, 則向資料庫寫入完整定位資訊
: > =======================
: > 其實高鐵總共也才(19(北上)+19(南下))*6(站間)*(923(標準)+66(商務))=225492
: > 要紀錄所有空位資料才880KB(我相信訂票機不會超過1023台...)
: > 這種大小連資料庫都不需要動用, 直接作成矩陣就好...
: ============
: 使用一個大大的共用的 Array Table , 這個作法的 Model 就是 Distributed
: Shared Memory . 為了避免一位多賣, 互斥鎖定就用集中控管的 supervisor/
: mornitor 來管制, 也就是這裡的集中式訂票機.
: 單一 Mornitor 控管就是會把不相關的其他車廂的訂位變成了沒必要的株連九
: 族, 也就是減少了平行度, 其變慢可知.
變慢是多慢？有慢到檢索一次要花到1ms以上？
在怎麼慢都不可能慢過網路延遲時間
再次強調高鐵訂票機只有15x台
還有，在我的想法裡，訂票資料跟空位管理是獨立的
空位的管理是可以高度純化的，在這樣的背景條件下
分散式處理浪費在同步跟異動的時間跟經費(研發,除錯,設備等等)
絕對遠大於使用單一設備管理
: 也就是說 monitor 控管的顆粒度 (granulality) 大而無當.
: 透過終端機的做法則是 Single Node Shared Memory , 跟使用 multi-node
: cache/local memory 的 DSM 不同, 雖然都有鎖定的顆粒大小問題, 但 DSM
: 透過 I/O 做 cache validation/update 是會耗費相當可觀的延遲時間.
我不是相關科系，你跟我絡這些專業名詞沒有意義
只會讓我覺得你在自以為專業而已
: 當年台大, 清大的選課系統, 用查空位先搶先贏的策略時, 在高負荷下也都
: 曾發生超賣現象. 做過/看過 才能知道 何謂 "工程與品質" ?
網路選課系統，同時有數千台電腦以近似於DDOS攻擊的方式在查詢
而且又是倚靠以Internet為媒介的HTTP協定
跟高鐵訂票系統15x台專用主機走專用線路傳特製封包不可同語
解決問題的技術複雜性也有相當的差異

--
〒作者：SmallBee      來自：48-204.dorm.ncu.edu.tw
◎二進位的世界【140.115.50.50‧binary.csie.ncu.edu.tw】
推 gpmm:其實我也覺得依高鐵目前的營運情形，沒有必要
→ gpmm:用到分散式系統。真的是吃力不討好 = =||
→ gpmm:不過如果說為了以後長久的遠大想法考慮的話..
推 ephesians:我認同你的訂票與配位二模組分離概念