Azure Function SQL触发器缩放异常：高目标工作者数仅单实例执行

场景描述 #

• 涉及一张约400万条记录的SQL表，使用Azure Function的SQL触发器处理数据
• 当前宿主配置：

"sql": {
  "maxBatchSize": 100,
  "pollingIntervalMs": 200,
  "maxChangesPerWorker": 50000,
  "commandTimeout": "00:05:00"
}

• 调整配置参数至较小值后，出现以下日志：

2024-09-01T13:26:42Z [Verbose] Target worker count for '16ace858c406cf50' is '38714'    
2024-09-01T13:26:42Z [Verbose] No enabled functions or scale votes so scaling in

• 现象：尽管目标工作者数极高，但函数仅单工作者运行，扩容控制器未执行扩容操作

用户疑问 #

1. 为何高目标工作者数下Azure Function仍不扩容？
2. 日志信息"No enabled functions or scale votes so scaling in"在此场景下是什么意思？
3. 如何配置才能让Azure Function正常扩容并利用多工作者处理大型SQL表？

1. 高目标工作者数却不扩容的原因 #

目标工作者数是扩容控制器基于负载计算的理论值，实际扩容需要满足两个核心条件：

• 函数必须生成有效的扩容投票：SQL触发器仅在检测到待处理数据量超过当前实例处理能力时，才会向控制器发送扩容请求。如果触发器未识别到待处理负载（比如数据已被单实例处理完毕，或配置错误导致无法读取变更），就不会产生投票，控制器不会执行扩容。
• 函数需处于正常启用状态：日志提示的"no enabled functions"说明可能存在函数未启用、触发器连接配置错误等情况，导致实例无法正常触发，无法生成扩容信号。

另外，过小的pollingIntervalMs（200ms）会导致数据库轮询过于频繁，可能让触发器误判负载状态；而maxChangesPerWorker设置过高，可能让控制器认为单实例足以处理全部负载，无需扩容。

2. 日志信息的含义 #

这条日志的意思是：

• 扩容控制器未收到任何来自函数实例的扩容投票请求，同时检测不到当前有正常启用且能工作的函数实例
• 基于该判断，控制器会执行缩容操作（scaling in），而非扩容。这就是为什么你只看到单实例运行，没有新增工作者的核心原因——控制器不仅没扩容，反而在准备缩减实例数。

3. 配置调整建议 #

针对大型SQL表的处理和扩容需求，按以下方向调整：

触发器配置优化 #

• 合理设置maxChangesPerWorker：对于400万条记录的表，建议降低该值至10000（默认值），让控制器更容易计算出需要多实例分担负载。
• 调整pollingIntervalMs：不要设置过小，建议改为5000ms，避免频繁轮询导致数据库压力过大，同时给实例足够时间处理批次数据，让触发器能准确识别待处理负载。
• 保留合理的maxBatchSize：100的批次大小合理，若单实例处理能力足够，可适当调高至500，提升单实例处理效率。

确保函数正常触发并生成扩容投票 #

• 验证触发器连接配置：确认SQL连接字符串正确，函数拥有表的读写权限，若使用Change Tracking，需确保表已启用该功能。
• 检查函数状态：在Azure门户确认函数处于启用状态，无报错或禁用情况。
• 开启详细日志：启用Diagnostic Logs，查看触发器是否成功读取待处理变更，是否有报错导致无法生成扩容投票。

扩容计划与限制检查 #

• 确保函数使用弹性高级计划或消耗计划，这两个计划支持自动扩容；专用计划需手动调整实例数。
• 检查扩容上限：消耗计划默认最大实例数200，高级计划可调整，确保目标实例数未超过该限制。

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