原因是：单台服务器并发量最多两三万，不够大。
客户端和某台服务器可建立IP隧道
想要更大并发量可以对负载均衡器再做集群
负载均衡模块在整个程序中的位置如下图
首先解压nginx的安装包 （tar zxvf）；
进入nginx安装包中编译加入--with-stream参数激活tcp负载均衡模块
~/package/nginx-1.12.2# ./configure --with-stream
~/package/nginx-1.12.2# make && make install
编译完成后，默认安装在 /usr/local/nginx
$ cd /usr/local/nginx/
/usr/local/nginx$ ls
可执行文件在sbin目录里面,配置文件在conf目录里面。
nginx -s reload #重新加载配置文件启动
nginx -s stop #停止nginx服务
nginx.conf的补充内容如下
events {
worker_connections 1024; #最大连接数1024，默认为512
}
#-------------------------------添加的内容------------------------
stream {
upstream MyServer {
# max_fails最大失败次数，若超过则判断连接失败
# fail_timeout，发出心跳包超过改时间没收到回包就算一次失败
server 127.0.0.1:6000 weight=1 max_fails=3 fail_timeout=30s;
server 127.0.0.1:6002 weight=1 max_fails=3 fail_timeout=30s;
}
server {
proxy_connect_timeout 1s;
listen 8000;
proxy_pass MyServer; # 所有连接到8000端口的请求都往MyServer指定的主机里负载均衡
tcp_nodelay on;
}
}
#---------------------------------------------------------------
其中 weight表示权重
上面配置也就是说，客户端连接服务器时端口号填8000就是连接到负载均衡器上，它会帮助我们把请求分发到 127.0.0.1:6000和127.0.0.1:6002端口上.
配置修改后可用 ./nginx -s reload平滑重启。
注意：这么修改了之后，客户端连接服务端的地址都要为127.0.0.1:8000，也就是连接到负载均衡器上而不是确定的服务器端口上。
sudo netstat -anp查看nginx进程是否启动在80端口监听
服务器通过负载均衡器按权重分别接收一个连接
当客户端登录到不同的服务器时，应该如何解决跨服务器通信问题？
假如采用两两服务器之间建立连接
上图设计相当于在服务器网络之间进行广播。这样的设计使得各个服务器之间耦合度太高，不利于系统扩展，并且会占用系统大量的socket资源，各服务器之间的带宽压力很大，不能够节省资源给更多的客户端提供服务，因此绝对不是一个好的设计。
集群部署的服务器之间进行通信，最好的方式就是引入中间件消息队列，解耦各个服务器，使整个系统松耦合，提高服务器的响应能力，节省服务器的带宽资源，如下图所示：
集群分布式环境中，经常使用的中间件消息队列ActiveMQ、RabbitMQ、Kafka等，都是应用场景广泛并且性能很好的消息队列，供集群服务器之间，分布式服务之间进行消息通信。
发布订阅是观察者模式的使用场景。
消息队列是长连接跨服务器聊天通用方法,工作流程大致如下
客户端c1在某个服务器上连接后，要把该连接在redis队列上订阅一个通道ch1
别的客户端c2在不同的服务器上登录要给c1发消息，会直接发到redis队列上的通道ch1,客户端c1可接受到信息发布到通道ch1
要开一个单独线程进行监听通道上的事件，有消息给业务层上报。
当服务器发现发送的对象id没有在自己的_userConnMap上，就要往消息队列上publish，消息队列就会把消息发布给订阅者。
redis服务器后台运行输入如下指令
redis-server --daemonize yes
发布订阅功能要开两条redis连接即两个redisContext *,一条用于订阅和接收消息，一条用于发布消息，这么做的原因是因为订阅 SUBSCRIBE时会进入阻塞状态，代码如下
// 向redis指定通道channel发布消息
bool Redis::publish(int channel, string message)
{
redisReply *reply = (redisReply *)redisCommand(_publish_context, "PUBLISH %d %s", channel, message);
if (nullptr == reply)
{
cerr << "publish command failed!" << endl;
return false;
}
freeReplyObject(reply);
return true;
}
// 向redis指定通道subscribe订阅消息
bool Redis::subscribe(int channel)
{
// SUBSCRIBE命令本身会造成线程阻塞等待通道里发生消息，这里只做订阅通道，不接受通道消息
// 通道消息接收专门在 observer_channel_message 函数中的独立线程中进行
// 只负责发送命令，不阻塞接收redis server响应消息，否则和notifyMsg线程抢占响应资源
if (REDIS_ERR == redisAppendCommand(this->_subscribe_context, "SUBSCRIBE %d", channel))
{
cerr << "subscribe command failed!" << endl;
return false;
}
// redisBufferWrite可循环发送缓冲区累积的命令，知道缓冲区数据发送完毕（done被置1）
int done = 0;
while (!done)
{
if (REDIS_ERR == redisBufferWrite(this->_subscribe_context, &done))
{
cerr << "subscribe command failed!" << endl;
return false;
}
}
return true;
}
本项目使用hiredis进行redis编程,加入redis的发布订阅消息队列后，业务层的改动大致如下：
chatservice构造中连接redis即调用connect,并设置上报消息的回调，connect中会开启一条新线程调用 observer_channel_message函数进行循环接收订阅通道上的消息，有消息到来给业务层上报。subscribe channeluserid不在map中，但状态为online)就publishunsubscribe channel若不满意Nginx负载均衡效果前面可加LVS（Linux Virtual Server）
负载均衡器 - 一致性哈希算法学有余力可了解
IP隧道
IP隧道（IP Tunnel）是一种虚拟的网络连接方式，它允许将一个IP数据包传输到另一个IP网络中，同时保留原始数据包的源和目的地址。它通常用于将两个不同的IP网络连接起来，使它们看起来像一个单一的网络。IP隧道的主要目的是为了解决网络互联问题，特别是当两个不兼容的网络需要进行通信时。
在IP隧道中，数据包被封装在另一个IP数据包中，以便在一个网络上传输到另一个网络。这个封装过程称为“隧道ing”，隧道的两端点被称为“入口”和“出口”。入口点将原始IP数据包封装在另一个IP数据包中，将其发送到出口点。出口点接收到封装后的数据包，然后解封装出原始的IP数据包，并将其传送到目的地。
IP隧道的优点是它可以让不同的网络连接起来，同时保持原有的网络拓扑结构和地址分配。但是，它也会带来一些缺点，例如会增加网络延迟和降低网络性能。