The first article describes Redis as a powerful key-value repository that supports five flexible data structures. In fact, Redis also supports some other advanced: transactions, publications and subscriptions, pipelines, scripts, and so on, so let's take a look at the transaction.
In the previous article we mentioned that each command in Redis is atomic because the implementation within Redis is single-threaded. Of course, Redis also supports transactions between multiple commands, but transactions are relatively simple in Redis, unlike database transactions that involve features such as propagation levels, isolation levels, and so on.
Use the Multi command to start a new transaction, the EXEC command commits, and the discard command rolls back. If the credit card's available amount is deposited into the balance, and the amount owed to debt, the two keys must be updated in one transaction at the time of consumption.
127.0.0.1:6379> set balance 100ok127.0.0.1:6379> set debt 0ok127.0.0.1:6379> multiok127.0.0.1:6379> Decrby Balance 25queued127.0.0.1:6379> Incrby Debt 25queued127.0.0.1:6379> exec1) (integer) 752) (integer) 25127.0.0.1:6379> Get Balance "127.0.0.1:6379>" Get Debt "25"
Other commands after the Multi command, the return result is "QUEUED", these commands are not executed immediately, but simply cached on the server side. They will not be executed together after the EXEC command is issued, or the discard command rolls back the transaction.
There are two features in the Redis official documentation that indicate transactions:
- The commands in a transaction are executed sequentially in the order in which they enter the cache queue, and Redis will not accept commands from other clients during transaction execution (isolation)
- The commands in the transaction, or all of them, or all do not execute. (Atomic nature)
The above example is a credit card deduction, but in practice we need to check if the balance is sufficient in the actual deduction, so this is usually done:
Redis.multi () balance = redis.get (' balance ') if (balance < amttosubtract) { redis.discard ()} else { Redis.decrby (' balance ', amttosubtract) Redis.incrby (' Debt ', amttosubtract) redis.exec ()}
For normal database transactions, the above code is fine, but not for redis transactions, because all commands are cached by Redis before the EXEC command, and the value of balance is not reached at all. What about a transaction like this that needs to be based on a value that already exists in Redis? The answer is the Watch command:
Redis.watch (' balance ') balance = redis.get (' balance ') if (balance < amttosubtract) { redis.unwatch ()} else { Redis.multi () Redis.decrby (' balance ', amttosubtract) Redis.incrby (' Debt ', amttosubtract) redis.exec ( )}
In layman's words, the Watch command marks a key, and if a key is marked, the transaction will fail if the key is modified by someone else before committing the transaction, which can usually be done again in the program. Like the example above, first mark the key balance, and then check whether the balance is sufficient, not enough to cancel the mark, do not make a deduction, enough to start a transaction to update the operation, if the key balance by others during this period, the commit transaction (EXEC) will be error, This type of error can usually be caught in a program and re-executed again until it succeeds.
Rollback is not supported after Redis transaction failureOne difference that is important to database transactions is that Redis transactions do not roll back after an error occurs during execution. After the EXEC command, Redis server starts executing a cached command one at a time, and the previous command will not be rolled back if a command execution fails.
After the exec commits the transaction, the error occurs when executing to INCR value2 (the data type is incorrect), but the operation of the transaction to value is in effect, which can be seen from the return value of the Get value later.
Redis (ii) Advanced Features: Transactions
