Transactions in Redis Cluster (Multi Nodes)

• Redis also supports transactions not same as SQL databases. In Redis, transactions consist of a block of commands placed between MULTI and EXEC.
• Commands in connections are not get executed instead of this they get Queued and when EXEC get executed all changes applied to Redis.

Let’s see with some of the examples.

• In the above example, we have started block with MULTI and then we are setting values of key tutorials as Redis. Let’s check that key is present in Redis

• No, it's not. Now we execute command EXEC.

• Now we check

Yay!! it's working. As we have seen the command(set tutorials Redis) which are between MULTI AND EXEC are executed in a transaction.

• When an EXEC is encountered, they are all applied in a single unit.

Key Points of transaction in Redis:

• All the commands in a transaction are serialized and executed sequentially
• It also guarantees that the commands are executed as a single isolated operation.
• Redis transactions are also atomic.
• Redis does not support rollback. If some of the commands fail in the transaction but all other commands which are successful are applied.

Discarding the command queue:

If you want to abort the transaction don’t want to commit the transaction you can use discard this will not execute any commands and connection states will back to normal

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> SET tutorial redis
QUEUED
127.0.0.1:6379> GET tutorial
QUEUED
127.0.0.1:6379> DISCARD
127.0.0.1:6379> Keys *
(empty list or set)

Watch command for Optimistic Locking:

we can use the watch command to detect any changes done by other clients. in case any changes are done on the key for which watch command is issued then transaction gets rolled back and EXEC command returns null response.

• It provides CAS (compare and swap ) kind of behavior.

Let’s see some example.

Clients1 executed these commands.

127.0.0.1:6379>WATCH tutorials
OK
127.0.0.1:6379>MULTI
OK
127.0.0.1:6379>SET tutorials redis-test // key get updated
QUEUED
127.0.0.1:6379>EXEC
(nil)

At the same time, Client2 updated the value before it was committed by client1 then it will get rollback.

127.0.0.1:6379>SET tutorials redis-test-client2 //key get updated

Now let's see the value of key tutorials.

127.0.0.1:6379>GET tutorials
redis-test-client2

We have seen how transactions work in Redis. Let’s discuss about the transaction in Redis Cluster.

Transactions in Redis Cluster:

If transactions are done in a standalone server or all the keys are present in the same node then it can be achieved. This option allows for fully-featured transactions. The client is required to keep track of the node the transaction is executed while the transaction is in progress. The client needs to set a transactional flag and on the very first command containing a key, the MULTI command needs to be issued, right before the first command within the transaction.

In a distributed environment when the keys which are required to get updated are present in different nodes in this case once the transaction is executed, When the key is requested from a particular node and the node is not yet part of the transaction, aMULTI command is issued to join the node to the transaction. In this case, the individual transaction does not know that the value of the keys is updated in different node because node, where the transaction is done other node is aware of this. So this cause problem in multi sharded environment.

Thanks

PS: If you like these articles please claps and share it, It motivates to write more articles.