socket.io在node cluster模式下的解决方案

Posted 2023-03-29

参考技术A 默认地，一个long-polling连接将被首先创建，接着会发送一个websocket upgrading请求，服务端响应该请求，从而建立起websocket通信。
流程如下：

由于cluster下多个进程间拥有自己独立的运行空间，这就要求从long-polling通信升级到websocket通信的过程中，多次请求都落到最初创建session的服务端，否则，就会导致unknown session id，造成通信失败的后果。我们可以将这个过程称为 session sticky 。

归根结底，解决这个问题的关键就在于how to sticky session。一般地，我们可以通过ip hash的方式，即将来源于同一个IP的所有请求，负载到相同的服务器，这样就达到了最终目的。此外，我们也可以通过其他hash的方式来进行session sticky，只要该方式能够唯一标识用户即可（例如cookie）。

具体解决场景基于nginx，node cluster和socket.io实现。
基本思路是，nginx作为负载服务器处理所有socket.io path请求，根据ip hash进行session sticky。最终，将同一个客户端来源请求负载到相同的socket.io server上。

本文仅仅讲述了node cluster模式下的session sticky方案，在实际项目中，服务器架构可能如下图所示，仅供参考：

https://nodejs.org/api/cluster.html#cluster_how_it_works
https://socket.io/docs/using-multiple-nodes