时间戳

首页 > 解决方案 > Azure 服务总线侦听器打开太多 TCP 连接（耗尽）

c# - Azure 服务总线侦听器打开太多 TCP 连接（耗尽）

问题描述

我们有几个服务总线侦听器在应用服务内作为连续的 Azure Webjobs 运行。总而言之，有 12 个侦听器 Web 作业在同一个 S1 应用服务计划上运行。环境很小，每天总共有大约 1000-10000 条消息。最近我们部署了一个新的侦听器（一个定期向原始主题重新发送 DLQ 消息最多 24 小时和 10 次重试（指数退避）的侦听器），昨天我们在托管应用服务上收到一条 TCP/IP 耗尽错误消息。在 S1 上，这意味着 webjobs 总共打开了超过 2000 个 TCP 连接。
总而言之，我们无法解释为什么听众如此渴望 TCP 连接。每个人都在他们的应用程序生命周期中使用一个 Topic-/QueueReceiver，并且还使用一个单例 HttpClient 来连接到目标 API。从理论上讲，这应该意味着每个侦听器一次打开的 TCP 连接永远不会超过 10 个。

我分析了代码，但没有发现 TCP 连接需求高的原因。

所有侦听器都大致像这样工作（.NET 控制台应用程序，在应用服务中作为连续的 Azure Webjobs 托管）：

public static async Task Main(string[] args)
{
    var configuration = GetConfiguration();

    // Setup dependencies (e.g. Singleton HttpClient)
    IServiceCollection serviceCollection = new ServiceCollection();
    ConfigureServices(serviceCollection, configuration);

    IServiceProvider serviceProvider = serviceCollection.BuildServiceProvider();
    var factory = serviceProvider.GetService<TopicReceiverFactory<Model>>();
    var receiver = await factory.CreateAsync();
    receiver.ReceiveMessages();

    Console.ReadLine();
}

// ctor of the receiver used above
public QueueReceiver(QueueConfiguration configuration, IHandler<T> handler, ILogger<IReceiver> logger)
        : base(logger, handler)
{
    this.configuration = configuration;

    this.Client = new QueueClient(
    this.configuration.ConnectionString,
    this.configuration.QueueName,
    this.configuration.ReceiveMode);
}

// The ReceiveMessages Method used in Main
public void ReceiveMessages()
{
    var messageHandlerOptions = new MessageHandlerOptions(this.HandleExceptionReceivedAsync)
    {
        MaxConcurrentCalls = this.configuration.MaxConcurrentCalls,
        AutoComplete = false
    };

    this.Register(messageHandlerOptions);
}

protected void Register(MessageHandlerOptions messageHandlerOptions)
{
    if (messageHandlerOptions == null)
    {
        throw new ArgumentNullException(nameof(messageHandlerOptions));
    }

    this.Client.RegisterMessageHandler(this.ProcessMessageAsync, messageHandlerOptions);
}

ProcessMessage大致有这样的逻辑：调用特定实体的handler（将消息发布到api），如果成功：完成消息；如果不成功的关键异常（例如 JsonSerializerException 因为消息的格式错误）直接死信。轻微异常会导致内置重试（最多十次）。

预计 TCP 连接永远不会耗尽。环境中发生的事情并不多。

编辑：我发现从侦听器到服务总线的出站连接是问题的根源。应用服务的“TCP 连接”分析器显示以下信息： 出站 TCP 连接

标签： c#azure.net-coreazureservicebusazure-webjobs

解决方案

我们找到了问题的根源。考虑以下架构：具有多个主题和一个队列的服务总线命名空间。消息被发送到服务总线侦听器接收和处理消息的主题。如果无法处理消息，它们将被转发到中央错误处理队列。在此队列中，一个侦听器正在接收消息并读取消息上的 DeadLetterSource-Property。在此属性中，有关于原始主题的信息。

现在问题来了：目前我们正在为每条消息创建一个 TopicClient。发生这种情况是因为此侦听器不需要事先知道有哪些主题，从而降低了可重用性。然而，正如我们现在发现的那样，这是不可持续的，因为您耗尽了 TCP 连接。

解决方案：我们通过配置引入主题名称，以便此侦听器可以为整个应用程序生活方式的每个主题创建一个 TopicClient。本质上，有 n-Singleton TopicClient 实例同时运行。

推荐阅读