一次性密碼（One Time Password，OTP）是網路服務常見的一種雙重身份驗證，又稱雙因素身份驗證 （2FA，Two-Factor Authentication），相信大家都熟悉類似的畫面：
這種方式是現在主流採用的安全措施，由於單一密碼強度太低，因此添加第二層保護來確保帳戶安全性更堅固。然而，水能載舟亦能覆舟，當你今天要使用在超大流量的網路活動時，2FA 就是一把雙面刃，大流量的風險可能使它反咬你一口！
A. 2018、2019年時，各國瘋搶購 iPhone XR、iPhone 11，當時 Apple推出iReserve系統，讓消費者需要獲得SMS OTP認證碼，才可以進入系統搶購。19年9月11日，Apple官方發表會後，隔日不到早上8:00， 中國京東平台顯示，iPhone11預約人數達到304421人，iPhone11 Pro達到494992人。記得當時很多人都抱怨因為收不到SMS而搶iPhone失敗相當氣惱，顯然 SMS系統的throughput是有限的，幾十萬封SMS根本無法同時送出。
B. 2020年7月，台灣為了振興藝文產業所發行的 「藝fun券」，超過200萬人抽中資格，當天許多中獎者登入APP領獎時，卻發現系統大出包，網友紛紛上PTT抱怨等了將近三小時。
其實，原因是官方使用簡訊發送驗證碼，超出負荷量釀成伺服器壅塞，導致根本是連收都收不到，不然就是輸入驗證後頻頻顯示「驗證失敗」，被迫緊急增加硬體設備。
C. 以上都是採用簡訊方式，那麼用Email－OTP 會不會比較好呢？答案是不會，有興趣的人可以看看2019年底 香港除夕大抽獎，就是採用 Email－OTP 一樣延遲了很久，畢竟Email－OTP 是比SMS－OTP還更難控制的。
總之SMS OTP 在大流量使用上有一定的上限，超載的流量尖峰都可比擬為「人肉版的DDoS」！
應用程式效能監控（Application Performance Management，APM）是支援線上任務的重要因素。當活動運行，透過具體數據與圖表，協助保持系統穩定執行、IT部門在客戶支援功能上的時間和金錢也變得可控。
A.「監控」的重要性在於，讓你在發生災難前排除問題，以及確切知道「問題來自什麼？」，有個明確方向找出原因，就能預防及優化處理，記住：「找出發生問題的原因」與「解決問題本身」一樣重要。
應用程式效能監控（APM），可以幫助監控生態系統中發生的事件，讓你及時做出對應的反應，其功能可能包含:
追踪運行緩慢的區域 知道花了多少時間在數據庫的要求上 視覺化數據庫 數據庫調用響應時間和吞吐量
B. 提供10個APM服務方案，以供參考：
1. SolarWinds 2. WhatsUp Gold 3. Loggly 4. Elastic Observability 5. nSpectrum 6. Splunk 7. Dynatrace 8. Datadog 9. AppDynamics 10. Synthtic Monitoring
第三方 HTTP 請求 （Third-Party HTTP Requests）是為了獲取額外的資源而連接到其它的伺服器下載，如果有網路延遲或是對方伺服器忙碌都會影響網頁效能。
什麼是第三方服務？ 舉電商為例，他是部署在電商網站上的基於雲端的技術，目的是為線上消費者提供更好的購物者體驗。 第三方供應商的服務器和用戶的瀏覽器之間傳輸數據和內容：用戶評論、廣告、推薦等等，都是由第三方JavaScript交付內容的常見例子。 但是，根據 YOTTAA 分析報告〈2018 eCOMMERCE 3RD PARTY TECHNOLOGY INDEX〉，網站延遲的原因中竟有 75% 由第三方服務造成，也就是說這些為了幫助你提供更完善的工具，同時也是造成用戶體驗倒退的原因之一。
我們在〈RedSo的新產品－NoQ〉這篇文章中有提過，大流量系統難在於數據庫。為了防止錯誤，數據庫在寫入的時候必須確保同一時間只有一個寫入，同時由於數據量大，亦有資訊保安的問題。然而就算前端可以同時顯示資料給一百萬人閱覽，在下訂單要寫入數據庫時，依然會遇到其他瓶頸。將數據庫做Sharding分片化是其中一個方法，但遇上幾萬人同時搶購同一產品，單一產品的庫存更新還是非常不易的。
Fred Hebert 《Learn You Some Erlang for Great Good!》書中將網站與流量做了有趣的比擬：看看下圖，我們的系統就是這個水槽，而網站流量是流進的水。
當進水量大於排水量，數據輸入越來越快，出口就無法即時處理所有數據，通常這時候我們會想到增加一個緩沖存儲臨時數據，但隊伍持續的超載到達上限還是會導致系統崩潰。開發人員此時會開始一連串步驟，從一一檢視到擴大系統，可是最根本的問題可能是存在於「出水口」，例如數據庫，外部服務API，磁盤速度，帶寬或常規I / O限制，頁面調度速度（分頁速度），CPU限制等。開發人員應該做的是阻止再輸入，即反壓（back-pressure）或者暫時丟棄數據，即卸載（load-shedding）。
延續上段所講，通常在決定擴展系統之前，會做相當耗時的檢查，例如查看堆疊追蹤（堆棧軌跡）、排隊隊伍、數據庫慢速查詢、以及調用的API等，因為擴展是需要付出代價的，也是最後不得已的選擇。這個動作並不表示網站所有部分可以安穩的一起擴展， Hartley Brody 認為，一些複雜的背後機制其實會令保持性能有所困難：
添加新功能需要更長的時間 代碼可能更難測試 查詢和修復錯誤更令人沮喪 使本地環境和生產環境相匹配更加困難
所以除非真的不得已，盡量選擇其他更簡單又快速的方式處理問題是最好的，沒有人喜歡自找麻煩。
綜合以上五個原因，你可以怎麼做？
1.與虛擬排隊系統對接，如 RoomQ，暫時卸載過多流量到虛擬等候室中安置，並且隨時依據目標網站容量變化，將可負荷人流引導回去；
2.直接租用超大容量系統，最好是連超過一百萬流量都能掛保證穩固順暢的 NoQ Flash。