思考
由於疫情，我們做的是互聯網教育類，所以今年我們的產品流量增加了兩倍，但是通過擴容加機器資源的方式完全扛住了，突然想到如果是爆發式的，假如流量突增10倍甚至20倍該如何處理呢？仔細思考了了一下這個問題，加上查找資料，就想簡單寫寫有哪些方案。
場景
假如一個系統最大隻能接受10w的併發訪問量，現在我們有一個秒殺活動，秒殺活動開始的時候預計併發訪問量可以達到100w。很明顯100w遠遠超過系統正常的承載量，該怎麼解決這突增的流量呢？從用戶訪問開始，其實請求要經歷好幾個階段，我們可以針對每個階段來做層層限流。
合法性限流
首先我們思考就是這100w包括正常訪問的用戶，也存在惡意刷單的用戶，甚至某些機器人，那麼我們肯定是要攔截刷單和機器人的請求的，因爲這些請求嚴重影響正常用戶的購買需求。那麼怎麼在這一層限流呢，首先非常簡單其實，就是加一個驗證碼，首先，驗證碼可以攔截掉機器人的請求，其次可以拉長用戶的訪問時間。然後可以使用ip限制，如果通過網絡技術發現了某些下單請求只需要幾毫秒，或者是重複購買同一種商品，就能認爲該請求用戶不是合法用戶或者是機器人，這樣我們可以將這個ip加入黑名單限制禁止訪問。最後，不是必須的情況下，不到秒殺開始的時間我們不開放秒殺地址入口。
負載限流
現在，經過第一層合法性限流之後，還是有大概50w的流量進來了，我們可以使用nginx轉發流量到服務端集羣裏，假如我們集羣有3臺機器，每臺機器只需要處理大概17w的併發訪問量。再者，我們知道根據網絡七層模型，nginx處於第七層，我們也可以在其它的網絡層進行負載，比如說我們在第二層的數據鏈路層進行mac地址的負載，我們可以生成一個虛擬mac，然後將這個地址映射到其它3臺服務器上，同樣的可以在第三層通過網絡ip進行負載，在第四層通過端口號進行負載。大多數我們通常使用nginx，或者nginx+lvs進行負載即可。
服務限流
前兩層都是請求達到服務器的時候進行的限流，那麼請求到了服務器的時候我們該如何處理呢，首先比如我們常用的tomcat服務器可以限制連接數，超過連接數會放棄掉多餘的請求，我們還可以使用令牌桶算法，每秒只生成1000個令牌，搶到令牌的請求才能搶購秒殺商品。考慮到每個服務器處理請求能力的不同，我們還可以使用消息隊列來進行限流，可以使用補償通知的手法告知用戶搶購成功。如果我們使用前後端分離的架構，用戶訪問的html和js代碼可以直接緩存在瀏覽器裏面，大點的圖片可以保存在nginx或者oss雲服務器上，體積特別大的視頻可以部署在cdn上面，利用區域就近訪問的特點來提高用戶的訪問速度，當然上面的緩存可以相互補充，比如oss服務器可以作爲cdn的回源服務器。而數據業務的動態緩存就是服務端程序員去考慮的了，一般使用本地緩存+redis，但是我們不是使用越多的緩存就越好，緩存使用的越多，數據的一致性得到保障的可能性就越低。