Question

我已经在.Net Standard 2.0中开发了基于队列触发器的功能应用程序。当该应用因维护或新版本而关闭时，可能会发生队列中有超过20000条消息的情况。基本上，应用程序使用XMLReader读取每个xml文件的内容并创建一个记录。这些记录直接插入到Azure SQL数据仓库中。但是，当重新启动该应用程序时，由于SQL登录错误，我们会遇到很多依赖性错误。

int f(int x, int y){

  if(x==y)
    return 0;
  if(x>y)
    return -1;
  if(2*x < y){
    int max=f(2*x, y);
    return max;
  }
  else {
    int max=f(x+1,y);
    return max+1;
  }
}

查看数据仓库的统计信息时，我可以看到此时有800多个活动连接。所以我确实知道这可能太多了，但是我怎么解决呢，我认为没有办法限制同时运行的功能Apps的数量，...

如果有人有主意（即使在星期六晚上），也请放心。

PS：在正常操作中，该功能可以正常运行，只是在重新启动时会触发得太快...

Answer 1

我想了解更多有关该应用程序的信息，因为这是加载ASDW的反模式。

更一般的方法是将XML切成小批量文件，然后使用Polybase提取文件。根据您的着陆区的结构，即使重新启动也是非常简单的任务。

您正在运行哪个DWU？该模型的并发效应可能很大，不仅性能低下，而且对当时的其他工作负载也有负面影响。

回复后编辑：

如果必须处理这样的工作负载，则可以将EventHub或Kafka用于Databricks，切碎XML，然后写入ASDW。这是一个很好的示例，每30秒向DW滴加一次微批处理：

https://azure.microsoft.com/en-au/blog/near-real-time-analytics-in-azure-sql-data-warehouse/

这种方法将使用Polybase将数据摄取到ASDW，这将比SQL插入快得多，并提供增强的并发性。

Answer 2

如果您正在使用消费计划，则可能会发生这种情况，因为由于大量队列消息积压，您的功能应用程序正在大规模扩展。在这种情况下，WEBSITE_MAX_DYNAMIC_APPLICATION_SCALE_OUT文档中的here将帮助您限制应用程序运行的虚拟机数量（尽管由于系统在遇到容量限制时的行为方式，所以并非100％保证的限制）

此问题跟踪改善该领域的整体经验，但是没有预计到达时间： https://github.com/Azure/azure-functions-host/issues/1207

如何避免Azure Function App中的Sql超时

2 个答案: