如何实现两个ASP.NET Blazor Server站点间的跨站点通知触发？

现有方案的优缺点分析 #

1. 数据库轮询 #

• 优势：实现门槛极低，完全基于现有共享DbContext就能快速搭建，不需要引入任何新依赖，适合小团队快速落地。
• 劣势：确实存在你提到的两难困境——短间隔轮询会徒增数据库无效查询量，长间隔又会导致通知延迟。如果请求量不大，可以做些优化：比如针对员工站点的活跃时段缩短轮询间隔，非活跃时段拉长；或者只轮询当前登录员工负责的请求类型，缩小查询范围，但本质还是被动等待，实时性体验一般。

2. 重量级消息系统 #

• 优势：可靠性、实时性拉满，能应对高并发场景下的通知需求。
• 劣势：对你的场景来说完全是过度设计，部署维护成本高，学习曲线陡，没必要为了低请求量、允许偶尔丢通知的需求投入这么大的成本。

更适配的轻量替代方案 #

1. SignalR跨站点实时通知 #

两个站点都是Blazor Server，本身就集成了SignalR，可以直接用它做轻量实时通信：

• 实现逻辑：在共享数据项目中添加简单的消息发布逻辑，当客户提交请求时，调用SignalR Hub向员工站点推送通知；员工站点前端通过SignalR Hub接收消息，实时更新通知栏。
• 注意事项：如果两个站点部署在不同服务器，需要配置SignalR跨域；不需要持久化消息，完全符合你“偶尔丢通知也无妨”的需求，开发和部署成本极低，实时性最优。

2. 数据库触发器+极简通知表 #

• 实现逻辑：给请求表添加数据库触发器，当有新请求插入时，将核心信息（请求ID、类型、创建时间）写入一个极简的通知表；员工站点启动后台定时任务，只查询这个通知表的未读记录，处理完成后标记为已读。
• 优势：比全表轮询高效得多，因为仅查询小体量的通知表；触发器能保证消息不会遗漏（除非数据库故障），又不需要额外的消息系统，成本极低。

3. 共享内存缓存（仅限同服务器部署） #

如果两个站点部署在同一台服务器，可以用IMemoryCache共享通知信息：

• 实现逻辑：客户站点提交请求时，将通知信息写入共享缓存；员工站点前端定时从缓存拉取（间隔可以设短，因为内存操作几乎无性能损耗）。
• 劣势：仅限同服务器部署，缓存重启会丢失未处理的通知，但符合你“后续可补查”的需求。

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