> ==>發信人: =?big5?B?5qPmow==?= <devil@tainan.com.tw.x>, 信區: programming
> 我不知道為何會把搜尋空位當成很複雜的問題...
找可售的路段空位對著 3-dim 的座位表(array table)言, 一點
都不複雜
1. Client 端若是要複製一份空位表, 自行先判斷空位再請求
這至少就會是 local memory cache approach.
2. 這種用法或架構的問題就是複制的 cached data 無法讓所有
client 保持一致性. 所以就很 "樂觀" 的自以為有空位可
選就向 Shared Main-Memory "請求確認" 或 "驗證".
3. Shared Main-Memory(或是集中資訊的共用資料庫)就得被請
求查證與更新, 這查證更新在數量變大下成為瓶井.
4. 最新的更新資料未及時且適時送達 client 更正 replicated
data 時, client 因之誤判的請求就隨之發生, 隨 client 數
造成對應的數量級的無效與不必要的請求量.
售票系統講究的就是高需求下的反應速度, (3, 4) 都影響反應.
當然, 局部地區性的高鐵還用不上 scalability 的考量.
全球性的行動手機對行動手機的查詢定位與計費扣款才有數量上
的高伸縮問題.
> 這個專案不是我接的，所以沒有很深入思考。
> 假設資料庫內有兩個表（不同時間班次可增加欄位屬性過濾掉，所以只要看一個車次）：
> 1. 座位狀態表：座位編號、起訖、屬性
> 起訖、屬性均為旗標值。
> 起迄，0 未售出，1 已售出：
> 1: 台北板橋
> 2: 板橋新竹
> 4: 新竹台中
> 8: 台中嘉義
> 16: 嘉義台南
> 32: 台南高雄
> 屬性：
> 1: 靠窗
> 2: 靠走道
> 3: 不限制 (1 Or 2)
> 先要求使用者輸入條件
> 1. 起、迄站：決定起迄屬性，比如說台中到台南，旗標值為 24
> 2a. 單人是否選位，靠窗或靠走道。(1、2)
> 2b. 多人是否並排坐或同車廂。(3)
> 資料庫查詢
> Select 座位編號 From 座位狀態表 Where (((起訖 AND x) = 0) AND ((屬性 AND x) > 0))
> 傳回剩餘座位表
> 2b 情形可能要用程式過濾掉不符連續或同車廂規則的，或是在座位編號或增加欄位來讓規則更複雜。
> 選位：
> 傳回結果可能可以輸出到螢幕上讓使用者選
> 或是系統基於營運考量，增加其他條件，比如說優先填滿前後段座位已售出的優先售出
> 購票：
> 鎖定選擇位置，檢查起迄是否被更新，是則告知使用者在選位期間該位置以被售出，將不得購買之座位更新本機댊> 挩l座位表（不需重新查詢，可降低網路流量），重新選位。
> 否則更新座位狀態表，標記為售出，並進入車票付款程序。
> 其它：
> 1.理論上應該可以找一些數學規劃的方法來加速選位，不過不是自己的案子，不管這些，用最簡單的邏輯處理。
> 2.另應有售票紀錄表來追蹤帳款是否完成付款，若未完成即結束，則恢復該座位為未購買狀態。
> 註：支援位元運算的資料庫引擎好像有點少...
> ==> 本文由 "try or test <tester.bbs@bbs.csie.ncu.edu.tw>"
> > 於 news:4S4Qj0%24yXO%40bbs.csie.ncu.edu.tw 發表
> > > ==>發信人: SmallBee.bbs@binary.csie.ncu.edu.tw (喵～～～), 信區: programming
> > > : 使用一個大大的共用的 Array Table , 這個作法的 Model 就是 Distributed
> > > : Shared Memory . 為了避免一位多賣, 互斥鎖定就用集中控管的 supervisor/
> > > : mornitor 來管制, 也就是這裡的集中式訂票機.
> > > : 單一 Mornitor 控管就是會把不相關的其他車廂的訂位變成了沒必要的株連九
> > > : 族, 也就是減少了平行度, 其變慢可知.
> > > 變慢是多慢？有慢到檢索一次要花到1ms以上？
> > 這個 array table 應該是 3-dim 的.
> > 高鐵從北到南假設有 5 個停靠上下站, 那就有可能一個位子有四個路段
> > 的賣出狀況, 一張票的起訖站決定一個位子被使用的時段, 所以需臨時鎖
> > 住的會是多個路段記號, 全路段湊不出空位時才是條件不符, 不成就得釋
> > 出那幾個路段記號, 這種連程一票起訖不會是只有一個記號動作. 假如又
> > 可以一票更換座位連程到底, 就會發生每個路段都就近(總不能要乘客車頭
> > 搬到車尾滿場飛)找空位, 這就變成鎖-找-鎖-找...起訖滿足才算成功.
> >
> > > 在怎麼慢都不可能慢過網路延遲時間
> >
--
◎ Origin: 中央松濤站□bbs.csie.ncu.edu.tw From: 140.115.6.234