Redis Transaction Processing

Current redis version

#redis-cli  -vredis-cli 2.6.4

Multi, exec, discard, and watch are the foundation of redis transactions.

1. multiThe 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. ExecWhen a command is called, all the commands in the queue will be executed.
++ Commands ++

redis 192.168.1.53:6379> multiOKredis 192.168.1.53:6379> incr fooQUEUEDredis 192.168.1.53:6379> set t1 1QUEUEDredis 192.168.1.53:6379> exec1) (integer) 22) 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.exec();if (result == null || result.isEmpty()) {     System. err.println( "Transaction error...");     return ;}for (Object rt : result) {     System. out.println(rt.toString());}

When using a transaction, 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 (parameter quantity errors, parameter name errors, and so on), or other more serious errors, for example, the memory is insufficient (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, while ignoring the failed commands, starting from redis 2.6.5, the server will record the failure of the command to enter the queue, and refuse to execute and automatically discard the transaction when the client calls the EXEC command. ++ Commands ++

redis 192.168.1.53:6379> multiOKredis 192.168.1.53:6379> incr fooQUEUEDredis 192.168.1.53:6379> set ff 11 22(error) ERR wrong number of arguments for ‘set‘ commandredis 192.168.1.53:6379> exec1) (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 queue, most clients stop and cancel the transaction.
The second error: 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.

++ Commands++

redis 192.168.1.53:6379> multiOKredis 192.168.1.53:6379> set a 11QUEUEDredis 192.168.1.53:6379> lpop aQUEUEDredis 192.168.1.53:6379> exec1) OK2) (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.exec();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. DiscardThe transaction is abandoned, the transaction queue is cleared, and the client exits from the transaction status. ++ Commands ++

redis 192.168.1.53:6379> set foo 1OKredis 192.168.1.53:6379> multiOKredis 192.168.1.53:6379> incr fooQUEUEDredis 192.168.1.53:6379> discardOKredis 192.168.1.53:6379> get foo"1"

4. WatchCommand to 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 fooOKredis 192.168.1.53:6379> set foo 5OKredis 192.168.1.53:6379> multiOKredis 192.168.1.53:6379> set foo 9QUEUED

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

redis 192.168.1.53:6379> exec(nil)redis 192.168.1.53:6379> get foo"8"

++ Second command++

redis 192.168.1.53:6379> set foo 8OK

++ Java code ++

Jedis = new Jedis ("192.168.1.53", 6379); Jedis. watch ("foo"); transaction Tx = Jedis. multi (); Tx. incr ("foo"); List <Object> result = tx.exe C (); // breakpoint occurs here during the runtime, then, use the command line to change the value of Foo 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.