部署 请教 Unicorn worker 是如何处理用户请求的

willmouse · 2012年06月03日 · 最后由 i5ting 回复于 2013年09月15日 · 3175 次阅读

对 Unicorn 的工作模式只有一点点了解,Google 的几篇 Unicorn 文章也看过,不过还有几个关于 worker 的相关问题没弄太清楚,请教一下:

  1. 当有请求分发到某一个 worker 上,worker 具体是怎么处理该请求?worker 会监听相应的端口或者 unix socket,使用 master 加载到内存的当前 Rails app 作为环境,在该环境执行相应的处理?

  2. 当有大量请求从 Nginx 通过 socket 发送到相应 worker 中时,这个请求是进入某一个队列中吗?一个请求在为执行完以前应该会阻塞其它的请求吧?2 个 worker 是如何处理大量的请求的?还是 fork 子进程来处理大量的请求?

没有前辈分享一下吗?

关于第二条在高并发情况下的问题,应该首先是由 Nginx 或者 Apache 接收到请求,之后再转给上游的 Unicorn,前面 Web server 应该也会对大量的请求进行一定的处理吧?

这个问题其实关注了很久,也跟你一样,在等待前辈高手分享一下心得,呵呵。

worker 具体是怎么处理该请求? worker 有多种模式啊。

首先是,类似 Apache 的 prefork 模式,这个其实就是说,你 fork 出多个进程之后,就在子进程分别 select 就行了 (至于为啥可以,你去看操作系统是怎么实现的)。为了避免内存泄漏带来影响,处理比如 1000 个请求后,进程就自杀,这会触发父进程的 signal,父进程于是就 fork 一个新的子进程出来。大致上是这样的,细节你自己看代码吧。

你可以 fork 多个进程也可以不 fork 。在单个进程里面,你可以弄个线程池,也可以用协程,或者事件驱动也成啊,当然了,你想让一个进程同时只处理一个请求,那也没问题。

这个请求是进入某一个队列中吗

同上,这个是操作系统干的事情

一个请求在为执行完以前应该会阻塞其它的请求吧

假如你能同时处理的请求数小于实际的请求数,当然可能阻塞。

2 个 worker 是如何处理大量的请求的?还是 fork 子进程来处理大量的请求?

同最上面,这个取决于你的 worker 是怎么实现的。

关于第二条在高并发情况下的问题,应该首先是由 Nginx 或者 Apache 接收到请求,之后再转给上游的 Unicorn

你也可以不用反向代理转发,只要你能撑得住。

前面 Web server 应该也会对大量的请求进行一定的处理吧?

你怎么配置的就会怎么被处理呗。

挖坟啦,很有帮助

需要 登录 后方可回复, 如果你还没有账号请 注册新账号