開發進階:Dotnet Core多路徑非同步終止

老王Plus發表於2021-01-20

今天用一個簡單例子說說非同步的多路徑終止。我儘可能寫得容易理解吧,但今天的內容需要有一定的程式設計能力。

今天這個話題,來自於最近對gRPC的一些技術研究。

話題本身跟gRPC沒有太大關係。應用中,我用到了全雙工資料管道這樣一個相對複雜的概念。

我們知道,全雙工連線是兩個節點之間的連線,但不是簡單的“請求-響應”連線。任何一個節點都可以在任何時間傳送訊息。概念上,還是有客戶端和服務端的區分,但這僅僅是概念上,只是為了區分誰在監聽連線嘗試,誰在建立連線。實際上,做一個雙工的API比做一個“請求-響應”式的API要複雜得多。

由此,延伸出了另一個想法:做個類庫,在庫內部構建雙工管道,供給消費者時,只暴露簡單的內容和熟悉的方式。

    為了防止不提供原網址的轉載,特在這裡加上原文連結:https://www.cnblogs.com/tiger-wang/p/14297970.html

一、開始

假設我們有這樣一個API:

  • 客戶端建立連線
  • 有一個SendAsync訊息從客戶端傳送到伺服器
  • 有一個TryReceiveAsync訊息,試圖等待來自伺服器的訊息(伺服器有訊息傳送為True,返之為False)
  • 伺服器控制資料流終止,如果伺服器傳送完最後一條訊息,則客戶端不再傳送任何訊息。

介面程式碼可以寫成這樣:

interface ITransport<TRequest, TResponse> : IAsyncDisposable
{
    ValueTask SendAsync(TRequest request, CancellationToken cancellationToken);
    ValueTask<(bool Success, TResponse Message)> TryReceiveAsync(CancellationToken cancellationToken);
}

忽略連線的部分,程式碼看起來並不複雜。

下面,我們建立兩個迴圈,並通過列舉器公開資料:

ITransport<TRequest, TResponse> transport;
public async IAsyncEnumerable<TResponse> ReceiveAsync([EnumeratorCancellation] CancellationToken cancellationToken)
{
    while (true)
    {
        var (success, message) =
            await transport.TryReceiveAsync(cancellationToken);
        if (!success) break;
        yield return message;
    }
}

public async ValueTask SendAsync(IAsyncEnumerable<TRequest> data, CancellationToken cancellationToken)
{
    await foreach (var message in data.WithCancellation(cancellationToken))
    {
        await transport.SendAsync(message, cancellationToken);
    }
}

這裡面用到了非同步迭代器相關的概念。如果不明白,可以去看我的另一篇專門討論非同步迭代器的文章,【傳送門】。

二、解決終止標誌

好像做好了,我們用迴圈接收和傳送,並傳遞了外部的終止標誌給這兩個方法。

真的做好了嗎?

還沒有。問題出在終止標誌上。我們沒有考慮到這兩個流是相互依賴的,特別是,我們不希望生產者(使用SendAsync的程式碼)在任何連線失敗的場景中仍然執行。

實際上,會有比我們想像中更多的終止路徑:

  • 我們可能已經為這兩個方法提供了一個外部的終止令牌,並且這個令牌可能已經被觸發
  • ReceiveAsync的消費者可能已經通過WithCancellation提供了一個終止令牌給GetAsyncEnumerator,並且這個令牌可能已經被觸發
  • 我們的傳送/接收程式碼可能出錯了
  • ReceiveAsync的消費者在資料獲取到中途,要終止獲取了 - 一個簡單的原因是處理收到的資料時出錯了
  • SendAsync中的生產者可能發生了錯誤

這只是一些可能的例子,但實際的可能會更多。

本質上,這些都表示連線終止,因此我們需要以某種方式包含所有這些場景,進而允許傳送和接收路徑之間傳達問題。換句話說,我們需要自己的CancellationTokenSource

顯然,這種需求,用庫來解決是比較完美的。我們可以把這些複雜的內容放在一個消費者可以訪問的單一API中:

public IAsyncEnumerable<TResponse> Duplex(IAsyncEnumerable<TRequest> request, CancellationToken cancellationToken = default);

這個方法:

  • 允許它傳入一個生產者
  • 通話它傳入一個外部的終止令牌
  • 有一個非同步的響應返回

使用時,我們可以這樣做:

await foreach (MyResponse item in client.Duplex(ProducerAsync()))
{
    // ... todo
}
async IAsyncEnumerable<MyRequest> ProducerAsync([EnumeratorCancellation] CancellationToken cancellationToken = default)
{
    for (int i = 0; i < 100; i++)
    {
        yield return new MyRequest(i);
        await Task.Delay(100, cancellationToken);
    }
}

上面這段程式碼中,我們ProducerAsync還沒有實現太多內容,目前只是傳遞了一個佔位符。稍後我們可以列舉它,而列舉行為實際上呼叫了程式碼。

回到Duplex。這個方法,至少需要考慮兩種不同的終止方式:

  • 通過cancellationToken傳入的外部令牌
  • 使用過程中可能傳遞給GetAsyncEnumerator()的潛在的令牌

這兒,為什麼不是之前列出的更多種終止方式呢?這兒要考慮到編譯器的組合方式。我們需要的不是一個CancellationToken,而是一個CancellationTokenSource

public IAsyncEnumerable<TResponse> Duplex(IAsyncEnumerable<TRequest> request, CancellationToken cancellationToken = default) => DuplexImpl(transport, request, cancellationToken);

private async static IAsyncEnumerable<TResponse> DuplexImpl(ITransport<TRequest, TResponse> transport, IAsyncEnumerable<TRequest> request, CancellationToken externalToken, [EnumeratorCancellation] CancellationToken enumeratorToken = default)
{
    using var allDone = CancellationTokenSource.CreateLinkedTokenSource(externalToken, enumeratorToken);
    // ... todo
}

這裡,DuplexImpl方法允許列舉終止,但又與外部終止標記保持分離。這樣,在編譯器層面不會被合併。在裡面,CreateLinkedTokenSource反倒像編譯器的處理。

現在,我們有一個CancellationTokenSource,需要時,我們可能通過它來終止迴圈的執行。

using var allDone = CancellationTokenSource.CreateLinkedTokenSource(externalToken, enumeratorToken);
try
{
    // ... todo
}
finally
{
    allDone.Cancel();
}

通過這種方式,我們可以處理這樣的場景:消費者沒有獲取所有資料,而我們想要觸發allDone,但是我們退出了DuplexImpl。這時候,迭代器的作用就很大了,它讓程式變得更簡單,因為用了using,最終裡面的任何內容都會定位到Dispose/DisposeAsync

下一個是生產者,也就是SendAsync。它也是雙工的,對傳入的訊息沒有影響,所以可以用Task.Run作為一個獨立的程式碼路徑開始執行,而如果生產者出現錯誤,則終止傳送。上邊的todo部分,可以加入:

var send = Task.Run(async () =>
{
    try
    {
        await foreach (var message in request.WithCancellation(allDone.Token))
        {
            await transport.SendAsync(message, allDone.Token);
        }
    }
    catch
    {
        allDone.Cancel();
        throw;
    }
}, allDone.Token);

// ... todo: receive

await send;

這裡啟動了一個生產者的並行操作SendAsync。注意,這裡我們用標記allDone.Token把組合的終止標記傳遞給生產者。延遲await是為了允許ProducerAsync方法裡可以使用終止令牌,以滿足複合雙工操作的生命週期要求。

這樣,接收程式碼就變成了:

while (true)
{
    var (success, message) = await transport.TryReceiveAsync(allDone.Token);
    if (!success) break;
    yield return message;
}

allDone.Cancel();

最後,把這部分程式碼合在一起看看:

private async static IAsyncEnumerable<TResponse> DuplexImpl(ITransport<TRequest, TResponse> transport, IAsyncEnumerable<TRequest> request, CancellationToken externalToken, [EnumeratorCancellation] CancellationToken enumeratorToken = default)
{
    using var allDone = CancellationTokenSource.CreateLinkedTokenSource(externalToken, enumeratorToken);
    try
    {
        var send = Task.Run(async () =>
        {
            try
            {
                await foreach (var message in request.WithCancellation(allDone.Token))
                {
                    await transport.SendAsync(message, allDone.Token);
                }
            }
            catch
            {
                allDone.Cancel();
                throw;
            }
        }, allDone.Token);

        while (true)
        {
            var (success, message) = await transport.TryReceiveAsync(allDone.Token);
            if (!success) break;
            yield return message;
        }

        allDone.Cancel();

        await send;
    }
    finally
    {
        allDone.Cancel();
    }
}

三、總結

相關的處理就這麼多。這裡實現的關鍵點是:

  • 外部令牌和列舉器令牌都對allDone有貢獻
  • 傳輸中傳送和接收程式碼使用allDone.Token
  • 生產者列舉使用allDone.Token
  • 任何情況下退出列舉器,allDone都會被終止
    • 如果傳輸接收錯誤,則allDone被終止
    • 如果消費者提前終止,則allDone被終止
  • 當我們收到來自伺服器的最後一條訊息後,allDone被終止
  • 如果生產者或傳輸傳送錯誤,allDone被終止

最後多說一點,關於ConfigureAwait(false)

預設情況下,await包含一個對SynchronizationContext.Current的檢查。除了表示額外的上下文切換之外,在UI應用程式的情況下,它也意味著在UI執行緒上執行不需要在UI執行緒上執行的程式碼。庫程式碼通常不需要這樣做。因此,在庫程式碼中,通常應該在所有用到await的地方使用. configureawait (false)來繞過這個檢查。而在一般應用程式的程式碼中,應該預設只使用await而不使用ConfigureAwait,除非你知道你在做什麼。

微信公眾號:老王Plus

掃描二維碼,關注個人公眾號,可以第一時間得到最新的個人文章和內容推送

本文版權歸作者所有,轉載請保留此宣告和原文連結

相關文章