Savez-vous quels sont les scénarios d'utilisation de Context dans Golang ?

La colonne suivante du tutoriel golang vous présentera les scénarios d'utilisation de Context dans golang. J'espère qu'elle sera utile aux amis dans le besoin !

Scénarios d'utilisation de Context dans Golang

Context a été inclus dans la bibliothèque standard depuis Go1.7. Son utilisation principale, en une phrase, est de contrôler le cycle de vie de la goroutine. Lorsqu'une tâche informatique est reprise par une goroutine et que nous voulons abandonner la tâche informatique de la goroutine pour une raison quelconque (timeout ou sortie forcée), alors ce contexte est utilisé.

Cet article aborde principalement certains scénarios d'utilisation du contexte en golang :

Scénario 1 : appel RPC

Il y en a 4 sur la goroutine principale RPC et RPC2/3/4 sont demandés en parallèle. Ici, nous espérons qu'après l'échec de la requête RPC2, une erreur sera renvoyée directement et RPC3/4 cessera de continuer à calculer. À ce stade, le contexte est utilisé.

La mise en œuvre spécifique de ceci est la suivante.

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()
}

Bien sûr, j'utilise waitGroup ici pour m'assurer que la fonction principale ne se termine pas tant que tous les appels RPC ne sont pas terminés.

Dans la fonction Rpc, le premier paramètre est un CancelContext. Ce Context est un microphone Lors de la création du CancelContext, un écouteur (ctx) et un microphone (fonction d'annulation) sont renvoyés. Toutes les goroutines détiennent cet écouteur (ctx). Lorsque la goroutine principale veut dire à toutes les goroutines qu'elle est sur le point de se terminer, elle indique à toutes les goroutines les informations de fin via la fonction d'annulation. Bien sûr, toutes les goroutines doivent avoir une logique intégrée pour gérer le signal de fin d'écoute (ctx->Done()). Nous pouvons regarder à l'intérieur de la fonction Rpc et utiliser une sélection pour déterminer lequel des ctx est effectué et l'appel rpc en cours se termine en premier.

Ce waitGroup et l'un des appels RPC notifient toute la logique RPC. En fait, il existe un package qui l'a déjà fait pour nous. groupe d'erreurs. Pour une utilisation spécifique de ce package errorGroup, veuillez consulter l'exemple de test de ce package.

Certaines personnes peuvent craindre que notre Cancel() ici soit appelé plusieurs fois. L'appel Cancel dans le package contextuel est idempotent. Vous pouvez l'appeler plusieurs fois en toute confiance.

Jetons un coup d'oeil ici. La fonction Rpc ici est en fait une requête « bloquante » dans notre exemple Si cette requête est implémentée en utilisant http.Get ou http.Post, en fait, La Goroutine de la fonction Rpc. est terminé, mais le véritable http.Get inside n'est pas terminé. Par conséquent, vous devez comprendre qu'il est préférable que la fonction ici soit "non bloquante", comme http.Do, et qu'elle peut ensuite être interrompue d'une manière ou d'une autre. Par exemple, comme cet exemple dans cet article Cancel http.Request using Context :

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
    }
  }
}

Il utilise http.Client.Do, puis lors de la réception de ctx.Done, il termine par appeler transport.CancelRequest.
Nous pouvons également faire référence à net/dail/DialContext
En d'autres termes, si vous souhaitez que le package que vous implémentez soit "arrêtable/contrôlable", alors dans la fonction que vous implémentez, il est préférable de Peut recevoir un Contexte fonction et gérer Context.Done.

Scénario 2 : PipeLine

Le modèle de pipeline est un modèle de chaîne de montage Plusieurs ouvriers sur la chaîne de montage ont n produits et les assemblent un par un. En fait, l'implémentation du modèle pipeline n'a rien à voir avec le contexte. Nous pouvons également utiliser chan pour implémenter le modèle pipeline sans contexte. Mais pour contrôler l’ensemble du pipeline, Context doit être utilisé. L’exemple de cet article Pipeline Patterns in Go en est une très bonne illustration. Voici une description approximative de ce code.

Il y a trois travailleurs de pipeline dans runSimplePipeline. lineListSource est responsable de diviser les paramètres un par un pour la transmission, lineParser est responsable du traitement des chaînes dans int64 et le récepteur détermine si les données sont disponibles en fonction de la valeur spécifique. Toutes leurs valeurs de retour ont essentiellement deux canaux, un pour transmettre les données et un pour transmettre les erreurs. (chaîne <-chan, erreur <-chan) a essentiellement deux valeurs, l'une est le contexte, qui est utilisé pour le contrôle de la transmission vocale, et l'autre est (dans <-chan) le produit d'entrée.

On peut voir que dans les fonctions spécifiques de ces trois Workers, switch est utilisé pour gérer le cas <-ctx.Done(). Il s'agit du contrôle-commande sur la ligne de production.

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
}

Scénario 3 : Demande de délai d'attente

Lorsque nous envoyons une requête RPC, nous souhaitons souvent imposer une limite de délai d'attente à cette demande. Lorsqu'une requête RPC dépasse 10 secondes, elle sera automatiquement déconnectée. Bien sûr, nous pouvons également réaliser cette fonction en utilisant CancelContext (démarrez une nouvelle goroutine, cette goroutine contient la fonction d'annulation, et lorsque le temps est écoulé, la fonction d'annulation est appelée).

Comme cette exigence est très courante, le package de contexte implémente également cette exigence : timerCtx. Les méthodes d'instanciation spécifiques sont WithDeadline et WithTimeout.

La logique spécifique de timerCtx est d'appeler ctx.cancel via time.AfterFunc.

Exemple officiel :

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"
    }
}

C'est aussi une méthode courante pour ajouter un timeout dans le client http

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()

Comment définir un timeout sur le serveur http ?

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的冲突问题了。

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!