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

> ==>發信人: [e-mail] (喵～～～), 信區: programming
> : > 流程1
> : > 讀取空位, 這個動作由訂票機直接向資料庫請求完整的空位資料
> : > 流程2
> : > 使用者下訂單, 此時不是直接寫入資料庫, 而是向一個唯一服務程式送出空位註冊
> : > 流程3
> : > 訂票機自行向資料庫確認定位是否成功, 藉由確認該空位的註冊者是不是自己
> : > =======================
> : > 其實高鐵總共也才(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 是會耗費相當可觀的延遲時間.
> 我不是相關科系，你跟我絡這些專業名詞沒有意義
> 只會讓我覺得你在自以為專業而已

別的網友已提供一個有關 高鐵 使用 Win2003  terminal service 的資訊
http://tinyurl.com/y22uc5

也就是 Single Node Shared Memory 的做法, 跟當年台大最早外包的選課
系統類似, 主要的決策回應是 server 端在處理. Client 端似乎是只點選
座位條件(如靠窗)而不是點選座位表的空位(這樣就不必向 server 隨時下
載整車座位空表.

Server 端到底是 multi-thread 還是 single supervisor 就沒有那麼說
明清楚, 但是開始時沒用到 Lock 處理, 應該是出狀況時的事實. 

1. On line transaction 要用到 lock 是設計考量時的 "保證正確性與效
   率分析" 問題.
2. 壓力測是軟體完工上線前, 該做的 "性能與堪用性量測的品管步驟" 問
   題.

假如不用 Lock 保證不會一位數賣, 而是用萬一發生撞位溢賣則用備位替
補, 採用備位的想法就要有備援的額外車廂可以加掛, 這就考驗緊急調度
能力了. 然道這是 "對管理調度的現場壓力測" ?

--
 ◎ Origin: 中央松濤站□bbs.csie.ncu.edu.tw  From: 140.115.6.234
推 aaronliu0719:看文章是用在辦公室 非訂票系統