websocket连接太多导致服务器卡顿怎么办？一招轻松实现横向扩展

2020-05-04

前言

项目中有即时聊天的需求，经过调研我们采用了socket.io自己实现了一个聊天服务器。

开始的一段时间由于用户不是很多，消息的发送接收都还算流畅，最近随着在线用户数量飙升，每过一段时间就会发生发送消息卡顿和接收消息延时的问题，最后只能通过重启socket服务来暂时解决问题。

那有没有办法从根本上解决这个问题呢？

在介绍什么是socket.io之前，不得不先提一下WebSocket。

我们都知道HTTP协议是一种单向的网络通信协议，服务端只能被动响应来自客户端的请求，却不能主动向客户端推送数据。

在WebSocket技术没有出现之前，如果要开发一个需要实时获取服务端数据的Web应用，常见有以下两种方式：ajax轮询和Long Polling。

ajax轮询的原理其实很简单，就是让客户端每隔一小段时间就主动向服务端发送一次请求，如果有新数据客户端就把它显示出来。
可以看出不管有没有新数据，ajax轮询都会定时向服务端发起请求，这会导致服务端不必要的性能消耗，Long Polling就是对ajax轮询的一种改进。客户端向服务端发送请求，服务端不会立即就响应客户端而是会先保持住此次连接，直到有新的数据时才会返回，客户端接收到数据之后再立即发送一个新的请求给服务端，并不断得重复这一过程。

可以看出这两种方式都需要不断的建立连接，但是建立连接是一个比较消耗性能的操作，这个时候如果有一个新的通信协议可以支持客户端和服务端双向通信就好了，所以WebSocket应运而生。

WebSocket是html5新增的一种通信协议。WebSocket协议是一种支持双向通信的协议，它和HTTP协议一样通过TCP来进行数据传输，但是WebSocket又不同于HTTP：

说了这么多，那么WebSocket跟socket.io又是什么关系呢？

一直以来我都以为socket.io只是WebSocket协议的一种实现而已，深入之后才发现这种观点不完全正确。

socket.io是一个基于Node.js技术和WebSocket协议开发的实时的，可双向通信的和基于事件的的开源通信框架。

WebSocke是HTML5新推出的协议，主流浏览器对它的支持还不是很完善，所以socket.io不仅仅实现了WebSocket协议，除此之外它还支持一些其他的通信方式，比如前面我们提到的ajax轮询和Long Polling等，可以根据浏览器的支持程度切换不同的通信方式。

接下来我们就是使用socket.io来实现一个简易的即时聊天的web应用。

先来看一下效果：

下面简单介绍一下实现方式，主要分为客户端和服务端两个部分。

服务端核心代码：

服务端主要定义了3个监听事件，分别用来监听客户端的加入群聊、发送消息和离开群聊事件，服务端在监听到事件后会再通过broadcast.emit方法将消息向全体用户广播。

客户端核心代码：

主要流程：

socket服务端维护连接是一个十分消耗性能的操作，那么大量的连接必然会给服务器带来非常大的性能压力，当单台socket服务器支撑不了时该怎么办呢？

解决方案其实也很简单：分而治之，我们可以将多个socket服务端组成负载均衡集群，再将连接平均分配到每个服务端。

有人也许会提出疑问：多个socket服务端之间怎么通信？比如用户1连接到了socket服务端1，用户2连接到了socket服务端2，那么用户1发的消息怎么广播到socket服务端2呢？

这里就需要提一下redis了，对你没看错，就是那个用作缓存的Redis。

其实Redis除了当作缓存使用之外，它还有一个非常厉害的功能：发布/订阅。

Redis的发布订阅机制包括三个部分：发布者、订阅者和频道。发布者将消息发送到某个频道，那么Redis服务器就会主动将消息推送到订阅了这个频道的所有订阅者。

socket.io正式利用Redis的发布订阅机制来支持分布式部署的：

当客户端1通过emit触发了一个事件到socket服务端1，socket服务端1将这个消息发送到Redis的某个频道，订阅了这个频道的socket服务端2就会收到这个消息，socket服务端2再向连接它的用户广播就行了。

代码增加reids和socket.io-redis模块：

socket.io是一个基于Node.js技术和WebSocket协议开发的实时的，可双向通信的和基于事件的的开源通信框架。除此之外它还兼容ajax轮询和Long Polling等前后端通信方式，我们可以根据浏览器的支持程度进行自由切换。

socket.io非常适合客户端和服务端需要进行实时通信的场景，它利用Redis的发布订阅机制可以实现分布式部署，这让socket服务端横向扩展变得很加容易。