401-集群聊天服务器为什么要引入负载均衡器

我们使用的socketfd本质上是文件描述符，默认大小是1024个，我们通过一个进程，使用limit调大，一台服务器在我们的32位的linux下并发量：2万左右的并发量，单台的chatserver支持2万左右的用户在线聊天，如果要支持3万，4万用户同时在线聊天就不可以了。如果我们想提供我们聊天服务器的并发能力，让更多的用户可以同时在线聊天，我们要进行集群部署。在水平方向上扩展多台主机，每一台主机运行着独立的chatserver，我们在下图中，引入了3台主机，每一台主机运行着独立的chatserver服务器，可以给用户提供聊天服务，但是，我们在用QQ客户端登录的时候，人家有没有问你想连哪个服务器？不能把选择服务器的决定扔给客户，客户又不知道哪个服务器空闲哪个服务器繁忙。所以，我们在集群聊天服务器，要引入负载均衡器，也叫做方向代理设备，帮我们统一接收客户端的请求，然后根据配置的既定的负载均衡算法，来把客户端的这些请分发到业务服务器chatserver上。

我们将使用nginx负载均衡器，nginx的TCP负载均衡模块可以轻松提供5-6万的并发量。我们一台nginx负载均衡器带上3台chatserver，能够马上把用户的并发量提升到5-6万。解决并发量最直接最简单的方法。如果要提供更大更大的并发量，也是有办法的：我们的负载均衡器本身也可以集群，前端再挂一个LVS（比较底层的负载均衡器）。负载均衡有业务层的负载均衡（业务分发），传输层的负载均衡（TCP,UDP），网络层的负载均衡（通过ip），数据链路层的负载均衡（数据帧）。LVS的并发量轻松到10多万。一台LVS带多台nginx就可以更大进行用户聊天的并发量。

首先，用户在使用客户端的时候，不用去选择连接哪个服务器，客户端软件默认的连接负载均衡器，负载均衡器的角色相当于一个中间的桥梁，连接了客户端和服务器之间的通信，client1先发送请求到负载均衡器，负载均衡器根据配置的既定的负载算法，比如说轮询，按权重，按ip哈希等等，负载均衡器给client1的请求分发到了chatserver1上，相当于client1就登录到了chatserver1上。client2现在登录，通过负载算法，轮询，登录到了chatserver2上。再来client3登录的话，就登录到了chatserver3上。
就这样，分别注册到了3台服务器上。
这样的话，就有效地把不同的客户端用户分发到了不同的服务器上，一台32位的linux带2万，3台就是带6万并发量了。

负载均衡器处理的3件事情如在上图中显示。
聊天服务器是长连接的业务，聊天的链路一直保持着。客户端的请求和服务器的响应都是要经过负载均衡器

也有的方法场景是：负载均衡只是做客户端请求的分发，分发了以后，服务器最终给客户端回复消息的时候是通过建立一条ip隧道，直接把请求响应给相应的客户端，因为负载均衡器可以把客户端的网络信息ip和port保存。

关于心跳见我在基于RPC的分布式TCP通信框架项目的文章。

如果要再扩展一台设备。我们把这个设备的信息添加到负载均衡器上，然后再把负载均衡器重启一下，肯定是不行的，因为此时用户就不能使用了。但是nginx支持平滑启动，可以在不中断服务的前提下去加载配置文件，动态的识别新添加的服务信息。

muduo的【方案5】 ： reactors in process - one loop pre processnginx服务器的网络模块设计，基于进程设计，采用多个Reactors充当I/O进程和工作进程，通过一把accept锁，完美解决多个Reactors的“惊群现象”。