標題

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

(4/21篇)看板Soft_Job軟工板作者bndan (seed)推文15則 (5推 0噓 10→)
※ 引述《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的話一半 因為資料端部份我沒有列...@@

   以上純屬討論.技術上理論可行.實際需要拿原型下去測才知道了 ~_~"--
※ 發信站: 批踢踢實業坊(pttweb.tw), 來自: 122.146.40.116
※ 文章網址: https://pttweb.tw/Soft_Job/M.1420537990.A.C3D