[Redis] Transactions

1) Overview

Redis transactions allow a group of commands to be executed sequentially; avoiding the problem of race conditions. It is not possible that a request issued by another client is executed in the middle of the execution of a Redis transaction. Additionally, Redis transactions are atomic, meaning either all of the commands or none are processed.

2) Implementation

A transaction follows the format of:
multi
<your command(s)>
exec
Any commands you enter between multi--exec are queued. 

2.1) Example

127.0.0.1:6379> multi
127.0.0.1:6379> set num 10
127.0.0.1:6379> incrby num 10
127.0.0.1:6379> exec
(integer) 20

2.2) Discard Example

If you want to cancel your transaction while using the redis-cli, you can just enter discard.
127.0.0.1:6379> multi
127.0.0.1:6379> set num 10
127.0.0.1:6379> incrby num 10
127.0.0.1:6379> discard

3) Errors inside a transaction

There are two types of error that can happen during a transaction:

3.1) Before EXEC

A command may fail to be queued. For example, the command may be syntactically wrong (wrong # of arguments, name.etc). Starting with Redis 2.6.5, server will refuse the entire transaction if a before-exec error happens.

3.2) After EXEC

A command may fail after exec is called, for example, if the key we are performing operation on is wrong. Unfortunately, there is no special way to handle this: even if some commands fails, the other commands will be executed.

3.2.1) Example

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set a 1
QUEUED
127.0.0.1:6379> set b 2
QUEUED
127.0.0.1:6379> lpop a
QUEUED
127.0.0.1:6379> exec
1) OK
2) OK
3) (error) WRONGTYPE Operation against a key holding the wrong kind of value
127.0.0.1:6379> get a
"1"
127.0.0.1:6379> get b
"2"

4) Rollbacks

It may be odd that Redis does not roll back when commands fail during a transaction. But here are some good reasons for that:

  • Redis commands can fail only if it is called with a wrong syntax, or against keys holding the wrong data type. This means that these failures are a result of programming errors and should be detected during development. 
  • Redis is internally simplified and faster because it does not need the ability to roll back.

5) Check-and-set

WATCH is the command to do a check-and-set transaction. Watch are often used with multi-exec to ensure that a variable did not change since the moment we 'watched' it. If no such change occured, then we run out transaction. If there are changes, then the entire transaction aborts and EXEC returns a null response.

For example:

127.0.0.1:6379> watch test1
OK
127.0.0.1:6379> set test1
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> get test1
QUEUED
127.0.0.1:6379> exec
(nil)

5.1) WATCH - Solving race conditions

The code below works perfectly with a single client. However, if multiple clients try to increment the key about the same time, then there'll be a race condition - the variable, val, can be incremented multiple times before being set to mykey.
val = GET mykey
val = val + 1
SET mykey $val

Thankfully, we can fix this using the WATCH method. The only difference here is WATCH, MULTI-EXEC are used.
watch mykey
val = GET mykey
val = val + 1
multi
SET $val
exec

5.2) UNWATCHed

Whenever a EXEC is called, all keys are UNWATCHED: meaning that are no longer being 'watched'/monitored.

6) Redis Scripting and Transactions

A Redis script is transaction by definition, meaning that everything you can do in a transaction, you can do it with a script; and is usually simpler and faster.

Resource

https://redis.io/topics/transactions

Comments

Post a Comment

Popular posts from this blog

[Redis] Redis Cluster vs Redis Sentinel

1) In-Depth Guides to Redis Cluster and Sentinel For more in-depth explanation for Redis Cluster or Redis Sentinel, please read my other posts: Sentinel:  https://notafraidofwong.blogspot.com/2019/05/redis-redis-sentinel.html Cluster:  https://notafraidofwong.blogspot.com/2019/05/redis-redis-cluster.html 2) Deciding between Redis Sentinel and Redis Cluster Similarities : Both solutions provide high availability for your system. 2.1) Redis Cluster 2.1.1) Pros Shards data across multiple nodes Has replication support Has built-in failover of master 2.1.2) Cons Not every library supports it May not be as robust (yet) as Standalone Redis or Sentinel Setup and maintenance is more complicated 2.2) Redis Sentinel 2.2.1) Pros Automatically selects new master in case of failure Easy to setup, (seems) easy to maintain 2.2.2) Cons No data sharding; master might be overutilized. Another distributed system to maintain. 3) So how do I decide? In
Read more

[Unit Testing] Test Doubles (Stubs, Mocks....etc)

Image
In unit testing, isolation is key. The goal of unit testing is to test individual components, and not an entire system . The class/object/function you are testing is System Under Test (SUT) , and the other components of the system are Collaborators or Dependencies. Test Double  is a generic term for any kind of 'pretend' object used in place of a real object for testing purposes.  There are several types of Testing Doubles. We will start with: Fake Stub Mock Command Queries Mocks vs Stubs And then: Dummy Spies Spies vs Mocks I) Basic Testing Doubles a) Fake Fake are objects that have working implementations, but not same as production one. Usually they take some shortcut and have simplified version of production code. Note that Fake is a generic term - that can point to anything; usually mock and stubs. An example of this is an in-memory implementation of a database. This fake implementation will not access the actual database, but will u
Read more

[Node.js] Pending HTTP requests lead to unresponsive nodeJS

This is a recap conclusion to the potential problems of a NodeJS program I worked on previously. The program simulates thousands of clients navigating a website by sending thousands of http requests to a given API . The idea is to load test a particular API to make sure they can handle high traffic. Because we are simulating clients, it's important to keep track of the state of the simulated client as well. The problem with this program is it is buggy and becomes unresponsive from time to time (the only solution is to restart it). The problem was fixed by re-writing the entire program in Java, but it was regretful that I never had enough time to find the exact reason the nodeJS version of it failed. The following are potential causes I suspect: 1. Exceptions The NodeJS program was not written very neatly and stacked callbacks on top of callbacks on top of callbacks. This made it very difficult to keep track of exceptions and unexpected http responses are prone to happen. So
Read more