Nginx-Push-Stream-Model(基于Comet和PHP的WebIM实现,Android推送)

xinjiang

　　

公司新项目要做个WEB IM, 之前只是自己写了个demo玩玩, 浅尝辄止. 这回可能要系统的复习一遍了…
comet已经出现很久了,网上也出现了不少应用到生产环境的实例, comet资料可以看这里:
http://www.ibm.com/developerworks/cn/web/wa-lo-comet/
 
因为公司的网站环境都是LAMP/LNMP的, 且运维的帅哥们也没兴趣提供其他方面的支持, 所以只能采取nginx+php的方案来解决了.
PHP写个死循环来实现的方式显然很SB, 想把这种方案用在生产环境的还是早点放弃吧. 本文所说的PHP实现, 其实是仅将PHP用作信息发送前的处理.
后来找到了一个nginx的插件, nginx-push-module.  关于配置安装就不再阐述了, 网上资料一大堆.  可是发现这个东西用在生产环境后一样非常恼火,  在高并发的时候占用的内存会越来越多.  硬要用的话  可以参考http://blog.lifeibo.com/?p=186来改造. 但是这个插件的原作者早在2年前就停止更新了,  而链接中的改造方法  也并非面面俱到, 还有很多需要解决的地方.对于完全没兴趣去爬源码的我 只好作罢.
nginx-push-stream-module. 看名字和之前的nginx-http-push-module十分相近, 是无意中在github里发现的.  基于slack版的二次开发. 基本完美解决了内存分配机制的问题, 且加入了HTML5 Web Sockets的支持.
来看下配置吧.
nginx.conf:

http段:
#最大共享内存
push_stream_shared_memory_size256M;
#频道ID最大长度
push_stream_max_channel_id_length           32;
#仅认证频道可被客户端监听
push_stream_authorized_channels_onlyon;
#缓存消息
push_stream_store_messages    on;
#每个频道最大缓存消息数量
push_stream_max_messages_stored_per_channel 1;
#缓存消息超时
push_stream_message_ttl                      5m;
 

server段:
location /pub {
push_stream_publisher    admin;
set $push_stream_channel_id             $arg_id;
push_stream_keepalive    on;
client_max_body_size                    32k;
client_body_buffer_size                 32k;
}
location ~ /sub/(.*) {
# 模式选择 streaming/long-polling/websocket
push_stream_subscriberlong-polling;
set $push_stream_channels_path              $1;
#长链接超时时间
#push_stream_subscriber_connection_ttl30s;
push_stream_longpolling_connection_ttl      30s;
# 发送content-type头信息
push_stream_content_type                    "text/javascript"
#时间标签
push_stream_last_received_message_time      $arg_time;
#Etag
push_stream_last_received_message_tag$arg_tag;
} 
 
其中sub模块用来接受客户端链接, 以及推送数据到客户端. pub则接收数据 可对sub模块相应的频道进行转发消息/关闭/清除缓存等操作.
需要一题的是, 整个系统需要一个唯一的识别码, 在这个module中被称为频道.
向pub模块POST一条数据 设定频道为 “my_channel”

curl -s -v -X POST 'http://localhost/pub?id=my_channel' -d 'Hello World!'
此时则可以由客户端发送请求, 在已经设定的频道”my_channel”中监听并等待返回数据

curl -s -v 'http://localhost/sub/my_channel'
 
那么可以基于LNMP 设计一个基本完整的WEB IM系统. 由nginx+push module来维护客户端的长链接, PHP来做消息处理. 比如:
浏览器发送请求[Client] —> 验证用户信息[PHP] —> 创建channel_id(防止非法监听,建议加密)[PHP] —> 设定在线状态[PHP] —> 通知Comet Server创建频道[PHP]—> 返回数据[PHP] —> 收到channel_id[Client] —> 创建链接(/sub)并等待返回[Client]
客户端:
收到数据 —> 分析状态 —> 页面显示 —> 重新发送链接(/sub)
 
具体的PHP和JS代码就不贴了, 说一下模块中的几个重要参数.
 

push_stream_authorized_channels_only
这个参数被设为on后, 则只有先在pub模块中POST一次数据, sub模块才可以监听指定频道, 否则会返回403错误.
 

push_stream_store_messages
设定为on则缓存消息pub模块收到的消息, 若push_stream_subscriber设为long-polling 且开启了authorized_channels_only, 则必须开启此选项. 否则sub模块将直接返回403错误.
 

push_stream_longpolling_connection_ttl
每次长链接的超时时间, 一般设定为30S. 防止服务器因过多的长链接而出现阻塞. push_stream_subscriber_connection_ttl则可设定所有模式的超时时间
 

push_stream_content_type
发送头信息, safari/chrome浏览器解析内容不符时 有可能中断, 用此设定返回正确的链接类型. 如jsonp请求时返回 “text/javascript”
 

push_stream_last_received_message_time & push_stream_last_received_tag
若push_stream_subscriber设为long-polling 且开启了authorized_channels_only, 则这两项必须设定.
一般客户端的JS会设定若长链接完成, 则重新发起链接, 若不设定这两项, 则客户端每次请求, 都会返回最后一条缓存的消息(store_messages) 客户端需要发送头部来被sub模块识别, 如:
If-Modified-Since:Thu, 23 Feb 2012 12:15:45 GMT
If-None-Match:0
若为jsonp请求, 则可将此数据跟在get参数后, 如http://localhost/sub/my_channel?_=1234567890&time=Thu, 23 Feb 2012 12:15:45 GMT&tag=0
 
 
先说到这里, 具体的实现及性能开销等数据之后再写
插件在 https://github.com/wandenberg/nginx-push-stream-module/  下载