Applications for REDIS transactions

Redis support for transactions is now relatively straightforward. Redis can only guarantee that commands in one client-initiated transaction can be executed consecutively, but not in the middle of the other client's commands. Since Redis is a single-threaded process for all client requests, it is easy to do so. In general, Redis will process and return processing results immediately after receiving a command from a client, but when a client issues a multi command in a connection, the connection goes into a transaction context, and the subsequent command is not executed immediately, but is first placed in a queue. When the EXEC command is received from this connection, Redis executes all the commands in the queue sequentially. The results of all commands are packaged together and returned to the client. The connection then ends the transaction context.

Redis and MySQL things

	Mysql	Redis
open	Start transaction	Muitl
statement	normal sql	General Command
failed	Rollback rollback	Discard cancel
Success	Commit	Exec

one, under normal circumstances, a thing open, grammar check no problem, not immediately submitted directly, but placed in a queue QUEUED

simple verification of the normal situation a thing of the process: a simple bank transfer,Wang has a yuan,Zhao has a $,Wang turn 100 the implementation process for Zhao

127.0.0.1:6379> set Wang 200

Ok

127.0.0.1:6379> Set Zhao 700

Ok

127.0.0.1:6379> Multi

Ok

127.0.0.1:6379> Decrby Zhao #decrby minus 100

QUEUED

127.0.0.1:6379> Incrby Wang # increased 100

QUEUED

127.0.0.1:6379> EXEC # because it is open transaction, so "commit" can be

1) (integer) 600

2) (integer) 300

127.0.0.1:6379> Mget Wang Zhao

1) "300"

2) # # # Here you can see and set the initial value is not the same ~ ~!

second, when a transaction is opened, if there is a transaction syntax check can not be caused by the exception, the entire transaction will fail, directly discard

127.0.0.1:6379> Multi # Open transaction

Ok

127.0.0.1:6379> Decrby Zhao # minus andhints in the queue

QUEUED

127.0.0.1:6379> DF # Enter an error

(Error) ERR unknown command ' DF '

127.0.0.1:6379> exec

(Error) Execabort transactioN discarded because of previouserrors.

127.0.0.1:6379> Mget Zhao Wang

1) "600"

2) # # # found original minus not effective

Third, the simple transaction of Redis, the syntax itself is correct, but the applicable objects have problems, such as zadd operation List Object

after Exec, when the transaction is in the queue, the correct statements are executed and the inappropriate statements are skipped .

127.0.0.1:6379> Mget Zhao Wang

1) "500"

2) "300"

127.0.0.1:6379> Multi

Ok

127.0.0.1:6379> Decrby Zhao 100

QUEUED

127.0.0.1:6379> sadd Wang DF

QUEUED

127.0.0.1:6379> exec

1) (integer) 400

2) (Error) Wrongtype operation against a key holding the wrong kind of value

127.0.0.1:6379> Mget Zhao Wang

1) "400"

2) "300"

Four, the Redis transaction , enabled is optimistic lock, only responsible for monitoring key has not been changed, if key is changed things canceled, to buy tickets for example: if you do not monitor the key will lead to the money is gone, The ticket did not buy the money is deducted , does not add watch own verification ...

Implementation process:

Windows 1

127.0.0.1:6379> Mget Zhao Wang ticket

1) "600"

2) "600"

3) "1"

127.0.0.1:6379> Watch ticket #监测ticket

Ok

127.0.0.1:6379> Multi #开启事务

Ok

127.0.0.1:6379> Decrby Zhao #减去200

QUEUED

127.0.0.1:6379> DECR Ticket #获取TICKET

QUEUED

window 2:

127.0.0.1:6379> DECR ticket #直接购买票了, move faster than window 1

window 1:

127.0.0.1:6379> exec

(nil)

127.0.0.1:6379> Mget Zhao Wang ticket

1) "600"

2) "600"

3) "0"

Watch can monitor multiple keys, and if multiple keys have a change , the transaction is canceled

Cancel monitoring unwatch

This article is from the "DBSpace" blog, so be sure to keep this source http://dbspace.blog.51cto.com/6873717/1885834

Applications for REDIS transactions