const cluster = require('cluster');
const http = require('http');
const numCPUs = require('os').cpus().length;
if (cluster.isMaster) {
console.log(`Master ${process.pid} is running`);
// Fork workers.
for (let i = 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 is an HTTP server
var sticky = require('sticky-session');
var express = require('express');
var app = express();
app.get('/', function (req, res) {
console.log('worker: ' + cluster.worker.id);
res.send('Hello World!');
});
var server = http.createServer(app);
sticky.listen(server,3000);
console.log(`Worker ${process.pid} started`);
}
nodejsクラスタリングとスティッキーセッションのドキュメントと、これに関する別のスタックオーバーフローの回答を調べました
var cluster = require('cluster');
var http = require('http');
var sticky = require('sticky-session');
var express = require('express');
var app = express();
app.get('/', function (req, res) {
console.log('worker: ' + cluster.worker.id);
res.send('Hello World!');
});
var server = http.createServer(app);
sticky.listen(server,3000);
上記のスニペットが fork せずに実行された場合は正常に動作しますが、スレッドが開始されてもサーバーが初期化されない上記のクラスター化された例に示されているように動作しません。
スティッキークラスターの代替手段があることを読みました。誰かがこのトピックについて適切な信頼できる回答を与えることができます。これは、同じものを探している人にとって役立ちます。これに伴う別の主な問題は、変数を保存するために使用される app.locals オブジェクトです。アプリインスタンスと複数のサーバーインスタンスが発生すると、インスタンスごとに値が異なるため、これが壊れます。このアプローチは大きな問題を引き起こし、アプリが壊れます。答えるときは、コードをコピーして貼り付けないでください。その利点と欠点にアプローチします。
sticky-sessions nodejs モジュールの使用に限定された答えを探しているわけではありません。プロセッサのすべてのコアが使用され、セッションの継続性が保証される他のすべてのアプローチを歓迎します。
RedisStore や MongoDb ストアが関係する場合は問題ありません。知りたいのは、セッション継続性を備えたクラスタリングを使用する nodejs アプリケーションの場合の標準的なアプローチについてです。
https://github.com/indutny/sticky-session