CODEWITHSUNDEEP
node.jsconcurrencyredissocket.io
ryAn_Hdot
ryAn_Hdot

Reputation: 79

What assumptions can I make when using Redis with a single connection from a NodeJS server

I'm using SocketIO on a NodeJS instance with a single connection to a Redis cache. This cache is being used as a means to maintain state in a real time environment.

My premises include that concurrency issues will likely occur due to high volume of transactions occurring, however, I'm not sure exactly which concurrency issues I need to account for...

My initial design implements using Lua scripts and EVAL (a script called with EVAL is considered an atomic transaction to Redis) in order enable checks on the state of a given key, but aside from this I'm not sure if I need to implement locks anywhere else.

The main concern I have is when SocketIO catches a connection and subsequently an event to execute, what can I guarantee about the Redis EVAL that happens in that event. A specific use case:

1) Client A emits an event that is caught by the server

2) Server executes requested event, which includes a call to EVAL a Lua script on Redis

3) Client B emits an event that is caught by the server

4) Server executes requested event, which includes a call to the EVAL a different Lua script on Redis

Due to the asynchronous nature of NodeJS, am I able to assume that the EVAL from Client A will always be received by the Redis server before Client B's? Am I understanding the event loop completely wrong?

Upvotes: 0

Views: 138

Answers (1)

Dmitry
Dmitry

Reputation: 289

The answer completely depends on your code. Basically yes, for such type of events nodejs will process them in order they appear on the event loop queue.

However, you say that request processing includes a call to EVAL, that means if your processing includes other I/O (like querying persistent database), the order of steps in processing request from a Client A can interleave with steps in processing requests from Client B.

In general, you should try to avoid creating a logic that breaks on concurrency if possible. If something needs to be done in the exact same order, consider creating a processing queues (global queue where next item can be processed only after previous was completed) or localise critical parts in atomic sequences (like LUA script).

Upvotes: 1

Related Questions