> ==>發信人: SmallBee.bbs@binary.csie.ncu.edu.tw (喵～～～), 信區: programming
> 流程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 控管就是會把不相關的其他車廂的訂位變成了沒必要的株連九
族, 也就是減少了平行度, 其變慢可知.
也就是說 monitor 控管的顆粒度 (granulality) 大而無當.
透過終端機的做法則是 Single Node Shared Memory , 跟使用 multi-node
cache/local memory 的 DSM 不同, 雖然都有鎖定的顆粒大小問題, 但 DSM
透過 I/O 做 cache validation/update 是會耗費相當可觀的延遲時間.
當年台大, 清大的選課系統, 用查空位先搶先贏的策略時, 在高負荷下也都
曾發生超賣現象. 做過/看過 才能知道 何謂 "工程與品質" ?
--
◎ Origin: 中央松濤站□bbs.csie.ncu.edu.tw From: 140.115.6.234