Azure环境下依赖事件数据的定时器触发处理器设计及优化咨询

现有方案优化建议 #

1. 临时存储优化（解决Storage Table查询效率低问题） #

你当前考虑的两种方案中，处理完记录直接删除的收益远高于定期清空，除此之外还有更适配场景的方案可选：

• 优先选用Azure Queue Storage作为临时存储：事件上报后直接将查询密钥写入队列即可，无需提前拉取全量数据存储，天然支持先进先出，不存在历史数据累积问题，消费效率远高于Storage Table，同时成本更低
• 若必须保留临时结构化存储能力，可改用无服务器模式的Azure Cosmos DB，给表设置TTL自动删除已处理的记录，无需手动维护清理逻辑；将分区键设置为「消费状态+时间戳」，查询待消费记录时可精准命中分区，避免全表扫描，查询效率比Storage Table高3~5倍
• 若坚持使用Storage Table，除了处理完直接删除记录外，额外将分区键设置为消费状态+日期、行键设置为事件ID，查询待消费记录时可直接定位分区，大幅提升查询速度

2. 下游API负载优化（解决单事件单调用负载过高问题） #

合并多笔记录查询为单次调用是非常合理的优化方向，具体可落地的方案如下：

• 取消ConsumerApp的实时拉取逻辑，先将事件携带的查询密钥暂存到队列/缓存中，等定时器触发ProcessorApp时，批量取出所有未处理的密钥，合并为单次批量查询请求调用下游服务，仅需要下游服务适配批量密钥查询接口即可，API调用次数可降低一个数量级
• 若下游服务暂时不支持批量查询，可增加Azure Redis Cache层，对相同密钥的查询结果设置1~2个定时器周期间的缓存，重复触发的相同密钥无需再次调用下游API，命中率较高的场景下可降低70%以上的API调用量
• 若要保留ConsumerApp的拉取逻辑，可给拉取动作设置1~5分钟的滑动窗口，窗口内收集到的同类型事件合并为一次批量拉取，再存入存储层，避免频繁调用下游接口

全新轻量化架构方案（可选） #

整套流程可以简化为3步，无需维护两个Azure Function和中间存储层，运维成本大幅降低：

1. 事件上报到Event Grid Topic后，直接推送到Event Grid高级订阅的批处理队列，设置每N个事件或者和处理器运行间隔对齐的固定时长合并为一批事件投递
2. 定时器触发Azure Function时，直接消费队列中的一批事件，提取所有查询密钥合并为批量请求调用下游服务拉取全量数据
3. 拉取数据后按指定列分组生成文件，直接存入Blob容器，全程无需中间临时存储待消费记录

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