rails部署艺术

听到Rails部署这两词，可能你首先想到的是下面这堆东西：

 

* CGI
* Apache/mod_fastcgi
* Lighttpd/fcgi
* Apache2/mod_fcgi
* Lighttpd/SCGI
* Lightspeed

 

但时代已经变了，新时代需要新思维

Mongrel：The year of the dog

Mongrel是由Zed Shaw完成的一个HTTP Server，它：

 

* 使用Ragel + C的快速HTTP解析
* 使用C的快速URI过滤器
* 堆栈式请求处理
* 配置灵活
* 安全同时兼容RFC的HTTP解析器

 

Mongrel就足够了？

 

答案是：不够，因为：

 

* Rails请求分发需要使用互斥锁
* 一个Mongrel实例只能同时处理一个请求
* 需要使用Mongrel_cluster创建多个实例来获取可伸缩性

 

因此，你仍然需要一个前端HTTP Server，幸好有一大堆：

 

* Pen，Pound，Balance，Haproxy（不支持静态文件，只是代理）
* Lightspeed（支持静态文件和代理）
* Apache2.2.x/mod_proxy_balancer（支持静态文件和代理）

 

这就搞定了？还不行：

 

* Pen（不支持SSL，不能限制连接速率）
* Pound（不支持高负载，不能限制连接速率）
* Haproxy（可限制连接速率，性能非常高，不支持静态文件）
* Lightspeed（免费版功能严重残缺）
* Apache2.2.x（没什么不好，就是：太臃肿了）

 

那怎么办？

Nginx：From Russia, with Love

 

Nginx有什么好处：

 

* 专为性能优化而开发，性能是其最重要的考量
* 非常小的资源占用
* 经过考验的高负载支持，没有内存泄漏
* 杀手级的Rewrite及Proxy模块
* 平易近人的作者以及快速扩大的社区

 

答案有了：Nginx + Mongrel，现在

 

* Apache很清闲了，它只需要负责mod_dav_svn就可以了
* 灵活的nginx.conf语法可以很轻易的搞定Rails Cache及动态请求
* 还有就是：快，快，快
* 我有说过快吗？

 

当然还有一些问题：

 

* Nginx会自动缓冲文件上传，因此将失去mongrel_upload_progress支持
* Proxy模块暂时还不支持连接速率限制

 

完美的部署就这样产生了：

 

* Linux
* Nginx
* Mongrel(Mongrel_cluster)
* Monit

 

就这么完了？还有一点，上面讲到过Mongrel的问题：

 

* 不能同时处理多个请求
* Rails分发需要取得互斥锁
* 还有多线程切换

 

这些都会损耗性能，因此我们需要新思维

Swiftiply: Evented Mongrel

 

Swiftiply事实上是Mongrel的修订版，那么它对Mongrel做了什么：

 

* 去除了Mongrel中对线程和Socket的处理
* 使用EventMachine的事件循环来代替
* Mongrel成了单线程，事件驱动
* 显著的速度及IO吞吐量提升
* 即使高并发，也没有不良症状（性能下降及内存泄漏）

 

你可能疑惑为何单线程会优于多线程，这是因为：

 

* Ruby的绿色线程进行上下文切换时需要拷贝大量的状态信息
* 互斥锁非常昂贵
* 单个进程的IO吞吐量有限
* 事件驱动意味着更紧凑的循环已经回调处理
* 由于节省了进程切换的时间，因此单线程可以将更多的精力集中到网络IO上。

 

Swiftiply还有一个好处：它可以启动多个Mongrel，但只使用一个端口。

评论

9 楼 kendy 2009-11-18  

引用

重启时，kill -USR2 master_pid master加载代码,启动一个worker, 并让以前的worker做完事情后退出

这个好 
good idea

8 楼 机器人 2009-11-15  

引用

重启时，kill -USR2 master_pid master加载代码,启动一个worker, 并让以前的worker做完事情后退出

这个好 

7 楼 sina2009 2009-11-15  

最近我的所有服务器都换成了nginx + unicorn

零down机重启，启动速度快

unicron的运行方式与nginx的master worker方式极其相似，每一部分做他擅长的事情

nginx负责接收请求。并维护相关的长连接

linux kernel socket负责转发，

unicorn master负责启动与监视worker,

重启时，kill -USR2 master_pid master加载代码,启动一个worker, 并让以前的worker做完事情后退出

是不是与nginx的kill -HUP nginx_pid很相似呢，那你就对了

http://github.com/blog/517-unicorn推荐篇博客

用了那么多部署方式，只有这个让我感觉最爽

6 楼 trace 2009-11-12  

机器人 写道

我用的是lightTPD + fastCGI(用nginx+mongrel cluster也行)

请教大家，我在工作时间有时为了更新，不得不重启 web server，有什么办法可以让当前正在处理的请求（如支付订单的操作）不中断，直到它安全的执行完呢？有没有什么 办法可以安全地重启更新呢，这样心惊肉跳的，早晚会出事。

还是在你的首页上说明一下吧，你看支付宝不也是偶尔出一个维护通知吗

5 楼 erickdu888 2009-11-12  

这个标题很好听。

4 楼 QuakeWang 2009-11-10  

机器人 写道

我用的是lightTPD + fastCGI(用nginx+mongrel cluster也行)

请教大家，我在工作时间有时为了更新，不得不重启 web server，有什么办法可以让当前正在处理的请求（如支付订单的操作）不中断，直到它安全的执行完呢？有没有什么 办法可以安全地重启更新呢，这样心惊肉跳的，早晚会出事。

你的fastcgi应该有多个进程，你可以在发布新版本的时候kill一个fastcgi进程然后再重启一个，而不需要重启web server，这样就不会中断了。

3 楼 机器人 2009-11-10  

引用

Swiftiply还有一个好处：它可以启动多个Mongrel，但只使用一个端口。

这个有意思

2 楼 机器人 2009-11-10  

我用的是lightTPD + fastCGI(用nginx+mongrel cluster也行)

请教大家，我在工作时间有时为了更新，不得不重启 web server，有什么办法可以让当前正在处理的请求（如支付订单的操作）不中断，直到它安全的执行完呢？有没有什么 办法可以安全地重启更新呢，这样心惊肉跳的，早晚会出事。

1 楼 leon0122 2009-11-10  

最后的结论是什么
根据这个号的方案，详细的部署方法呢
如果有这个，就更好了