前言
在golang中，context.Context可以用來用來設(shè)置截止日期、同步信號，傳遞請求相關(guān)值的結(jié)構(gòu)體。 與 goroutine 有比較密切的關(guān)系。
在web程序中，每個Request都需要開啟一個goroutine做一些事情，這些goroutine又可能會開啟其他的 goroutine去訪問后端資源,比如數(shù)據(jù)庫、RPC服務(wù)等,它們需要訪問一些共享的資源，比如用戶身份信息、認(rèn)證token、請求截止時間等 這時候可以通過Context，來跟蹤這些goroutine，并且通過Context來控制它們， 這就是Go語言為我們提供的Context，中文可以理解為“上下文”。
簡單看一下Context結(jié)構(gòu)：
type Context interface {
Deadline() (deadline time.Time, ok bool)
Done() <-chan struct{}
Err() error
Value(key interface{}) interface{}
}
- Deadline方法是獲取設(shè)置的截止時間的意思，第一個返回值是截止時間，到了這個時間點，Context會自動發(fā)起取消請求； 第二個返回值ok==false時表示沒有設(shè)置截止時間，如果需要取消的話，需要調(diào)用取消函數(shù)(CancleFunc)進行取消。
- Done方法返回一個只讀的chan，類型為struct{}，在goroutine中，如果該方法返回的chan可以讀取，則意味著parent context已經(jīng)發(fā)起了取消請求， 我們通過Done方法收到這個信號后，就應(yīng)該做清理操作，然后退出goroutine，釋放資源。之后，Err 方法會返回一個錯誤，告知為什么 Context 被取消。
- Err方法返回取消的錯誤原因，Context被取消的原因。
- Value方法獲取該Context上綁定的值，是一個鍵值對，通過一個Key才可以獲取對應(yīng)的值，這個值一般是線程安全的。
常用的
// 傳遞一個父Context作為參數(shù)，返回子Context，以及一個取消函數(shù)用來取消Context。
func WithCancel(parent Context) (ctx Context, cancel CancelFunc)
// 和WithCancel差不多，它會多傳遞一個截止時間參數(shù)，意味著到了這個時間點，會自動取消Context，
// 當(dāng)然我們也可以不等到這個時候，可以提前通過取消函數(shù)進行取消。
func WithDeadline(parent Context, deadline time.Time) (Context, CancelFunc)
// WithTimeout和WithDeadline基本上一樣，這個表示是超時自動取消，是多少時間后自動取消Context的意思
func WithTimeout(parent Context, timeout time.Duration) (Context, CancelFunc)
//WithValue函數(shù)和取消Context無關(guān)，它是為了生成一個綁定了一個鍵值對數(shù)據(jù)的Context，
// 綁定的數(shù)據(jù)可以通過Context.Value方法訪問到，這是我們實際用經(jīng)常要用到的技巧，一般我們想要通過上下文來傳遞數(shù)據(jù)時，可以通過這個方法，
// 如我們需要tarce追蹤系統(tǒng)調(diào)用棧的時候。
func WithValue(parent Context, key, val interface{}) Context
一、HTTP請求的Context傳遞到異步任務(wù)的坑
看下面例子：我們將http的context傳遞到goroutine 中：
package main
import (
"context"
"fmt"
"net/http"
"time"
)
func IndexHandler(resp http.ResponseWriter, req *http.Request) {
ctx := req.Context()
go func(ctx context.Context) {
for {
select {
case <-ctx.Done():
fmt.Println("gorountine off,the err is: ", ctx.Err())
return
default:
fmt.Println(333)
}
}
}(ctx)
time.Sleep(1000)
resp.Write([]byte{1})
}
func main() {
http.HandleFunc("/test1", IndexHandler)
http.ListenAndServe("127.0.0.1:8080", nil)
}
結(jié)果：
從上面結(jié)果來看，在http請求返回之后，傳入gorountine的context被cancel掉了，如果不巧，你在gorountine中進行一些http調(diào)用或者rpc調(diào)用傳入了這個context，那么對應(yīng)的請求也將會被cancel掉。因此，在http請求中異步任務(wù)出去時，如果這個異步任務(wù)中需要進行一些rpc類請求，那么就不要直接使用或者繼承http的context，否則將會被cancel。
糾其原因：http請求再結(jié)束后，將會cancel掉這個context，所以異步出去的請求中收到的context是被cancel掉的。
下面來看下源代碼：
ListenAndServe–>Server：Server方法中有一個大的for循環(huán)，這個for循環(huán)中，針對每個請求，都會起一個協(xié)程進行處理。
serve方法處理一個連接中的請求，并在一個請求serverHandler{c.server}.ServeHTTP(w, w.req)結(jié)束后cancel掉對應(yīng)的context：
// Serve a new connection.
func (c *conn) serve(ctx context.Context) {
c.remoteAddr = c.rwc.RemoteAddr().String()
ctx = context.WithValue(ctx, LocalAddrContextKey, c.rwc.LocalAddr())
defer func() {
if err := recover(); err != nil && err != ErrAbortHandler {
const size = 64 << 10
buf := make([]byte, size)
buf = buf[:runtime.Stack(buf, false)]
c.server.logf("http: panic serving %v: %v\n%s", c.remoteAddr, err, buf)
}
if !c.hijacked() {
c.close()
c.setState(c.rwc, StateClosed, runHooks)
}
}()
if tlsConn, ok := c.rwc.(*tls.Conn); ok {
if d := c.server.ReadTimeout; d != 0 {
c.rwc.SetReadDeadline(time.Now().Add(d))
}
if d := c.server.WriteTimeout; d != 0 {
c.rwc.SetWriteDeadline(time.Now().Add(d))
}
if err := tlsConn.Handshake(); err != nil {
// If the handshake failed due to the client not speaking
// TLS, assume they're speaking plaintext HTTP and write a
// 400 response on the TLS conn's underlying net.Conn.
if re, ok := err.(tls.RecordHeaderError); ok && re.Conn != nil && tlsRecordHeaderLooksLikeHTTP(re.RecordHeader) {
io.WriteString(re.Conn, "HTTP/1.0 400 Bad Request\r\n\r\nClient sent an HTTP request to an HTTPS server.\n")
re.Conn.Close()
return
}
c.server.logf("http: TLS handshake error from %s: %v", c.rwc.RemoteAddr(), err)
return
}
c.tlsState = new(tls.ConnectionState)
*c.tlsState = tlsConn.ConnectionState()
if proto := c.tlsState.NegotiatedProtocol; validNextProto(proto) {
if fn := c.server.TLSNextProto[proto]; fn != nil {
h := initALPNRequest{ctx, tlsConn, serverHandler{c.server}}
// Mark freshly created HTTP/2 as active and prevent any server state hooks
// from being run on these connections. This prevents closeIdleConns from
// closing such connections. See issue https://golang.org/issue/39776.
c.setState(c.rwc, StateActive, skipHooks)
fn(c.server, tlsConn, h)
}
return
}
}
// HTTP/1.x from here on.
ctx, cancelCtx := context.WithCancel(ctx)
c.cancelCtx = cancelCtx
defer cancelCtx()
c.r = &connReader{conn: c}
c.bufr = newBufioReader(c.r)
c.bufw = newBufioWriterSize(checkConnErrorWriter{c}, 4<<10)
for {
// 從連接中讀取請求
w, err := c.readRequest(ctx)
if c.r.remain != c.server.initialReadLimitSize() {
// If we read any bytes off the wire, we're active.
c.setState(c.rwc, StateActive, runHooks)
}
.....
.....
// Expect 100 Continue support
req := w.req
if req.expectsContinue() {
if req.ProtoAtLeast(1, 1) && req.ContentLength != 0 {
// Wrap the Body reader with one that replies on the connection
req.Body = &expectContinueReader{readCloser: req.Body, resp: w}
w.canWriteContinue.setTrue()
}
} else if req.Header.get("Expect") != "" {
w.sendExpectationFailed()
return
}
c.curReq.Store(w)
// 啟動協(xié)程后臺讀取連接
if requestBodyRemains(req.Body) {
registerOnHitEOF(req.Body, w.conn.r.startBackgroundRead)
} else {
w.conn.r.startBackgroundRead()
}
// HTTP cannot have multiple simultaneous active requests.[*]
// Until the server replies to this request, it can't read another,
// so we might as well run the handler in this goroutine.
// [*] Not strictly true: HTTP pipelining. We could let them all process
// in parallel even if their responses need to be serialized.
// But we're not going to implement HTTP pipelining because it
// was never deployed in the wild and the answer is HTTP/2.
serverHandler{c.server}.ServeHTTP(w, w.req)
/**
* 重點在這兒，處理完請求后將會調(diào)用w.cancelCtx()方法cancel掉context
**/
w.cancelCtx()
if c.hijacked() {
return
}
w.finishRequest()
if !w.shouldReuseConnection() {
if w.requestBodyLimitHit || w.closedRequestBodyEarly() {
c.closeWriteAndWait()
}
return
}
c.setState(c.rwc, StateIdle, runHooks)
c.curReq.Store((*response)(nil))
if !w.conn.server.doKeepAlives() {
// We're in shutdown mode. We might've replied
// to the user without "Connection: close" and
// they might think they can send another
// request, but such is life with HTTP/1.1.
return
}
if d := c.server.idleTimeout(); d != 0 {
c.rwc.SetReadDeadline(time.Now().Add(d))
if _, err := c.bufr.Peek(4); err != nil {
return
}
}
c.rwc.SetReadDeadline(time.Time{})
}
}
至此，我們知道，http請求在正常結(jié)束后將會主動cancel掉context。此外，在請求異常時候也會主動cancel掉context（cancel目的就是為了快速失?。?，具體可見w.conn.r.startBackgroundRead() 其中的實現(xiàn)。
在日常開發(fā)中，我們知道有時候會存在客戶端超時情況，和ctx相關(guān)的原因可歸納如下：文章來源：http://www.zghlxwxcb.cn/news/detail-472723.html
- 服務(wù)端收到的請求的request context被cancel掉。
- 客戶端本身收到context deadline exceeded錯誤
- 服務(wù)端業(yè)務(wù)業(yè)務(wù)使用了http的context，但沒有用于做rpc等需要建立連接的任務(wù)，那么客戶端即使收到了context canceled的錯誤，服務(wù)端實際上還是在繼續(xù)執(zhí)行業(yè)務(wù)代碼。
- 服務(wù)端業(yè)務(wù)業(yè)務(wù)使用了http的context，并用于做rpc等需要建立連接的任務(wù)，那么客戶端收到context canceled錯誤，并且服務(wù)端也會在對應(yīng)的rpc等建立連接任務(wù)處返回context cancled的錯誤。
最后，如果context cancel掉了，但是業(yè)務(wù)又在繼續(xù)執(zhí)行，有時候并不是我們想要的結(jié)果，因為這會占用資源，因此我們可以主動在業(yè)務(wù)中通過監(jiān)聽context Done的信號來做context canceled的處理，從而可以達到快速失敗，節(jié)約資源的目的。文章來源地址http://www.zghlxwxcb.cn/news/detail-472723.html
到了這里，關(guān)于【Golang】golang中http請求的context傳遞到異步任務(wù)的坑的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
