CN112650776A - Redis-based distributed lock implementation method, storage device and server - Google Patents
Redis-based distributed lock implementation method, storage device and server Download PDFInfo
- Publication number
- CN112650776A CN112650776A CN202011209982.7A CN202011209982A CN112650776A CN 112650776 A CN112650776 A CN 112650776A CN 202011209982 A CN202011209982 A CN 202011209982A CN 112650776 A CN112650776 A CN 112650776A
- Authority
- CN
- China
- Prior art keywords
- lock
- redis
- time
- name
- bit
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 31
- 230000008569 process Effects 0.000 claims description 13
- 230000006870 function Effects 0.000 description 13
- 238000012545 processing Methods 0.000 description 7
- 230000006872 improvement Effects 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000005856 abnormality Effects 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000003780 insertion Methods 0.000 description 1
- 230000037431 insertion Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2455—Query execution
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/21—Design, administration or maintenance of databases
- G06F16/215—Improving data quality; Data cleansing, e.g. de-duplication, removing invalid entries or correcting typographical errors
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/22—Indexing; Data structures therefor; Storage structures
- G06F16/2228—Indexing structures
- G06F16/2255—Hash tables
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/248—Presentation of query results
Abstract
The invention provides a method for realizing a distributed lock based on Redis, which is characterized by comprising the following steps of: s1 sends out inquiry request to Redis server by using lock name code as inquiry condition, checks whether lock exists, if yes, then step S2 enters lock heartbeat check flow, if not, then step S3 prepares to write lock information into Reids database. S2 the lock requester checks if the lock is present, when it is detected that the lock is not present, go to step S1, try to lock the target again, when it is detected that the lock is present and the longest waiting time is exceeded, then feedback lock failure to the caller; s3 attempts to write the phase-related information to the Redis database. The invention has the advantages that the realized distributed lock does not depend on middleware excessively and has the rapid transplanting capability. The calling mode is simple, no complex configuration parameters exist, and the learning time can be reduced.
Description
Technical Field
The invention relates to the field of computers, in particular to a method for realizing a distributed lock based on Redis, a storage device and a server.
Background
Currently, enterprise-level systems are more and more complex in design, and more servers are involved, so that more and more subsystems are necessarily involved, and some common key data need to be operated (added, edited and deleted). Under the high concurrency of the system, when a plurality of demand parties need to operate the same data, if the key data are not locked, data inconsistency is easily caused, and the stability and the safety of the whole system are further damaged. In order to ensure the security and consistency of the data in the aforementioned operations, a lock tool is also generated, which is used to lock the data for exclusive operation before operating the data. The main implementation modes of the lock in the current software system are as follows: the lock is realized by a memory mode, the lock is realized by a relational database mode and the lock is realized by a middleware mode. Realizing the lock based on the memory mode means that: when the key data needs to be locked, a lock is directly opened in the memory, other requesters need to check whether the lock exists before operating the data, and if the lock exists, the other requesters wait for the release of the lock in a queue. Realizing the lock based on the relational database mode means that: the distributed lock is realized by using a relational database row lock connected with a distributed system, specifically, a distributed lock table is defined in the relational database, a corresponding lock record is inserted, the distributed system preempts the database row lock through a query statement with a lock before processing a task, a thread which is successfully preempted performs task processing, and a thread which is failed in lock preemption exits from the processing or waits for lock release. The realization of the lock based on the middleware mode is as follows: using a special distributed lock middleware, before key data needs to be requested, first requesting the middleware to lock the data to obtain operation authority, if the request is successful (meanwhile, the locking is successful), the data can be operated, otherwise, continuously and circularly waiting (such as a distributed coordination middleware zookeeper which is relatively named in the industry).
Disclosure of Invention
The technical problem to be solved by the invention is as follows:
1, the distributed lock is processed by adopting an internal memory or a database and other self-existing modes, the processing logic which is complex in configuration and needs a large amount of professionals to develop the lock exists, and if the bug or network fault occurs, the fault that the lock cannot be released according to normal logic all the time is easily caused. But this approach also falls off linearly in response time and processing efficiency as the amount of concurrency increases.
2, the lock is realized by adopting a middleware mode, and the problems of complex configuration, large requirement of professional personnel and high cost are also existed in the commercial use of the open source system. Due to the adoption of the independent middleware, the dependence of the system on the middleware is too high, the realization mode has no universality, the heterogeneous systems are difficult to transplant, and the like. As the amount of access increases, the expansion of middleware processing power is difficult, which is also a real problem.
The invention provides a method for realizing a distributed lock based on Redis, which comprises the following steps:
s1 sends out inquiry request to Redis server by using lock name code as inquiry condition, checks whether lock exists, if yes, then step S2 enters lock heartbeat check flow, if not, then step S3 prepares to write lock information into Reids database.
S2 checks whether the lock exists at regular time, when the lock does not exist, the step S1 is carried out, the target is tried to be locked again, when the lock exists and the longest waiting time is exceeded, the locking failure is fed back to the calling party;
s3 attempts to write the phase-related information to the Redis database.
Furthermore, the lock name code is constructed by adopting a lock name and automatic failure time;
the lock related information includes a lock name, a lock unique signature, and a lock automatic expiration time.
Further, each lock has its own unique signature;
if two lock objects with the same name are generated at the same time, when the calling party actively releases the lock, the system automatically identifies the correct lock through the unique signature of the lock, and ignores the wrong lock;
the unique signature generation rule comprises a machine room identifier + machine identifier + 13-bit time rubbing + 4-bit incremental sequence, and 23-bit string codes in total;
the machine room identification: 99 different machine rooms are supported through 2-bit strings, and the insufficient number of bits is occupied by 0;
the machine identification: using 4-bit strings, 9999 servers are supported by the same machine room, and the insufficient digits are occupied by 0;
the time is rubbing: adopting a code generator to reduce the difference value of the starting time by using the current time, and finally formatting into 13 bits, wherein the bit is occupied by 0 when the number of bits is insufficient;
the increment sequence is as follows: count in millisecond is adopted, 9999 count numbers are supported in the same machine and the same millisecond, and the insufficient digit is occupied by 0.
Further, the method also comprises the step of,
the system automatically releases the lock after the lock automatic expiration time has expired.
Further, the method also comprises the step of,
and automatically checking whether the lock name is consistent with the unique signature of the lock through a predefined LUA function, if so, releasing the current lock, and otherwise, returning error information.
Predefining an LUA function of Redis, and completing the processes of verifying the lock and deleting the lock in one request;
the predefined LUA function of Redis performs the logic of first checking if a lock name exists and then comparing if the unique identifier stored by the lock object is consistent with the unique identifier stored in the Redis database.
The present invention also provides a memory device having stored therein a plurality of instructions adapted to be loaded and executed by a processor to:
s1 sends out inquiry request to Redis server by using lock name code as inquiry condition, checks whether lock exists, if yes, then step S2 enters lock heartbeat check flow, if not, then step S3 prepares to write lock information into Reids database.
S2 checks whether the lock exists at regular time, when the lock does not exist, the step S1 is carried out, the target is tried to be locked again, when the lock exists and the longest waiting time is exceeded, the locking failure is fed back to the calling party;
s3 attempts to write the phase-related information to the Redis database.
Furthermore, the lock name code is constructed by adopting a lock name and automatic failure time;
the lock related information comprises a lock name, a unique lock signature and automatic lock failure time;
each lock has its own unique signature;
if two lock objects with the same name are generated at the same time, when the calling party actively releases the lock, the system automatically identifies the correct lock through the unique signature of the lock, and ignores the wrong lock;
the unique signature generation rule comprises a machine room identifier + machine identifier + 13-bit time rubbing + 4-bit incremental sequence, and 23-bit string codes in total;
the machine room identification: 99 different machine rooms are supported through 2-bit strings, and the insufficient number of bits is occupied by 0;
the machine identification: using 4-bit strings, 9999 servers are supported by the same machine room, and the insufficient digits are occupied by 0;
the time is rubbing: adopting a code generator to reduce the difference value of the starting time by using the current time, and finally formatting into 13 bits, wherein the bit is occupied by 0 when the number of bits is insufficient;
the increment sequence is as follows: counting within milliseconds is adopted, 9999 counting numbers are supported in the same machine and the same millisecond, and the insufficient digits are occupied by 0;
the method also comprises the step of carrying out the following steps,
the system automatically releases the lock after the lock automatic expiration time has expired.
And automatically checking whether the lock name is consistent with the unique signature of the lock through a predefined LUA function, if so, releasing the current lock, and otherwise, returning error information.
Predefining an LUA function of Redis, and completing the processes of verifying the lock and deleting the lock in one request;
the predefined LUA function of Redis performs the logic of first checking if a lock name exists and then comparing if the unique identifier stored by the lock object is consistent with the unique identifier stored in the Redis database.
The invention also provides a server comprising
A processor adapted to implement instructions; and
a storage device adapted to store a plurality of instructions, the instructions adapted to be loaded and executed by a processor to:
s1 sends out inquiry request to Redis server by using lock name code as inquiry condition, checks whether lock exists, if yes, then step S2 enters lock heartbeat check flow, if not, then step S3 prepares to write lock information into Reids database.
S2 checks whether the lock exists at regular time, when the lock does not exist, the step S1 is carried out, the target is tried to be locked again, when the lock exists and the longest waiting time is exceeded, the locking failure is fed back to the calling party;
s3 attempts to write the phase-related information to the Redis database.
Furthermore, the lock name code is constructed by adopting a lock name and automatic failure time;
the lock related information comprises a lock name, a unique lock signature and automatic lock failure time;
each lock has its own unique signature;
if two lock objects with the same name are generated at the same time, when the calling party actively releases the lock, the system automatically identifies the correct lock through the unique signature of the lock, and ignores the wrong lock;
the unique signature generation rule comprises a machine room identifier + machine identifier + 13-bit time rubbing + 4-bit incremental sequence, and 23-bit string codes in total;
the machine room identification: 99 different machine rooms are supported through 2-bit strings, and the insufficient number of bits is occupied by 0;
the machine identification: using 4-bit strings, 9999 servers are supported by the same machine room, and the insufficient digits are occupied by 0;
the time is rubbing: adopting a code generator to reduce the difference value of the starting time by using the current time, and finally formatting into 13 bits, wherein the bit is occupied by 0 when the number of bits is insufficient;
the increment sequence is as follows: counting within milliseconds is adopted, 9999 counting numbers are supported in the same machine and the same millisecond, and the insufficient digits are occupied by 0;
the method also comprises the step of carrying out the following steps,
the system automatically releases the lock after the lock automatic expiration time has expired.
And automatically checking whether the lock name is consistent with the unique signature of the lock through a predefined LUA function, if so, releasing the current lock, and otherwise, returning error information.
Predefining an LUA function of Redis, and completing the processes of verifying the lock and deleting the lock in one request;
the predefined LUA function of Redis performs the logic of first checking if a lock name exists and then comparing if the unique identifier stored by the lock object is consistent with the unique identifier stored in the Redis database.
The distributed lock implementation method has the advantages that the distributed lock implementation method is not excessively dependent on middleware and has a rapid transplanting capability. The calling mode is simple, no complex configuration parameters exist, and the learning time can be reduced. Through the NoSql database, the complex logic of the prior relational database is simplified, and the throughput capacity of the system can be improved almost without limit.
Drawings
FIG. 1 is a flow chart of the present invention.
Detailed Description
The invention is characterized in that a relationship type database or middleware which needs complex configuration and is not beneficial to expansion is replaced by a nosql database which is Redis to store and manage the locks. The lock calling process is packaged through the logic program, the learning process of a user is simplified, the user can perfectly solve the calling and releasing of the lock only by paying attention to few calling parameters, and the lock can be used without configuration and opening the box. Finally, the nosql database of Redis used in the invention is naturally generated for large concurrency, and can almost infinitely expand the processing capacity of the system, thereby perfectly solving all the problems encountered before improvement.
The distributed lock designed by the invention is realized by the following steps:
1. and constructing a lock object and coding the lock name according to the lock name and the automatic failure time.
2. And (3) locking a target process: and (4) sending a query request to a Redis server by taking the lock name code as a query condition, and checking whether the lock exists. If the target is locked, entering a lock heartbeat check flow; if not, then the lock information is ready to be written to the Reids database.
3. If the lock exists, the lock heartbeat checking process: checking whether the lock exists at regular time, switching to a target locking process when detecting that the lock does not exist, and trying to lock the target again; otherwise, when the longest waiting time is exceeded, the locking failure is fed back to the calling party.
4. If the lock does not exist, the Reids database insertion flow: attempts are made to write lock related information (including lock name, lock unique signature, and lock auto-expiration time) to the Redis database. The flow utilizes the Redis single-thread characteristic, and ensures that the lock which can be successfully written in is unique, thereby ensuring the uniqueness and the data consistency of system transactions.
5. Lock unique signature: each lock request has a unique signature, and the cross calling condition of the lock with the same name can not occur in a high concurrency state.
(unique signature shows that the lock unique signature generation rule comprises a machine room identifier (2-bit string) + a machine identifier (4-bit string) + 13-bit time twist + 4-bit incremental sequence, and a total of 23-bit string codes.
Machine room identification: through the 2-bit string, 99 different computer rooms are theoretically supported, and the insufficient number of bits is occupied by 0.
Machine identification: by using 4-bit strings, 9999 servers are theoretically supported by the same machine room, and the insufficient bits are occupied by 0.
Rubbing for time: the time rub here is not the time rub of the current time, but the code generator uses the current time to rub down the difference value of the starting time rub, and finally formats into 13 bits, and the bit number is not enough and occupies 0.
Increasing sequence: counting in millisecond, 9999 counting numbers are supported in the same machine and the same millisecond theoretically, and the insufficient digits are occupied by 0. )
6. The cross-call case of the lock with the same name is as follows: in the extreme special case of high concurrency, two lock objects with the same name are generated at the same time (they may be in different servers or even different computer rooms), but only one of the Redis-based locks is actually successfully saved, and when the caller actively releases the lock, the system can automatically identify the correct lock through the unique signature of the lock itself, and ignore the wrong lock.
7. Automatic lock failure time: even if network errors or any other abnormalities occur, the system can not release the lock in time, the system can also automatically release the lock after the automatic failure time of the lock expires (the time is set by a user when the lock is created through parameters), and therefore the safety of the system is guaranteed.
8. Once the lock is available to the calling party, the locked target data can be exclusively added, deleted and changed, and the lock can ensure the uniqueness of the operations within the validity period of the lock, so that the data inconsistency caused by high concurrency is avoided.
9. And (3) lock releasing flow: and after the data operation of the calling party is completed, calling the flow. The process automatically checks whether the lock name is consistent with the unique signature of the lock through a predefined LUA function, if so, the current lock is released, and otherwise, error information is returned.
10. Release lock LUA function: in order to reasonably utilize the single-thread characteristic of Redis, a group of LUA functions of Redis is predefined and used for completing the processes of verifying and deleting locks in one request, so that errors caused by high concurrency are avoided. LUA function execution logic: whether the lock name exists or not is checked, whether the unique identification code stored in the lock object is consistent with the unique identification code stored in the Redis database or not is compared, and the lock deleting operation is executed when the data are consistent.
The functional formula is as follows,
the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention, and various modifications and changes may be made by those skilled in the art. Any modification, equivalent replacement, or improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.
Claims (9)
1. A method for realizing a distributed lock based on Redis is characterized by comprising the following steps:
s1, using the lock name code as a query condition, sending a query request to a Redis server, checking whether a lock exists, if yes, turning to step S2 to enter a lock heartbeat check flow, and if not, turning to step S3 to prepare to write lock information into a Reids database;
s2 checks whether the lock exists at regular time, when the lock does not exist, the step S1 is carried out, the target is tried to be locked again, when the lock exists and the longest waiting time is exceeded, the locking failure is fed back to the calling party;
s3 attempts to write the phase-related information to the Redis database.
2. A Redis-based distributed lock implementation method according to claim 1,
the lock name code is constructed by adopting a lock name and automatic failure time;
the lock related information includes a lock name, a lock unique signature, and a lock automatic expiration time.
3. A Redis-based distributed lock implementation method according to claim 1,
each lock has its own unique signature;
if two lock objects with the same name are generated at the same time, when the calling party actively releases the lock, the system automatically identifies the correct lock through the unique signature of the lock, and ignores the wrong lock;
the unique signature generation rule comprises a machine room identifier + machine identifier + 13-bit time rubbing + 4-bit incremental sequence, and 23-bit string codes in total;
the machine room identification: 99 different machine rooms are supported through 2-bit strings, and the insufficient number of bits is occupied by 0;
the machine identification: using 4-bit strings, 9999 servers are supported by the same machine room, and the insufficient digits are occupied by 0;
the time is rubbing: adopting a code generator to reduce the difference value of the starting time by using the current time, and finally formatting into 13 bits, wherein the bit is occupied by 0 when the number of bits is insufficient;
the increment sequence is as follows: count in millisecond is adopted, 9999 count numbers are supported in the same machine and the same millisecond, and the insufficient digit is occupied by 0.
4. A method for implementing a Redis-based distributed lock according to claim 1, further comprising the step of,
the system automatically releases the lock after the lock automatic expiration time has expired.
5. A method for implementing a Redis-based distributed lock according to claim 1, further comprising the step of,
automatically checking whether the lock name is consistent with the unique signature of the lock through a predefined LUA function, if so, releasing the current lock, otherwise, returning error information;
predefining an LUA function of Redis, and completing the processes of verifying the lock and deleting the lock in one request;
the predefined LUA function of Redis performs the logic of first checking if a lock name exists and then comparing if the unique identifier stored by the lock object is consistent with the unique identifier stored in the Redis database.
6. A memory device having stored therein a plurality of instructions adapted to be loaded and executed by a processor to:
s1, using the lock name code as a query condition, sending a query request to a Redis server, checking whether a lock exists, if yes, turning to step S2 to enter a lock heartbeat check flow, and if not, turning to step S3 to prepare to write lock information into a Reids database;
s2 checks whether the lock exists at regular time, when the lock does not exist, the step S1 is carried out, the target is tried to be locked again, when the lock exists and the longest waiting time is exceeded, the locking failure is fed back to the calling party;
s3 attempts to write the phase-related information to the Redis database.
7. A storage device according to claim 6,
the lock name code is constructed by adopting a lock name and automatic failure time;
the lock related information comprises a lock name, a unique lock signature and automatic lock failure time;
each lock has its own unique signature;
if two lock objects with the same name are generated at the same time, when the calling party actively releases the lock, the system automatically identifies the correct lock through the unique signature of the lock, and ignores the wrong lock;
the unique signature generation rule comprises a machine room identifier + machine identifier + 13-bit time rubbing + 4-bit incremental sequence, and 23-bit string codes in total;
the machine room identification: 99 different machine rooms are supported through 2-bit strings, and the insufficient number of bits is occupied by 0;
the machine identification: using 4-bit strings, 9999 servers are supported by the same machine room, and the insufficient digits are occupied by 0;
the time is rubbing: adopting a code generator to reduce the difference value of the starting time by using the current time, and finally formatting into 13 bits, wherein the bit is occupied by 0 when the number of bits is insufficient;
the increment sequence is as follows: counting within milliseconds is adopted, 9999 counting numbers are supported in the same machine and the same millisecond, and the insufficient digits are occupied by 0;
the method also comprises the step of carrying out the following steps,
the system automatically releases the lock after the automatic failure time of the lock expires;
automatically checking whether the lock name is consistent with the unique signature of the lock through a predefined LUA function, if so, releasing the current lock, otherwise, returning error information;
predefining an LUA function of Redis, and completing the processes of verifying the lock and deleting the lock in one request;
the predefined LUA function of Redis performs the logic of first checking if a lock name exists and then comparing if the unique identifier stored by the lock object is consistent with the unique identifier stored in the Redis database.
8. A server, comprising
A processor adapted to implement instructions; and
a storage device adapted to store a plurality of instructions, the instructions adapted to be loaded and executed by a processor to:
s1, using the lock name code as a query condition, sending a query request to a Redis server, checking whether a lock exists, if yes, turning to step S2 to enter a lock heartbeat check flow, and if not, turning to step S3 to prepare to write lock information into a Reids database;
s2 checks whether the lock exists at regular time, when the lock does not exist, the step S1 is carried out, the target is tried to be locked again, when the lock exists and the longest waiting time is exceeded, the locking failure is fed back to the calling party;
s3 attempts to write the phase-related information to the Redis database.
9. The server according to claim 8,
the lock name code is constructed by adopting a lock name and automatic failure time;
the lock related information comprises a lock name, a unique lock signature and automatic lock failure time;
each lock has its own unique signature;
if two lock objects with the same name are generated at the same time, when the calling party actively releases the lock, the system automatically identifies the correct lock through the unique signature of the lock, and ignores the wrong lock;
the unique signature generation rule comprises a machine room identifier + machine identifier + 13-bit time rubbing + 4-bit incremental sequence, and 23-bit string codes in total;
the machine room identification: 99 different machine rooms are supported through 2-bit strings, and the insufficient number of bits is occupied by 0;
the machine identification: using 4-bit strings, 9999 servers are supported by the same machine room, and the insufficient digits are occupied by 0;
the time is rubbing: adopting a code generator to reduce the difference value of the starting time by using the current time, and finally formatting into 13 bits, wherein the bit is occupied by 0 when the number of bits is insufficient;
the increment sequence is as follows: counting within milliseconds is adopted, 9999 counting numbers are supported in the same machine and the same millisecond, and the insufficient digits are occupied by 0;
the method also comprises the step of carrying out the following steps,
the system automatically releases the lock after the automatic failure time of the lock expires;
automatically checking whether the lock name is consistent with the unique signature of the lock through a predefined LUA function, if so, releasing the current lock, otherwise, returning error information;
predefining an LUA function of Redis, and completing the processes of verifying the lock and deleting the lock in one request;
the predefined LUA function of Redis performs the logic of first checking if a lock name exists and then comparing if the unique identifier stored by the lock object is consistent with the unique identifier stored in the Redis database.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011209982.7A CN112650776A (en) | 2020-11-03 | 2020-11-03 | Redis-based distributed lock implementation method, storage device and server |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011209982.7A CN112650776A (en) | 2020-11-03 | 2020-11-03 | Redis-based distributed lock implementation method, storage device and server |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112650776A true CN112650776A (en) | 2021-04-13 |
Family
ID=75347146
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011209982.7A Pending CN112650776A (en) | 2020-11-03 | 2020-11-03 | Redis-based distributed lock implementation method, storage device and server |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112650776A (en) |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108874552A (en) * | 2018-06-28 | 2018-11-23 | 杭州云英网络科技有限公司 | Distributed lock executes method, apparatus and system, application server and storage medium |
| CN110750506A (en) * | 2019-09-17 | 2020-02-04 | 苏宁云计算有限公司 | Data object identification generation method and device, computer equipment and storage medium |
| CN111611247A (en) * | 2020-05-25 | 2020-09-01 | 山东健康医疗大数据有限公司 | ID generator and ID generating method for multi-domain computer room |
| CN111708793A (en) * | 2020-06-18 | 2020-09-25 | 辽宁振兴银行股份有限公司 | Distributed application lock implementation method and device |
-
2020
- 2020-11-03 CN CN202011209982.7A patent/CN112650776A/en active Pending
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108874552A (en) * | 2018-06-28 | 2018-11-23 | 杭州云英网络科技有限公司 | Distributed lock executes method, apparatus and system, application server and storage medium |
| CN110750506A (en) * | 2019-09-17 | 2020-02-04 | 苏宁云计算有限公司 | Data object identification generation method and device, computer equipment and storage medium |
| CN111611247A (en) * | 2020-05-25 | 2020-09-01 | 山东健康医疗大数据有限公司 | ID generator and ID generating method for multi-domain computer room |
| CN111708793A (en) * | 2020-06-18 | 2020-09-25 | 辽宁振兴银行股份有限公司 | Distributed application lock implementation method and device |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US5916307A (en) | Method and structure for balanced queue communication between nodes in a distributed computing application | |
| JP4993905B2 (en) | Server queuing system and method | |
| CN112463144B (en) | Distributed storage command line service method, system, terminal and storage medium | |
| US8484166B2 (en) | Oracle rewind: metadata-driven undo | |
| CN101615203B (en) | Concurrency control method and device | |
| CN110764942A (en) | Multi-type data checking method, device, computer system and readable storage medium | |
| CN104065636B (en) | Data processing method and system | |
| WO1999046674A1 (en) | Isolation levels and compensating transactions in an information system | |
| WO2005088473A1 (en) | Apparatus and method for data consistency validation | |
| US20030204804A1 (en) | Providing a chain of tokenized error and state information for a call stack | |
| CN101198937A (en) | Secure storage management system and method | |
| CN110222028B (en) | Data management method, device, equipment and storage medium | |
| CN112650776A (en) | Redis-based distributed lock implementation method, storage device and server | |
| CN111913804A (en) | Pre-visit report generation method and device, electronic equipment and storage medium | |
| CN110543465B (en) | Directory operation method and device, computer equipment and storage medium | |
| Membrey et al. | A disk based stream oriented approach for storing big data | |
| CN115934272A (en) | Online batch task processing method and device | |
| CN111078442A (en) | Fault-tolerant retry method and device and terminal | |
| CN113900840A (en) | Distributed transaction final consistency processing method and device | |
| CN114461409A (en) | Auxiliary analysis method, system and storage medium for abnormal blocking of mutual exclusion semaphore | |
| US8327378B1 (en) | Method for gracefully stopping a multi-threaded application | |
| CN111722946A (en) | Distributed transaction processing method and device, computer equipment and readable storage medium | |
| CN117076547B (en) | Data storage method based on virtual distributed server | |
| CN116720818B (en) | Warehouse processing method, device and computer equipment based on block chain | |
| CN113377467B (en) | Information decoupling method and device, server and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20210413 |
|
| RJ01 | Rejection of invention patent application after publication |