Re: [請益] 請問寬宏售票為何常當機?

看板Soft_Job作者 (000)時間9年前 (2015/01/06 19:42), 編輯推噓11(1103)
留言14則, 12人參與, 最新討論串6/21 (看更多)
我看不下去了 根據我兩個下午在電腦前搶票的經歷 與之前工作過的經驗 來說說寬宏的"誠意"在哪 這邊就不討論程式寫的有多爛 單純考慮架構來看 瓶頸根本就是 web service 完全還不用去討論結賬系統之前就完敗 1. 沒有 band 掉 spam request 這種由人工造成的 ddos 一個系統完全沒有機制處理這種 request 沒有 connect limit for per IP 也沒有 req for per IP 不管頻寬再寬 機器再多 也都沒有用 2. 沒有 auto scaling 機制 寬宏的網路架構不知道是哪個白癡寫的 可以拖出去埋了 天真的以為只有幾檯電腦就能 handle 這種情況 根本沒有想把事情做好 難怪台灣的網路環境連大陸的車尾燈都看不到 3. 加入購物車的票沒有 lock 在網路極度不順的情況之下 縱使把票加入購物車 也不能保證能順利結賬 然後就不知道哪個白癡的系統架構這樣設計的 先付款就先搶到位子 好歹你也給個 buffer 這樣又造成無窮 request loop 4. 沒有用 api handle 後台邏輯 導致機器和 service 的效能浪費太多 一個 request 你就把整個網頁丟給人家 5. cache勒 越寫越生氣 你一張靜態的座位圖也不把它 cache 起來 每次 request 你就一樣重丟 是嫌效能太多是不是 其他一些細節要挑也挑不完 ※ 引述《pttnews (PTT新聞)》之銘言: : ※ 引述《LaPass (LaPass)》之銘言: : : 我記得這種API都是平行處理REQUEST : : 應該不會有這種狀況才對 : : 即使是1000人進來應該也是也是只有2秒 : : 不過我也沒親自寫過跟銀行串接的部分 : : 有沒有寫過的人可以講一下這怎麼處理的? : : 還是銀行API真的有鎖每個帳號在同一時間只能有一人進入付款程序? : 我也沒寫過金流這一塊,但是我寫過ATM提款機 : 以下是「我認為啦~」 : 金流有很多家,但是每家背後都只有一個銀行,叫做交易銀行 : 交易銀行負責把交易傳給財金資訊,財金資訊負責找發卡銀行扣款,把帳轉給交易銀行。 : 換句話 : 1. 生意上門囉!確認發出交易的某人是否合法(n次斡旋以上) : 某人 -----芝麻開門---- > 金流公司 ----芝麻開門----> 交易銀行 : 某人 <----開開了 ---- 金流公司 <----開門了 ---- 交易銀行 : 某人 -----卡號 ---- > 金流公司 ----卡號 ----> 交易銀行 : 2. 跟財金資訊發出交易 : 交易銀行 財金資訊 : -- 生意上門 --> : <-- 靠悲我知道拉-- : -----卡號 ---- > : 3. 財金要轉帳 : 財金資訊 發卡銀行 收款銀行 : -- 生意上門 --> : <-- 靠悲我知道拉 ------ : -----卡號 ---- > : <--卡號正確,不是詐騙給錢,關門 : -- 生意上門 -------------------> : <-- 靠悲我知道拉-------------------- : -- 給錢 -------------------> : <-- 已收錢,關門-------------------- : 4. 財金通知 : 交易銀行 財金資訊 : <-- 錢入賬 ------ : --- 靠悲我知道拉----> : <----關門 -------- : 5. 交易銀行通知 : 某人 金流公司 交易銀行 : <------- 交易成功 ---------- : -------- 關門 ---------> : <--- 交易成功 ---------- : -------- 關門 ---------> : 以上有n 個斡旋,事實上更多, : 金流不管帳號,只管交易,你指的帳號,應該就是交易內容。 : 至於可否並行,一次發出多個交易,應該可以,但是要看金流公司強不強? : 例如 paypal 就很強了 : : 寬宏那邊是怎麼處理的我不清楚,我沒去搶票,也沒看過畫面 : : 雖然可以做的到把所有位置放在網頁上給人選,並即時顯示動態 : : 不過一般不會這樣 : : 如果是管理頁面要顯示所有座位也就算了 : : 但「把所有的座位列在畫面上給買票者選」這種設計本身就是一個問題 : : 比較好的處理方式應該是: : : 1. 選區,然後電腦自動從該區選位置 : : 2. 選區,然後電腦從該區挑出幾個空位來給使用者選,被挑的位置先鎖定 : : 等選完後再把沒被選中的位置解除鎖定 : : 如果很堅持要把一堆位置列在螢幕上人選的話 : : 也可以這樣作: : : 3.選區,每區的大小大概幾十個至一百個位置 : : 然後,每個區用一台獨立的伺服器去負責 : : 進入該區的人只能看到/選該區的位置 : : 所以,不會遇到那種需要每秒通知數百萬的對像的狀況 : : 除非有人腦包堅持要把所有位置列出來給大家選,並叫程式設計師這樣做 : : 另外別對伺服器有太大的信任 : : 網站這種東西平時不會多大的流量,但一有狀況,流量就會「爆衝」 : : 很顯然寬宏沒考慮到這一點 : : 我私底下跟其他寫程式的朋友聊天時 : : 有聽過幾次「這是台灣之恥」之類的言論 : : 雖然有的人講話沒這麼毒,但講的意思都差不多是這樣 : : ========================== : : 離題講一下別的東西 : : 對付這種大流量的狀況 : : 有個最基本的手法就是「切」 : : 拿MMORPG來講 : : 一個遊戲會切成好幾個伺服器、伺服器中的地圖又被切成好幾個區塊 : : 甚至還出現副本之類的東西 : : 那就都是為了把玩家分散到不同電腦上去作處理 : : 這樣就是為了避免原PO講的,同步來同步去的問題 : : 我也不是什麼大師 : : 只是我聽過的,關於程式軟體的故事比較多一點罷了 : 切塊也是方法,但是喔... : 1. 先選 搖滾區 、 好棒棒區 、 好爛區 、 更爛區 : 2. 更爛區又分,左、中、右 : 3. 右區又分上中下 : 如果客戶允許網頁這樣設計,事實分區是個好方法 : 打完好累...... -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 220.142.90.85 ※ 文章網址: http://www.ptt.cc/bbs/Soft_Job/M.1420544530.A.DD5.html

01/06 21:21, , 1F
推第一手的測試報告
01/06 21:21, 1F

01/06 21:28, , 2F
01/06 21:28, 2F

01/06 21:52, , 3F
專業推
01/06 21:52, 3F

01/06 21:55, , 4F
搞不好是故意的 買氣十足省廣告錢
01/06 21:55, 4F

01/07 00:10, , 5F
推~專業
01/07 00:10, 5F

01/07 00:52, , 6F
買票不塞車新聞不會報 可能還會被說人氣下滑不用排隊XD
01/07 00:52, 6F

01/07 01:42, , 7F
推~
01/07 01:42, 7F

01/07 13:44, , 8F
金馬影展是IBON售票 10分鐘內沒結帳 票才會被取消
01/07 13:44, 8F

01/07 13:57, , 9F
根據臺灣生態,一定是錢少趕工出來的東西,不用太苛刻RD
01/07 13:57, 9F

01/07 13:57, , 10F
01/07 13:57, 10F

01/08 01:27, , 11F
只能給推,根本沒有考慮多人的機制。
01/08 01:27, 11F

01/08 01:28, , 12F
第3點超靠杯,確認座位的時候就應該鎖了。
01/08 01:28, 12F

01/08 18:39, , 13F
專業
01/08 18:39, 13F

01/09 10:01, , 14F
推第一手QA XDDD
01/09 10:01, 14F
文章代碼(AID): #1KgyeItL (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容:
以下文章回應了本文
完整討論串 (本文為第 6 之 21 篇):
文章代碼(AID): #1KgyeItL (Soft_Job)