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

公司新项目要做个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_size		256M;
    #频道ID最大长度
    push_stream_max_channel_id_length           32;
    #仅认证频道可被客户端监听
    push_stream_authorized_channels_only	on;
    #缓存消息
    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_subscriber			long-polling;
            set $push_stream_channels_path              $1;
            #长链接超时时间
	    #push_stream_subscriber_connection_ttl	30s;
            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/  下载