Shulou(Shulou.com)06/01 Report--

Redis vs memcached .

Redis compared with memcached, redis is not only suitable for caching, but also for storage, which is a bit of a database shadow. When it comes to databases, transactions are a very important aspect.

Database transaction

Transaction is a logical unit in the execution process of database management system, which is composed of a limited sequence of database operations.

A database transaction usually contains a sequence of read / write operations to the database. It exists for the following two purposes:

1. It provides a method for the database operation sequence to recover from failure to the normal state, and provides a way for the database to maintain consistency even in the abnormal state.

two。 When multiple applications are accessing the database concurrently, you can provide an isolation method between these applications to prevent each other's operations from interfering with each other.

Transaction constraint

When a transaction is committed to DBMS (database management system), DBMS (database management system) needs to ensure that all operations in the transaction are completed successfully and the results are permanently saved in the database. If some operations in the transaction are not completed successfully, all operations in the transaction need to be rolled back to the state before the transaction is executed. At the same time, the transaction has no effect on the execution of the database or other transactions, and all transactions seem to be running independently.

Through the constraints of the transaction, four characteristics can be summarized.

Atomicity: transactions are executed as a whole, and either all or none of the operations on the database are performed.

Consistency: transactions should ensure that the state of the database transitions from one consistent state to another. The meaning of consistent state is that the data in the database should meet the integrity constraints.

Isolation: when multiple transactions are executed concurrently, the execution of one transaction should not affect the execution of other transactions

Durability: changes made to the database by committed transactions should be permanently saved in the database

If you are interested in learning more about transaction relevance, you can pay attention to transaction propagation attributes and transaction isolation level.

This article mainly demonstrates the effect of redis's support for transactions.

1 related commands

Command

Action

Available version

Time complexity return value WATCH key [key...]

Monitor one (or more) key, and if the key (or these) is altered by other commands before the transaction is executed, the transaction will be interrupted.

> = 2.2.0

O (1)

Always return OK

MULTI

Mark the start of a transaction block > = 1.2.0O (1) always returns OKEXEC

Execute commands within all transaction blocks.

If a key (or some) is being monitored by the WATCH command and there are commands related to this (or these) key in the transaction block, the EXEC command is executed and takes effect only if the key (or these) is not altered by other commands, otherwise the transaction is interrupted (abort).

> = 1.2.0

The sum of the time complexity of all commands in the transaction block and the return values of all commands in the transaction block, in the order in which the commands were executed.

Returns a null value of nil when the operation is interrupted.

DISCARD cancels the transaction and discards all commands within the transaction block.

If you are using the WATCH command to monitor a key (or some), canceling all monitoring is equivalent to executing the command UNWATCH.

> = 2.0.0O (1) always returns OK. UNWATCH

Unmonitor all key from the WATCH command.

If the EXEC command or DISCARD command is executed first after the WATCH command is executed, then there is no need to execute UNWATCH.

Because the EXEC command executes the transaction, the effect of the WATCH command has already been produced; while the DISCARD command cancels the transaction, it also cancels all monitoring of the key, so there is no need to execute UNWATCH after these two commands are executed. > = 2.2.0O (1) is always OK.

Above, I have only sorted it out, and there is nothing to say. The point is the drill.

two。 Command exercise

2.1MULTI, to declare the meaning of the transaction. The following command, pack a package and make a whole, but not absolutely.

127.0.0.1 incr foo 6379 > incr bar (integer) 1127.0.0.1 incr foo (integer) transactions start the command issued by 127.0.0.1 incr foo 6379 > multiOK#, return QUEUED directly, put it in the queue, do not immediately execute 127.0.0.1 integer 6379 > incr barQUEUED127.0.0.1:6379 > execute commands within all transaction blocks 127.0.0.16379 > exec1) (integer) 22) (integer) demonstrate syntax errors Directly stop transaction 127.0.0.1 ERR unknown command 6379 > incr barQUEUED127.0.0.1:6379 > incrbar (error) ERR unknown command 'incrbar'127.0.0.1:6379 > exec (error) EXECABORT Transaction discarded because of previous errors.# transaction does not allow continuous declaration of 127.0.0.1 ERR unknown command 6379 > multiOK127.0.0.1:6379 > multi (error) ERR MULTI calls can not be nested# demo command parameter mismatch Partial success 127.0.0.1 value2 6379 > multiOK127.0.0.1:6379 > incr barQUEUED127.0.0.1:6379 > lpush bar "value2" QUEUED127.0.0.1:6379 > exec1) (integer) 22) (error) WRONGTYPE Operation against a key holding the wrong kind of value

Conclusion

Multi: nesting is not supported

Redis's support for transactions is not rigorous. It doesn't quite conform to the atomicity of ACID.

Redis does not roll back when the transaction fails, but continues to execute the remaining commands. "

If you have experience with relational databases, it may be a bit strange for you to "Redis continues to execute the remaining commands instead of rolling back when a transaction fails."

Here are the advantages of this approach:

Redis commands only fail because of incorrect syntax (and these problems cannot be found when entering the queue), or commands are used on the wrong type of keys: that is, from a practical point of view, failed commands are caused by programming errors that should be found during development and not in the production environment.

Because there is no need to support rollback, the interior of Redis can be kept simple and fast.

2.discard, "discard" means. It means "I don't want all the above orders". It's a bit of a rollback, but it's not. Discard means to discard the commands in the queue. No commands have been issued at this time.

127.0.1 multiOK127.0.0.1:6379 6379 > multiOK127.0.0.1:6379 > discardOK127.0.0.1:6379 > multiOK127.0.0.1:6379 > incr barQUEUED127.0.0.1:6379 > incr fooQUEUED127.0.0.1:6379 > discardOK

2. 1 WATCH: meaning "monitoring". This is my dish, other people stand aside.

The 127.0.1 flushdbOK127.0.0.1:6379 > multiOK#watch command cannot appear in the transaction, otherwise the ERR127.0.0.1:6379 > watch bar (error) ERR WATCH inside MULTI is not allowed# monitoring bar,bar is no longer a casual key and is not allowed to be modified casually. 127.0.0.1 watch barOK# 6379 > before the bar transaction is modified, the transaction succeeds 127.0.1 multiOK127.0.0.1:6379 > incr barQUEUED127.0.0.1:6379 > exec1) (integer) 1#exec, interrupting watch and re-watch127.0.0.1:6379 > watch barOK## before the transaction Modify bar, transaction failed 127.0.0.1 integer 6379 > incr bar (integer) 2127.0.1 integer 6379 > multiOK127.0.0.1:6379 > incr barQUEUED127.0.0.1:6379 > exec (nil)

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.