Redis Transaction Processing

Redis Transaction Processing

Current redis version
 
# Redis-cli-v
Redis-cli 2.6.4

MULTI, EXEC, DISCARD, and WATCH are the foundation of Redis transactions.

1. The MULTI command is used to start a transaction. It always returns OK.
After MULTI is executed, the client can continue to send any number of commands to the server. These commands are not executed immediately, but put into a queue.

2. When the EXEC command is called, all the commands in the queue will be executed.

++

Redis 192.168.1.53: 6379> multi
OK
Redis 192.168.1.53: 6379> incr foo
QUEUED
Redis 192.168.1.53: 6379> set t1 1
QUEUED
Redis 192.168.1.53: 6379> exec
1) (integer) 2
2) OK

++ Java code ++

Jedis jedis = new Jedis ("192.168.1.53", 6379 );
Transaction tx = jedis. multi ();
Tx. incr ("foo ");
Tx. set ("t1", "2 ");
List <Object> result = tx.exe c ();
 
If (result = null | result. isEmpty ()){
System. err. println ("Transaction error ...");
Return;
}
 
For (Object rt: result ){
System. out. println (rt. toString ());
}
 

When using transactions, you may encounter the following two errors:
1. Before the transaction executes EXEC, the queuing command may fail. For example, a command may produce syntax errors (Incorrect Parameter quantity, incorrect parameter name, and so on), or other more serious errors, such as insufficient memory.

(If the server uses maxmemory to set the maximum memory limit ).

2. The command may fail after EXEC is called. For example, commands in a transaction may process keys of the wrong type, such as using LIST commands on string keys, and so on.

The first error:
Server:
Before Redis 2.6.5, Redis only executes the successful commands in the transaction and ignores the failed commands.

However, starting from Redis 2.6.5, the server will record the failure of command queuing, and refuse to execute and automatically discard the transaction when the client calls the EXEC command.
++
 
Redis 192.168.1.53: 6379> multi
OK
Redis 192.168.1.53: 6379> incr foo
QUEUED
Redis 192.168.1.53: 6379> set ff 11 22
(Error) ERR wrong number of arguments for 'set' command
Redis 192.168.1.53: 6379> exec
1) (integer) 4

Because my version is 2.6.4, Redis only executes the successful commands in the transaction and ignores the failed commands.

Client (jredis ):

In the past, the client checked the return value obtained from the command: If QUEUED is returned when the command is sent to the queue, the queue is successful; otherwise, the queue fails. If a command fails to join the team,

Then most clients stop and cancel the transaction.

The second error:

As for the errors generated after the EXEC command is executed, they are not specially processed: even if some/some commands in the transaction produce errors during execution, other commands in the transaction will continue to be executed.
 
++
 
Redis 192.168.1.53: 6379> multi
OK
Redis 192.168.1.53: 6379> set a 11
QUEUED
Redis 192.168.1.53: 6379> lpop
QUEUED
Redis 192.168.1.53: 6379> exec
1) OK
2) (error) ERR Operation against a key holding the wrong kind of value
 
++ Java code ++

Jedis jedis = new Jedis ("192.168.1.53", 6379 );
Transaction tx = jedis. multi ();
Tx. set ("t1", "2 ");
Tx. lpop ("t1 ");
List <Object> result = tx.exe c ();
 
If (result = null | result. isEmpty ()){
System. err. println ("Transaction error ...");
Return;
}
 
For (Object rt: result ){
System. out. println (rt. toString ());
}
 

Redis does not roll back when the transaction fails, but continues to execute the remaining commands.
This approach may make you feel a bit strange. The following are the advantages of this approach:
1. redis commands only fail due to wrong syntax (and these problems cannot be found during the queue), or the commands are used on Wrong keys: that is to say, from a practical point of view, failed commands are caused by programming errors, which should be discovered during development rather than in the production environment.
2. Because rollback is not required, Redis can be kept simple and fast internally.

Since there is no mechanism to avoid errors caused by programmers themselves, and such errors are usually not present in the production environment, therefore, Redis chose a simpler and faster non-rollback method to process transactions.

3. When the DISCARD command is run, the transaction is abandoned, the transaction queue is cleared, and the client exits from the transaction status.
++

Redis 192.168.1.53: 6379> set foo 1
OK
Redis 192.168.1.53: 6379> multi
OK
Redis 192.168.1.53: 6379> incr foo
QUEUED
Redis 192.168.1.53: 6379> discard
OK
Redis 192.168.1.53: 6379> get foo
"1"
 

4. The WATCH command can provide check-and-set (CAS) behavior for Redis transactions.
Keys monitored by WATCH are monitored, and you will find that these keys have been modified. If at least one monitored key is modified before EXEC execution, the entire transaction will be canceled.
++ The First Command

Redis 192.168.1.53: 6379> watch foo
OK
Redis 192.168.1.53: 6379> set foo 5
OK
Redis 192.168.1.53: 6379> multi
OK
Redis 192.168.1.53: 6379> set foo 9
QUEUED
 

++ Pause (execute the following command only after the second command is executed) ++

Redis 192.168.1.53: 6379> exec
(Nil)
Redis 192.168.1.53: 6379> get foo
"8"
 

++

Redis 192.168.1.53: 6379> set foo 8
OK
 
++ Java code ++

Jedis jedis = new Jedis ("192.168.1.53", 6379 );
Jedis. watch ("foo ");
Transaction tx = jedis. multi ();
Tx. incr ("foo ");
 
List <Object> result = tx.exe c (); // when you run the command, you can open a breakpoint and change the value of foo through the command line.
If (result = null | result. isEmpty ()){
System. err. println ("Transaction error ...");
Return;
}
For (Object rt: result ){
System. out. println (rt. toString ());
}

If another client modifies the value of mykey after the WATCH execution and before the EXEC execution, the transaction of the current client will fail. What the program needs to do is to retry the operation until there is no collision.
This form of lock is called optimistic lock, which is a very powerful lock mechanism. In addition, in most cases, different clients access different keys, and there are usually few collisions. Therefore, Retry is usually not required.

Install and test Redis in Ubuntu 14.04

Redis cluster details

Install Redis in Ubuntu 12.10 (graphic explanation) + Jedis to connect to Redis

Redis series-installation, deployment, and maintenance

Install Redis in CentOS 6.3

Learning notes on Redis installation and deployment

Redis. conf

Redis details: click here
Redis: click here

This article permanently updates the link address: