关于nodejs的热重启
发布于 9 年前 作者 crystaldust 28409 次浏览 最后一次编辑是 8 年前 来自 分享

前段时间发帖子问了一下关于nodejs热重启的问题,感谢论坛里几位活跃的朋友提点(coordcn,imacc等等,不一一列举了,原提问帖在这里:https://cnodejs.org/topic/552e06816966089a258141e0)。最近和同事一起研究了一下pm2,经过测试,pm2确实可以实现0 downtime,具体就是使用pm2的 reload外加cluster模式:

pm2 start app.js -i 1

按照pm2的文档,-i N是在cluster模式下启动N个worker。pm2的这个机制是对nodejs原生cluster的一个封装,不必自己写复杂的cluster代码,而直接由pm2管理cluster,还支持各大常见的框架(Express,koa等),真是太强大了,即便监听了某个端口或者unix socket文件,在pm2的管理下也不会出现EADDRINUSE的错误。

当需要更新代码的时候,只需调用pm2的reload命令即可:

// update the code
pm2 reload app.js

按照这篇文章https://keymetrics.io/2015/03/26/pm2-clustering-made-easy/ 的提示:

PM2 reload <app name> feature will restart your workers one by one, and for each worker, wait till the new one has spawned before killing the old one. 
This way, your server keeps running even when you are deploying the new patch straight to production.

在cluster模式下,pm2会尝试按顺序重启不同的worker,对于每个worker,只有在新的实例重启成功后才会杀死把旧worker杀死。所以reload的时候,还是可以保持服务一直能够响应,当reload结束后,新的worker已经开启,新代码就可以正常工作了。整个过程中,不会出现no responsing的问题。

21 回复

渣,这不叫热重启. 这还是重启.重启后该304的都变成200了.

@hezedu 呃,鄙人才疏学浅,可能理解有误差,您能详细的说一下吗?让我也学习一下哈

试试 bearcat 的热更新功能

@hezedu 前面加个 nginx 作反向,就能解决 304 了。好像很少人这么干?

@crystaldust 其实很简单,待我晚上搞一个出来

@klesh 可以详细的讲一下嘛?

@crystaldust OK,多谢,十分期待哈

@fantasyni 好,待我研究一下哈

@crystaldust 原理上就是前面有个 ngxin 负责处理静态文件,非静态文件的请求通过 proxy pass 到 express socket。 如此一来,后面的 express 死掉重启什么的,对前面静态文件是没有影响的,该304的还是304。 这种方式应该是复杂度最低的,而且也是推荐的生产环境布署方式。node.js 再快也快不过 nginx 处理静态文件的速度,各司其职。

具体如何弄有专门的文章讲如何布置的,貌似本社区就有,搜一下 nginx + express 可以看到很多。

@hezedu 还以为只有体育版面才有你这种人

@klesh 主要是动态内容还是要0 downtime,重启这段时间也要能访问。静态文件的话,一般都用nginx来处理的。

@20082496 大哥你好,多谢顶贴

@crystaldust 呵呵,既然都有在用 nginx ,那304的问题不需要担心了呀。一般情况下静态文件才需要304。具体你可以用浏览器测试一下,重启这段时间,该304的应该都还是304的。

@klesh 嗯,对的,静态文件确实不需要担心。用pm2来做reload还是针对动态内容的

直接安装supervisor就可以实现热部署啦。

@moxiaobei2 抱歉,最近忙着离职一堆杂事,回复晚了,请问能否具体的说一下呢?万分感激啊

关于nodejs和Nginx的benchmark,

http://centminmod.com/siegebenchmarks/2013/020313/

Quite interesting to see how well node.js clustered static file server scaled almost 2x times better in terms of transactions per second compared to Nginx web server (4,250 trans/s vs 2,118 trans/s) - especially at the higher concurrency levels. Also check out average response times (0.14s vs 0.23s), longest transaction time (1.10s vs 13.95s) and transaction availability numbers all in node.js’s favour.

@klesh 大哥,我错了.

@openroc 最近nginx不是更新了说性能大增么?

这个问题很有意义,不过我很少care,我的业务吧,都是很多台机器在跑的,运维自动化也会一台一台的重启,期间对于上游负载均衡启示不敏感

@captainblue2013 嗯,如果有集群+自动化op,确实没这方面的需求。然而我上一家公司是个小公司,开发和维护都压到我自己头上了。

回到顶部