Shulou(Shulou.com)05/31 Report--

This article mainly introduces what is the transaction in Redis. It is very detailed and has certain reference value. Friends who are interested must finish reading it.

The related command format function returns the result WATCHWATCH key [key...] The given Keys is marked as a monitoring state, and as a condition for transaction execution, always OK.UNWATCHUNWATCH clears the monitoring state of Keys in the transaction. If EXEC or DISCARD is called, it is no longer necessary to manually call UNWATCHalways OK.MULTIMULTI to explicitly open the redis transaction, and the subsequent commands will be queued to wait for the commands queue in the always OK.EXECEXEC transaction to be executed using EXEC atoms to restore the connection state. If WATCH is called before, the command will be executed only if the Keys in the monitor has not been modified. Otherwise, stop execution (see below, CAS mechanism) succeeded: return array-each element corresponds to the return result of a command in an atomic transaction

Failed: NULL is returned (Ruby returns `nil`); DISCARDDISCARD clears the commands queue in the transaction and restores the connection status. If WATCH is called before, release the Keysalways OK in the monitor.

Note:

-MULTI,EXEC,DISCARD is a common command to explicitly open and control transactions, which can be compared to BEGAIN,COMMIT,ROLLBACK in relational databases (in fact, there is a big gap)

The-WATCH command is used to solve the problem of unrepeatable and phantom reads caused by transaction concurrency (simply understood as locking Key)

Redis transaction

MULTI, EXEC, and DISCARD and WATCH are the basis of Redis transactions. Used to explicitly open and control a transaction that allows a set of commands to be executed in a step. And provide two important guarantees:

All commands in the transaction are serialized and executed sequentially. During the execution of a Redis transaction, there are no requests made by another client. This ensures that the command queue is executed as a separate atomic operation.

All commands in the queue are either processed or ignored. The EXEC command triggers the execution of all commands in the transaction, so when the client loses its connection to the server in the context of the transaction

If it occurs before the MULTI command is invoked, no commands is executed

If the EXEC command is called before, all commands are executed.

At the same time, redis uses AOF (append-only file) to write transactions to disk using an additional write operation. In case of downtime, process collapse, etc., you can use redis-check-aof tool to repair append-only file to make the service start normally and resume some operations.

Usage

Use the MULTI command to explicitly open the Redis transaction. The command always responds with OK. At this point, the user can issue multiple commands, and instead of executing them, Redis queues them. After EXEC is called, all commands are executed. Calling DISCARD clears the commands queue in the transaction and exits the transaction.

The following example increments the bonds foo and bar atomically.

> MULTIOK > INCR fooQUEUED > INCR barQUEUED > EXEC1) (integer) 12) (integer) 1

As you can see from the above command execution, EXEC returns an array where each element is the result of a single command in the transaction in the same order as the command was issued. When the Redis connection is in the context of the MULTI request, all commands reply with the string QUEUED (sent as a status reply from the perspective of the Redis protocol) and are queued in the command queue. Only when EXEC is called will the queued command be executed, and the real result will be returned.

Errors in transactions

During a transaction, you may encounter two types of command errors:

An error occurred before invoking the EXEC command (COMMAND queuing failed).

For example, a command may have syntax errors (wrong number of parameters, wrong command name.)

Or there may be some key conditions, such as running out of memory (if the server uses the maxmemory instruction to make a memory limit).

The client detects the first error before the EXEC call. By checking the status reply of the queued command (* * Note: this refers to the status reply of the queue, not the execution result * *), if the command responds with QUEUED, it has been queued correctly, otherwise Redis will return an error. If an error occurs while queuing a command, most clients abort the transaction and clear the command queue. However:

Prior to Redis 2.6.5, in this case, after the EXEC command was invoked, the client executed a subset of the command (the successfully queued command) and ignored the previous error.

Starting with Redis 2.6.5, the server remembers the errors that occurred during the cumulative command, refuses to execute the transaction when the EXEC command is invoked, returns these errors, and automatically clears the command queue.

Examples are as follows:

> MULTI+OK > INCR a b c-ERR wrong number of arguments for 'incr' command

This is due to a syntax error in the INCR command, which is detected before calling EXEC and terminates the transaction (version2.6.5+).

An error occurred after invoking the EXEC command.

For example, perform an operation on a key with the wrong value (such as calling a List operation on a string value)

Errors that occur after the execution of EXEC commands are not given special treatment: even if some commands in the transaction fail, other commands are executed normally.

Examples are as follows:

> MULTI+OK > SET a 3+QUEUED > LPOP a+QUEUED > EXEC*2+OK-ERR Operation against a key holding the wrong kind of value

EXEC returns a string array of two elements, one element is OK and the other is-ERR.

Whether the error can be reasonably fed back to the user depends on the self-implementation of the client library (such as Spring-data-redis.redisTemplate).

It is important to note that even if the command fails, all other commands in the queue will be processed-Redis will not stop the processing of the command.

Redis transactions do not support Rollback (key)

In fact, the Redis command may fail when the transaction is executed, but will continue to execute the remaining commands instead of Rollback (transaction rollback). If you have ever used a relational database, this situation may make you feel strange. However, there is a good explanation for this situation:

Redis commands may fail simply because the wrong syntax is invoked (errors that cannot be detected when commands are queued) or manipulate a Key with the wrong data type: this means that failed commands are actually caused by programming errors that can be detected in development and should not exist in a production environment. "it's all your own programming mistakes, and it has nothing to do with us." )

Because there is no need to support Rollback,Redis internal simplicity and more efficient.

"what if the mistake just happened?" This is an argument against Redis's point of view. It should be noted, however, that in general, a rollback does not save programming errors. Since no one can save the programmer's error, and the error type required for the failure of the Redis command is unlikely to enter the production environment, we chose a simpler and faster approach that does not support error rollback (Rollback).

Clear command queue

DISCARD is used to abort a transaction. All commands in the transaction will not be executed and the connection will return to normal.

> SET foo 1OK > MULTIOK > INCR fooQUEUED > DISCARDOK > GET foo "1" these are all the contents of the article "what are transactions in Redis?" Thank you for reading! Hope to share the content to help you, more related knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.