3. 重新開機與過載保護
如果系統發生“雪崩”，貿然重新開機服務，是無法解決問題的。最常見的現象是，啟動起來後，立刻挂掉。這個時候，最好在入口層将流量拒絕，然後再将重新開機。如果是redis/memcache這種服務也挂了，重新開機的時候需要注意“預熱”，并且很可能需要比較長的時間。
秒殺和搶購的場景，流量往往是超乎我們系統的準備和想象的。這個時候，過載保護是必要的。如果檢測到系統滿負載狀态，拒絕請求也是一種保護措施。在 前端設定過濾是最簡單的方式，但是，這種做法是被使用者“千夫所指”的行為。更合适一點的是，将過載保護設定在CGI入口層，快速将客戶的直接請求傳回。
二、作弊的手段：進攻與防守
秒殺和搶購收到了“海量”的請求，實際上裡面的水分是很大的。不少使用者，為了“搶“到商品，會使用“刷票工具”等類型的輔助工具，幫助他們發送盡可 能多的請求到伺服器。還有一部分進階使用者，制作強大的自動請求腳本。這種做法的理由也很簡單，就是在參與秒殺和搶購的請求中，自己的請求數目占比越多，成功的機率越高。
這些都是屬于“作弊的手段”，不過，有“進攻”就有“防守”，這是一場沒有硝煙的戰鬥哈。
1. 同一個賬号，一次性發出多個請求
部分使用者通過浏覽器的插件或者其他工具，在秒殺開始的時間裡，以自己的賬号，一次發送上百甚至更多的請求。實際上，這樣的使用者破壞了秒殺和搶購的公平性。
這種請求在某些沒有做資料安全處理的系統裡，也可能造成另外一種破壞，導緻某些判斷條件被繞過。例如一個簡單的領取邏輯，先判斷使用者是否有參與記 錄，如果沒有則領取成功，最後寫入到參與記錄中。這是個非常簡單的邏輯，但是，在高并發的場景下，存在深深的漏洞。多個并發請求通過負載均衡伺服器，配置設定 到内網的多台Web伺服器，它們首先向存儲發送查詢請求，然後，在某個請求成功寫入參與記錄的時間差内，其他的請求獲查詢到的結果都是“沒有參與記錄”。 這裡，就存在邏輯判斷被繞過的風險。
應對方案：
在程式入口處，一個賬号隻允許接受1個請求，其他請求過濾。不僅解決了同一個賬号，發送N個請求的問題，還保證了後續的邏輯流程的安全。實作方案， 可以通過Redis這種記憶體緩存服務，寫入一個标志位（隻允許1個請求寫成功，結合watch的樂觀鎖的特性），成功寫入的則可以繼續參加。
或者，自己實作一個服務，将同一個賬号的請求放入一個隊列中，處理完一個，再處理下一個。
本教程由尚矽谷教育大資料研究院出品，如需轉載請注明來源。