android 心跳连接 长连接 简书,设计思路分布式websocket亿万级长连接实时通讯

这个思路yichen是用swoole设计完成的。

一直想写一个websocket框架没时间弄.

研究了几天swoole的相关文档。感觉这个东西挺好，适合做大并发长连接。

准备工作

1，绑定域名，域名绑定到nginx服务期做域名转发

2，搭建redis服务器

3，搭建mysql 服务器

4和5 可以业务量，分别布置多少台服务器。随时增减都不影响

4，搭建http或https服务器 需要安装php+swoole

5，搭建websocket 服务器需要安装php+swoole

nginx 做负载均衡参考

打开 nginx 配置文件

[root@master ~]# vi /etc/nginx/conf.d/default.conf

写轮询配置

websocket 根据域名端口转发即可

upstream websocket{

#后端服务器访问规则

server 192.168.1.115:8080 weight=1; #server1

server 192.168.1.131:8081 weight=1; #server1

server 192.168.1.94:8090 weight=1; #server3

fair;

}

server {

listen 9501;

server_name 192.168.1.131;

location / {

proxy_pass http://websocket;

}

}

http负载均衡根据域名端口转发即可

upstream webhttp{

#后端服务器访问规则

server 192.168.1.115:80 weight=1; #server1

server 192.168.1.131:80 weight=1; #server2

server 192.168.1.94:80 weight=1; #server3

server 192.168.1.131:80 weight=1; #server4

server 192.168.1.94:80 weight=1; #server5

}

server {

listen 80;

server_name 192.168.1.131;

location / {

proxy_pass http://webhttp;

}

}

配置完成后

//检查 nginx 配置是否正确

nginx -t

//重新加载 nginx 配置

service nginx reload

【一】websocket 服务器集群

一套代码可以用在多台服务器进行运行，互相之间不通信。

需要设置http通信管道 ip和密码,仅允许指定ip和密码的客户端发来转发消息。

这个服务器是用于维持保持与用户端的长连接；相当于是个服务器与用户端的中间人。

功能责任

1：向用户端推送消息内容。

2：接受http服务器发来的消息。推送给用户。

3：把用于uid和链接fd绑定报存到redis内。

6：用户创建连接时候验证token成功即可，失败立即关闭连接。

7：如果是http服务器创建的连接，需要验证ip+密码，然后把服务器状态保存的redis缓存池。

【二】http 服务器集群

一套代码可以布置到多台服务器互相不通信。

http服务器启动时，建立与所有websocket集群的连接，其实就是充当客户端角色，有ip+密码的限制，只有通过验证的客户端才可以发消息，发消息失败或者某个websocket连接掉线，从新连接。

这个服务器是用于接受用户发来的消息，进行业务处理，然后根据redis获取用户所属的websocket服务器ip,把消息转发到用户所在的websocket服务器，websocket服务器在把消息推送到用户端。

功能责任

1：接受用户端发送的消息内容，进行处理

2：根据用户uid读取redis缓存，拿到用户所在websocket服务器的ip。然后把消息推到该服务器。

3：每条消息内容存放到redis缓存池；用list类型。每条消息rpush追加到末端即可。

4：执行定时任务，每秒批量读取redis缓存池内容，从左侧取出并删除。把消息批量写入mysql数据库，一旦写入失败，执行数据备份任务，批量写入备份库。

其他

1，定时任务，消息写入mysql数据库，主要为了提升批量写的性能。

每秒执行一次,读取redis list型消息表 ，把数据拼接成sql语句 ；

mysql 执行一条语句写入所有数据。或者每秒写入5000条这样设置。

关于cpu使用率更好利用，多进程

worker_num主进程我用了1，因为进程多会占用系统资源，另外进程间数据不共享，会加重业务量。

更重要一点，因为我的http服务器客户端是长连接，是会被分配到同一个worker进程里，也就是说，每次收发消息都会在同一个进程进行，不用有效利用cpu其他核的资源，所以我在worker主进程不处理任何业务，只用来接收和转发到task进程去执行业务逻辑。

单核worker1秒投递100万个任务是没问题的,交给task去处理业务就好。如果业务逻辑不多，就没必要使用task了，毕竟投递任务也消耗时间。

task_worker_num辅助进程我用cpu核的2倍。4核cpu就用8个进程。并行处理任务数。

websocket接到消息触发onmessage函数把内容直接丢给给task去工作，判断处理业务。

如果没有业务逻辑需要处理，不适应task速度会非常快。使用了task反而会慢了。

e34核cpu+2g内存，我测试了访问1万次。业务逻辑只做了一个for循环50万次，没写别的操作。

直接在worker内执行完耗时：42秒。

采用task投递执行for循环任务耗时：12秒。

如此看来，如果不采用task投递基本就卡死了。用了task投递明显速度能提高。4核cpu基本提升4倍速度。