① atomicity. A transaction is an inseparable work unit, and the operations included in the transaction are either done or not done.
② Consistency. Transactions must change the database from one consistency state to another. Consistency and atomicity are closely related.
③ isolation. The execution of a transaction cannot be interfered by other transactions. That is, the operations and data used within a transaction are isolated from other concurrent transactions, and the concurrent transactions cannot interfere with each other.
④ durability. Persistence, also known as permanence, means that once a transaction is committed, its changes to the data in the database should be permanent. The following other operations or faults should not have any impact on it.
There is no concept of isolation level in Redis transactions!
In Redis, a single command guarantees atomicity, but transactions do not guarantee atomicity!
① When concurrency may occur in the program, it is necessary to ensure the accuracy of the data in the case of concurrency, so as to ensure that when the current user operates with other users, the result is the same as that when he operates alone.
② If concurrency control is not done well, dirty reading, unreal reading and non repeatable reading may be caused.
Optimistic locking can be realized in Redis!
1, How does Redis implement transactions?
① Normal execution of transactions
127.0.0.1:6379> multi #Open transaction OK 127.0.0.1:6379> set name dingyongjun #Add data QUEUED 127.0.0.1:6379> set age 26 #Add data QUEUED 127.0.0.1:6379> set high 172 #Add data QUEUED 127.0.0.1:6379> exec Execute transactions 1) OK 2) OK 3) OK 127.0.0.1:6379> get name #Successful data acquisition proves successful transaction execution "dingyongjun" 127.0.0.1:6379> get age "26"
② Abandon transaction
127.0.0.1:6379> multi #Open transaction OK 127.0.0.1:6379> set name dingyongjun #Add data QUEUED 127.0.0.1:6379> set age 26 #Add data QUEUED 127.0.0.1:6379> discard #Abandon transaction OK 127.0.0.1:6379> get name #Will not perform the add operation in the transaction (nil)
③ Compile time exceptions, code problems, or command problems, all commands will not be executed
127.0.0.1:6379> multi #Open transaction OK 127.0.0.1:6379> set name dingyongjun #Add data QUEUED 127.0.0.1:6379> set age 23 #Add data QUEUED 127.0.0.1:6379> getset name #Enter an incorrect command, and an error has been reported at this time, but this is still in the transaction queue (error) ERR wrong number of arguments for 'getset' command 127.0.0.1:6379> set high 173 #Add data QUEUED 127.0.0.1:6379> exec #Execute transactions, report errors, and all commands will not be executed (error) EXECABORT Transaction discarded because of previous errors. 127.0.0.1:6379> get name #The obtained data is empty, which proves that it has not been implemented (nil)
④ For runtime exceptions, except that syntax errors will not be executed and exceptions are thrown, other correct commands can be executed normally
127.0.0.1:6379> multi #Open transaction OK 127.0.0.1:6379> set name dingyongjun #Add string data QUEUED 127.0.0.1:6379> incr name #Self incrementing string data QUEUED 127.0.0.1:6379> set age 23 #Add data QUEUED 127.0.0.1:6379> get age #get data QUEUED 127.0.0.1:6379> exec #Execute transactions. Although an error is reported in the auto increment operation of string data, other commands can be executed normally 1) OK 2) (error) ERR value is not an integer or out of range 3) OK 4) "23" 127.0.0.1:6379> get age #Data acquisition succeeded "23"
⑤ Summary: it can be concluded from the above that Redis supports single command transactions, but transactions cannot guarantee atomicity!
2, How does Redis implement optimistic lock?
127.0.0.1:6379> set money 100 #Add money 100 OK 127.0.0.1:6379> set cost 0 #Add expense 0 OK 127.0.0.1:6379> watch money #Monitor money OK 127.0.0.1:6379> multi #Open transaction OK 127.0.0.1:6379> DECRBY money 30 #Money -30 QUEUED 127.0.0.1:6379> incrby cost 30 #Cost +30 QUEUED 127.0.0.1:6379> exec #Execute transaction, successful! Only when there is no change in the data can we succeed 1) (integer) 70 2) (integer) 30
② Multithreaded test watch
#Thread 1 127.0.0.1:6379> set money 100 #Add money 100 OK 127.0.0.1:6379> set cost 0 #Add expense 0 OK 127.0.0.1:6379> watch money #Turn on monitoring (Le Guan lock) OK 127.0.0.1:6379> multi #Open transaction OK 127.0.0.1:6379> DECRBY money 20 #Money -20 QUEUED 127.0.0.1:6379> INCRBY cost 20 #Cost +20 QUEUED #Don't execute it here. Execute thread 2 first to modify the monitored value 127.0.0.1:6379> exec #An error is reported during execution, because we have monitored the value of money. If the transaction wants to operate on this value #The monitor will judge whether this value is normal. If it changes, the transaction execution fails! (nil)
#Thread 2, this operation is executed before the transaction is executed 127.0.0.1:6379> INCRBY money 20 #Money +20 (integer) 120
③ Summary: the difference between optimistic lock and pessimistic lock.
Pessimistic lock: there will be problems at any time, so I have been monitoring. Before the current step is completed, no thread is allowed to execute, which is a waste of performance! Generally not used!
Optimistic lock: only when updating the data, judge whether someone has modified the monitored data during this period. If not, the transaction will be executed normally, otherwise the execution will fail!