Kennen Sie die Nutzungsszenarien von Context in Golang?

Die folgende Kolumne stellt die Verwendungsszenarien von Context in Golang aus der Kolumne Golang-Tutorial vor. Ich hoffe, dass es für Freunde hilfreich ist, die es brauchen!

Verwendungsszenarien von Context in Golang

Context ist seit Go1.7 in der Standardbibliothek enthalten. Sein Hauptzweck besteht in einem Satz darin, den Lebenszyklus von Goroutine zu steuern. Wenn eine Rechenaufgabe von einer Goroutine übernommen wird und wir die Rechenaufgabe der Goroutine aus irgendeinem Grund (Zeitüberschreitung oder erzwungenes Beenden) abbrechen möchten, wird dieser Kontext verwendet.

In diesem Artikel werden hauptsächlich einige Verwendungsszenarien des Kontexts in Golang besprochen:

Szenario 1: RPC-Aufruf

Es gibt 4 RPCs in der Haupt-Goroutine, und RPC2/3/4 werden parallel angefordert. Wir hoffen, dass hier Nachher Die RPC2-Anfrage schlägt fehl, ein Fehler wird direkt zurückgegeben und RPC3/4 wird gestoppt, um die Berechnung fortzusetzen. Zu diesem Zeitpunkt wird Kontext verwendet.

Die konkrete Umsetzung davon ist wie folgt.

package main

import (
	"context"
	"sync"
	"github.com/pkg/errors"
)

func Rpc(ctx context.Context, url string) error {
	result := make(chan int)
	err := make(chan error)

	go func() {
		// 进行RPC调用，并且返回是否成功，成功通过result传递成功信息，错误通过error传递错误信息
		isSuccess := true
		if isSuccess {
			result <- 1
		} else {
			err <- errors.New("some error happen")
		}
	}()

	select {
		case <- ctx.Done():
			// 其他RPC调用调用失败
			return ctx.Err()
		case e := <- err:
			// 本RPC调用失败，返回错误信息
			return e
		case <- result:
			// 本RPC调用成功，不返回错误信息
			return nil
	}
}


func main() {
	ctx, cancel := context.WithCancel(context.Background())

	// RPC1调用
	err := Rpc(ctx, "http://rpc_1_url")
	if err != nil {
		return
	}

	wg := sync.WaitGroup{}

	// RPC2调用
	wg.Add(1)
	go func(){
		defer wg.Done()
		err := Rpc(ctx, "http://rpc_2_url")
		if err != nil {
			cancel()
		}
	}()

	// RPC3调用
	wg.Add(1)
	go func(){
		defer wg.Done()
		err := Rpc(ctx, "http://rpc_3_url")
		if err != nil {
			cancel()
		}
	}()

	// RPC4调用
	wg.Add(1)
	go func(){
		defer wg.Done()
		err := Rpc(ctx, "http://rpc_4_url")
		if err != nil {
			cancel()
		}
	}()

	wg.Wait()
}

Natürlich verwende ich hier waitGroup, um sicherzustellen, dass die Hauptfunktion nicht beendet wird, bis alle RPC-Aufrufe abgeschlossen sind.

In der Rpc-Funktion ist der erste Parameter ein CancelContext, bei dem es sich um ein Mikrofon handelt. Beim Erstellen des CancelContext werden ein Listener (ctx) und ein Mikrofon (Cancel-Funktion) zurückgegeben. Alle Goroutinen enthalten diesen Listener (ctx). Wenn die Haupt-Goroutine allen Goroutinen mitteilen möchte, dass sie enden sollen, teilt sie allen Goroutinen die Endinformationen über die Abbruchfunktion mit. Natürlich müssen alle Goroutinen über eine integrierte Logik verfügen, um das Listener-Endsignal (ctx->Done()) zu verarbeiten. Wir können einen Blick in die Rpc-Funktion werfen und mithilfe einer Auswahl bestimmen, welcher von ctx ausgeführt wird und der aktuelle Rpc-Aufruf zuerst endet.

Diese waitGroup und einer der RPC-Aufrufe benachrichtigen die gesamte RPC-Logik. Tatsächlich gibt es ein Paket, das dies bereits für uns erledigt hat. Fehlergruppe. Informationen zur spezifischen Verwendung dieses errorGroup-Pakets finden Sie im Testbeispiel dieses Pakets.

Einige Leute befürchten möglicherweise, dass unser cancel() hier mehrmals aufgerufen wird. Der cancel-Aufruf im Kontextpaket ist idempotent. Sie können es bedenkenlos mehrmals aufrufen.

Wir könnten hier auch einen Blick darauf werfen. Die Rpc-Funktion ist in unserem Beispiel tatsächlich eine „blockierende“ Anfrage. Wenn diese Anfrage mithilfe von http.Get oder http.Post implementiert wird, handelt es sich tatsächlich um die Goroutine der Rpc-Funktion vorbei, aber das eigentliche http.Get inside ist noch nicht beendet. Daher müssen Sie verstehen, dass die Funktion hier am besten „nicht blockierend“ ist, z. B. http.Do, und dann auf irgendeine Weise unterbrochen werden kann. Zum Beispiel wie in diesem Beispiel in diesem Artikel http.Request mit Kontext abbrechen:

func httpRequest(
  ctx context.Context,
  client *http.Client,
  req *http.Request,
  respChan chan []byte,
  errChan chan error
) {
  req = req.WithContext(ctx)
  tr := &http.Transport{}
  client.Transport = tr
  go func() {
    resp, err := client.Do(req)
    if err != nil {
      errChan <- err
    }
    if resp != nil {
      defer resp.Body.Close()
      respData, err := ioutil.ReadAll(resp.Body)
      if err != nil {
        errChan <- err
      }
      respChan <- respData
    } else {
      errChan <- errors.New("HTTP request failed")
    }
  }()
  for {
    select {
    case <-ctx.Done():
      tr.CancelRequest(req)
      errChan <- errors.New("HTTP request cancelled")
      return
    case <-errChan:
      tr.CancelRequest(req)
      return
    }
  }
}

Es ​​verwendet http.Client.Do, und wenn dann ctx.Done empfangen wird, endet es mit dem Aufruf von transport.CancelRequest.
Wir können auch auf net/dail/DialContext verweisen
Mit anderen Worten, wenn Sie möchten, dass das von Ihnen implementierte Paket „stoppbar/kontrollierbar“ ist, dann ist es am besten, einen Kontext in der von Ihrem Paket implementierten Funktion und Handles zu erhalten Kontext.Fertig.

Szenario 2: Pipeline

Das Pipeline-Modell ist ein Fließbandmodell. Mehrere Arbeiter am Fließband haben n Produkte und montieren sie einzeln. Tatsächlich hat die Implementierung des Pipeline-Modells nichts mit dem Kontext zu tun. Wir können Chan auch verwenden, um das Pipeline-Modell ohne Kontext zu implementieren. Für die Steuerung der gesamten Pipeline muss jedoch Kontext verwendet werden. Das Beispiel in diesem Artikel „Pipeline-Muster in Go“ ist eine sehr gute Veranschaulichung. Hier ist eine kurze Beschreibung dieses Codes.

In runSimplePipeline gibt es drei Pipeline-Worker. lineListSource ist für die Aufteilung der Parameter nacheinander für die Übertragung verantwortlich, lineParser ist für die Verarbeitung von Zeichenfolgen in int64 verantwortlich und sink bestimmt anhand des spezifischen Werts, ob die Daten verfügbar sind. Alle ihre Rückgabewerte haben grundsätzlich zwei Kanäle, einen für die Übergabe von Daten und einen für die Übergabe von Fehlern. (<-chan-Zeichenfolge, <-chan-Fehler) Die Eingabe hat im Wesentlichen zwei Werte, einer ist der Kontext, der für die Sprachübertragungssteuerung verwendet wird, und der andere ist (in <-chan) das Eingabeprodukt.

Wir können sehen, dass in den spezifischen Funktionen dieser drei Worker der Schalter verwendet wird, um den Fall <-ctx.Done() zu behandeln. Dies ist die Befehlssteuerung in der Produktionslinie.

func lineParser(ctx context.Context, base int, in <-chan string) (
	<-chan int64, <-chan error, error) {
	...
	go func() {
		defer close(out)
		defer close(errc)

		for line := range in {

			n, err := strconv.ParseInt(line, base, 64)
			if err != nil {
				errc <- err
				return
			}

			select {
			case out <- n:
			case <-ctx.Done():
				return
			}
		}
	}()
	return out, errc, nil
}

Szenario 3: Timeout-Anfrage

Wenn wir eine RPC-Anfrage senden, möchten wir dieser Anfrage häufig ein Timeout-Limit auferlegen. Wenn eine RPC-Anfrage länger als 10 Sekunden dauert, wird die Verbindung automatisch getrennt. Natürlich können wir diese Funktion auch mithilfe von CancelContext erreichen (starten Sie eine neue Goroutine, diese Goroutine enthält die Abbruchfunktion und wenn die Zeit abgelaufen ist, wird die Abbruchfunktion aufgerufen).

Da diese Anforderung sehr häufig vorkommt, implementiert das Kontextpaket auch diese Anforderung: timerCtx. Die spezifischen Instanziierungsmethoden sind WithDeadline und WithTimeout.

Die spezifische Logik in timerCtx besteht darin, ctx.cancel über time.AfterFunc aufzurufen.

Offizielles Beispiel:

package main

import (
    "context"
    "fmt"
    "time"
)

func main() {
    ctx, cancel := context.WithTimeout(context.Background(), 50*time.Millisecond)
    defer cancel()

    select {
    case <-time.After(1 * time.Second):
        fmt.Println("overslept")
    case <-ctx.Done():
        fmt.Println(ctx.Err()) // prints "context deadline exceeded"
    }
}

Es ist auch eine gängige Methode, eine Zeitüberschreitung im http-Client hinzuzufügen.

uri := "https://httpbin.org/delay/3"
req, err := http.NewRequest("GET", uri, nil)
if err != nil {
	log.Fatalf("http.NewRequest() failed with '%s'\n", err)
}

ctx, _ := context.WithTimeout(context.Background(), time.Millisecond*100)
req = req.WithContext(ctx)

resp, err := http.DefaultClient.Do(req)
if err != nil {
	log.Fatalf("http.DefaultClient.Do() failed with:\n'%s'\n", err)
}
defer resp.Body.Close()

Wie stelle ich eine Zeitüberschreitung auf dem http-Server ein?

package main

import (
	"net/http"
	"time"
)

func test(w http.ResponseWriter, r *http.Request) {
	time.Sleep(20 * time.Second)
	w.Write([]byte("test"))
}


func main() {
	http.HandleFunc("/", test)
	timeoutHandler := http.TimeoutHandler(http.DefaultServeMux, 5 * time.Second, "timeout")
	http.ListenAndServe(":8080", timeoutHandler)
}

我们看看TimeoutHandler的内部，本质上也是通过context.WithTimeout来做处理。

func (h *timeoutHandler) ServeHTTP(w ResponseWriter, r *Request) {
  ...
		ctx, cancelCtx = context.WithTimeout(r.Context(), h.dt)
		defer cancelCtx()
	...
	go func() {
    ...
		h.handler.ServeHTTP(tw, r)
	}()
	select {
    ...
	case <-ctx.Done():
		...
	}
}

场景四：HTTP服务器的request互相传递数据

context还提供了valueCtx的数据结构。

这个valueCtx最经常使用的场景就是在一个http服务器中，在request中传递一个特定值，比如有一个中间件，做cookie验证，然后把验证后的用户名存放在request中。

我们可以看到，官方的request里面是包含了Context的，并且提供了WithContext的方法进行context的替换。

package main

import (
	"net/http"
	"context"
)

type FooKey string

var UserName = FooKey("user-name")
var UserId = FooKey("user-id")

func foo(next http.HandlerFunc) http.HandlerFunc {
	return func(w http.ResponseWriter, r *http.Request) {
		ctx := context.WithValue(r.Context(), UserId, "1")
		ctx2 := context.WithValue(ctx, UserName, "yejianfeng")
		next(w, r.WithContext(ctx2))
	}
}

func GetUserName(context context.Context) string {
	if ret, ok := context.Value(UserName).(string); ok {
		return ret
	}
	return ""
}

func GetUserId(context context.Context) string {
	if ret, ok := context.Value(UserId).(string); ok {
		return ret
	}
	return ""
}

func test(w http.ResponseWriter, r *http.Request) {
	w.Write([]byte("welcome: "))
	w.Write([]byte(GetUserId(r.Context())))
	w.Write([]byte(" "))
	w.Write([]byte(GetUserName(r.Context())))
}

func main() {
	http.Handle("/", foo(test))
	http.ListenAndServe(":8080", nil)
}

在使用ValueCtx的时候需要注意一点，这里的key不应该设置成为普通的String或者Int类型，为了防止不同的中间件对这个key的覆盖。最好的情况是每个中间件使用一个自定义的key类型，比如这里的FooKey，而且获取Value的逻辑尽量也抽取出来作为一个函数，放在这个middleware的同包中。这样，就会有效避免不同包设置相同的key的冲突问题了。

Das obige ist der detaillierte Inhalt vonKennen Sie die Nutzungsszenarien von Context in Golang?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!