※ 引述《tester.bbs@bbs.csie.ncu.edu.tw (try or test)》之銘言：
: > 很難相信一票多賣的 bug 居然還會出現在正式商業運轉的程式裡面
: > 而且還不是久久才發生一次，第一天第一班車就有，之後的班次也還有
: > 類似這種問題應該做過非常大量的 QA testing，早就 fixed 了才對
: > 怎麼還可能這麼容易出現呢?
: > 實在懷疑負責程式設計的 team 倒底作了多少程度的 QA?
: ======
: 1. 這一題看似簡單, 其實不易, 以下純想像推論.
: 2. 在接近滿位時, 假設需求還是不斷進來, 這時候若要購買多個同車廂空
: 位, 就可能相當於在雜亂無序的空位中全搜(假設來不及對回收排序), 而
: 這些需求都已排長龍, 但由於是條件不符, 而非滿座, 就不能先通知已無
: 座位可買, 此時每個需求的平均等候時間就不會是平均幾分鐘內就能有結
: 果.
: 3. 需求訂位進行中, 就把預訂交易的空位先鎖住, 當成批同車廂訂位無法
: 滿足時, 就造成整批已先鎖住的退位, 此時的交易反應時間因之就更不易
: 滿足規格的要求. 為了驗收過關就可能針對測試做答案, 乾脆不鎖.
: 4. 不鎖, 碰上人潮, 衰事就發生了.
: 5. 對 Critical Section 做 Mutual exclusion access 的教學, 最難的
: 就是讓學生接受這種看似不太可能的失誤.
: 6. 台灣軟體發展的致命觀念處就是: 沒逮到錯誤就是對的 !
整個系統的效能的弱點就在於，一個人的買票時間 不是瞬間的
機器可能已經以為甲要買票了，結果買票的甲想了十秒又跟機器說不買了。
結果機器已經跟之前的乙說「對不起你的票沒了」
結果在甲放棄之後，丙排在乙的後面也是要買相同的票，就買到票了。
這到還是最簡單的問題。
火車各站之間，就算台灣沒有發生什麼特殊事件，
都至少會隨著 年+月+日+時 的組合 在各站產生不同的 進來出來的問題。
distributed system 能否 調整的合宜 使得 這系統 經的起這樣子的考驗。
如果要考慮使用者的合理化，變成很多事就要符合這合理化，不然不懂CS的乘客
至少不能夠讓人會認為這機器在整他。
如果每台機器都能夠有一個Queue出來，由中央核心的Server 跟這些Queue互動
而使用者本身可得到的資訊不是全台灣的資訊，他會以這Queue的資訊為資訊。
便不會有那種機器整它的問題。
但一但位置趨進飽合 而且大家又大量購買的時候，就會出現了問題
這時候就會有極少量的票，中央核心的系統可能就必須把這少量的票全部給
oo高鐵火車站上面。
由oo火車站的Server來裁徹到底票要給誰。
===========================分隔線===================
我想的方法是：
核心
/ \
火車站 火車站
A B
/ | | \
機 機 機 機
器 器 器 器
Aa Ab Ba Bb
對於買票的人而言，他只會知道買票週遭的附近 人的買票情形
只要在週圍上是合理的情況下，他們就能夠接受買不到票的事實。
而這個樹裡面的每個edge 都可以想成是一個 queue
核心會分配 給各火車站 他們可以賣出的票有那些
而火車站的設計者，再去想辦法說 要把那些車票分配在那個機器上。
而最後 當有人對著 Ab機器買 票的時候， Ab 只能提供 Queue上有的票給使用者
而機器 Ab不是只有賣票，他還一方面跟 火車站A 提供 要求 Queue的資料
而火車站A 也是會跟核心要求票
核心在 面臨有 年+月+日+時 的時間組合，要如何把車票適當分配在各車站
分的好就賺大錢，分不好可能就賺不到什麼錢，還會被客人抱怨車票難買。
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 125.225.149.5
※ 編輯: milochen 來自: 125.225.149.5 (01/07 17:03)