Ausführliche Erläuterung zur Implementierung der Go-Timeout-Kontrolle

                                                        O Die folgende Tutorial-Kolumne wird von lGolang

eingeführt, um vorzustellen, wie man GO über die Zeit kontrolliert. Ich hoffe, dass es Freunden in Not hilfreich sein wird!

Warum brauchen wir eine Timeout-Kontrolle?

Wenn die Anforderungszeit zu lang ist, hat der Benutzer diese Seite möglicherweise verlassen und der Server verbraucht immer noch Ressourcen für die Verarbeitung, und die erhaltenen Ergebnisse sind bedeutungslos.

Eine zu lange Verarbeitung auf dem Server beansprucht zu viele Ressourcen , was zu einer Verringerung der Parallelität führt.

• Notwendigkeit der Go-Timeout-Kontrolle

Go wird normalerweise zum Schreiben von Back-End-Diensten verwendet Möglicherweise handelt es sich um eine weitere interne Anfrage. Wenn diese Anfrage also abläuft, müssen wir schnell zurückkehren und die belegten Ressourcen wie Goroutine, Dateideskriptoren usw. freigeben.

Gemeinsame Timeout-Kontrolle auf der Serverseite

Logische Verarbeitung innerhalb des Prozesses

Client-Anfragen lesen und schreiben, z. B. HTTP- oder RPC-Anfragen

• Andere Serveranfragen aufrufen, einschließlich RPC-Anrufe oder DB-Zugriffe, usw.
• Was passiert, wenn es keine Timeout-Kontrolle gibt?

Um diesen Artikel zu vereinfachen, nehmen wir eine Anforderungsfunktion hardWork. Es spielt keine Rolle, wofür sie verwendet wird, sie kann langsamer verarbeitet werden.

func hardWork(job interface{}) error {
    time.Sleep(time.Minute)
    return nil}func requestWork(ctx context.Context, job interface{}) error {
  return hardWork(job)}

Zu diesem Zeitpunkt sieht der Client immer den vertrauten Bildschirm

hardWork 为例，用来做啥的不重要，顾名思义，可能处理起来比较慢。

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 <p>这时客户端看到的就一直是大家熟悉的画面</p><p><img src="/static/imghwm/default1.png" data-src="https://img.php.cn/upload/article/000/000/020/ea4492ddee56842b8d2dd9e34d636408-1.jpg?x-oss-process=image/resize,p_40" class="lazy" alt="Ausführliche Erläuterung zur Implementierung der Go-Timeout-Kontrolle"></p><p>绝大部分用户都不会看一分钟菊花，早早弃你而去，空留了整个调用链路上一堆资源的占用，本文不究其它细节，只聚焦超时实现。</p><p>下面我们看看该怎么来实现超时，其中会有哪些坑。</p><h2>
<span class="header-link octicon octicon-link"></span>第一版实现</h2><p>大家可以先不往下看，自己试着想想该怎么实现这个函数的超时，第一次尝试：</p><pre class="brush:php;toolbar:false">func main() {
    const total = 1000
    var wg sync.WaitGroup
    wg.Add(total)
    now := time.Now()
    for i := 0; i <p>我们写个 main 函数测试一下</p><pre class="brush:php;toolbar:false">➜ go run timeout.go
elapsed: 2.005725931s

跑一下试试效果

time.Sleep(time.Minute*2)fmt.Println("number of goroutines:", runtime.NumGoroutine())

超时已经生效。但这样就搞定了吗？

goroutine 泄露

让我们在main函数末尾加一行代码看看执行完有多少goroutine

➜ go run timeout.go
elapsed: 2.005725931s
number of goroutines: 1001

sleep 2分钟是为了等待所有任务结束，然后我们打印一下当前goroutine数量。让我们执行一下看看结果

done := make(chan error, 1)

goroutine泄露了，让我们看看为啥会这样呢？首先，requestWork 函数在2秒钟超时后就退出了，一旦 requestWork 函数退出，那么 done channel 就没有goroutine接收了，等到执行 done 这行代码的时候就会一直卡着写不进去，导致每个超时的请求都会一直占用掉一个goroutine，这是一个很大的bug，等到资源耗尽的时候整个服务就失去响应了。

那么怎么fix呢？其实也很简单，只要 make chan 的时候把 buffer size 设为1，如下：

➜ go run timeout.go
elapsed: 2.005655146s
number of goroutines: 1

这样就可以让 done 不管在是否超时都能写入而不卡住goroutine。此时可能有人会问如果这时写入一个已经没goroutine接收的channel会不会有问题，在Go里面channel不像我们常见的文件描述符一样，不是必须关闭的，只是个对象而已，<code>close(channel) 只是用来告诉接收者没有东西要写了，没有其它用途。

改完这一行代码我们再测试一遍：

panic("oops")

goroutine泄露问题解决了！

panic 无法捕获

让我们把 hardWork 函数实现改成

go func() {
  defer func() {
    if p := recover(); p != nil {
      fmt.Println("oops, panic")
    }
  }()

  defer wg.Done()
  requestWork(context.Background(), "any")}()

修改 main 函数加上捕获异常的代码如下：

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>此时执行一下就会发现panic是无法被捕获的，原因是因为在 <code>requestWork</code> 内部起的goroutine里产生的panic其它goroutine无法捕获。</p><p>解决方法是在 <code>requestWork</code> 里加上 <code>panicChan</code> 来处理，同样，需要 <code>panicChan</code> 的 <code>buffer size</code></p>Die überwiegende Mehrheit der Benutzer wird sich die Chrysantheme nicht eine Minute lang ansehen und Sie vorzeitig verlassen, sodass der gesamte Anruflink viele Ressourcen beansprucht. In diesem Artikel wird nicht auf weitere Details eingegangen , nur Fokus-Timeout-Implementierung. 🎜🎜Schauen wir uns an, wie man Timeout umsetzt und welche Fallstricke es gibt. 🎜🎜🎜🎜Implementierung der ersten Version🎜🎜Sie können unten mit dem Lesen aufhören und versuchen, darüber nachzudenken, wie Sie das Timeout dieser Funktion implementieren können. Erster Versuch:🎜<pre class="brush:php;toolbar:false">ctx, cancel := contextx.ShrinkDeadline(ctx, time.Second*2)

🎜Lassen Sie uns eine Hauptfunktion schreiben, um sie zu testen🎜

package mainimport (
    "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 🎜Führen Sie sie aus Probieren Sie den Effekt aus 🎜rrreee🎜Das Timeout ist wirksam. Aber ist das erledigt? 🎜🎜🎜🎜goroutine durchgesickert🎜🎜Lassen Sie uns am Ende der Hauptfunktion eine Codezeile hinzufügen, um zu sehen, wie viele Goroutinen ausgeführt wurden🎜rrreee🎜sleep 2 Minuten bedeutet, auf das Ende aller Aufgaben zu warten, und dann drucken wir die aus aktuelle Anzahl von Goroutinen. Lass es uns ausführen und das Ergebnis sehen🎜rrreee🎜Die Goroutine ist durchgesickert, mal sehen, warum das passiert? Zunächst wird die Funktion <code>requestWork</code> nach einer Zeitüberschreitung von 2 Sekunden beendet. Sobald die Funktion <code>requestWork</code> beendet wird, kann der <code>Done-Kanal</code> keine Goroutine mehr empfangen Warten Sie, bis beim Ausführen von <code>done  diese Codezeile hängen bleibt und nicht geschrieben werden kann, was dazu führt, dass jede Timeout-Anfrage eine Goroutine belegt. Der gesamte Dienst reagiert nicht mehr, wenn die Ressourcen erschöpft sind. 🎜🎜Wie kann man das Problem beheben? Tatsächlich ist es ganz einfach, die <code>Puffergröße</code> beim <code>make chan</code> wie folgt auf 1 zu setzen: 🎜rrreee🎜Auf diese Weise können Sie <code>done  Kann schreiben, ohne die Goroutine zu blockieren, unabhängig davon, ob es zu einer Zeitüberschreitung kommt. An dieser Stelle könnte jemand fragen, ob es ein Problem gibt, wenn Sie an einen Kanal schreiben, der keine Goroutine hat, um ihn zu empfangen. In Go ist es nicht notwendig, den Kanal zu schließen nur ein Objekt. <code>close(channel)</code> wird nur verwendet, um dem Empfänger mitzuteilen, dass es nichts zu schreiben gibt, und hat keinen anderen Zweck. 🎜🎜Nachdem wir diese Codezeile geändert haben, testen wir sie noch einmal: 🎜rrreee🎜Das Goroutine-Leak-Problem ist gelöst! 🎜🎜🎜🎜Panik kann nicht abgefangen werden🎜🎜Ändern wir die Funktionsimplementierung <code>hardWork</code> in 🎜rrreee🎜Ändern Sie die Funktion <code>main</code> und fügen Sie den Code zum Erfassen der Ausnahme wie folgt hinzu: 🎜rrreee🎜Zu diesem Zeitpunkt werden Sie feststellen, dass die Panik nicht erfasst werden kann. Der Grund dafür ist, dass die in der Goroutine innerhalb von <code>requestWork</code> erzeugte Panik nicht von anderen Goroutinen erfasst werden kann. 🎜🎜Die Lösung besteht darin, <code>panicChan</code> zur Verarbeitung zu <code>requestWork</code> hinzuzufügen. Ebenso muss die <code>Puffergröße</code> von <code>panicChan</code> hinzugefügt werden sei 1 , wie folgt: 🎜<pre class="brush:php;toolbar:false">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>改完就可以在 <code>requestWork</code> 的调用方处理 <code>panic</code> 了。</p><h2>
<span class="header-link octicon octicon-link"></span>超时时长一定对吗？</h2><p>上面的 <code>requestWork</code> 实现忽略了传入的 <code>ctx</code> 参数，如果 <code>ctx</code> 已有超时设置，我们一定要关注此传入的超时是不是小于这里给的2秒，如果小于，就需要用传入的超时，<code>go-zero/core/contextx</code> 已经提供了方法帮我们一行代码搞定，只需修改如下：</p><pre class="brush:php;toolbar:false">ctx, cancel := contextx.ShrinkDeadline(ctx, time.Second*2)

Data race

这里 requestWork 只是返回了一个 error 参数，如果需要返回多个参数，那么我们就需要注意 data race，此时可以通过锁来解决，具体实现参考 go-zero/zrpc/internal/serverinterceptors/timeoutinterceptor.go，这里不做赘述。

完整示例

package mainimport (
    "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 <h2>
<span class="header-link octicon octicon-link"></span>更多细节</h2><p>请参考 <code>go-zero</code> 源码：</p>

• go-zero/core/fx/timeout.go
• go-zero/zrpc/internal/clientinterceptors/timeoutinterceptor.go
• go-zero/zrpc/internal/serverinterceptors/timeoutinterceptor.go

项目地址

github.com/tal-tech/go-zero

欢迎使用 go-zero 并 star 支持我们！

Das obige ist der detaillierte Inhalt vonAusführliche Erläuterung zur Implementierung der Go-Timeout-Kontrolle. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!