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

> ==>發信人: [e-mail] (喵～～～), 信區: programming
> ※ 引述《[e-mail] (try or test)》之銘言：
> : > 變慢是多慢？有慢到檢索一次要花到1ms以上？
> : 這個 array table 應該是 3-dim 的.
> : 高鐵從北到南假設有 5 個停靠上下站, 那就有可能一個位子有四個路段
> : 的賣出狀況, 一張票的起訖站決定一個位子被使用的時段, 所以需臨時鎖
> : 住的會是多個路段記號, 全路段湊不出空位時才是條件不符, 不成就得釋
> : 出那幾個路段記號, 這種連程一票起訖不會是只有一個記號動作. 假如又
> : 可以一票更換座位連程到底, 就會發生每個路段都就近(總不能要乘客車頭
> : 搬到車尾滿場飛)找空位, 這就變成鎖-找-鎖-找...起訖滿足才算成功.
> : > 在怎麼慢都不可能慢過網路延遲時間
> 對於空位管理服務器而言，沒有所謂的暫時鎖定這回事
> 註冊了就是註冊了這樣，由於是單執行緒，沒有重複註冊問題
> 至於有效的連續空位檢索，是Client端的工作，與Server端無關
> 也因此，不管今天找空位要花多少時間，都跟伺服器延遲無關
假設全路段有 n 個站, 共 c 台 clients , client 要讀空位得有
read 執行緒到這個 3-dim array table [座位數* (n-1)個路段]
讀出所有座位路段的記號, 要確保正確最快就是 Multiple Read 
Single Wright , 而且一旦寫入成功就得通知所有讀走空位的 
clint 立即更新.
假設所有的 c client 在高需求最壞情況下就會發生同時搶同一個空
位(可能不同路段或路段重疊)的情形, 這 c 個請求就在單一 Wright
執行緒下變成需全部排隊等候搶空位(企圖第一個寫入成功), 由於是
對空位改成已售出, 這排隊如果還不是按座位分對應 queue (這就是
顆粒度大小之不同), 就必須先對空位路段記號再做檢查, 以確保是未
售出才能企圖寫入記號, 也就是說必須對所需空位路段(1..n-1)記號
做 read-check-wright. 只是全在 server 端的 wright 執行緒做.

假設規格要求在 T 時間內就完成成功或不成的寫入交易, 假設單筆請
求是 S 送達時間與 R 回覆時間, 每筆請求就是 P 處理時間, 排隊下
最壞就是排到尾巴, 所以要 c * P 處理時間, 故同時請求時每個請求
與回覆各有專線與收送器負擔, 所以收送是重疊平行, 最後最壞的一個
所需的時間就是 (S + c*P + R) , 照日本的範例就是 T <= 6 秒, 再
假設最後一個也是搶不到者, 搶不到者的判讀只要有一線段記號 read-
check 不成立就是得放棄, 以最短的一個 read-check 為估算,  T = 
(S + c *(read-check) + R) <= 6 秒.
以往, 這個 read-check-wright 必須是寫入 perment storage 以應付
臨時斷電 crash , 如果使用快速 DRAM 就要不停電備援.
Clint 端發現座位已售出的情況是

1.自己企圖賣出
2.已無法賣出
3.被通知已被他站賣出或自行向 server 端 array table 讀取空位路段
  記號.

上面就是 Single Supervisor/Monitor 的解法, Read 與  Wright 併行
緒還是必須對 Single shared memory (空位路段記號的 array table)
做 Mutual Exclusive Lock 的鎖定與判讀動作 (通稱 semaphore).

這種做法, client 數量 c 那天變大或變小就受影響, 不是伸縮衣無法適
應體型成長(Scalability).

--
 ◎ Origin: 中央松濤站□bbs.csie.ncu.edu.tw  From: 140.115.6.234
推 march20:大家來找碴, 是 write 不是 wright XD
推 seagal:我也疑惑了很久
推 realmojo:就是wright 少自以為是
推 realmojo:是我自以為是  是write沒錯
推 march20:難免會寫錯字咩, 所以我說我在"找碴"啊 XD