Use cluster to extend your own node server to a multithreaded server _node.js

With Nodejs friends have learned that node is single-threaded, that is, running on the 8 core CPU, can only use a core of the force.
Single-threaded has always been a source of criticism for node, but with the introduction of cluster in version 0.6, the situation has changed, and developers can rely on cluster to easily extend their node servers to multi-threaded servers.

What is cluster

Cluster is a multi-line threading provided by the node that users can use to create multiple threads, sharing a listening port between threads, and cluster forwarding requests to random threads when there is an external request for this port. Because each node thread consumes dozens of megabytes of memory, it is not possible to create a thread for each request like PHP, and the maximum number of threads created will not exceed the core number of CPUs in general.

Copy Code code as follows:

var cluster = require (' cluster ');
var http = require (' http ');
var Numcpus = require (' OS '). CPUs (). length;

if (cluster.ismaster) {
Fork workers.
for (var i = 0; i < Numcpus; i++) {
Cluster.fork ();
}

Cluster.on (' Exit ', function (worker, code, signal) {
Console.log (' worker ' + worker.process.pid + ' died ');
});
} else {
Workers can share any TCP connection
In the case of its a HTTP server
Http.createserver (function (req, res) {
Res.writehead (200);
Res.end ("Hello world\n");
}). Listen (8000);
}

As shown in the code above, the program will be set to true when it runs, and when Cluster.fork () is invoked, the program creates a thread and cluster.ismaster it, then Cluster.ismaster is set to false. We mainly use this variable to determine whether the current thread is a child thread.

You can also note that after each child thread is created, it listens on 8000 ports without causing a conflict, which is the function of the cluster shared port.

Communication between threads

When threads are created, they do not share memory or data with each other. All data exchange can only be handled by Worker.send and Worker.on (' message ', handler) in the mainline Chengri, and an example of a broadcast system is listed below.

Copy Code code as follows:

var cluster = require (' cluster ');


var http = require (' http ');


var Numcpus = require (' OS '). CPUs (). length;

if (cluster.ismaster) {

var workers=[];
New worker
function Newworker () {
var worker=cluster.fork ();

Listen for information, if type is broadcast, then set to broadcast
Worker.on (' message ', function (msg) {
if (msg.type== ' broadcast ') {
var event=msg.event;
Send this broadcast to all worker
Workers.foreach (function (worker) {
Worker.send (event);
})
}
});
return worker;
}

for (var i = 0; i < Numcpus; i++) {
Workers.push (Newworker ());
}

Cluster.on (' online ', function (worker) {
Console.log (' Worker%d is online ', worker.id);
})
} else {
var Worker=cluster.worker;

Broadcast is to send a type of broadcast information, event is broadcast content
Worker.broadcast=function (event) {
Worker.send ({
Type: ' Broadcast ',
Event:event
});
}

It looks like you can't worker.on the information back here.
Process.on (' message ', function (event) {
Console.log (' Worker: ' +worker.id+ ' recived event from ' +event.workerid);
})

Send broadcast
Worker.broadcast ({
Message: ' Online ',
WorkerId:worker.id
})
}

Issues to be aware of

As mentioned above, there is no sharing of data between threads, and all data exchange can only be exchanged through the communication between threads. And the data exchanged is serializable, so functions, file descriptors, and HttpResponse can't be passed.

If you are using cluster, you need to consider the issue of data interchange at the time of programming, and my own approach is to keep this kind of session-like data in Redis, with every thread doing the work of access, and all the data in node memory.

Finally, cluster is now officially labeled as Experimental by node, and the API may change in the future.