基于SignalR与Azure通知中心的非活跃用户消息通知方案咨询

现有定时Azure Functions方案的优化建议 #

• 缩小检查范围，降低资源消耗
  不要每分钟全量扫描未读消息，而是在消息创建时记录待通知标记，或者维护一个「待通知用户-未读消息」的临时队列（比如用Azure Queue Storage）。Functions优先消费队列消息，仅保留低频兜底扫描（比如每小时一次），避免无效的全量查询。
• 精准判断用户活跃状态
  结合用户最后活跃时间（存储在Azure Cosmos DB或SQL中）与SignalR连接状态：当用户通过SignalR断开连接时，实时更新最后活跃时间；推送前判断用户最后活跃时间是否超过阈值（比如30分钟）且存在未读消息，再触发推送，减少误推。
• 批量处理与限流控制
  每次触发Functions时，批量拉取50-100个待通知用户，调用Azure通知中心的批量推送接口，减少API调用次数。同时给Functions设置并发上限，避免短时间内大量请求触发通知中心限流。
• 重试与死信机制
  推送失败的请求（如设备令牌失效、临时网络错误），放入死信队列。单独配置一个处理死信的Functions，每日执行一次，清理失效令牌，对临时错误的请求尝试重新推送。
• 推送内容去重与合并
  对同一用户的多条未读消息，合并成一条推送内容（比如「您有3条未读消息」），避免用户收到轰炸式通知。处理时按用户分组统计未读数量，再生成统一推送内容。

其他实现思路 #

• 事件驱动实时触发
  放弃定时扫描，改用事件触发：新消息创建时，通过Event Grid或Service Bus触发Azure Functions，实时检查消息接收方的活跃状态。若接收方不在SignalR活跃列表且超过活跃阈值，立即调用通知中心推送，时效性远高于定时方案。
• SignalR+Redis状态联动
  用Redis作为SignalR的背板，同时存储用户在线状态：用户上线时加入SignalR分组并标记在线，下线时更新状态为离线。新消息发送时，先通过SignalR推送给在线用户，再直接从Redis读取离线用户列表，调用通知中心推送，状态同步更可靠，无需额外维护活跃列表。
• Azure App Service WebJobs替代Functions
  若后端已部署在Azure App Service，可直接用WebJobs实现定时扫描逻辑，无需单独部署Functions，减少运维成本。WebJobs与主应用共享资源，配置更简洁。
• 个性化推送策略
  不要用固定阈值判断非活跃，结合用户行为数据（通过Azure Application Insights收集）调整推送时机：比如对每日仅登录一次的用户，消息创建后1小时推送；对高频在线用户，离线30分钟后推送，提升推送精准度。

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