websocket高并发聊天室

> 客户端效果图

 

 

> 客户端chatease.js

本来客户端代码量是很少的，这里做了闭包封装，作为插件形式以方便使用。里面主要包含事件驱动、MVC、权限管理、皮肤系统等，容易扩展。内嵌flash以支持IE8/9，比sockjs更好用。

项目地址：https://github.com/studease/chatease

使用手册：http://studease.cn/chatease.html

 

> 服务端rtmpmate

这是一个websocket高并发聊天服务器，使用Go编写。默认配置下，如果客户端连接带token，服务器会访问data/userinfo.json接口，以获取用户信息；不带token时会自动分配游客身份。

下载地址：http://studease.cn/rtmpmate.html

 

说到并发，我并不能给你一个具体的数字。因为影响因素很多，每个应用环境、业务类型和硬件都可能影响最终结果。可以肯定的是，rtmpmate没有连接上限限制，也就是说连接上限与硬件相关。

聊天服务的压力在于同频道连接数，比如一个频道有1000人，每秒发言率10%，也就是每秒100条，服务器需要发送1000x100次，假设每条消息100B，总流量约10M，也就是说100M带宽几乎没有了。这个发言率其实已经很高了，看弹幕密集度就知道。同样的1000人，平均分配到10个不同的频道（或者软件分割），发言率10%，单频道每秒就只有10条，10个频道带宽总占用约10M，其实就是总发言率只有1%。

再说内存，拿C底层来说，每个连接发送和接收缓冲区的系统最低值都是4K（发送buf和接收buf为系统占用），那么，在所有的连接都没有数据传输的情况下，8G内存按7.5可用来算，大约可支撑98W。

然而，实际业务和应用场景往往使压力点错中复杂，因此增加了对“频道”的可配置性：channel中又分出group，可以固定group容量，也可以指定1个channel，让group容量动态变化，消息类型分组内消息和频道消息来广播。因此，可能两个客户端即使是连接的同一个频道ID，却户型收不到消息，这样就能减小带宽等压力。

 

> 附（spring websocket，项目地址：https://github.com/studease/chatease-server-temp）：

解决移动端，如微信、QQ、Safari等使用websocket连接时，服务端报错：

java.lang.IllegalArgumentException: The extension [x-webkit-deflate-frame] is not supported

 

 

在继承HandshakeInterceptor的类里面，重写beforeHandshake方法中加入：

if (request.getHeaders().containsKey("Sec-WebSocket-Extensions")) {
    request.getHeaders().set("Sec-WebSocket-Extensions", "permessage-deflate");
}

 

这里主要是由于spring不认x-webkit-deflate-frame这种老的不标准的压缩方式，直接改为未压缩方式传输就行。