node. JS Cluster multi-process, load-balancing, and smooth restart

1 Cluster multi-process

Cluster after several generations of development, now it is better. With cluster, you can automatically complete the child process Worker assignment request, no longer need to write your own code in the master process Robin to each worker assigned a task.

Const CLUSTER = require (' cluster '); const HTTP= Require (' http '); Const Numcpus= Require (' OS '). CPUs (). length;if(cluster.ismaster) {//Fork workers.   for(vari = 0; i < Numcpus; i++) {cluster.fork (); } cluster.on (' Exit ', (worker, code, signal) ={console.log (' worker ${worker.process.pid} died '); });} Else {  //Workers can share any TCP connection  //In this case it's an HTTP serverHttp.createserver ((req, res) ={Res.writehead (200); Res.end (' Hello world\n '); }). Listen (80);}

The simple code above enables the creation of multiple workers based on the number of CPUs. As for the actual project, it is exactly one nucleus corresponding to a worker, or a check should be 2, 3 workers, depending on the situation. It should be better to set up more than 2 workers if the project waits for a particularly long time for other servers, such as databases.

But generally speaking, a CPU is good for a worker.

So, the whole architecture is like this:

The master process, what needs to be done is to monitor the worker's life cycle, if the worker is found to be dead, restart the worker, and do the corresponding log.

The whole architecture does not have much difficulty, the focus is to do some detail processing, such as restart, log, 5-second heartbeat packet and so on.

Multi-process architecture, compared to the original single-process +PM2 Restart benefits Certainly a lot more, the whole node service will be more stable, not suddenly completely hung up.

In addition, compared to PM2 multi-process, there are advantages, mainly master logic in the development of their own hands, you can do a custom log and mail, SMS alarm.

For the entire NODEJS service management convenience, in the master process, we generally turn on the management port monitoring, such as 12701, through the command line Curl 127.0.0.1:12701:xxx to initiate a simple HTTP GET request, easy to manage.

For example, the XXX incoming reload can be used as a server restart instruction.

2 Load Balancing

When it comes to multi-process, the aim is to use multicore CPUs as much as possible to improve the load capacity of single machines.

But often in the actual project, the processing time of the business logic and the system CPU scheduling impact, resulting in virtually all process load is not the ideal of complete balance.

The official also said:

In practice however, distribution tends to being very unbalanced due to operating system scheduler vagaries. Loads has been observed where over 70% of all connections ended up in just and processes, out of a total of eight.

Translation: 70% of requests end up on 2 workers, and these 2 workers consume more CPU resources.

So in the actual project deployment, we can try a step further: Bind the CPU. 4-core CPU, we fork out 4 workers, each of which binds to the #1-#4 CPU respectively.

Node does not provide us with a ready-made interface, but we can use the Linux command:taskset

In node, we can use child_process to execute the shell.

Cp.exec (' TASKSET-CP ' + (CPU) + ' + process.pid,{     " ,function(err,data,errdata {     if(err) {         logger.error (err.stack);     }          if (data.length) {         logger.info (' \ n ' + data.tostring (' UTF-8 '))     ;         } if (errdata.length) {         logger.error (' \ n ' + errdata.tostring (' UTF-8 ');     }});

As a practical point of view, the effect is good.

3 Smooth restart

Each time a new version is released, the server must be restarted.

Simple and brutal, kill the main process, all restart, there will be a period of time service interruption.

For small businesses Fortunately, can be scheduled to restart in the early hours, but for large companies big products, it cannot be so rude.

Then we need a smooth reboot to implement the service without interruption during the restart.

The strategy is not complex, but very effective:

1, the worker process rotation restart, interval time;

2, the worker process is not a direct restart, but the first to shut down the new request listening, and so on, and so on, and then restart the current request.

  Try {        //Make sure we close within seconds        varKillTimer = SetTimeout (() ={process.exit (1); }, 30000); //stop taking new requests.Server.close (); //Let the master know we ' re dead. This would trigger a        //' Disconnect ' in the cluster master, and then it'll fork        //a new worker.Cluster.worker.disconnect (); } Catch(er2) {}

After a smooth restart, the server's throughput rate is much smoother.

node. JS Cluster multi-process, load-balancing, and smooth restart