※ 引述《tester.bbs@bbs.csie.ncu.edu.tw (try or test)》之銘言：
: > 其實這種東西一定早就有寫好的了
: > 訂票系統又不是第一次出現...
: > 在我的想法裡, 我認定所有訂票機器都是固定的
: > 也因此，每一台訂票機都擁有一個唯一識別碼
: > 流程1
: > 讀取空位, 這個動作由訂票機直接向資料庫請求完整的空位資料
: > 在使用者確認的過程中, 訂票機以一定不影響系統效能的頻率確認空位還空著
: > 流程2
: > 使用者下訂單, 此時不是直接寫入資料庫, 而是向一個唯一服務程式送出空位註冊
: > 該服務程式使用UDP+CRC Check+單執行緒確保不會有兩個請求同時到達
: > 資料內容包含訂票機識別號碼
: > 由於只有唯一的程式負責寫入訂位, 自然沒有重複畫位問題
: ======
: 這是將所有請求用排隊來確保單進單出, 這只有解決互斥, 但需化併行為串行,
: 所以整個反應變慢.
反應慢, 高鐵總共也才15x台訂票機, 能有多少請求...?
檢查880KB的有序要多久?
總共只有「註冊空位」一個動作需要串行處理
這動作本來就是「必須要」串行處理
當然，進階的方法或許可以先「註冊空位觀察」
但是我認為以現有高鐵無論是訂票系統或是座位的規模都沒有這個必要
: 如果是同時想定同一車廂的多個空位, 也是排隊一個訂好, 再排隊訂另一個嗎 ?
: 何時可以 "快速" 確定滿額 ? 還是每次都得去 try ?
一台訂位機當然是一次送出所有在該台訂位機的當次訂位的所有空位設定
事實上我記得高鐵一輪只能買兩張還四張的樣子....
掃描一個已知結構的小型矩陣，方法一大堆，這是不需要特別研究的超入門問題
: 此題不難, 但成敗論英雄. 這是一個 "物美" (在各種狀況下都有一定品質) 與
: "價廉" (效能/成本, 時間反應) 必需兼得的項目.
說真的
如果網路訂票重複劃位可能還有點道理
因為除了重劃位檢查，還有人會鑽漏洞等等非正常操作
現場訂票出問題實在是罪大惡極
========
另外新聞有提到，超賣是因為「終端設備的時間差」
大約是以時間作為「誰訂到位」的標準吧
--
〒作者：SmallBee 來自：48-204.dorm.ncu.edu.tw
◎二進位的世界【140.115.50.50‧binary.csie.ncu.edu.tw】