Polly v8中OnRetry回调传递自定义上下文的实现及池使用疑问

问题描述 #

我在使用Polly v8的新ResiliencePipeline API时，希望通过ResiliencePipeline.ExecuteAsync()结合重试策略处理异步操作。需要在构建ResiliencePipeline时（通过ResiliencePipelineBuilder）定义的OnRetry回调里访问自定义上下文，但发现回调只能拿到OnRetryArguments对象，推测只能通过ResilienceContext的Properties属性传递自定义数据。

目前我是通过从ResilienceContextPool.Shared获取实例、配置后传给ExecuteAsync重载，执行完成再归还实例的方式实现，但觉得这个流程有点复杂。想请教：

• 这是不是推荐的实现方式？
• 有没有更简便的方法被我忽略了？
• ResilienceContextPool.Shared是不是就是为这类场景设计的？

补充代码 #

我写了下面这个扩展方法，测试下来可以正常工作：

public static class ResiliencePipelineExtensions
{
    public static async ValueTask ExecuteAsync(this ResiliencePipeline resilience, Func<CancellationToken, ValueTask> action, string operation, IDictionary<string, object> context, CancellationToken cancellationToken)
    {
        var resilienceContext = ResilienceContextPool.Shared.Get(operation, cancellationToken);

        foreach (var property in context)
        {
            resilienceContext.Properties.Set(new ResiliencePropertyKey<object>(property.Key), property.Value);
        }

        try
        {
            await resilience.ExecuteAsync(ctx => action(ctx.CancellationToken), resilienceContext);
        }
        finally
        {
            ResilienceContextPool.Shared.Return(resilienceContext);
        }
    }
}

回答 #

1. 这是官方推荐的实现方式 #

Polly v8的设计中，ResilienceContext是传递自定义上下文的标准载体，而通过对象池获取、归还实例是官方明确推荐的使用模式——因为ResilienceContext是可变类型，池化能避免频繁创建销毁对象带来的性能损耗，同时保证每次调用的上下文隔离性。你当前的实现完全符合官方设计意图。

2. 可以简化扩展方法的实现 #

你可以借助ResilienceContext实现的IAsyncDisposable接口，用using语句自动替代手动写finally归还实例的逻辑，让代码更简洁：

public static class ResiliencePipelineExtensions
{
    public static async ValueTask ExecuteAsync(this ResiliencePipeline resilience, Func<CancellationToken, ValueTask> action, string operation, IDictionary<string, object> context, CancellationToken cancellationToken)
    {
        using var resilienceContext = ResilienceContextPool.Shared.Get(operation, cancellationToken);
        
        foreach (var (key, value) in context)
        {
            resilienceContext.Properties.Set(new ResiliencePropertyKey<object>(key), value);
        }

        await resilience.ExecuteAsync(ctx => action(ctx.CancellationToken), resilienceContext);
    }
}

另外，如果你的自定义上下文有固定结构，建议定义强类型的ResiliencePropertyKey，既能避免装箱拆箱的性能损耗，还能提升类型安全性：

// 定义强类型属性键
public static class CustomContextKeys
{
    public static readonly ResiliencePropertyKey<string> OrderId = new("OrderId");
    public static readonly ResiliencePropertyKey<int> RetryCount = new("RetryCount");
}

// 在扩展方法中设置强类型属性
resilienceContext.Properties.Set(CustomContextKeys.OrderId, "12345");

后续在OnRetry回调中读取也更直观：

new RetryStrategyOptions
{
    OnRetry = args =>
    {
        if (args.Context.Properties.TryGetValue(CustomContextKeys.OrderId, out var orderId))
        {
            // 使用orderId做自定义逻辑
        }
        return ValueTask.CompletedTask;
    }
}

3. ResilienceContextPool.Shared正是为此场景设计的 #

Polly v8引入ResilienceContextPool的核心目的就是复用ResilienceContext实例，减少高频调用场景下的内存分配和垃圾回收压力。Shared静态实例是全局默认的对象池，适用于绝大多数不需要自定义池配置的场景；如果你的应用有特殊性能需求，也可以创建自定义的ResilienceContextPool实例，但一般情况下用Shared就足够了。

内容的提问来源于stack exchange，提问作者sharpener