多个 Socket.io 应用程序进程导致每个客户端套接字重复连接和断开连接答案

【问题标题】：Multiple Socket.io app processes cause each client socket connects and disconnects repeatedly多个 Socket.io 应用程序进程导致每个客户端套接字重复连接和断开连接
【发布时间】：2019-01-30 08:48:05
【问题描述】：

我正在使用 Socket.io 开发 nodejs 应用程序，并且我使用 PM 2 在单个进程中进行了测试，并且没有错误。然后我转移到我们的生产环境（我们使用谷歌云计算实例）。

我运行 3 个应用程序进程，一个 iOS 客户端连接到服务器。顺便说一句，iOS 客户端不会保持套接字连接。它不会向服务器发送断开连接。但它已断开连接并重新连接到服务器。它不断发生。

我不知道为什么服务器会断开客户端。如果您对此有任何提示或答案，我将不胜感激。

【问题讨论】：

标签： node.js socket.io haproxy

【解决方案1】：

这可能是因为请求最终出现在另一台机器上，而不是它们源自的机器上。

直接来自Socket.io Docs: Using Multiple Nodes：

如果您计划在不同进程或机器之间分配连接负载，则必须确保与特定会话 ID 关联的请求连接到发起它们的进程。

你需要做什么：

启用session affinity，也就是粘性会话。
如果您想使用房间/命名空间，您还需要使用集中式内存存储来跟踪命名空间信息，例如 Redis/Redis Adapter。

但我建议你阅读我发布的文档，自从我上次实现类似的东西以来，事情可能已经发生了一些变化。

【讨论】：

【解决方案2】：

默认情况下，socket.io 客户端通过几个 http 请求“测试”到其服务器的连接。如果您有多个服务器请求，并且这些初始 http 请求每次都不会发送到完全相同的服务器，那么 socket.io 连接将永远不会正确建立并且不会切换到 webSocket 并且它将继续尝试使用 http 轮询.

有两种方法可以解决此问题。

您可以将您的客户端配置为假设 webSocket 协议可以工作。这将使用一个且只有一个 http 连接启动连接，然后该连接将立即升级到 webSocket 协议（在此之上运行 socket.io）。在 socket.io 中，这是一个在初始连接中指定的 transport 选项。
您可以将服务器基础结构配置为粘性，以便来自给定客户端的请求始终返回到完全相同的服务器。有很多方法可以做到这一点，具体取决于您的服务器架构以及服务器之间的负载平衡方式。

如果您的服务器将任何客户端状态保留在服务器本地（而不是在所有服务器都访问的共享数据库中），那么您甚至需要断开连接并重新连接才能回到同一服务器，您将需要粘性连接作为您唯一的解决方案。您可以在 socket.io 网站here 上阅读有关粘性会话的更多信息。

【讨论】：

【解决方案3】：

感谢您的回复。

我终于弄清楚了这个问题。该问题是由 Google Cloud Load Balancer 中后端服务的 TTL 引起的。默认 TTL 为 30 秒，它使每个套接字连接都尝试断开并重新连接。

所以我将值更新为 3600s，然后我可以保持连接。

【讨论】：