IoT EventHub触发Azure Function App并发导致Redis数据损坏问题求解

你设置的实例数限制仅控制了Function App的横向扩展实例数量，没有限制单实例内部的并发调用逻辑：Event Hub触发器默认会在单个实例内对同一个分区拉取多批消息并行处理，这就是你观测到单实例仍有多线程并发读写Redis的核心原因。

1. 配置层面调整（优先操作，无需改代码） #

修改Function App根目录下的host.json配置文件，调整Event Hub触发器的并发参数：

{
  "version": "2.0",
  "extensions": {
    "eventHubs": {
      "maxConcurrentCallsPerPartition": 1,
      "batchCheckpointFrequency": 1,
      "batchSize": 1
    }
  }
}

• maxConcurrentCallsPerPartition: 设为1强制单个分区同一时间仅允许1个调用处理，从触发器层面保证同分区消息串行执行
• batchCheckpointFrequency: 设为1表示每处理完1批消息就提交一次消费偏移量，避免函数重启后重复处理大量已处理消息
• batchSize: 如无需批处理可设为1，每次仅拉取1条消息处理，进一步降低并发风险

另外需确认你的Function App使用了独立专属的Event Hub消费组，不要和其他应用共用消费组，避免偏移量同步混乱导致重复拉取消息。

2. 代码层面兜底（彻底避免并发风险） #

即使配置层面做了限制，也建议增加以下逻辑做兜底防护：

• 新增Redis分布式锁：函数执行核心逻辑前，先通过Redis的SET lock:func_exec NX EX 60命令申请锁，锁超时时间需大于函数最大执行时长，只有拿到锁的线程可以执行读写逻辑，未拿到锁的直接抛出异常触发消息重试即可
• 合并Redis读写为原子操作：将原本的「读Redis→修改→写Redis」逻辑替换为Redis Lua脚本或者内置原子命令（如INCR、HINCRBY等），从Redis底层保证操作的原子性，彻底避免并发读写冲突
• 新增幂等校验：将已经处理完成的Event Hub消息序列号存入Redis，每次执行前先校验当前消息的序列号是否已被处理，已处理的直接跳过，避免重复执行导致数据异常

调整完成后，先向Event Hub写入一批测试消息制造积压，再启动Function App查看调用日志，确认同分区消息按序列号顺序依次执行，且Redis数据更新符合预期即可。

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