[{"_1":2,"_3":-5,"_4":-5},"loaderData",{"_5":6,"_7":8},"actionData","errors","root",{"_11":-5,"_58":59,"_60":61,"_62":63},"routes/user.$name.replies",{"_9":10,"_11":12,"_13":14,"_15":16,"_17":18,"_19":20},"replies",[36],"user",{"_21":22,"_13":14,"_23":24,"_25":26,"_27":28,"_29":30,"_31":32,"_33":20,"_34":35},"loginname","tyo","page",1,"limit",50,"total",3,"id","1561","avatar_url","http://www.gravatar.com/avatar/3038cd3016181955e14964005d8e4086?s=48","githubUsername","","create_at","2011-12-06T17:59:53.000Z","score",15,"topic_count",0,"reply_count","is_star",false,{"_21":37,"_38":39,"_40":-5,"_41":42,"_43":44,"_45":46,"_47":48,"_49":35,"_33":50,"_51":52,"_27":53,"_54":55},"54","author_id","135","tab","content","多核编程的重要性无需多说，我们直奔主题，目前nodejs 的网络服务器有以下几种支持多进程的方式：\r\n
\r\n
#1 开启多个进程，每个进程绑定不同的端口，用反向代理服务器如 Nginx 做负载均衡，好处是我们可以借助强大的 Nginx 做一些过滤检查之类的操作，同时能够实现比较好的均衡策略，但坏处也是显而易见 ---我们引入了一个间接层。\r\n
\r\n
#2 多进程绑定在同一个端口侦听\r\n
在nodejs 中，提供了进程间发送“文件句柄” 的功能，这个功能实在是太有用了（貌似是yahoo 的工程师提交的一个patch） \r\n
不明真相的群众可以看这里： http://www.lst.de/~okir/blackhats/node121.html\r\n
在 node 中我们可以通过以下函数达到效果：\r\n

stream.write(string, encoding='utf8', [fd]）

\r\n
或在 node v0.5.9+ 中 fork 子进程之后：\r\n

child.send(message, [sendHandle])

\r\n
\r\n
所以我们设计以下方案：master 进程生成了listen 端口之后，发送这个 listenfd 给所有的worker 子进程，worker 子进程接收到handle 之后，执行listen 操作：\r\n
\r\n
master ：\r\n

function startWorker(handle){\r\n
  output(\"start workers :\" + WORKER_NUMBER);\r\n
  worker_succ_count = 0;\r\n
  for(var i=0; i    var c  =  cp.fork(WORKER_PATH);\r\n
    c.send({\"server\" : true}, handle);\r\n
  }\r\n
}\r\n
\r\n
function startServer(){\r\n
  var tcpServer = net.createServer();\r\n
  tcpServer.on(\"error\", function(err){\r\n
    output(\"server error ,check the port...\");\r\n
    about_exit();\r\n
  })  \r\n
  tcpServer.listen(PORT , function(){\r\n
    startWorker(tcpServer._handle);\r\n
    tcpServer.close();\r\n
  }); \r\n
}\r\n
\r\n
startServer();

\r\n
注意，因为我们只需要一个handle ，httpServer 其实是netServer 的一层封装，所以我们在master进程启动netServer ，发送这个listen套接字 “handle” 到各个子进程\r\n
worker ：

server = http.createServer(function(req, res){\r\n
  var i,r;\r\n
  for(i=0; i<10000; i++){\r\n
    r = Math.random();\r\n
  }   \r\n
  res.writeHead(200 ,{\"content-type\" : \"text/html\"});\r\n
  res.end(\"hello,world\");\r\n
  child_req_count++;\r\n
}); \r\n
\r\n
process.on(\"message\",function(m ,handle){\r\n
  if(handle){\r\n
    server.listen(handle, function(err){\r\n
      if(err){\r\n
        output(\"worker listen error\");\r\n
      }else{\r\n
        process.send({\"listenOK\" : true});\r\n
        output(\"worker listen ok\");\r\n
      }   \r\n
   });\r\n
  …\r\n
 });

\r\n
\r\n
worker 进程收到handle后，立即进行listen ，这样就会有多个worker进程 listen同一个socket端口，即同一个套接字被加入到多个进程的epoll 监控结构中，当一个外部连接到来时，此时只有一个幸运的worker 进程得到激活事件，接收这个连接。（在UNP 中讲到这种情况下会导致 “惊群” 效应，但据江湖传闻2.6以上的Linux 系统中，阻塞式的listenfd 已消除惊群现象，非阻塞的listenfd 依然存在，即我们的epoll还是会存在这个问题的，但个人认为nodejs 的epoll 结构中往往有很多的监控句柄而非仅listenfd，所以这时候惊群造成的影响应该是比较小的...）\r\n
\r\n
我们开5个worker 测试（以下测试均为开启keep-alive模式，本机测试）：\r\n
\r\n
测试业务如上代码所示：运行10K次 Math.random(), 然后输出 ”hello,world“;\r\n
\r\n
系统配置：\r\n

Linux 2.6.18-164.el5xen x86_64\r\n
\r\n
CPU X5 ，Intel(R) Xeon(R) CPU E5620 @ 2.40GHz\r\n
\r\n
free -m\r\n
\t total used free shared buffers cached\r\n
Mem: 7500 3672 3827 0 863 1183\r\n
\r\n

\r\n
\r\n

siege -c 100 -r 1000 -b localhost:3458/

\r\n
\r\n
结果为：\r\n
\r\n

ransactions:\t\t 100000 hits\r\n
Availability:\t\t 100.00 %\r\n
Elapsed time:\t\t 10.95 secs\r\n
Data transferred:\t 1.05 MB\r\n
Response time:\t\t 0.01 secs\r\n
Transaction rate:\t 9132.42 trans/sec\r\n
Throughput:\t\t 0.10 MB/sec\r\n
Concurrency:\t\t 55.61\r\n
Successful transactions: 100000

\r\n
\r\n
5 个worker 处理的请求量分别是：\r\n

child req total : 23000\r\n
child req total : 16000\r\n
child req total : 17000\r\n
child req total : 22000\r\n
child req total : 22000

\r\n
\r\n
再测一次：\r\n

child req total : 13000\r\n
child req total : 30000\r\n
child req total : 14000\r\n
child req total : 22000\r\n
child req total : 21000

\r\n
\r\n
在这种情况下，我们的负载均衡是建立在各个worker“随机接收“的特征基础上的，由操作系统来保证的，长期运行情况下应该是均衡的，但短期内还是会有可能导致负载倾斜的现象，特别是在客户端使用keep-alive连接并长期不关闭的情况下。\r\n
\r\n
\r\n
#3 一个进程负责监听、接收连接，然后把接收到的连接平均发送到子进程中去处理\r\n
\r\n
我们先看一下正常情况下一个http server 服务的流程，其大体可分为几个阶段: \r\n
\r\n
listenfd 绑定侦听 -> 接收到的Tcp 连接对象 → 包装成socket 对象 → 生成(req ,res)对象 -> 调用用户代码\r\n
\r\n
\r\n

\r\n
(#1) TCP.bind --- > TCP.listen (process.binding(“tcp_wrap”))\r\n
                                                |\r\n
                                                |TCP.emit(“connection” ,handle)\r\n
                                                |\t\r\n
(#2) Wrap TCP handle to Socket (Tcp.onconnection)\r\n
                                                |\r\n
                                                |Net.Server.emit(”connection” , socket)\r\n
                                                |\r\n
(#3)Create Req ,Res based on a Socket(net.server.connectionListen)\r\n
                                                |\r\n
                                                |Http.server.emit(“request” ,req ,res)\r\n
                                                |\r\n
(#4)your code writen here ：function(req ,res){\r\n
    res.writeHead(200 ,“content-type/text/html”);\r\n
    res.end(“hello,world”)\r\n
}\t\r\n

\r\n
\r\n
\r\n
nodejs 的child.send(message, [sendHandle]) 函数，此处的 sendHandle 这时应该为一个 tcp_wrap 对象，所以我们不能直接使用 net.createServer 返回给我们的socket ，否则的话我们需要”回滚“ 从Tcp 到 Socket 这一步骤，不仅浪费资源，同时也是不安全的，所以我们在tcpMaster 中直接使用 tcp_wrap :\r\n

\r\n
var TCP = process.binding(\"tcp_wrap\").TCP;\r\n
\r\n
var childs = [];\r\n
var last_child_pos = 0;\r\n
function startWorker(){\r\n
  for(var i=0; i    var c  =  cp.fork(WORKER_PATH);\r\n
    childs.push(c);\r\n
  }\r\n
}\r\n
function startServer(){\r\n
    server = new TCP();\r\n
    server.bind(ADDRESS, PORT);\r\n
    server.onconnection = onconnection;\r\n
    server.listen(BACK_LOG);\r\n
  }\r\n
function onconnection(handle){\r\n
    //output(\"master on connection\");\r\n
    last_child_pos++;\r\n
    if(last_child_pos >= WORKER_NUMBER){\r\n
      last_child_pos = 0;\r\n
    }\r\n
    childs[last_child_pos].send({\"handle\" : true}, handle);\r\n
    handle.close();\r\n
}\r\n
startServer();\r\n
startWorker();\r\n

\r\n
以上为tcpMaster 进程把接收的tcp 连接均匀分配给 tcpWorkers ：\r\n
\r\n

function onhandle(self, handle){\r\n
    if(self.maxConnections && self.connections >= self.maxConnections){\r\n
      handle.close();\r\n
      return;\r\n
    }\r\n
    var socket = new net.Socket({\r\n
      handle : handle,\r\n
      allowHalfOpen : self.allowHalfOpen \r\n
    }); \r\n
    socket.readable = socket.writable = true;\r\n
    socket.resume();\r\n
    self.connections++;\r\n
    socket.server = self;\r\n
    self.emit(\"connection\", socket);\r\n
    socket.emit(\"connect\");\r\n
  }\r\n
server = http.createServer(function(req, res){\r\n
    var r, i;\r\n
      for(i=0; i<10000; i++){\r\n
        r = Math.random();\r\n
      }   \r\n
      res.writeHead(200 ,{\"content-type\" : \"text/html\"});\r\n
      res.end(\"hello,world\");\r\n
      child_req_count++;\r\n
    }); \r\n
}\r\n
 process.on(\"message\",function(m ,handle){\r\n
     if(handle){\r\n
        onhandle(server, handle);\r\n
     }   \r\n
    if(m.status == \"update\"){\r\n
      process.send({\"status\" : process.memoryUsage()});\r\n
    }   \r\n
  });

\r\n
\r\n
以上为tcpWorker 将接收到的tcp handle 封装成socket ，为了充分的与http.server类兼容，我们还对connections的数量进行检查，并把socket.server 设为当前的server ，然后激发http.server 的 ”connection“ 事件.\r\n
\r\n
通过这种方式，我们用尽量小的开销，在充分保证http.server 类的兼容性的前提下，用尽量少而优雅的代码实现了负载均衡与高效并行。\r\n
测试结果如下：\r\n

\r\n
ransactions:\t\t 100000 hits\r\n
Availability:\t\t 100.00 %\r\n
Elapsed time:\t\t 10.47 secs\r\n
Data transferred:\t 1.05 MB\r\n
Response time:\t\t 0.01 secs\r\n
Transaction rate:\t 9551.10 trans/sec\r\n
Throughput:\t\t 0.10 MB/sec\r\n
Concurrency:\t\t 60.68\r\n
Successful transactions: 100000

\r\n

child req total : 20000\r\n
child req total : 20000\r\n
child req total : 20000\r\n
child req total : 20000\r\n
child req total : 20000

\r\n
数据会有所起伏，qps 总体在 8000~11000 范围内，注意以上worker 数目均设为5个，适量增大worker数目，qps 可以稳定达到10k，但这时系统load比较高，使用时需谨慎选择。\r\n
\r\n
几次测试完成后，我们查看/proc/[tcpMaster]/fd , 其占用的端口如下：\r\n

0 -> /dev/pts/30\r\n
1 -> /dev/pts/30\r\n
10 -> socket:[71040]\r\n
11 -> socket:[71044]\r\n
12 -> socket:[71054]\r\n
2 -> /dev/pts/30\r\n
3 -> eventpoll:[71027]\r\n
4 -> pipe:[71028]\r\n
5 -> pipe:[71028]\r\n
6 -> socket:[71030]\r\n
8 -> socket:[71032]\r\n
9 -> socket:[71036]

\r\n
查看其中一个tcpWorker：\r\n

0 -> socket:[71031]\r\n
1 -> /dev/pts/30\r\n
2 -> /dev/pts/30\r\n
3 -> eventpoll:[71049]\r\n
4 -> pipe:[71050]\r\n
5 -> pipe:[71050]

\r\n
tcpMaster 的fds 意义分别如下：\r\n

1个socket为listenfd

5个socket 用作父子进程通信

2个pipe（一对）用于asyn_watcher/signal_watcher 的触发

剩余的不解释..

\r\n
\r\n
tcpWorker 的fds 意义分别如下：\r\n

1个socket（这儿就是stdin）用作与父进程通信

其余fd与master中fd作用类似

\r\n
\r\n
所以tcpMaster/tcpWorker 端口占用正常，没有句柄泄露问题，负载均衡可控，但负责接收socket的master需要重新分配发送socket ，引入了额外的开销.\r\n
\r\n
小结：\r\n
\r\n
本文介绍了2种比较高效的多进程运行方式，两种方式各有优劣，需要使用者自行选择，在node v0.5.10+ 中，内置了cluster 库，不过在我看来，其宣传意义大于实用意义，因为这样官方就可理直气壮的宣称直接支持多进程运行方式，nodejs 官方为了让API 接口傻瓜化，用了一些比较trick 的方法，代码也比较绕，且这种多进程的方式，不可避免的要牵涉到进程通信、进程管理之类的东西，但我们往往有自己的需求，现在nodejs官方把它固化到lib中，我们就无法自由的更改添加一些功能。\r\n
\r\n
此外，有两个node 的module ，multi-node 和 cluster ，采用的策略和本文介绍的类似，但使用这些module往往有一些缺点：\r\n

更新不及时

复杂庞大，往往绑定了很多其他的功能，用户往往被绑架

遇到问题难以hack

\r\n
\r\n
\r\n
基于本文的介绍，你可以很方便的打造自己的高性能的、易维护的、最简的、优雅实用的cluster ，enjoy it！ \r\n
\r\n
源码地址：https://github.com/windyrobin/iCluster\r\n
\r\n
以下文章有些老，但和本文的策略很相似（俺是独立构思完后看到的，别喷俺抄袭哦）：\r\n
http://developer.yahoo.com/blogs/ydn/posts/2010/07/multicore_http_server_with_nodejs/\r\n
","title","NodeJs 多核多进程并行框架实作","last_reply_at","2015-12-18T08:30:49.796Z","good",true,"top",21,"visit_count",52074,"2011-10-27T08:55:13.000Z","author",{"_13":56,"_23":57},"windyrobin","http://www.gravatar.com/avatar/e9e2e24aa3ed291923d223924ec694ba?s=48","zones",[107],"tabs",[77,78,79,80,81,82],"publicConfig",{"_64":65,"_66":26,"_67":68},"apiBaseUrl","https://api.cnodejs.org","turnstileSiteKey","build",{"_69":70,"_71":72,"_73":74,"_75":76},"service","cnode-web","version","0.1.0","commit","9ab83f39eed6b4a14eedbb8fbadfefe40dba3d45","buildTime","2026-07-30T19:01:36Z",{"_21":16,"_84":105,"_86":106,"_88":48,"_89":16,"_91":99},{"_21":102,"_84":103,"_86":104,"_88":48,"_89":102,"_91":99},{"_21":20,"_84":100,"_86":101,"_88":48,"_89":20,"_91":99},{"_21":97,"_84":47,"_86":98,"_88":48,"_89":97,"_91":99},{"_21":93,"_84":94,"_86":95,"_88":35,"_89":96,"_91":92},{"_21":83,"_84":85,"_86":87,"_88":35,"_89":90,"_91":92},10,"key","test","label","测试","visible","sort_order",91,"scope","admin",9,"dev","开发",90,4,"精华","public","job","招聘",2,"ask","问答","share","分享",{"_21":16,"_108":109,"_110":101,"_111":112,"_113":114,"_88":48,"_89":16},"slug","jobs","name","description","Node.js 招聘信息专区","icon","briefcase"]