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

> ==>發信人: [e-mail] (喵～～～), 信區: programming
> 因為每一台機器每一次可能都需要不同區域的空位資料
> 而且使用者可能三心兩意一下要這一下要那
> 如果採要什麼就跟管理機器要哪一段的資訊
> 等於把空位搜索都交給管理機器
> 這樣管理機器的負載相對重的多
> 這樣不如統一由管理機器自動發送空位更新資料
> 將處理流程簡化成：
> 接收空位註冊請求-註冊空位資料-發送空位狀態更新
> 而全狀態更新則是在機器啟動時更新

1. 現在 中央訂位機 把 查找空位 的工作下放到 Client 端.
   這從 Single Shared Memory 變成 distributed catche.
2. 那張 3-dim 的座號路段空位表仍然是 shared memory 的主體,
   假設每個座號分配一個 request-queue , 當座位路段狀況改變
   時, 就先清查 queue 裡的其他請求是否已無位可賣, 這能立即
   減短 request-queue 的長度, 給 Client 端快速獲得已賣出的
   更正資訊. 標記狀態的改變, 可等候一段夠長的時間累積夠量才
   通知其他未做請求的 client 更新 cache 裡的這個資訊.
3. 是夠量適時的局部更新還是全面更新, 當然與需求負載有關, 迅
   速反應可阻止不必要的 "已售出的假空位訂位請求", 但不可忽
   略通訊封包對承載資訊量的經濟規模問題.
4. 假如 Distributed Cache 與 Main Memory 的內容一致性能 "迅
   速跟隨一致" 這就逼近 Distributed Shared Memory 了.


> 至於未來網頁跟手機的訂票系統
> 不能單純的直接靠Web，還是要有中介的軟體
> ※ 引述《=?big5?B?5qPmow==?= <[e-mail].x>, 看板: Language》之銘言：
> : 是因為怕網路斷線，所以要把資料全部下載到 client 端嗎？
> : 我本來是想配合前面有人說用 Web Service ，假設訂單確認通通在 Server 上，client 這邊只送出要求即可ꄊ> C
> : 假設另外加一個統計表，傳回各班次剩餘座位數。
> : 若是人工選位，使用者先選取搭乘班次（剩餘座位 > 0），則最多傳到 client 端的量只有當班次的剩餘座位렊> 禤①Aclient 上傳訂購車位數量及位置、時間、相關個人資料（比如說信用卡卡號）
> : 若是由系統優選自動訂位（比如說優先補齊該座位前後區間已有人搭乘的情況），Server 就直接傳回空位給 c
> lient ，那量就只有訂購車位數。
> : 這樣應該也可以很容易轉成網頁系統跟手機系統吧...
> : 註：我只是沒搞清楚幹麻把 2 周 88 班次所有資料下傳
> : ==> 本文由 "喵～～～ <[e-mail]>"
> : > 於 news:4S4lCb%24aeU%40binary.csie.ncu.edu.tw  發表
> : > 根據devil所提出的方案, 座位狀態表可以簡化到2Byte(可以紀錄到16個站距)
> : > 高鐵座位989席, 每日最大班次88班, 訂票是從2周前開始
> : > 假設用最蠢的完全更新, 資料量是2380KB
> : > 以現有100M網路架構打七折, 一秒可以更新3次
> : > 實際上只要更新賣出的資訊即可，而且順便可以把被誰買走更新出去

--
 ◎ Origin: 中央松濤站□bbs.csie.ncu.edu.tw  From: 140.115.6.234