Implementation of distributed database lock
Based on implementation of distributed database lock
Above have been analyzed based on the basic principles of implementation of distributed database locks: Keep exclusivity through a unique index, insert a record time of locking, unlocking is to delete this record. Here we take a brief look at realized based on distributed lock the database.
Table Design
CREATE TABLE `distributed_lock` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`unique_mutex` varchar(255) NOT NULL COMMENT '业务防重id',
`holder_id` varchar(255) NOT NULL COMMENT '锁持有者id',
`create_time` datetime DEFAULT NULL ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`id`),
UNIQUE KEY `mutex_index` (`unique_mutex`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
id field is incremented id, unique_mutex database field is our heavy anti-id, which is locked object, which is unique. On this table we add a unique index to ensure unique_mutex uniqueness. holder_id competition on behalf of the lock holder id.
Lock
insert into distributed_lock(unique_mutex, holder_id) values ('unique_mutex', 'holder_id');
If the current sql executed successfully locked on behalf of success, if an exception is thrown unique index (DuplicatedKeyException) represents the lock fails, the current lock has been acquired other competitors.
Unlock
delete from methodLock where unique_mutex='unique_mutex' and holder_id='holder_id';
Unlock very simple, direct delete this record can be.
analysis
Whether reentrant : For the above scenario, the distributed lock we achieve is not reentrant, that is one and the same competitor, again locked after acquiring the lock before the lock is not released, they would lock fails, so is not reentrant. Non-reentrant solve the problem is very simple: to determine whether the record exists unique_mutex record when locked, if it exists and holder_id same as the current competitors and id, the lock is successful. This problem can be solved not reentrant.
Lock release timing : Imagine if a competitor acquires the lock when the process hung up, this time distributed_lock table this record will always exist, other competitors can not be locked. To solve this problem, before every lock we first determine whether the difference between the creation time record already exists and the current system time has exceeded timeout period, if you have more than you delete this record, and then insert a new record. Also in the unlock, must be to unlock the lock holder, other competitors can not unlock. This can be determined by holder_id field.
Database of a single point : a single database prone to single-point problem: If the database is hung up, lock our service hung up. For that matter, you can consider implementing high availability database program, such as the MySQL MHA high-availability solutions.
Based on an exclusive lock on the database
Distributed Lock can be achieved through an exclusive lock on the database. Based on the MySql InnoDB engine, the lock operation may be implemented using the following methods:
Increase for update after the query, the database will increase to a database table exclusive lock (here mention one more, InnoDB engine when locked, only be retrieved by the index of the time will use row-level locking in the inquiry process, otherwise use table-level locking. here we want to use row-level locking, it is necessary to add method_name index, it is worth noting that the index must be created as a unique index, otherwise there will not be accessed simultaneously between multiple overloaded methods problem. overloaded methods, then proposed to also add the parameter type.). When a record is added exclusive lock, other threads can no longer record on the line to increase exclusive lock.
We can think of to acquire an exclusive lock thread can get distributed lock, when the lock is acquired, can execute business logic method, after the execution of the method, then unlocked by the following methods:
To release the lock by Connection.commit () operation.
This method can effectively solve the problem can not release the lock and blocking locks mentioned above.
- Blocking locks? for update statement will return immediately after the successful execution, when executing a failure has been in a blocked state, until it succeeds.
- After locking down services, can not be released? This way, after the database service downtime will own the lock released.
But still can not solve a single point and direct database reentrant problem.
reference: