之前写过一篇《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方式对业务连接会更友好，怎么说呢？你每停掉一个老程序的进程后，启动一个新进程监听刚停掉的那个老进程的端口，依次完成旧程序的下线和新程序的上线，那么几乎不会有业务连接的处理会受到影响。