※ 引述《tester.bbs@bbs.csie.ncu.edu.tw (try or test)》之銘言：
: > 我不知道為何會把搜尋空位當成很複雜的問題...
: 找可售的路段空位對著 3-dim 的座位表(array table)言, 一點
: 都不複雜
: 1. Client 端若是要複製一份空位表, 自行先判斷空位再請求
: 這至少就會是 local memory cache approach.
: 2. 這種用法或架構的問題就是複制的 cached data 無法讓所有
: client 保持一致性. 所以就很 "樂觀" 的自以為有空位可
: 選就向 Shared Main-Memory "請求確認" 或 "驗證".
根據devil所提出的方案, 座位狀態表可以簡化到2Byte(可以紀錄到16個站距)
高鐵座位989席, 每日最大班次88班, 訂票是從2周前開始
假設用最蠢的完全更新, 資料量是2380KB
以現有100M網路架構打七折, 一秒可以更新3次
實際上只要更新賣出的資訊即可，而且順便可以把被誰買走更新出去
: 3. Shared Main-Memory(或是集中資訊的共用資料庫)就得被請
: 求查證與更新, 這查證更新在數量變大下成為瓶井.
前文有提到，這個客戶端頂多1000, 不構成威脅
: 4. 最新的更新資料未及時且適時送達 client 更正 replicated
: data 時, client 因之誤判的請求就隨之發生, 隨 client 數
: 造成對應的數量級的無效與不必要的請求量.
用MultiCast方式就無此問題
: 售票系統講究的就是高需求下的反應速度, (3, 4) 都影響反應.
: 當然, 局部地區性的高鐵還用不上 scalability 的考量.
: 全球性的行動手機對行動手機的查詢定位與計費扣款才有數量上
: 的高伸縮問題.
如果是那樣的系統，單一管理伺服器當然就是不可行的
但是相對的對於處理時間有更多的餘裕
--
〒作者：SmallBee 來自：46-204.dorm.ncu.edu.tw
◎二進位的世界【140.115.50.50‧binary.csie.ncu.edu.tw】