本文主要是介绍nodejs的express负载均衡(续)，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
之前写过一篇《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核上，没有好用的系统命令来设置的话，得靠人肉手点。。。
好吧，完成了上述工作的话，是不是就好用了么？这也只是完成了轮询，并可以公平地将任务分配到每个CPU核上。
不用nodejs的cluster，用nginx的upstream怎样呢？客观的说，效果会好一些，upstream里有丰富的参数可配置，比如权重，最大失败次数，负载均衡算法等。
另外在程序代码更新发布时，nginx的upstream方式对业务连接会更友好，怎么说呢？你每停掉一个老程序的进程后，启动一个新进程监听刚停掉的那个老进程的端口，依次完成旧程序的下线和新程序的上线，那么几乎不会有业务连接的处理会受到影响。
这篇关于nodejs的express负载均衡(续)的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
