首先，你的架构场景（Java Jersey服务+ C#客户端+基于用户的事件推送）确实需要兼顾跨语言兼容性、低客户端负担和实时性，下面给你几个可行的方向，结合你的需求逐一分析：

一、基于WebSocket的双向通信方案 #

WebSocket是跨语言兼容的双向通信标准，完美适配你“服务主动推送事件给指定客户端”的需求，还能避免轮询的开销和TCP直连的客户端维护成本。

具体实现思路： #

• C#客户端登录时，除了注册用户名/主机信息，还和Java Jersey服务建立WebSocket连接，服务端用一个映射表（比如Map<String, WebSocketSession>）把每个WebSocket连接和对应的用户名绑定。
• 当Java服务收到JIRA的分配消息后，直接通过对应用户的WebSocketSession推送工单数据。
• 客户端收到推送后处理（确认/移除），并通过WebSocket回传操作结果给服务端，服务端同步更新数据模型即可。

技术选型： #

• Java Jersey本身支持JSR-356标准的WebSocket，直接集成即可，无需额外复杂框架。
• C#客户端可以用.NET原生的System.Net.WebSockets.ClientWebSocket（适配.NET Core/.NET 5+），或者更易用的第三方库WebSocketSharp，两者都能和Java服务完美兼容。

优势： #

• 实时性接近TCP直连，没有轮询的延迟和无效请求。
• 客户端不需要开放公网TCP端口（WebSocket基于HTTP/HTTPS升级，默认用80/443端口，防火墙友好）。
• 服务端统一维护连接和用户映射，客户端只需处理消息接收和回传，负担极轻。

二、基于MQTT的发布-订阅模式 #

如果你的场景需要更高的可靠性（比如客户端离线时消息可暂存，上线后自动接收），MQTT是非常合适的选择，天然支持跨语言和基于主题的筛选推送。

具体实现思路： #

• 部署一个轻量的MQTT broker（比如Eclipse Mosquitto，开源且资源占用低）。
• C#客户端登录时，订阅以自己用户名为前缀的主题（比如workassign/{username}），同时把用户名和客户端信息注册到Java服务。
• Java服务收到JIRA消息后，根据用户名找到对应主题，发布工单消息到该主题，客户端自动接收。
• 客户端处理完工单后，发布确认消息到主题workassign/{username}/ack，Java服务订阅这个主题同步状态。

技术选型： #

• Java端用Eclipse Paho MQTT Client连接broker并发布消息。
• C#端用MQTTnet（当前最流行的.NET MQTT库），支持所有.NET版本，和Java端兼容无压力。

优势： #

• 自带消息持久化、离线重连、QoS等级控制，可靠性拉满。
• 客户端无需和服务端直接建立长连接，只和broker通信，架构更解耦。
• 天然支持基于主题的用户筛选，完全匹配你“基于用户条件推送”的核心需求。

三、改进版轮询方案（短轮询/长轮询） #

如果暂时不想引入新的技术栈，也可以优化现有的轮询方案，降低不必要的开销：

长轮询（Long Polling）： #

• 客户端向Java服务发送请求，服务端如果没有该用户的新工单，就hold住请求，直到有新消息或者超时再返回。
• 客户端收到响应后立即重新发起请求，实现“准实时”的效果。

优势： #

• 完全基于HTTP，不需要修改现有REST架构的基础，客户端改动极小。
• 相比短轮询，大幅减少了无效请求的数量，降低服务端压力。

注意点： #

• Java Jersey需要支持异步请求来实现长轮询，避免线程被hold住耗尽。

方案对比总结 #

结合你的需求，WebSocket是最接近你理想状态的方案——既满足服务主动推送、基于用户筛选的要求，又跨语言兼容，客户端和服务端的开发成本都不高；如果需要应对客户端经常离线的场景，MQTT会是更可靠的选择。

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