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

看板Soft_Job作者bndan (seed)時間9年前 (2015/01/06 17:53)推噓5(5推 0噓 10→)

留言15則, 5人參與討論串4/21 (看更多)

※ 引述《pttnews (PTT新聞)》之銘言： : 兩個重點，頻寬不是重點 : 1. 信用卡付款機制掛了！ : 因為人太多交易又太久，假設一筆交易，金流交易銀行至少三個斡旋，要2秒， : 100人瞬間進來，第100人至少等200秒，然後第7個人到100人都以為「當機」了 : ps：2秒看似很久，但是事實上會更久。 : 2. 訂位機制很難在網頁呈現，這個位置是不是已經被別人訂走了， : 因為user猶豫的瞬間，假設一秒鐘，已經更新很多次，有7個人定位，有2個人退位。 : 然後user可能重複操作，一次開多個視窗，哭哭XD 我不是被釣出來.只是覺得隨同討論第2題蠻有趣的 : 原文: : : 以下我們都以「理性」來討論問題 : : Socket 即時我同意～ : 但是顧慮幾件事情 : 1. 每秒同一座位，有n百個人要搶耶～ : 2. 搶位的機制超難搞的，寫在DB裡適當嗎？還是用Memory比較快？這也是問題... : 3. 一人多視窗 : 4. 資料量是百萬個「對象」乘以萬個「座位」 : 等於 : 1. 同1ms裡，有三個人搶位，甲贏了，丙乙搶輸了，這件事情要通知百萬個「對象」 : 2. 這些百萬個「對象」，要等100ms，Server才會主動通知Client， : 為什麼要100ms，等一下說明... : 3. Server要每秒中通知百萬個「對象」，一萬個座位的即時狀況， : 4. Server好累，每秒通知已經超累了 : 5. 就算每秒通知，網頁還是不夠即時，還是會發生已定位，別人按定位問題 : 6. Server 還要防止Dos 以及外掛作弊 : 7. 一台Server夠嗎? 分散如何？搶位的機制如何分散？ : 分散以後，每台Server還要同步每台Server...........哭哭我覺得討論一件事應該先縮小其格局後.再將其分散單位串連 (大問題=>各小問題=>各小問題解聯合的最佳組合或是雲端的最小單位聯合的概念) 傳送無限資料(大資料/很多資料) => 傳送有限資料(小資料/單位資料) 無限操作數 => 有限操作數如果敝公司對敝人要求一個簡單的解法.我會大概分析以下資料 (非最佳) 簡單的目標: (客戶端<=>伺服器端) 1.少數人有限操作 + 即時反應 + 傳送有限資料這個狀況還蠻一般的頂多值得討論的只有即時反應. 即時反應可以簡單分 (1)操作事件回應這部份就..很一般的需求回應= = (2)資料事件回應這部份可分: -操作事件回應順便帶資料 (舊式) -伺服器資料變化即回應: *-波狀回應. *-只要有變化回應. (1)(2) 要整合在一起做或分開都可以.(因為可做成各自獨立) 2.少數人無限操作 + 即時反應 + 傳送有限資料這個的情況是在客戶端可以進行多項操作 EX:同時訂多個位置/張票這部份最簡單的設計只是需要在客戶端設計採波次進行動作而且即使回應比照1也沒差 (因為操作回傳的東西只是多些結果) 3.少數人有限操作 + 即時反應 + 傳送無限資料這個例子和1差最大的地方就是資料量大. 這部份一般新舊解差在下載量的時間位置. 舊解會以操作面進行下載 EX: 畫面進入第2區訂位那只會顯示第2區 (不夠小? 那再切也可) 新解雖然同舊解會區分資料單位.但差別在於會預先準備前後兩區的資料 (假設只能一區一區翻) 其他的就剩即時反應設計可以同1 4.少數人無限操作 + 即時反應 + 傳送無限資料這情況簡單來說就是 2和3的組合了..而且剛好2是客端.3是資料面不衝突 ========================= 以上1~4為簡單對應的需求設計. 實際的條件: 多數人無限操作 + 即時反應 + 傳送無限資料老實講...這部份設計就上比照上面的4也一樣可以跑.但"架構"上要改變. 客戶端 <=4解=> 伺服器端(服務端口) <=> 資料端 1.原本可能單一個WEB SERVER 全吃. 要改成"各"訂票區 "多個" WEB SERVER (甚至可稱之為SERVICE) 2.原本訂票資料比對在單一個WEB SERVER比. 要改成各交由資料端處理. 3.原本傳送資料可以隨便傳(EX:全傳讓客戶端程式自己比對) 但現在要改成傳變化. (在效能可以配合情況可以完成33毫秒回應最好) 4.原本客戶端表示座位資料可以只分已訂票/未訂票但現在要分成已訂票/訂票判定中/未訂票而在資料端要多做的事: 1. 波次比對訂票結果 2. 波次回應位置變化整體的簡圖如同下LINK: https://drive.google.com/file/d/0B4pcIvu9RQnEeWtxQmZHZUd2MzQ/view 簡單說明: 1.client APP 可以是 WEB APP 2.Service 為相同程式只是資料不同必要時可以設計讓雲端平台調節 3.資料端非敝人專業.在敝公司也非敝人所負責所以只拉一個大框 PS: 以上1~6問題應該都回到了? 7的話一半因為資料端部份我沒有列...@@ 以上純屬討論.技術上理論可行.實際需要拿原型下去測才知道了 ~_~" -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 122.146.40.116 ※ 文章網址: http://www.ptt.cc/bbs/Soft_Job/M.1420537990.A.C3D.html

推

asdfghjklasd

01/06 17:58, , 1^F

01/06 17:58, 1^F

→

bndan

01/06 18:00, , 2^F

01/06 18:00, 2^F

→

bndan

01/06 18:00, , 3^F

01/06 18:00, 3^F