持久连接（如通过 WebSocket 维护的连接）本质上会受到中断。 虽然 Azure SignalR 服务旨在实现较高的可靠性和可伸缩性，但偶尔的客户端断开连接是所有连接 Internet 的应用程序必须考虑的现实。
本文介绍客户端断开连接的性质、Azure SignalR 服务如何处理它们（尤其是在服务维护期间）以及如何设计应用程序以最大程度地减少重新连接的影响。
高级指南
1. 连接中断是不可避免的
由于各种原因和源（网络不稳定、浏览器选项卡挂起、负载均衡器重新配置或例行服务维护）可能会发生客户端断开连接。 这些是所有实时应用程序中的正常事件。
开发人员应设计应用程序， 期望会发生断开连接 ，并实现 重试和重新连接逻辑 作为连接生命周期的标准部分。
2. 使重新连接变得轻量级
应尽可能使重新连接轻量化，终端用户不应注意到是否发生了重新连接。 从用户的角度来看，应用将继续正常运行。
查看当前的流程，以确定是否所有依赖于活动 WebSocket 连接的操作真正依赖于它。 在许多应用程序中（如通知、拍卖、聊天、仪表板或协作体验）中，重新连接速度很快 （通常在几秒钟内） 和低影响。 对于涉及敏感数据或事务数据的应用程序，重新连接过程可能更繁重，但请考虑是否可以拆分某些操作并通过REST API接口而不是通过持久连接来执行。
3. 有效处理重新连接
当连接断开时，客户端通常会建立新的连接并恢复通信。 如何处理此重新连接过程极大地影响用户体验和系统可靠性。
如果适用，请使用有状态重新连接
Azure SignalR 服务 支持有状态重新连接 ，使客户端能够恢复其以前的连接，而不会丢失其状态。 当客户端使用相同的 连接 ID 重新连接时（例如，发生临时网络故障并且客户端快速恢复）时，这一点有效。
启用有状态重新连接后，客户端可以继续接收在短暂断开连接时段 （30 秒）期间错过的消息，减少数据丢失，并最大限度地减少最终用户感知到的中断。
使用新连接 ID 重新连接时
如果重新连接会导致不同的连接 ID（例如在完全应用程序重启后），客户端将被视为 Azure SignalR 服务的新连接。 开发人员应明确规划此方案。
如下所示：
- 重新加入客户端以前加入过的群组，
- 从可靠存储库还原会话状态（例如订阅）
- 如果消息传递的保证很重要，则通过从应用程序级别的存储或事件日志中检索错过的消息来处理未接收到的消息。
4. 在大规模重新连接期间管理负载
当大量客户端断开连接并尝试同时重新连接时，这可以在下游组件 （例如身份验证、状态存储或应用程序服务器）上施加额外的负载。 建议识别这些组件并实施 自动缩放策略 ，以吸收重新连接流量的临时峰值。
如果许多客户端一次尝试协商连接，服务可能会限制其中一些请求。 此限制与单位数成正比 - 更多的单位为你提供更高的阈值。 可以在此处了解有关如何将更多单元添加到 SignalR 资源的详细信息。 此外，为了减少限制的可能性，在每次重新连接尝试之前引入一个小随机延迟。 可在此处找到 重试示例。
5. 仔细考虑传输选项和托管模型
- 长时间轮询 和 服务器发送事件（SSE） 是没有 WebSocket 支持的环境的回退，但它们通常 不会提高可靠性。
- 使用自托管的 SignalR 可以让你完全控制维护时间和生命周期管理，但同时也将运营和扩展责任转移到团队。
- Azure SignalR 服务的无服务器模式不会降低连接断开的可能性或影响，因为断开连接是客户端的网络级行为。
服务维护期间断开连接
Azure SignalR 服务团队定期执行维护，以改进性能、可靠性、安全性和功能。
在计划内维护期间，Azure SignalR 服务采用 一种正常关闭策略 来最大程度地减少对已连接客户端的影响：连接在设定的时间范围内 逐渐断开连接 ，从而允许客户端逐步重新连接。
此方法为大多数客户提供了运营效率和用户体验之间的良好平衡。