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

看板Soft_Job作者 (心存善念盡力而為)時間9年前 (2015/01/07 07:32), 編輯推噓4(4021)
留言25則, 12人參與, 最新討論串8/21 (看更多)
※ 引述《timeflying (活在當下)》之銘言: : 請問寬宏售票為何常當機? : 我現在所做的是交易系統,是絕不容許當機的, : 每次運作的交易系統對我們的團隊而言就像是飛機起降一樣, : 不容許有任何意外的發生,如有意外,後果不堪設想。 : 不像寬宏售票系統視當機為理所當然,然後來炒新聞, : 他是希望我們寫個系統來和他搶生意嗎? : 不過不會當機的交易系統,也不一定賣的贏常當機的交易系統 早上在 FB 寫了一篇,轉過來一起討論。 ----------- 很多人都在討論演唱會系統該怎麼做比較好。覺得不應該這麼難。 站在專業角度來論述一下這件事情, 雖然坦白說,憑空討論這問題就像瞎子摸象,非常困難, 寬x 的問題可能是他獨有的問題,也可能是共通的問題。 我打算來從共通的面討論這件事情。 本質上你可以把所有演唱會位置視為一個格。 交易這回事本質上就是把人分到他想要的格子。 先不論金流來簡化問題, 這個問題的 key factor 在 concurrent user (同時在線人數), 這種大型演唱會搶票基本上都是 concurrent 萬人以上的。 會碰到的第一個問題是「我們要讓使用者知道哪個格有人、哪個格子沒人」, 因為使用者要選位,這件事情就已經夠困難了。 我不知道你們有沒有玩過線上遊戲, 實作同時一萬個人在線上(而且一直講話)的聊天室, 跟同時實作一百個人在線上的聊天室, 訊息量的差異是「指數級」以上的差距。 假設後者是 100^2 的話,前者可能就是 10000^6 。 (只是打個比方啦,數字沒有很精準) 而即時回報座位訊息,大概就像是一萬個人的聊天室。 (傳遞的是我選了、沒選的訊息) (btw 如果你仔細觀察的話,line/cubie/google hangout 都設定有一百人到兩百人不等得群組上限,背後的理由就在這裡......) 這是第一個,而且坦白說算相對好處理的,訊息問題。 接下來是問題的重點: lock 。 lock 是千古難題,概念上完全不困難,但實作非常困難。 race condition 一直都是我們這個領域中最難處理的問題。 很多人在談得許多機制都很合理,不論取號也好、各種作法也好。 但重點是concurrent 10000 人以上的情況,你一定要作「分散運算」, 否則你在 OS 層基本上很難處理這麼大量的並發程序, 而且風險也很高(重點)。 但分散運算對 lock 來講根本是先天的天險...... 原本我一台伺服器自己撈記憶體或檔案查就好的事情, 現在會變成多台伺服器要找某台中央 server 要資料。 兩者的速度與 request 差距是數十倍的。 另一方面如何確保這個 lock 在所有機器上都確實處理好了, 這個機制最後的「源頭」不又回到了concurrent 10000 對 1 的情況? 所以這不是這麼單純的事情, 我們還要把「格子」的管理也切開好幾台來分散式管理, 但這樣一來又回到原本的問題,你本來是多台對一台的訊息管理, 現在是多台對多台的訊息 request。 這又是一個架構級的變化,這中間的平衡非常 非常 不好抓。 更不用說,真正面對這個問題的廠商(寬x等), 根本就不覺得自己該把處理這種數萬人的架構當成他最重要的任務。 他們的想法就是把問題丟出去給 client 承擔(ex.ibon ...etc ), 甚至坦白說我覺得他們恐怕認為這個問題無解, 這些廠商如果有把這些事情當成真正一回事看, 這些系統的設計不會這麼原始、陽春而令人打從心理感到發笑。 (專家從系統面就看得出來有沒有認真花力氣了啦,真的。) 在這個面上,我覺得 kktix 有認真思考這個問題, 在「售票」這個層級我覺得他們的確有一手、 解決問題肯定比這些廠商強上好幾個指數級。 kktix 的問題在於他們處理「劃位」這件事情的經驗還太少, (我記得去年才開始籌備跟準備挑戰) 但我相信這只是時間問題。 這應該也是 kkbox 買 kktix 的戰略目標,我們等著未來看 kktix 表演吧。 以上,從我的角度思考為什麼演唱會這麼困難。 問題不在承擔這麼多流量,而是在這麼多同時操作的情況底下, 確保穩定的 lock 這件事情的成本高到很難取得一個服務的平衡。 另外週邊條件還有: server 本身的頻寬、 IO 能力、 是否有採用 CDN 、 網路連線狀況等等等 但這個相對而言,屬於比較可能「花錢解決」的範圍。 我知道這問題很多資訊圈的朋友可能會有不同見解,歡迎推文一起討論...... 至於金流部份,坦白說我認為先處理劃位,確定有位置優先, 金流用「時間」來確認就好...三天沒付錢就取消之類的。 不要想著把金流一次到位的解決, 就是這種什麼都要「一次到位」的作法才會讓這件事情變這麼困難。 FB 傳送門: http://goo.gl/WkElvg -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.166.98.109 ※ 文章網址: http://www.ptt.cc/bbs/Soft_Job/M.1420587160.A.F7F.html

01/07 09:07, , 1F
聊天室的估算看起來並沒很精準, 後面的數字過於誇大
01/07 09:07, 1F

01/07 09:07, , 2F
不過說只是打個比方, 就隨意了 XD
01/07 09:07, 2F

01/07 09:09, , 3F
三天才付錢, 那黃牛不就可以先把整場都給包了
01/07 09:09, 3F

01/07 09:10, , 4F
寫一個bot看到拿到多少slot就全拿, 問題也不小
01/07 09:10, 4F

01/07 09:19, , 5F
黃牛是另一個層次的問題,要分開解。
01/07 09:19, 5F

01/07 09:47, , 6F
分散處理下,沒有那麽難啦,前端的session無狀態有固定
01/07 09:47, 6F

01/07 09:47, , 7F
解法,後面的db寫入也有一定的處理手斷,是以lock沒有那
01/07 09:47, 7F

01/07 09:47, , 8F
麽難處理,只是分散系統的做法,不那麽為人所知
01/07 09:47, 8F

01/07 09:53, , 9F
看來KKBOX放不少人出來打廣告哦.
01/07 09:53, 9F

01/07 10:07, , 10F
當你有facebook能用 何必執著無名部落格XD
01/07 10:07, 10F

01/07 10:40, , 11F
看你想怎麼定義問題,以這例子,如果限定會員購票並且做好
01/07 10:40, 11F

01/07 10:40, , 12F
會員控管,就還好。
01/07 10:40, 12F

01/07 10:48, , 13F
race condition真的很麻煩
01/07 10:48, 13F

01/07 10:49, , 14F
共用資源如果同時處理的人數少,還可以用UX來擋一下
01/07 10:49, 14F

01/07 11:35, , 15F
這個問題我覺得用LMAX Disruptor來做可能會比較好
01/07 11:35, 15F

01/07 11:36, , 16F

01/07 11:40, , 17F
其實想想證券交易及銀行交易的concurrency都花多大心力
01/07 11:40, 17F

01/07 11:40, , 18F
寬宏沒花資源在這塊吧
01/07 11:40, 18F

01/07 13:50, , 19F
這移動時代其實不太適合會員才能OOXX的設計.在純交易來說..
01/07 13:50, 19F

01/07 13:50, , 20F
非必要的情況多加一層會員只是增加交易難度...
01/07 13:50, 20F

01/07 15:06, , 21F
kktix要先解決能在超商買票的問題..
01/07 15:06, 21F

01/07 15:11, , 22F
就算技術上做得到,聊天室也不該沒有人數或發言間隔時間
01/07 15:11, 22F

01/07 15:11, , 23F
等其它限制,要不然狂洗版的情形下,只有動態視力強到爆
01/07 15:11, 23F

01/07 15:11, , 24F
的人才有辦法聊天...
01/07 15:11, 24F

01/08 23:35, , 25F
推~~尤其是廠商的心態
01/08 23:35, 25F
文章代碼(AID): #1Kh72Oz_ (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容:
以下文章回應了本文
完整討論串 (本文為第 8 之 21 篇):
文章代碼(AID): #1Kh72Oz_ (Soft_Job)