1. Redis implements distributed transaction locks
Why can distributed transactions be implemented with redis, because redis is a program executed by a single process and a single thread.
SETNX command (SET if Not eXists)
syntax:
SETNX key value
function:
if and only if the key does not exist, set the value of the key to value and return 1; if the given key already exists, SETNX does not do any action, and returns 0.
GETSET Command
Syntax:
GETSET key value
Function:
Set the value of the given key as value and return the old value of the key. When the key exists but is not a string type, an error is returned. When the key does not exist, returns nil.
GET Command
Syntax:
GET key
Function:
Returns the string value associated with the key, or returns the special value nil if the key does not exist.
DEL command
Syntax:
DEL key [KEY ...]
Function:
delete one or more given keys, the non-existing keys will be ignored.
Distributed transaction locks are implemented through these four commands of redis
server A, server B
Option One
Server A accesses a transaction
执行SETNX("KEY","A")
If successful, the lock will be obtained and the business method will be executed, otherwise, wait for retry.
After the business method is executed, execute DEL("KEY")
Is it really that simple to achieve?
Suppose that server A executes SETNX and goes down when executing the business. A deadlock occurred shortly after this time.
Optimization plan two
Server A gets the value via GET("KEY")
If it is NULL, execute SETNX("KEY",curr_time) to obtain the lock.
Otherwise, the judgment value + timeout time (you need to set the business processing timeout time) is less than the current time
If it is greater than it, go back to the first step (it is best to wait for a while), otherwise execute GETSET("KEY",curr_time) to obtain the lock.
carry out business
Finished executing DEL("A")
Solve the down machine problem, if the down machine times out, it will automatically force the lock.
The new problem, if server A gets the lock through GET, and B also gets it at this time. Both A and B are judged to pass, and the lock is obtained at the same time when GETSET is executed.
Optimization plan three
When executing GETSET, the obtained value is compared with the value of the last GET to see if it is consistent. If it is consistent, the lock will be obtained and the execution will continue. Otherwise go back to the first step.
This solves the problem of acquiring locks at the same time.
There is a new problem. Suppose that the server A times out when executing the business, but it does not actually time out. At this time, server B forcibly obtains the lock, server A can still perform business, and B comes in again. Problems will arise. This is unavoidable and requires the operation and maintenance personnel to reasonably configure the timeout period. If the configuration is too large, the server freezes and a large number of queues are blocked. If the configuration is too small, it will cause transaction problems and dirty data. The waiting time should also be reasonably configured, as well as the number of waiting times, etc.