之前写过一篇《nodejs的express负载均衡》,给出了两种方式实现express web服务的nlb。一种是利用nodejs自带的cluster,创建多个worker进程,绑定同一个服务端口,由主进程负责监听和调度;另一种启动多个nodejs实例,每个实例绑定一个不同的端口,在nginx上配置成一个upstream pool由nginx来负责反向代理转发。对用户端来说实现的效果是一样的。不过有一些坑要提醒大家注意下。
如果是在windows环境下,那么nodejs的cluster的调度策略,不像linux环境中默认是轮询,而是啥也没有配置,所以你会发现,总是同一个worker进程在处理请求,代码里加入下面一条语句,可以将调度策略设为轮询:
cluster.schedulingPolicy = cluster.SCHED_RR;
这样就万事大吉了么?还有坑!
nodejs.org官方说,虽然理论上,分发请求策略可以给出最佳性能,但是一个有8个worker的场景中,观察到80%的请求落在2个worker上,并没有实现负载均衡。
究其原因,可能是创建进程时,操作系统并没有将这CPU核数的worker运行在不同的CPU核上。
linux下,有条命令taskset可以将指定pid的进程设置在指定的CPU核上,但是windows下,情况有些复杂,虽然图形界面可以对任务管理器中看到的指定进程设置CPU Affinity,可以使它跑在指定的一个或几个CPU核上,没有好用的系统命令来设置的话,得靠人肉手点。。。
下面附一段python代码实现将指定进程ID的进程限制在指定CPU核上运行。
#Usage: python adjpid.py pid cpuid
import win32api, win32con, win32process, sys
pid = int(sys.argv[1])
mask = 2**int(sys.argv[2])
handle = win32api.OpenProcess(win32con.PROCESS_ALL_ACCESS, True, pid)
win32process.SetProcessAffinityMask(handle, mask)
之所以贴这段python代码,是因为python实现最简单直观,微软是开放了相应接口,但是其他语言开发实现这个功能需要更多的折腾。。。。
好吧,完成了上述工作的话,是不是就好用了么?这也只是完成了轮询,并可以公平地将任务分配到每个CPU核上。
不用nodejs的cluster,用nginx的upstream怎样呢?客观的说,效果会好一些,upstream里有丰富的参数可配置,比如权重,最大失败次数,负载均衡算法等。
另外在程序代码更新发布时,nginx的upstream方式对业务连接会更友好,怎么说呢?你每停掉一个老程序的进程后,启动一个新进程监听刚停掉的那个老进程的端口,依次完成旧程序的下线和新程序的上线,那么几乎不会有业务连接的处理会受到影响。