> ==>發信人: SmallBee.bbs@binary.csie.ncu.edu.tw (喵～～～), 信區: programming
> : Single Wright , 而且一旦寫入成功就得通知所有讀走空位的
> ^^^^^^ 應該是 Write, 後面都寫錯了
謝謝 ! 一直都覺得怪怪的 , 沒再查字典.
> : 最壞就是排到尾巴, 所以要 c * P 處理時間, 故同時請求時每個請求
> : 與回覆各有專線與收送器負擔, 所以收送是重疊平行, 最後最壞的一個
> : 所需的時間就是 (S + c*P + R) , 照日本的範例就是 T <= 6 秒, 再
> : 假設最後一個也是搶不到者, 搶不到者的判讀只要有一線段記號 read-
> : check 不成立就是得放棄, 以最短的一個 read-check 為估算, T =
> : (S + c *(read-check) + R) <= 6 秒.
> 你認為這樣會超過6秒嗎....
> 我認為你可以把文章寫的更清楚
> 為什麼看你的文章看老半天還是不知道你想講什麼
這種方法主要是 70 年代的技術, 如果把所有車次都再放進去, 再增加售票
點就不太能應付了. 日本與法國現在的系統顯然是不受這個數量限制.
網路技術使得 replicated data 可以放在 client 端 local cache 做查詢,
但 client 端的快速更正與一致性考量則是 80 年代以後的技術. 這是不能
被忽略的.
> 剩餘空位的資料可以用MultiCast執行，由控制端主動發送
這是直覺的方法, 實況就得使用專屬網路, 這還是 scalability 與
cost 問題.
> : 以往, 這個 read-check-wright 必須是寫入 perment storage 以應付
> : 臨時斷電 crash , 如果使用快速 DRAM 就要不停電備援.
> : Clint 端發現座位已售出的情況是
> 如果機房沒有不斷電備援那還真是糟糕
> 更何況另外還有一個訂位系統紀錄完整的訂位資料
> 只是從訂位資料重新建構空位資料需要一點時間
> 但是既然機房都重啟了，這點就無須在意
不管是否由 log 重建, log 還是得使用 perment storage , 重建就得問
多快還原, 因此還是 UPS + DRAM (RAM disk) + Magnetic Storage 比較
能快速還原.
> : 上面就是 Single Supervisor/Monitor 的解法, Read 與 Wright 併行
> : 緒還是必須對 Single shared memory (空位路段記號的 array table)
> : 做 Mutual Exclusive Lock 的鎖定與判讀動作 (通稱 semaphore).
> : 這種做法, client 數量 c 那天變大或變小就受影響, 不是伸縮衣無法適
> : 應體型成長(Scalability).
> 商業與研究是不同的思考方向
> 商業領域要考慮的實際上可能的最大運量
只有落後國家才會認為研究與實用無關, 因為無法落實.
如果人家賣給你一個先進的網路資料庫系統那就不會是用兩輛機車湊出來的
四(或三)輪車價位, 必然就是 Benz 的價碼. 而且還是一分錢一分貨讓客戶
覺得是價廉與物美的值得.
> 目前高鐵共八站150台, 未來我估計12站220台
> 以每台機器8秒完成一次訂單設定, 空位的管理能力要求每36ms確認一個空位
> 以現有的CPU處理能力，一台電腦綽綽有餘
您認為台鐵對不同車廂分路段配票是不足取的嗎 ? 假使上面方法使用再細分
的 queue 針對不同的 "轄區" 獨立管轄是不必要的嗎 ?
還是你要每個車次都派一台獨立的,對應的 PC Server 當 "訂位機" ?
很多先進的訂位系統都考慮了轉接的車次(如航空與捷運)能一次完成一條龍的
訂位與售票.
好的設計(Well Design) 是恰到好處又可長可久(可適應不算短時期的成長)的,
品質提升又能偷工剪料(少做笨事的效率)是源自架構與模式的改變, 隨之必增
與必要的可是一分都不能少 !
PC 把終端機併入主處理機是偷工減料還能有繪圖品質的提升, 但那得建立在
dual port memory 的架構上. 原理說穿都不值錢, 但落後就是認知慢 !
--
◎ Origin: 中央松濤站□bbs.csie.ncu.edu.tw From: 140.115.6.234