Redis (2) advanced features: transactions, redis
The first article introduces Redis as a powerful key-value warehouse that supports five flexible data structures. In fact, Redis also supports some other advanced features: transactions, publishing and subscription, pipelines, scripts, etc. In this article, let's take a look at the transactions.
As mentioned in the previous article, every command in Redis is atomic, because the internal implementation of Redis is single-threaded. Of course, Redis also supports transactions between multiple commands, but the transaction is relatively simple in Redis, unlike database transactions that involve features such as the propagation level and isolation level.
Use the multi command to start a new transaction, Execute Command commit, and run the discard command to roll back. If you save the available credit card quota to balance and the overdue amount to debt, the two keys must be updated simultaneously in a transaction during 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"75"127.0.0.1:6379> get debt"25"
For other commands after multi commands, the returned results are all "QUEUED". These commands are not executed immediately, but are simply cached on the Server. After the exec command is issued, they will be executed together; or the discard command will roll back the transaction.
In the official Redis documentation, we have two features of transactions: The above example is credit card deduction, but in practice, we need to check whether the balance is sufficient during deduction, So we generally do this:
redis.multi()balance = redis.get('balance')if (balance < amtToSubtract) { redis.discard()} else { redis.decrby('balance', amtToSubtract) redis.incrby('debt', amtToSubtract) redis.exec()}
For general database transactions, the above Code is okay, but it does not work for Redis transactions, because before the exec command, all the commands are cached by Redis, the balance value cannot be obtained at all. How can we implement such transactions in Redis based on an existing value? 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()}
Generally speaking, the watch command marks a key. If a key is marked, the transaction will fail if it has been modified before the transaction is committed, in this case, you can try again in the program. As in the above example, the key balance is marked first, and then check whether the balance is sufficient. If the balance is insufficient, the flag is canceled without deduction. If the balance is sufficient, the transaction is started to update the transaction, if the key balance is modified by others during this period, an error will be reported when the transaction is committed (execute exec). This type of error can usually be captured in the program and then re-executed until it succeeds.
Rollback is not supported after Redis transactions fail.An important difference from a database transaction is that Redis transactions do not roll back when errors occur during execution. After the exec command, Redis Server starts executing cached commands one by one. If an error occurs in executing a command, the previous command will not be rolled back.
127.0.0.1:6379> set value 1OK127.0.0.1:6379> set value2 abcOK127.0.0.1:6379> multiOK127.0.0.1:6379> incr valueQUEUED127.0.0.1:6379> incr value2QUEUED127.0.0.1:6379> exec1) (integer) 22) (error) ERR value is not an integer or out of range127.0.0.1:6379> get value"2"127.0.0.1:6379>
After exec commits a transaction, it is wrong when it is executed to incr value2 (the data type is incorrect), but the transaction's operation on value takes effect, this can be seen from the returned values of get values.
