sanben wrote:
整個癱瘓風波較小。...(恕刪)
阿就Table LOCK
如果DB LOCK就會88 188兩個一起慢
jeff-yeh wrote:
我猜想,應該是記錄已銷售量的Record Lock問題,一筆記188已售多少,另一筆記88已售多少,好做已售數量統計,進而做到限量管制.
188人數較少,所以該筆Lock的情況還好
如果是"已銷售量"
那天88和188的成交數量在18:56(88售完)前是差不多的
有異動才需要lock、沒異動就不用lock
所以88和188"已銷售量"異動(lock)的次數也會是差不多的
台星想針對88做"限量管制"我是相信的
就是假裝系統忙碌把人給踢出去不給結帳啦
又平時結帳有ATM轉帳選項
預期雙11人潮踴躍，更應該保留這種付款方式
讓使用者先成立訂單，再找時間付款
但雙11時台星刻意拿掉ATM轉帳功能
另外一般系統忙碌的做法是停在該頁面再重送資料
又流覽器的上一頁功能不刻意封印是會有效的
但雙11把人踢出系統後不給用上一頁功能
有在寫程式的人就知道這是刻意在程式裡這樣做
雙11那天序號場入口進去，然後被踢出後
再次重新排隊入口(偽排隊場)很容易就進場了
乍看跟排隊場入口長的一樣，但入場後只有188可選
這擺明台星在用不當的手法誤導消費者
台星說「保證入場，不保證成功購買」
看來是有預謀的出現系統忙碌把人踢出去
蝦米爸爸 wrote:
如果是'已銷售量'...(恕刪)
台星想針對88做"限量管制"我是相信的
就是假裝系統忙碌把人給踢出去不給結帳啦
>其實同時那麼多人,對系統的考驗是很嚴苛的,網路頻寬也是,台星應該沒那麼無聊去踢人,加上那天同時多家在辨活動,網路應該也很吃緊.
又平時結帳有ATM轉帳選項
預期雙11人潮踴躍，更應該保留這種付款方式
讓使用者先成立訂單，再找時間付款
但雙11時台星刻意拿掉ATM轉帳功能
>限定信用卡是個問題,如果開放多種付款方式,或許就可以解決上面那個問題了.
另外一般系統忙碌的做法是停在該頁面再重送資料
又流覽器的上一頁功能不刻意封印是會有效的
但雙11把人踢出系統後不給用上一頁功能
有在寫程式的人就知道這是刻意在程式裡這樣做
>或許他們有他們系統環境的考量吧,同時數萬人以上在線,對系統是很大的考驗.
雙11那天序號場入口進去，然後被踢出後
再次重新排隊入口(偽排隊場)很容易就進場了
乍看跟排隊場入口長的一樣，但入場後只有188可選
這擺明台星在用不當的手法誤導消費者
台星說「保證入場，不保證成功購買」
看來是有預謀的出現系統忙碌把人踢出去
>如果台星真想這麼搞,他何必辨這活動,不要辨就好了,何必辨一個活動來搞臭自己.
jeff-yeh wrote:
＞其實同時那麼多人,對系統的考驗是很嚴苛的,網路頻寬也是,台星應該沒那麼無聊去踢人,加上那天同時多家在辨活動,網路應該也很吃緊.
如果真的是網路頻寬或伺服器loading之類的問題
那就是流覽器轉圈圈、無反應、反應遲鈍，但那天並不是
早上的驗證碼圖形出不來就真的是超過負荷
但這狀況在中午後就恢復正常了
也就是中午後的台星系統負荷是受到控制的
jeff-yeh wrote:
＞限定信用卡是個問題,如果開放多種付款方式,或許就可以解決上面那個問題了.
平時有ATM轉帳選項，那天沒有，顯然是故意的
jeff-yeh wrote:
＞或許他們有他們系統環境的考量吧,同時數萬人以上在線,對系統是很大的考驗.
那天台星的即時線上人數統計在線人數沒那麼多
例如下午2點半左右的線上人數8千多人
弄成把辦理88方案的人因系統忙碌被踢出去
還真的是把所有的網友當作沒有開發系統的經驗來唬弄
我的技術沒很好，但8千多人就算同一時間送出訂單
不管table lock，還是你說的record lock
就是程式在lock時等候一下，等排在前面的交易unlock
然後把這些資料餵進資料庫還是不成問題的
另外也可以參考一下線上人數是怎麼做出來的
台星實際怎麼做的我不清楚，但原理應該大同小異
https://dotblogs.com.tw/jhsiao/2015/11/04/153791
wrote:
在這個範例裡面是運用$_SERVER['REMOTE_ADDR']函數，去抓取使用者的IP，並把值跟時間存入MySQL資料庫
好讓系統做比對，不會每一次刷新就加一次人數
同時，設定存活時間，要是超出存活時間，會執行清除的動作，刪除資料庫內舊有的資料
11/11能統計出某一時間的即時線上人數最高時可達一萬多人
表示台星的系統(包括資料庫)能承受一萬多人操作網站是沒問題的
jeff-yeh wrote:
＞如果台星真想這麼搞,他何必辨這活動,不要辨就好了,何必辨一個活動來搞臭自己.
如果台星很不想賣88，真的就不要賣
不要用技術性的手段來干預88訂單成交
說真的我覺得原PO解釋非常合理
內文搜尋
從 APP 打開
X