同一Function App下两个Azure Functions无法共享静态ConcurrentDictionary问题咨询

首先明确：同一Function App资源下的同一运行实例内的所有函数，默认共享同一个进程，同进程内的静态变量（包括静态ConcurrentDictionary）是可以互通的，和两个函数是否在同一个类没有关系。你部署后无法共享的核心原因通常是以下几种：

• 使用了消费级（Consumption）计划：触发结束后实例可能被自动回收，下次触发会启动全新进程，之前的内存数据全部重置
• 触发了自动横向扩容：当请求量上升时，Function App会自动创建多个运行实例，每个实例有独立的内存空间，Http请求可能落到实例A写入数据，Timer触发时在实例B运行，自然无法读取到另一个实例的内存数据
• 进程意外重启：部署、配置变更、运行时异常都可能触发进程重启，内存中的静态数据会全部丢失

你可以根据业务场景选以下任意一种方案实现生产者-消费者模式：

方案1：使用消息队列解耦（官方推荐） #

直接把原来的静态ConcurrentDictionary替换为Azure Queue Storage或Azure Service Bus队列：

• HttpTrigger（生产者）收到请求后直接把数据写入队列
• 把原来的TimerTrigger替换为QueueTrigger，自动监听队列消费数据
  这个方案天然支持多实例部署、重试、死信队列等可靠性特性，不需要自己维护共享状态，是Azure Functions下实现该模式的最优解。

方案2：使用分布式缓存存储共享数据 #

如果需要保留定时批量消费的逻辑，可以用Azure Redis缓存存储共享数据：

• 生产者写入数据到Redis的哈希结构，对应原来的ConcurrentDictionary操作
• 消费者定时从Redis读取数据批量处理，处理完成后删除对应缓存键
  这个方案不受实例扩容、进程重启影响，数据一致性可以得到保证。

方案3：强制单实例运行（不推荐生产用） #

如果一定要保留现有内存共享的代码逻辑，需要修改Function App配置：

• 把托管计划从消费级改为专用App Service计划或弹性Premium计划
• 开启Always On配置，防止进程被自动回收
• 把横向扩缩容的最大实例数设置为1，保证永远只有一个运行实例
  这个方案存在单点故障风险，实例重启时内存数据会丢失，仅适合测试或对可靠性要求极低的场景。

你可以在本地启动多个独立的Function Host进程模拟多实例场景：

1. 把项目代码复制到两个独立的文件夹
2. 分别在两个文件夹执行func start命令，指定不同的端口
3. 往第一个进程的Http接口写入测试数据，访问第二个进程的接口/触发Timer逻辑，就能复现静态变量不互通的问题。

注：将两个函数放在同一个类中无法解决该问题，因为问题根源是跨进程的内存隔离，和代码的类结构无关。

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