React?SSR?中的限流案例詳解
當對 React 應用進行頁面加載或 SEO 優(yōu)化時,我們一般繞不開 React SSR。但 React SSR 畢竟涉及到了服務端,有很多服務端特有的問題需要考慮,而限流就是其中之一。
所謂限流,就是當我們的服務資源有限、處理能力有限時,通過對請求或并發(fā)數(shù)進行限制從而保障系統(tǒng)正常運行的一種策略。本文會通過一個簡單的案例來說明,為什么服務端需要進行限流。
為什么要限流
如下所示是一個簡單的 nodejs 服務端項目:
const express = require('express') const app = express() app.get('/', async (req, res) => { // 模擬 SSR 會大量的占用內(nèi)存 const buf = Buffer.alloc(1024 * 1024 * 200, 'a') console.log(buf) res.end('end') }) app.get('/another', async (req, res) => { res.end('another api') }) const listener = app.listen(process.env.PORT || 2048, () => { console.log('Your app is listening on port ' + listener.address().port) })
其中,我們通過 Buffer
來模擬 SSR 過程會大量的占用內(nèi)存的情況。
然后,通過 docker build -t ssr .
指定將我們的項目打包成一個鏡像,并通過以下命令運行一個容器:
docker run \ -it \ -m 512m \ # 限制容器的內(nèi)存 --rm \ -p 2048:2048 \ --name ssr \ --oom-kill-disable \ ssr
我們將容器內(nèi)存限制在 512m,并通過 --oom-kill-disable
指定容器內(nèi)存不足時不關閉容器。
接下來,我們通過 autocannon
來進行一下壓測:
autocannon -c 10 -d 1000 http://localhost:2048
通過, docker stats
可以看到容器的運行情況:
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS d9c0189e2b56 ssr 0.00% 512MiB / 512MiB 99.99% 14.6kB / 8.65kB 41.9MB / 2.81MB 40
此時,容器內(nèi)存已經(jīng)全部被占用,服務對外失去了響應,通過 curl -m 5 http://localhost:2048
訪問,收到了超時的錯誤提示:
curl: (28) Operation timed out after 5001 milliseconds with 0 bytes received
我們改造一下代碼,使用 counter.js
來統(tǒng)計 QPS,并限制為 2:
const express = require('express') const counter = require('./counter.js') const app = express() const limit = 2 let cnt = counter() app.get( '/', (req, res, next) => { cnt(1) if (cnt() > limit) { res.writeHead(500, { 'content-type': 'text/pain', }) res.end('exceed limit') return } next() }, async (req, res) => { const buf = Buffer.alloc(1024 * 1024 * 200, 'a') console.log(buf) res.end('end') } ) app.get('/another', async (req, res) => { res.end('another api') }) const listener = app.listen(process.env.PORT || 2048, () => { console.log('Your app is listening on port ' + listener.address().port) }) // counter.js module.exports = function counter(interval = 1000) { let arr = [] return function cnt(number) { const now = Date.now() if (number > 0) { arr.push({ time: now, value: number, }) const newArr = [] // 刪除超出一秒的數(shù)據(jù) for (let i = 0, len = arr.length; i < len; i++) { if (now - arr[i].time > interval) continue newArr.push(arr[i]) } arr = newArr return } // 計算前一秒的數(shù)據(jù)和 let sum = 0 for (let i = arr.length - 1; i >= 0; i--) { const {time, value} = arr[i] if (now - time <= interval) { sum += value continue } break } return sum } }
此時,容器運行正常:
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS 3bd5aa07a3a7 ssr 88.29% 203.1MiB / 512MiB 39.67% 24.5MB / 48.6MB 122MB / 2.81MB 40
雖然此時訪問 /
路由會收到錯誤:
curl -m 5 http://localhost:2048 exceed limit
但是 /another
卻不受影響:
curl -m 5 http://localhost:2048/another another api
由此可見,限流確實是系統(tǒng)進行自我保護的一個比較好的方法。
令牌桶算法
常見的限流算法有“滑動窗口算法”、“令牌桶算法”,我們這里討論 “令牌桶算法” 。在令牌桶算法中,存在一個桶,容量為 burst
。該算法以一定的速率(設為 rate
)往桶中放入令牌,超過桶容量會丟棄。每次請求需要先獲取到桶中的令牌才能繼續(xù)執(zhí)行,否則拒絕。
根據(jù)令牌桶的定義,我們實現(xiàn)令牌桶算法如下:
export default class TokenBucket { private burst: number private rate: number private lastFilled: number private tokens: number constructor(burst: number, rate: number) { this.burst = burst this.rate = rate this.lastFilled = Date.now() this.tokens = burst } setBurst(burst: number) { this.burst = burst return this } setRate(rate: number) { this.rate = rate return this } take() { this.refill() if (this.tokens > 0) { this.tokens -= 1 return true } return false } refill() { const now = Date.now() const elapse = now - this.lastFilled this.tokens = Math.min(this.burst, this.tokens + elapse * (this.rate / 1000)) this.lastFilled = now } }
然后,按照如下方式使用:
const tokenBucket = new TokenBucket(5, 10) if (tokenBucket.take()) { // Do something } else { // refuse }
簡單解釋一下這個算法,調(diào)用 take
時,會先執(zhí)行 refill
先往桶中進行填充。填充的方式也很簡單,首先計算出與上次填充的時間間隔 elapse
毫秒,然后計算出這段時間內(nèi)應該補充的令牌數(shù),因為令牌補充速率是 rate
個/秒,所以需要補充的令牌數(shù)為:
elapse * (this.rate / 1000)
又因為令牌數(shù)不能超過桶的容量,所以補充后桶中的令牌數(shù)為:
Math.min(this.burst, this.tokens + elapse * (this.rate / 1000))
注意,這個令牌數(shù)是可以為小數(shù)的。
令牌桶算法具有以下兩個特點:
- 當外部請求的 QPS
M
大于令牌補充的速率rate
時,長期來看,最終有效的 QPS 會趨向于rate
。這個很好理解,拉的總不可能比吃的多吧。 - 因為令牌桶可以存下
burst
個令牌,所以可以允許短時間的激增流量,持續(xù)的時間為:
T = burst / (M - rate) // rate < M
可以理解為一個水池里面有 burst
的水量,進水的速率為 rate
,出水的速率為 M
,則凈出水速率為 M-rate
,則水池中的水放空的時間即為激增流量的持續(xù)時間。
到此這篇關于React SSR 之限流的文章就介紹到這了,更多相關React SSR內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家!
相關文章
React構(gòu)建簡潔強大可擴展的前端項目架構(gòu)
這篇文章主要為大家介紹了React構(gòu)建簡潔強大可擴展的前端項目架構(gòu)實現(xiàn),有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步,早日升職加薪2022-08-08詳解使用React.memo()來優(yōu)化函數(shù)組件的性能
本文講述了開發(fā)React應用時如何使用shouldComponentUpdate生命周期函數(shù)以及PureComponent去避免類組件進行無用的重渲染,以及如何使用最新的React.memo API去優(yōu)化函數(shù)組件的性能2019-03-03解決React報錯Functions are not valid as 
這篇文章主要為大家介紹了React報錯Functions are not valid as a React child解決詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步,早日升職加薪2022-12-12react?hooks?d3實現(xiàn)企查查股權(quán)穿透圖結(jié)構(gòu)圖效果詳解
這篇文章主要為大家介紹了react?hooks?d3實現(xiàn)企查查股權(quán)穿透圖結(jié)構(gòu)圖效果詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步,早日升職加薪2023-01-01