请教亦春，关于nginx扩展和drizzle的问题
珠珠
珠珠
其他大侠也请帮助，谢谢
smallfish
--
邮件自: 列表“openresty”,专用于技术讨论!
发言: 请发邮件到 open...@googlegroups.com
退订: 请发邮件至 openresty+...@googlegroups.com
详情: http://groups.google.com/group/openresty
官网: http://openresty.org/
仓库: https://github.com/agentzh/ngx_openresty
建议: 提问的智慧 http://wiki.woodpecker.org.cn/moin/AskForHelp
教程: http://agentzh.org/misc/nginx/agentzh-nginx-tutorials-zhcn.html
agentzh
2012/10/26 珠珠:
> 亦春，你好
> 很惊艳与openresty 和nginx的性能，我准备设计一个类似msn的im系统，想要在web
> server上登录，然后将sessionid发送到im的服务器上，这样im服务器不必处理数据库操作。
> 由于刚刚接触openresty ，厚颜请教：这样的结构是否可以用 类似upstream的扩展来给im服务器发送信息，如发送后收到回复然后response
> http客户端，是否有现成的第三方扩展呢？
>
可以参考老王同学的这两篇文章：
* 《Nginx与Lua》 http://huoding.com/2012/08/31/156
*《实现一个简单的服务端推方案》 http://huoding.com/2012/09/28/174
openresty.org 网站上也有不少示例和指向用户教程文章的链接：
Best regards,
-agentzh
珠珠
agentzh
2012/10/29 珠珠:
> 感谢2位，这2天学习了点，感觉结构上无法让所有的worker进程共用一条upstream的长连接，
从技术上讲，在目前的多进程模型下，通过 sendmsg
等机制来实现连接的跨进程共享，涉及的进程同步和通信开销还是比较大的（如果不是不可能的话）。几年前我和晓哲老师讨论的结果是暂不予尝试（因为很可能得不偿失）。
当然，我们也不会因此而切换到多 OS 线程模型下，因为又会引入很多新的问题，比如线程安全的问题、锁的问题，等等。
> keepalive的长连接某一时刻也只能给一个前端http用户使用；不过适应这个构架很好
>
你肯定不会希望看到一个 TCP 连接在一个时刻同时被多个客户端所读写。因为 TCP
连接是有状态的、面向流的，所以你真的那么做的话就意味着灾难。在那种情形下，你根本无法保证各个客户端的读写逻辑是彼此相对独立的 :)
Best regards,
-agentzh
珠珠
开始我的设想是：整个webserver部分已有一条tcp连接到upstream，接着看到nginx是多进程的，设想每个进程1条tcp连接到upstream，不过确实实现起来可能得不偿失。
>
Simon
ngx-lua的cosocket功能可以完全替换upstream的功能，所以能写lua尽量写lua，写upstream就要用c了。
在 2012年10月30日星期二UTC+8上午10时28分06秒，珠珠写道：
agentzh
2012/10/29 珠珠:
>> keepalive的长连接某一时刻也只能给一个前端http用户使用；不过适应这个构架很好
>>
> 这里我的意思是后台 upstream的那个长连接，我看ngx_http_upstream_keepalive_module
> 是用连接池的，如果只用一条upstream的长连接,势必要保存前端http连接socket，并将该信息关联，等upstream返回再找到前端http连接socket做回应。从效率上看，连接池也是十分高效的，所以我说改动后台服务器代码适应了这个也是很不错的。
> 以上是我现在的想法，也有可能对nginx upstream keepalive理解错误。
>
虽然我对 ngx_http_upstream_keepalive_module 的实现非常熟悉并且据此实现了 ngx_lua 的
cosocket 连接池，但我仍然不能看懂你的意思，非常抱歉 :P
在 upstream_keepalive 和 ngx_lua cosocket
连接池的模型中，上游连接与下游连接都是多对多的关系，即使是在一个 OS 线程中（或者说在一个 nginx worker
进程中）。这里不存在任何形式的串行化。
当然，一个下游（http）请求可以同时发起多个并发的上游请求（对应多个上游连接），但不会出现多个下游请求同时使用一个上游连接。对于后者，需要自己实现串行化以解决并发访问的问题，而且这种串行化的模型一般效率奇差，因为上游的并发只有
1，所有的下游（并发）请求都要等待一个上游连接逐一地进行处理。
Best regards,
-agentzh
pengqi
--
邮件自: 列表“openresty”,专用于技术讨论!
发言: 请发邮件到 open...@googlegroups.com
退订: 请发邮件至 openresty+...@googlegroups.com
详情: http://groups.google.com/group/openresty
官网: http://openresty.org/
仓库: https://github.com/agentzh/ngx_openresty
建议: 提问的智慧 http://wiki.woodpecker.org.cn/moin/AskForHelp
教程: http://agentzh.org/misc/nginx/agentzh-nginx-tutorials-zhcn.html
Software Engineer
Server Platforms Team at Taobao
珠珠
agentzh
2012/10/29 pengqi:
> 多个前端请求共用一个后端的连接，这需要自定义协议来实现，这样的实现有利于减少后端服务器的连接数，淘宝的tbnet库就支持，tair，tfs都使用了tbnet这个网络库，客服端可以在一条连接上同时处理多个请求。
>
嗯，你描述的这种模型类似 DNS
协议那样需要对上游请求和上游响应自己进行类似编号和配对这样的处理，需要传输协议本身以及上游服务器端的特殊支持。目前，ngx_http_upstream
和 ngx_lua cosocket 都不支持定义这种模型。
这里在 ngx_lua cosocket 连接池一侧可以做得更好的一个地方是，当连接池空了的时候，可以让 connect()
调用排队等待某段（可配置的）时间，以便有新的空闲连接入池可供使用，而不是像现在这样直接创建新的连接。这样可以避免后端的连接数在前端的并发度瞬时提高时变得过大。晓哲和网易的一位工程师都曾经提到过这个问题。
Regards,
-agentzh
珠珠
谢谢 jinglong、亦春
zeta...@gmail.com
这里在 ngx_lua cosocket 连接池一侧可以做得更好的一个地方是，当连接池空了的时候，可以让 connect()
调用排队等待某段（可配置的）时间，以便有新的空闲连接入池可供使用，而不是像现在这样直接创建新的连接。这样可以避免后端的连接数在前端的并发度瞬时提高时变得过大。晓哲和网易的一位工程师都曾经提到过这个问题。
Yichun Zhang (agentzh)
set_keepalive() 的接口作了修改，即连接池的容量上限此后需要在 connect() 调用中指定，而非
set_keepalive() 中（通过第二个参数）。
我在把本地分支整理完成之后会提给社区 review. 在此之前，建议直接在 Lua 里对会产生上游访问的下游连接的并发度进行控制。
Regards,
-agentzh