一文搞懂如何實現(xiàn)Go 超時控制
為什么需要超時控制?
- 請求時間過長,用戶側(cè)可能已經(jīng)離開本頁面了,服務(wù)端還在消耗資源處理,得到的結(jié)果沒有意義
- 過長時間的服務(wù)端處理會占用過多資源,導(dǎo)致并發(fā)能力下降,甚至出現(xiàn)不可用事故
Go 超時控制必要性
Go 正常都是用來寫后端服務(wù)的,一般一個請求是由多個串行或并行的子任務(wù)來完成的,每個子任務(wù)可能是另外的內(nèi)部請求,那么當(dāng)這個請求超時的時候,我們就需要快速返回,釋放占用的資源,比如goroutine,文件描述符等。
服務(wù)端常見的超時控制
- 進程內(nèi)的邏輯處理
- 讀寫客戶端請求,比如HTTP或者RPC請求
- 調(diào)用其它服務(wù)端請求,包括調(diào)用RPC或者訪問DB等
沒有超時控制會怎樣?
為了簡化本文,我們以一個請求函數(shù) hardWork 為例,用來做啥的不重要,顧名思義,可能處理起來比較慢。
func hardWork(job interface{}) error { time.Sleep(time.Minute) return nil } func requestWork(ctx context.Context, job interface{}) error { return hardWork(job) }
這時客戶端看到的就一直是大家熟悉的畫面
<img src="https://gitee.com/kevwan/static/raw/master/doc/images/loading.jpg" width="25%">
絕大部分用戶都不會看一分鐘菊花,早早棄你而去,空留了整個調(diào)用鏈路上一堆資源的占用,本文不究其它細(xì)節(jié),只聚焦超時實現(xiàn)。
下面我們看看該怎么來實現(xiàn)超時,其中會有哪些坑。
第一版實現(xiàn)
大家可以先不往下看,自己試著想想該怎么實現(xiàn)這個函數(shù)的超時,第一次嘗試:
func requestWork(ctx context.Context, job interface{}) error { ctx, cancel := context.WithTimeout(ctx, time.Second*2) defer cancel() done := make(chan error) go func() { done <- hardWork(job) }() select { case err := <-done: return err case <-ctx.Done(): return ctx.Err() } }
我們寫個 main 函數(shù)測試一下
func main() { const total = 1000 var wg sync.WaitGroup wg.Add(total) now := time.Now() for i := 0; i < total; i++ { go func() { defer wg.Done() requestWork(context.Background(), "any") }() } wg.Wait() fmt.Println("elapsed:", time.Since(now)) }
跑一下試試效果
➜ go run timeout.go
elapsed: 2.005725931s
超時已經(jīng)生效。但這樣就搞定了嗎?
goroutine 泄露
讓我們在main函數(shù)末尾加一行代碼看看執(zhí)行完有多少goroutine
time.Sleep(time.Minute*2) fmt.Println("number of goroutines:", runtime.NumGoroutine())
sleep 2分鐘是為了等待所有任務(wù)結(jié)束,然后我們打印一下當(dāng)前goroutine數(shù)量。讓我們執(zhí)行一下看看結(jié)果
➜ go run timeout.go
elapsed: 2.005725931s
number of goroutines: 1001
goroutine泄露了,讓我們看看為啥會這樣呢?首先,requestWork 函數(shù)在2秒鐘超時后就退出了,一旦 requestWork 函數(shù)退出,那么 done channel 就沒有g(shù)oroutine接收了,等到執(zhí)行 done <- hardWork(job) 這行代碼的時候就會一直卡著寫不進去,導(dǎo)致每個超時的請求都會一直占用掉一個goroutine,這是一個很大的bug,等到資源耗盡的時候整個服務(wù)就失去響應(yīng)了。
那么怎么fix呢?其實也很簡單,只要 make chan 的時候把 buffer size 設(shè)為1,如下:
done := make(chan error, 1)
這樣就可以讓 done <- hardWork(job) 不管在是否超時都能寫入而不卡住goroutine。此時可能有人會問如果這時寫入一個已經(jīng)沒goroutine接收的channel會不會有問題,在Go里面channel不像我們常見的文件描述符一樣,不是必須關(guān)閉的,只是個對象而已,close(channel) 只是用來告訴接收者沒有東西要寫了,沒有其它用途。
改完這一行代碼我們再測試一遍:
➜ go run timeout.go
elapsed: 2.005655146s
number of goroutines: 1
goroutine泄露問題解決了!
panic 無法捕獲
讓我們把 hardWork 函數(shù)實現(xiàn)改成
panic("oops")
修改 main 函數(shù)加上捕獲異常的代碼如下:
go func() { defer func() { if p := recover(); p != nil { fmt.Println("oops, panic") } }() defer wg.Done() requestWork(context.Background(), "any") }()
此時執(zhí)行一下就會發(fā)現(xiàn)panic是無法被捕獲的,原因是因為在 requestWork 內(nèi)部起的goroutine里產(chǎn)生的panic其它goroutine無法捕獲。
解決方法是在 requestWork 里加上 panicChan 來處理,同樣,需要 panicChan 的 buffer size 為1,如下:
func requestWork(ctx context.Context, job interface{}) error { ctx, cancel := context.WithTimeout(ctx, time.Second*2) defer cancel() done := make(chan error, 1) panicChan := make(chan interface{}, 1) go func() { defer func() { if p := recover(); p != nil { panicChan <- p } }() done <- hardWork(job) }() select { case err := <-done: return err case p := <-panicChan: panic(p) case <-ctx.Done(): return ctx.Err() } }
改完就可以在 requestWork 的調(diào)用方處理 panic 了。
超時時長一定對嗎?
上面的 requestWork 實現(xiàn)忽略了傳入的 ctx 參數(shù),如果 ctx 已有超時設(shè)置,我們一定要關(guān)注此傳入的超時是不是小于這里給的2秒,如果小于,就需要用傳入的超時,go-zero/core/contextx 已經(jīng)提供了方法幫我們一行代碼搞定,只需修改如下:
ctx, cancel := contextx.ShrinkDeadline(ctx, time.Second*2)
Data race
這里 requestWork 只是返回了一個 error 參數(shù),如果需要返回多個參數(shù),那么我們就需要注意 data race,此時可以通過鎖來解決,具體實現(xiàn)參考 go-zero/zrpc/internal/serverinterceptors/timeoutinterceptor.go,這里不做贅述。
完整示例
package main import ( "context" "fmt" "runtime" "sync" "time" "github.com/tal-tech/go-zero/core/contextx" ) func hardWork(job interface{}) error { time.Sleep(time.Second * 10) return nil } func requestWork(ctx context.Context, job interface{}) error { ctx, cancel := contextx.ShrinkDeadline(ctx, time.Second*2) defer cancel() done := make(chan error, 1) panicChan := make(chan interface{}, 1) go func() { defer func() { if p := recover(); p != nil { panicChan <- p } }() done <- hardWork(job) }() select { case err := <-done: return err case p := <-panicChan: panic(p) case <-ctx.Done(): return ctx.Err() } } func main() { const total = 10 var wg sync.WaitGroup wg.Add(total) now := time.Now() for i := 0; i < total; i++ { go func() { defer func() { if p := recover(); p != nil { fmt.Println("oops, panic") } }() defer wg.Done() requestWork(context.Background(), "any") }() } wg.Wait() fmt.Println("elapsed:", time.Since(now)) time.Sleep(time.Second * 20) fmt.Println("number of goroutines:", runtime.NumGoroutine()) }
更多細(xì)節(jié)
請參考 go-zero 源碼:
- go-zero/core/fx/timeout.go
- go-zero/zrpc/internal/clientinterceptors/timeoutinterceptor.go
- go-zero/zrpc/internal/serverinterceptors/timeoutinterceptor.go
項目地址
https://github.com/tal-tech/go-zero
到此這篇關(guān)于一文搞懂如何實現(xiàn)Go 超時控制的文章就介紹到這了,更多相關(guān)Go 超時控制內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
golang進行簡單權(quán)限認(rèn)證的實現(xiàn)
本文主要介紹了golang簡單權(quán)限認(rèn)證的實現(xiàn),文中通過示例代碼介紹的非常詳細(xì),具有一定的參考價值,感興趣的小伙伴們可以參考一下2021-09-09淺談Golang中創(chuàng)建一個簡單的服務(wù)器的方法
這篇文章主要介紹了淺談Golang中創(chuàng)建一個簡單的服務(wù)器的方法,golang中的net/http包對網(wǎng)絡(luò)的支持非常好,這樣會讓我們比較容易的建立起一個相對簡單的服務(wù)器,有一定的參考價值,感興趣的小伙伴們可以參考一下2018-06-06Go語言中的數(shù)據(jù)格式(json、xml?、msgpack、protobuf)使用總結(jié)
在分布式的系統(tǒng)中,因為涉及到數(shù)據(jù)的傳輸,所以一定會進行數(shù)據(jù)的交換,此時就要定義數(shù)據(jù)交換的格式,例如二進制、Json、Xml等等。本文總結(jié)了Go語言中的數(shù)據(jù)格式,對大家的學(xué)習(xí)或工作具有一定的參考借鑒價值,需要的朋友可以參考下2022-07-07Goland激活碼破解永久版及安裝詳細(xì)教程(親測可以)
這篇文章主要介紹了Goland激活碼破解永久版及安裝詳細(xì)教程(親測可以),本文通過實例圖文相結(jié)合給大家介紹的非常詳細(xì),對大家的學(xué)習(xí)或工作具有一定的參考借鑒價值,需要的朋友可以參考下2020-10-10Go錯誤處理之panic函數(shù)和recover函數(shù)使用及捕獲異常方法
這篇文章主要介紹了Go錯誤處理之panic函數(shù)使用及捕獲,本篇探討了如何使用 panic 和 recover 來處理 Go 語言中的異常,需要的朋友可以參考下2023-03-03