Redis learning Manual (Transaction)

I. Overview: Like many other databases, Redis also provides a transaction mechanism as a NoSQL database. In Redis, the four commands MULTIEXECDISCARDWATCH are the cornerstone for implementing transactions. I believe this concept is no stranger to developers with relational database development experience. Even so, we will briefly list things in Redis.

I. Overview: Like many other databases, Redis also provides a transaction mechanism as a NoSQL database. In Redis, the four commands MULTI/EXEC/DISCARD/WATCH are the cornerstone of our transaction implementation. I believe this concept is no stranger to developers with relational database development experience. Even so, we will briefly list things in Redis.

I. Overview: Like many other databases, Redis also provides a transaction mechanism as a NoSQL database. In Redis, the four commands MULTI/EXEC/DISCARD/WATCH are the cornerstone of our transaction implementation. I believe this concept is no stranger to developers with relational database development experience. Even so, we will briefly list the transaction implementation features in Redis: 1 ). all commands in the transaction will be executed in a serialized order. During the transaction execution, Redis will not provide any service for requests from other clients, this ensures that all commands in a transaction are executed by atoms. 2 ). Compared with a transaction in a relational database, if a command fails to be executed in a Redis transaction, the subsequent command will still be executed.3). We can use the MULTI command to start a TRANSACTION. People with experience in relational database development can understand it as a "begin transaction" statement. The commands executed after this statement are considered as operations in the transaction. Finally, we can commit/roll back all operations in the transaction by executing the EXEC/DISCARD command. The two Redis commands can be considered to be equivalent to the COMMIT/ROLLBACK statements in relational databases. 4). Before the transaction is started, if the communication between the client and the server fails and the network is disconnected, all the statements to be executed will not be executed by the server. However, if the network interruption occurs after the client executes the EXEC command, all the commands in the transaction will be executed by the server. 5) when the Append-Only mode is used, Redis will write all write operations in the transaction to the disk by calling the system function write. However, if a system crash occurs during the write process, such as a power failure, only some data may be written to the disk, but other data may be lost. The Redis server performs a series of necessary consistency checks when it is restarted. Once a similar problem is found, it immediately exits and provides an error message. In this case, we must make full use of the Redis-check-aof tool provided in the redis toolkit. This tool can help us locate data inconsistency errors, and roll back some data that has been written. After the repair, we can restart the Redis server again. Ii. Related command list: Command prototype time complexity command description return value MULTI is used to mark the start of a transaction, and subsequent commands will be stored in the command queue until EXEC is executed, these commands will be executed by the atom. Always return all commands in the command queue executed by OKEXEC in a transaction, and restore the status of the current connection to normal, that is, non-transaction status. If the WATCH command is executed in a transaction, only when the Keys monitored by WATCH are not modified can the EXEC command execute all the commands in the transaction queue, otherwise, EXEC will discard all commands in the current transaction. Atomically return the results of each command in the transaction. If WATCH is used in the transaction, once the transaction is abandoned, EXEC returns a NULL-multi-bulk reply. The DISCARD rolls back all commands in the transaction queue, and then restores the current connection status to normal, that is, non-transaction status. If the WATCH command is used, it will UNWATCH all Keys. Always Return OK. WATCH key [key...] O (1) You can specify the Keys to be monitored before executing the MULTI command. However, if the monitored Keys are modified before executing EXEC, EXEC will discard all commands in the transaction queue. Always Return OK. Unwatch o (1) cancels the specified monitored Keys in the current transaction. If the EXEC or DISCARD command is executed, you do not need to manually execute the command because after that, all monitored Keys in the transaction are automatically canceled. Always Return OK.
Iii. Command example: 1. The transaction is executed normally: # execute the Redis client tool under the Shell command line. /> Redis-cli # Start a new transaction on the current connection. Redis 127.0.0.1: 6379> multi OK # execute the first command in the transaction. The returned result shows that the command is not executed immediately, but is stored in the command queue of the transaction. Redis 127.0.0.1: 6379> incr t1 QUEUED # execute a new command. The result shows that the command is also stored in the transaction command queue. Redis 127.0.0.1: 6379> incr t2 QUEUED # execute all the commands in the transaction command queue. The result shows that the results of the commands in the queue are returned. Redis 127.0.0.1: 6379> exec 1) (integer) 1 2) (integer) 1 2. A failed command exists in the transaction: # Start a new transaction. Redis 127.0.0.1: 6379> multi OK # set the value of key a to 3 of the string type. Redis 127.0.0.1: 6379> set a 3 QUEUED # the pop-up element in the header of the value associated with the slave key a. Because the value is of the string type, the lpop command can only be used for the List type, therefore, when executing the exec command, the command will fail. Redis 127.0.0.1: 6379> lpop a QUEUED # set the value of key a to string 4 again. Redis 127.0.0.1: 6379> set a 4 QUEUED # obtain the value of key a to check whether the value is successfully set by the second set command in the transaction. Redis 127.0.0.1: 6379> get a QUEUED # From the result, we can see that the second lpop command in the transaction fails to be executed, and the subsequent set and get commands are successfully executed, this is the most important difference between Redis transactions and those in relational databases. Redis 127.0.0.1: 6379> exec 1) OK 2) (error) ERR Operation against a key holding the wrong kind of value 3) OK 4) "4" 3. rollback transaction: # sets the value before the execution of a transaction for key t2. Redis 127.0.0.1: 6379> set t2 tt OK # Start a transaction. Redis 127.0.0.1: 6379> multi OK # set a new value for this key in the transaction. Redis 127.0.0.1: 6379> set t2 ttnew QUEUED # discard the transaction. Redis 127.0.0.1: 6379> discard OK # Check the key t2 value. The result shows that the key value is still the value before the start of the transaction. Redis 127.0.0.1: 6379> get t2 "tt"