Game server on node.js using cluster and redis, what logic to use?

Question

Redis

Hello. I ask experienced colleagues for help in organizing the logic of the game server - on a new platform for me, because of which, due to lack of practical experience (behind the back of the most trivial browsers on php-mysql-memcache), I really would not want to screw up in terms of optimization, so that later I didn't have to reformat the logic on the fly.
The goal is to write a browser with a "room" turn-based combat (a la jrpg), where each player is "responsible" for his character. I settled on node.js as a server platform, redis with orm jugglingdb will serve as a database. Communication with clients via tcp sockets.
To the players participating in the battle, the server in turn gives the right to move, limiting the choice of the strike / item / skill used by the player to a specified interval (say, 20 seconds), then waits a certain period of time (depending on the duration of the animation of one or another action of the active character, prescribed in the server database), after which it gives the right to move to the next player.
For players who are out of combat (waiting in the lobby when recruiting players for a group battle, shopping in the store, etc.), the game restores the mana and health bar once every one or several seconds.
Sluggishness in the design of logic is caused by the fundamental desire to use cluster in order to move some of the processed tasks to parallel running workers, raising the performance ceiling compared to the operation of all logic within one process on one core.
What kind of tasks is reasonable to move from the main process to the "workers"? Only connecting sockets and communicating with them comes to mind. About redis, more precisely about its publish / subscribe functionality, I would also like to know in terms of performance - is it suitable for communication between threads and the master process, or is it better to organize this through process.on('message') / worker.send(data )?
This kind of data, such as battleroom objects and player gathering lobbies, is supposed to be stored in the main process. Perhaps there are better techniques?
I would really appreciate any advice, explanations and examples.

Answer 1

To do on a stream on a connection - the worst idea.
Using radish for interprocessor communication is a good idea.
How to split tasks into workers. I think it would be an excellent option to evenly spread everything over all the cores, that is, the main thread acts as a kind of router, which distributes in turn (in turn, the workers take it themselves) to themselves the information that came through the socket to the main process. In this case, everything can be broken down by players, and to bind on which of the streams which player is processed by its id, for example. For all this, you can use radishes, but it’s better not to be lazy and at least read a little about zeromq, there are sockets, and concurrency framework and message passing.

Answer 2

> What kind of tasks is reasonable to move from the main process to the "workers"? Only connecting sockets and communicating with them comes to mind.
Why do you need a "main process" in this scheme? To solve your problem, it is enough to run the required number of workers (let's say you have 8 cores on your machine - run 9 workers) on different ports and put HAProxy as a balancer in front of them in TCP mode. True, in this case, you will lose information about the IP addresses of clients, since connections are terminated on HAProxy, and in TCP mode it does not transfer information about client IP to the backend. It doesn't matter - you can use HTTP/1.1 and web sockets to solve your problem, then you can get the client address from the X-Forwarded-For header on the backend.
The second option is more complicated - indeed, use a master process that spawns the required number of workers in advance. The scheme is well described here , and there is even a picture, the difference between Unicorn and your scheme is that Unicorn workers work synchronously, and yours will work asynchronously.