A high-concurrency transaction locking method and system combining optimistic lock and pessimistic lock

Abstract

The present invention relates to a high-concurrency transaction locking method and system combining optimistic locks and pessimistic locks, including establishing a distributed pessimistic lock configuration file and judging the enabling status of the distributed pessimistic lock according to the configuration file, adding a distributed pessimistic lock to the transaction request in a timely manner according to the check status, adding an additional distributed pessimistic lock on the basis of the database optimistic lock, and dynamically adjusting the locking time, performing logical control of the pessimistic lock before the business logic access, avoiding waste of resources, reducing the pressure on components, achieving better performance and smaller non-functional system consumption; through the combination of optimistic locks and pessimistic locks, the advantages of both are fully utilized, and the defects of both are avoided, improving the stability and availability of the system while ensuring data consistency.

Description

Technical Field

[0001] The present invention relates to the technical field of distributed data processing and automatic programming, and in particular, to a high-concurrency transaction locking method and system combining an optimistic lock and a pessimistic lock. Background Art

[0002] In recent years, various promotional festivals such as Double Eleven have led to a sharp increase in transaction volumes such as consumption repayment. There is a problem of high concurrency in the transaction volumes of the same customer at the same moment. In order to process high-concurrency transactions, most B2C systems adopt a distributed system to relieve the processing pressure of machines. At the database operation level, database sharding and table partitioning are often used. Different data are routed and distinguished according to different partition keys (shardingkeys) and hashing algorithms, and different data are respectively mapped to different databases and different database tables, thus solving the problem that the pressure on a single database caused by overly concentrated data is too great. In addition, due to the limited processing speed of the database, if the concurrency of the same record is too large, it may lead to dirty data problems. Therefore, optimistic locks of the database are usually used to prevent dirty data problems. However, this will also introduce new problems. When the concurrency of consumption transactions is extremely large, the transaction success rate (the number of successful transactions divided by the total number of transactions within a time period) will decrease, that is, the transaction availability of the system will decrease, and there is no waiting mechanism to allow the customer's request to be processed again when the system is idle, but directly report an error, thus often reducing the customer experience.

[0003] A pessimistic lock refers to a lock with strong exclusivity and exclusiveness, which holds a conservative attitude towards the modification of data by the outside world, causing the data to remain locked during the processing until the data modification is completed and the lock is released. An optimistic lock, in contrast to a pessimistic lock, adopts a more optimistic and relaxed locking mechanism. It only verifies and judges the data when the transaction modifies the data, and does not continuously lock the data and resources. Currently, when dealing with high-concurrency maintenance transactions, using an optimistic lock at the database operation level is one of the common ways to control and maintain transaction consistency. This method uses the updated version number for comparison. Currently, most of the service frameworks or other technical frameworks used, when dealing with maintenance transactions, in order to ensure the consistency of maintenance operations, usually use aspect-oriented programming technology to uniformly process certain methods with specific names as a transaction. When processing a request record A maintained by a customer, the version number of this record will be incremented by one, and the system has not submitted the task. At this time, another maintenance request may also maintain record A. The version number control method, before maintenance, will verify whether the version number to be maintained is the same as the version number already existing in the database. If they are the same, maintenance is allowed; otherwise, an exception will be thrown. In this way, the problem of dirty data submitted to the database under high concurrency is controlled. In addition, for high-concurrency systems of a single system, there is also a way to use multi-threading for locking. For example, common multi-threading methods such as synchronized locks, semaphores, variables in special domains, and blocking queues are used to lock concurrent signals. This can also solve the problem of high concurrency in a single system.

[0004] In addition, in other companies or the industry, when dealing with high concurrency, other pessimistic lock solutions are also adopted. For example, a semaphore is set at the database operation level for locking, but this locking method increases the number of read and write operations on the database; there are also distributed locks through other open-source frameworks such as zookeeper or redission. These methods often rely too much on the framework and are not flexible enough. Other pessimistic lock solutions in the industry, such as for high-concurrency systems of a single system, using multi-threading tools for locking has certain limitations, that is, it is only convenient for a single system, but this method cannot be used for distributed systems.

[0005] Another solution is to adopt a transaction failure retry mechanism. In the processing logic after the database transaction has been rolled back and the transaction returns, add a judgment on the returned exception and try to re-execute all the processing logic of the transaction. The advantage is that there is no need to introduce a third-party middleware, and the processing efficiency of most transactions will not be affected. The disadvantage is that the overall transaction processing process becomes complex and the transaction chain becomes longer. When the transaction concurrency increases, it is easy to cause excessive waste of system resources.

[0006] If database-level locking is adopted, for some specific application scenarios, such as financial transactions, since other components or third parties need to be called, the business logic has often been entered and various verification and remote processing operations have been performed. Therefore, if pessimistic locking control is carried out at the database level, it will cause a large amount of pressure on the databases of its own components and the other party's component system, and even the database will crash when the conflict volume is too large. So this method is not a very good way. For other pessimistic locking solutions, such as other open-source frameworks like zookeeper and reddision, due to the inability to adjust parameters well and the lack of dynamic flexibility, they cannot adapt to the verification processing of high-concurrency transactions. Summary of the Invention

[0007] To solve the deficiencies of the prior art, the present invention proposes a high-concurrency transaction locking method and system combining optimistic locking and pessimistic locking. Based on the database optimistic locking, an additional distributed pessimistic locking is added, and the locking time is dynamically adjusted. The logical control of the pessimistic locking is carried out before the business logic access, avoiding waste of resources, reducing the pressure on components, achieving better performance and smaller non-functional system consumption; through the combination of optimistic locking and pessimistic locking, the advantages of both are fully utilized, and the defects of both are avoided, improving the stability and availability of the system while ensuring data consistency.

[0008] To achieve the above objectives, the technical solutions adopted by the present invention include:

[0009] A high-concurrency transaction locking method combining optimistic locking and pessimistic locking, characterized by including:

[0010] S1. Establish a distributed pessimistic locking configuration file, where the distributed pessimistic locking configuration file includes at least a distributed pessimistic locking total switch and distributed pessimistic locking flag bits corresponding to each transaction code;

[0011] S2. Obtain a transaction request, where the transaction request includes at least the transaction code and customer number corresponding to the transaction;

[0012] S3. Check the status of the current distributed pessimistic locking total switch; when the status of the distributed pessimistic locking total switch is off, no distributed pessimistic locking is added to the transaction request, and the transaction request is marked as pending;

[0013] S4. When the status of the distributed pessimistic locking total switch is on, continue to check the status of the distributed pessimistic locking flag bit corresponding to the transaction code of the transaction request; when the status of the distributed pessimistic locking flag bit is not enabled, no distributed pessimistic locking is added to the transaction request, and the transaction request is marked as pending;

[0014] S5. When the status of the distributed pessimistic lock flag is enabled, continue to perform flow control judgment on the current distributed cache. When it is determined that the distributed cache has a fault, do not add a distributed pessimistic lock to the transaction request and mark the transaction request as pending processing;

[0015] S6. When it is determined that the distributed cache has no fault, perform the operation of adding a distributed pessimistic lock to the transaction request;

[0016] S7. Check whether the distributed pessimistic lock is added successfully; when the distributed pessimistic lock is added successfully, mark the transaction request as locked; when the distributed pessimistic lock is not added successfully, mark the transaction request as pending processing;

[0017] S8. The marked transaction request continues to perform the transaction business processing logic; when the transaction request is marked as locked, perform the pessimistic lock processing logic on the transaction request; when the transaction request is marked as pending processing, add an optimistic lock to the transaction request and perform the optimistic lock processing logic.

[0018] Further, the method further includes:

[0019] S9. When the processing of the transaction request marked as locked is completed and feedback is received, perform the unlocking operation on the distributed pessimistic lock added to the transaction request.

[0020] Further, the performing flow control judgment on the current distributed cache includes:

[0021] Verify whether the number of consecutive failed accesses to the distributed cache exceeds a preset threshold. When the number of consecutive failed accesses to the distributed cache exceeds the preset threshold, it is determined that the distributed cache has a fault.

[0022] Further, step S6 further includes:

[0023] When it is determined that the distributed cache has a fault, randomly select a transaction request as a probe request and perform the operation of adding a distributed pessimistic lock to the probe request;

[0024] When the distributed pessimistic lock for the probe request is added successfully, clear the number of consecutive failed accesses to the distributed cache.

[0025] Further, the performing the operation of adding a distributed pessimistic lock to the transaction request includes:

[0026] Obtain the customer number corresponding to the transaction request, call the put method of the distributed cache to add a distributed pessimistic lock to the customer number corresponding to the transaction request, and set the survival time of the distributed pessimistic lock.

[0027] Further, the checking whether the distributed pessimistic lock is added successfully includes:

[0028] Verify whether the put method of the distributed cache is successfully called. When the call is successful, the distributed pessimistic lock is successfully added; otherwise, the addition is unsuccessful.

[0029] Further, step S7 further includes:

[0030] When the distributed pessimistic lock is not successfully added, re-execute the operation of adding the distributed pessimistic lock to the transaction request according to the preset waiting interval and the maximum number of retries;

[0031] When the distributed pessimistic lock is successfully added within the maximum number of retries, mark the transaction request as locked; when the distributed pessimistic lock is still not successfully added after exceeding the maximum number of retries, mark the transaction request as pending.

[0032] The present invention also relates to a high-concurrency transaction locking system combining an optimistic lock and a pessimistic lock, which is characterized by including:

[0033] A configuration file management module for establishing a distributed pessimistic lock configuration file;

[0034] A distributed pessimistic lock status control module for checking the status of the total switch of the current distributed pessimistic lock and the status of the distributed pessimistic lock flag bit corresponding to the transaction code of the transaction request;

[0035] A distributed cache verification module for performing flow control judgment on the current distributed cache;

[0036] A distributed pessimistic lock addition module for performing the operation of adding a distributed pessimistic lock to the transaction request and checking whether the distributed pessimistic lock is successfully added.

[0037] The present invention also relates to a computer-readable storage medium, which is characterized in that a computer program is stored on the storage medium, and when the computer program is executed by a processor, the above method is implemented.

[0038] The present invention also relates to an electronic device, which is characterized by including a processor and a memory;

[0039] The memory is used for storing the distributed pessimistic lock configuration file and the transaction request;

[0040] The processor is used for executing the above method by calling the distributed pessimistic lock configuration file and the transaction request.

[0041] The beneficial effects of the present invention are:

[0042] The high-concurrency transaction locking method and system using the combination of optimistic lock and pessimistic lock of the present invention, based on the database optimistic lock, performs various validations through a configuration file, adds an additional distributed pessimistic lock, and dynamically adjusts the locking time. The logical control of the pessimistic lock is carried out before the business logic access, avoiding resource waste and reducing the pressure on components. It can achieve better performance and less non-functional system consumption; through the combination of the optimistic lock and the pessimistic lock, the advantages of both are fully utilized, and the defects of both are avoided, improving the stability and availability of the system while ensuring data consistency. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] Figure 1 FIG. is a schematic flowchart of the high-concurrency transaction locking method using the combination of optimistic lock and pessimistic lock of the present invention.

[0044] Figure 2 FIG. is a schematic structural diagram of the high-concurrency transaction locking system using the combination of optimistic lock and pessimistic lock of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0045] In order to understand the content of the present invention more clearly, it will be described in detail in combination with the drawings and embodiments.

[0046] For the database part, the technical solution of the present invention uses the optimistic lock method to lock the records of the same partition key shardingkey. Since the processing speed of the database is relatively slow, when the system is in a concurrent situation, it is very likely that two modification requests will reach the database at the same time. At this time, we need to update or modify the records for the two modification requests in turn. Therefore, a version number can be designed for the database records, and the value of the version number will be incremented by one each time this record is modified. Each time a modification or update request is submitted, the version number should be verified. If the version number is not the largest (latest) in the database, it means that the data updated by this update request is not the latest data in the database, and this request will be rejected; if it is verified that the version number at this time is the largest (latest) in the database, it means that the update request updates the latest data in the database, and the update is successful. Through the optimistic lock of the database, the system can control the dirty data problem generated during concurrency, thus solving the data inconsistency at the database layer. However, only through the optimistic lock at the database layer, in scenarios with a large concurrency, the failure rate of the system will be relatively high, because the optimistic lock will reject the submission requests of records that are not the latest according to the version number. Although the consistency of the submitted data is guaranteed, the user experience is not very good.

[0047] Based on the database optimistic lock, the present invention further adds a distributed pessimistic lock and dynamically adjusts the locking time. For the transaction service application system, a processing chain for pre-processing can be preferably designed, and the processing logic before the business logic can be dynamically configured through a configuration file. For example, the processing chain can be designed as an object of a Java class, a transaction processing chain can be added to the processing stack file, and the distributed pessimistic lock control processing stack corresponding to the transaction can be configured in the processing stack. After a transaction request arrives at the application system, a distributed pessimistic lock is obtained through the pre-processing logic of the transaction, and the pessimistic lock processing logic is executed. The pessimistic lock is in the pre-processing chain before the authorization business logic processing. After successfully obtaining the pessimistic lock, subsequent processing is carried out; if the pessimistic lock is not obtained, or the waiting time or the number of retries is exceeded, subsequent processing can still be carried out without using the pessimistic lock.

[0048] Specifically, the first aspect of the present invention relates to a high-concurrency transaction locking method combining an optimistic lock and a pessimistic lock with a step flow as Figure 1 shown, including:

[0049] S1. Establish a distributed pessimistic lock configuration file, where the distributed pessimistic lock configuration file at least includes a distributed pessimistic lock total switch and distributed pessimistic lock flag bits corresponding to each transaction code. According to the distributed pessimistic lock total switch and the distributed pessimistic lock flag bits of the transaction code in the configuration file, it is determined whether to execute the distributed pessimistic lock locking processing logic. Only when the total switch is turned on and the flag bit is enabled will the pessimistic lock locking processing logic be executed, and the configuration parameters can take effect dynamically. A typical configuration file and parameters can include:

[0050] Related attribute parameters based on the redis distributed lock

[0051] Named envvariables.properties

[0052] # Maximum waiting time for pessimistic lock:

[0053] pessimisticLockMaxWaitSecond = 1000

[0054] # Maximum timeout time for pessimistic lock:

[0055] pessimisticLockMaxExpireSecond = 3000

[0056] # Distributed pessimistic lock total switch:

[0057] pessimisticLockSwitch = False

[0058] # Distributed pessimistic lock flag bit:

[0059] pessimisticLockOdaSwitch = True

[0060] # Redis Master name:

[0061] redisMasterName = mymaster

[0062] # Maximum number of consecutive pessimistic lock exceptions:

[0063] pessimisticLockMaxContinueFailNum = 10

[0064] # Maximum number of attempts to acquire pessimistic lock:

[0065] pessimisticLockMaxAttemptNum = 20

[0066] # Pessimistic lock control transaction code list ---- Switch settings for transactions that require lock control:

[0067] pessimisticLockService.A02XXXXX = True

[0068] pessimisticLockService.A02XXXXX = True

[0069] pessimisticLockService.XXXXX = True

[0070] Redis configuration for AP deployment cluster machines:

[0071] Named redis.properties:

[0072] by18cisauap1001.srvInfoList = ${redis.ip}

[0073] by18cisauap1002.srvInfoList = ${redis.ip}

[0074] …

[0075] S2. Obtain a transaction request, where the transaction request includes at least the transaction code and customer number corresponding to the transaction.

[0076] S3. Check the status of the current distributed pessimistic lock master switch; when the status of the distributed pessimistic lock master switch is off, do not add a distributed pessimistic lock to the transaction request and mark the transaction request as pending. Among them, the transaction request marked as pending is the request for which the distributed pessimistic lock addition logic is not executed, but the optimistic lock business processing logic can still be normally executed.

[0077] S4. When the status of the distributed pessimistic lock master switch is on, continue to check the status of the distributed pessimistic lock flag bit of the transaction code corresponding to the transaction request; when the status of the distributed pessimistic lock flag bit is not enabled, do not add a distributed pessimistic lock to the transaction request and mark the transaction request as pending.

[0078] S5. When the status of the distributed pessimistic lock flag bit is enabled, continue to perform flow control judgment on the current distributed cache, including verifying whether the number of consecutive access failures to the distributed cache exceeds a preset threshold. When the number of consecutive access failures to the distributed cache exceeds the preset threshold, it is determined that there is a fault in the distributed cache, do not add a distributed pessimistic lock to the transaction request, and mark the transaction request as pending. If a fault occurs in the distributed cache, dynamic isolation and recovery of access to the distributed cache can be achieved through dynamic flow control to prevent the overall transaction processing time from becoming longer due to the fault of the distributed cache. The above-mentioned distributed cache preferably uses redis connection access. When a fault occurs in the redis connection access and a large number of access failure exceptions occur in the distributed cache, it is necessary to turn on the flow control switch, dynamically isolate the distributed lock locking and unlocking mechanism, remove the corresponding distributed cache access logic, and directly execute the transaction processing logic to prevent phenomena such as the transaction server malfunctioning, the spread of faults, and the overall transaction response time becoming longer due to the fault of the distributed cache.

[0079] S6. When it is determined that there is no fault in the distributed cache, perform the operation of adding a distributed pessimistic lock to the transaction request, including obtaining the customer number corresponding to the transaction request, calling the put method of the distributed cache to add a distributed pessimistic lock to the customer number corresponding to the transaction request, and setting the survival time of the distributed pessimistic lock; when it is determined that there is a fault in the distributed cache, select any transaction request as a probe request and perform the operation of adding a distributed pessimistic lock to the probe request; when the addition of the distributed pessimistic lock to the probe request is successful, clear the number of consecutive failed accesses to the distributed cache. A continuous failure strategy can be adopted to dynamically isolate the distributed cache. For example, if the number of consecutive failed accesses to the distributed cache exceeds 20, isolate the next 2000 requests for accessing the distributed cache. After 2000 requests, try to use the distributed cache to add a lock again; or other strategies can be adopted, such as if the number of exceptions when attempting to obtain the distributed lock exceeds 10 times, then perform a circuit breaker operation, that is, subsequent transaction requests will no longer attempt to obtain the distributed pessimistic lock, but a probe transaction will be selected to attempt to add a pessimistic lock to check and confirm whether the distributed cache has returned to normal. The distributed cache can ensure that for the requests to add a pessimistic lock for the same customer, only one thread can operate successfully.

[0080] S7. Check whether the addition of the distributed pessimistic lock is successful, especially verify whether the put method of the distributed cache is called successfully; when the addition of the distributed pessimistic lock is successful, mark the transaction request as locked. For the transaction request with successful locking, the transaction request can be marked as locked by setting a locking success flag in the internal data exchange area, and update the corresponding monitoring data, and execute the processing logic of the transaction; when the addition of the distributed pessimistic lock is not successful, re-execute the operation of adding a distributed pessimistic lock to the transaction request according to the preset waiting interval and the maximum number of retries; when the distributed pessimistic lock is successfully added within the maximum number of retries, mark the transaction request as locked; when the addition of the distributed pessimistic lock is still not successful after exceeding the maximum number of retries, mark the transaction request as pending. If the locking fails, it is preferably determined whether there is a corresponding exception thrown for accessing the distributed cache. If an exception is thrown, perform exception capture, update the monitoring data, and then execute the subsequent transaction processing logic. Preferably, the preset waiting interval (the time for the thread to wait) can be set to be unequal. For example, wait for 200 ms for the first time, 150 ms for the second time, and 100 ms for the third time, which can reduce the probability of the occurrence of the phenomenon that the waiting thread is "starved to death". During the process of accessing the distributed cache, perform timeout control such as corresponding connection timeout and read timeout control, and do a good job in the routing of multiple distributed cache clusters.

[0081] S8. The marked transaction request continues with the transaction business processing logic; when the transaction request is marked as locked, the pessimistic lock processing logic is executed on the transaction request; when the transaction request is marked as pending, an optimistic lock is added to the transaction request, and the optimistic lock processing logic is executed.

[0082] S9. When the processing of the transaction request marked as locked is completed and feedback is received, the distributed pessimistic lock added to the transaction request is unlocked. The unlocking process of the distributed pessimistic lock after the transaction is a conventional technical means. If the transaction request is locked during the pre-transaction processing, regardless of whether the transaction is successful or failed, the corresponding unlocking operation needs to be performed, that is, the cached data of the corresponding customer number is deleted.

[0083] The server of the distributed cache preferably adopts the master-slave mode, with one master server and n slave servers. The master server is responsible for receiving the corresponding read and write requests. When the master server fails, one of the slave servers takes over the work of the master and receives the corresponding read and write requests.

[0084] The access control classes for different languages to redis are not the same, and the technical solution of the present invention does not make specific restrictions. However, it is preferable to encapsulate the connection object and data collection object of redis to implement an interface or class of RedisAccessor, providing the following features: 1) Provide a method putIfNotExist(key, value) for accessing redis, the purpose of which is to insert the key-value pair into redis. If the specified key already exists, no operation is performed and 0 is returned; otherwise, the specified key is inserted into redis and 1 is returned; 2) Provide methods such as replace to update the key-value into redis; 3) Provide a remove_data method to delete the key-value from redis, returning 1 if the deletion is successful and 0 if the deletion fails or an exception occurs.

[0085] The present invention realizes the effect of dynamically attempting to obtain for the addition of the distributed pessimistic lock, and the following steps can be specifically executed:

[0086] 1. Insert the key-value pair through the method putIfNotExist(key, value), and attempt to obtain the pessimistic lock. If the acquisition is successful, set the pessimistic lock acquisition flag bit in the swap area;

[0087] 2. In the case of failed acquisition, calculate the system time and calculate the reference time for each attempt to obtain the pessimistic lock. Here, the method and standard for calculating the reference time vary from person to person. Generally, the sleep time becomes shorter each time, and the thread is made to sleep for the calculated reference time;

[0088] 3. Calculate the number of attempts to obtain the pessimistic lock and the total waiting time. If the number of lock acquisition attempts exceeds the preset maximum number, or the total waiting time exceeds the preset waiting time, then break out of the loop. If the lock is successfully acquired during the loop, then continue to execute the success logic.

[0089] For transaction requests with the same customer number, they often have the same key value. In such concurrent transaction threads, the queue queuing mode is not adopted to obtain the distributed pessimistic lock in turn according to the first-come, first-served principle. For the lock acquisition requests of new and old transaction requests at the same time point, the probability of obtaining the distributed lock is the same. If the concurrency of transaction requests for the same customer is very high, some threads will have the "starvation" phenomenon, that is, the time to obtain the lock will become longer. If a queuing mechanism is introduced to obtain the distributed lock in turn, the queue cache data structure of the distributed cache can be used to implement it, but the technical complexity and the dependence on the distributed cache will be higher. According to the existing usage data, the concurrency of transaction requests for the same customer is not so high that it cannot be tolerated, and it is not entirely necessary to introduce a queuing mechanism.

[0090] Adopt the multi-cluster multi-active mode of the distributed cache to improve the overall high availability of the distributed pessimistic lock and ensure the processing efficiency. Assume that there are two sets of distributed cache clusters providing services externally at the same time. Based on the basket number corresponding to the transaction request customer number, the customer numbers can be evenly distributed in the two clusters. The first cluster stores the list of customer numbers where the basket number corresponding to the customer number % 2 = 0, and the second cluster stores the list of customer numbers where the basket number corresponding to the customer number % 2 = 1. When the distributed lock accesses the distributed cache, it accesses the corresponding distributed cache cluster according to the data distribution rule.

[0091] When one of the distributed cache clusters fails, manual intervention or event notification mode can be adopted to transfer all access requests to the other cluster. During the migration of the distributed cache cluster, since the data stored in the cache are all temporary data, there is no need to perform data migration work.

[0092] Another aspect of the present invention also relates to a high-concurrency transaction locking system combining an optimistic lock and a pessimistic lock, the structure of which is as Figure 2 shown, including:

[0093] A configuration file management module, used to establish a distributed pessimistic lock configuration file;

[0094] A distributed pessimistic lock status control module, used to check the overall switch status of the current distributed pessimistic lock and the status of the distributed pessimistic lock flag bit corresponding to the transaction code of the transaction request;

[0095] A distributed cache verification module, used to perform flow control judgment on the current distributed cache;

[0096] A distributed pessimistic lock addition module is used to perform the operation of adding a distributed pessimistic lock to a transaction request and check whether the distributed pessimistic lock is successfully added.

[0097] By using this system, the above-mentioned arithmetic processing method can be executed and the corresponding technical effects can be achieved.

[0098] An embodiment of the present invention also provides a computer-readable storage medium capable of implementing all steps in the method in the above embodiment. A computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, all steps of the method in the above embodiment are implemented.

[0099] An embodiment of the present invention also provides an electronic device for executing the above method. As an implementation device of the method, the electronic device at least includes a processor and a memory. In particular, data and related computer programs required for executing the method are stored on the memory, such as a distributed pessimistic lock configuration file and a transaction request, etc. All steps of the method are implemented by the processor calling the data and programs in the memory, and the corresponding technical effects are obtained.

[0100] Preferably, the electronic device may include a bus architecture. The bus may include any number of interconnected buses and bridges, and the bus links various circuits including one or more processors and memories together. The bus may also link various other circuits such as peripheral devices, voltage regulators, and power management circuits, etc., which are well known in the art, so they will not be further described herein. The bus interface provides an interface between the bus and the receiver and the transmitter. The receiver and the transmitter may be the same element, that is, a transceiver, which provides a unit for communicating with various other systems on the transmission medium. The processor is responsible for managing the bus and general processing, and the memory may be used to store data used by the processor when executing operations.

[0101] Additionally, the electronic device may further include components such as a communication module, an input unit, an audio processor, a display, a power supply, etc. The processor (or controller, operation control) employed therein may include a microprocessor or other processor devices and / or logic devices, which receive inputs and control the operations of the various components of the electronic device; the memory may be one or more of a buffer, a flash memory, a hard drive, a removable medium, a volatile memory, a non-volatile memory, or other suitable devices, capable of storing the above-mentioned relevant data information, and may also store programs for executing relevant information, and the processor may execute the programs stored in the memory to achieve information storage or processing, etc.; the input unit is used to provide inputs to the processor, for example, it may be a key or a touch input device; the power supply is used to supply power to the electronic device; the display is used to display display objects such as images and texts, for example, it may be an LCD display. The communication module is a transmitter / receiver that transmits and receives signals via an antenna. The communication module (transmitter / receiver) is coupled to the processor to provide input signals and receive output signals, which may be the same as in the case of a conventional mobile communication terminal. Based on different communication technologies, multiple communication modules may be provided in the same electronic device, such as a cellular network module, a Bluetooth module, and / or a wireless local area network module, etc. The communication module (transmitter / receiver) is also coupled to the speaker and the microphone via the audio processor to provide audio output via the speaker and receive audio input from the microphone, thereby implementing normal telecommunication functions. The audio processor may include any suitable buffer, decoder, amplifier, etc. Additionally, the audio processor is also coupled to the central processor, so that recording can be performed on the device through the microphone, and the sound stored on the device can be played through the speaker.

[0102] Those skilled in the art should understand that the embodiments of the present invention may be provided as a method, a system, or a computer program product. Therefore, the present invention may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk memory, CD-ROM, optical memory, etc.) containing computer-usable program code.

[0103] The present invention is described with reference to the flowcharts and / or block diagrams of methods, apparatuses (systems), and computer program products according to embodiments of the present invention. It should be understood that each flow and / or block in the flowchart and / or block diagram, and the combination of flows and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, such that the instructions executed by the processor of the computer or other programmable data processing device generate a system for implementing the functions specified in one or more flows Figure 1 one or more flows and / or blocks Figure 1 or one or more blocks.

[0104] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, such that the instructions stored in the computer-readable memory generate a manufactured article including an instruction system that implements the functions specified in one or more flows Figure 1 one or more flows and / or blocks Figure 1 or one or more blocks.

[0105] These computer program instructions can also be loaded onto a computer or other programmable data processing device, such that a series of operational steps are executed on the computer or other programmable device to generate a computer-implemented process, so that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more flows Figure 1 one or more flows and / or blocks Figure 1 or one or more blocks. Although the preferred embodiments of the present invention have been described, those skilled in the art can make additional changes and modifications to these embodiments once they learn the basic creative concepts. Therefore, the appended claims are intended to be construed as including the preferred embodiments and all changes and modifications falling within the scope of the present invention.

[0106] The above are only the preferred specific embodiments of the present invention, but the protection scope of the present invention is not limited thereto. Any changes or substitutions that can be easily thought of by those skilled in the art within the technical scope disclosed by the present invention should be covered by the protection scope of the present invention. Therefore, the protection scope of the present invention should be subject to the protection scope of the claims.

Claims

1. A high-concurrency transaction locking method combining optimistic lock and pessimistic lock, characterized in that, it includes: S1. Establish a distributed pessimistic lock configuration file, which at least includes a distributed pessimistic lock total switch and distributed pessimistic lock flag bits corresponding to each transaction code; S2. Obtain a transaction request, which at least includes the transaction code and customer number corresponding to the transaction; S3. Check the status of the current distributed pessimistic lock total switch; when the status of the distributed pessimistic lock total switch is off, do not add a distributed pessimistic lock to the transaction request, and mark the transaction request as pending; S4. When the status of the distributed pessimistic lock total switch is on, continue to check the status of the distributed pessimistic lock flag bit corresponding to the transaction code of the transaction request; when the status of the distributed pessimistic lock flag bit is not enabled, do not add a distributed pessimistic lock to the transaction request, and mark the transaction request as pending; S5. When the status of the distributed pessimistic lock flag bit is enabled, continue to perform flow control judgment on the current distributed cache. When it is judged that the distributed cache has a fault, do not add a distributed pessimistic lock to the transaction request, and mark the transaction request as pending; S6. When it is judged that the distributed cache has no fault, perform the operation of adding a distributed pessimistic lock to the transaction request; S7. Check whether the distributed pessimistic lock is added successfully; when the distributed pessimistic lock is added successfully, mark the transaction request as locked; when the distributed pessimistic lock is not added successfully, mark the transaction request as pending; S8. The marked transaction request continues to perform the transaction service processing logic; when the transaction request is marked as locked, perform the pessimistic lock processing logic on the transaction request; when the transaction request is marked as pending, add an optimistic lock to the transaction request and perform the optimistic lock processing logic.

2. The method according to claim 1, characterized in that, the method further includes: S9. When the transaction request marked as locked feedbacks that the processing is completed, perform an unlocking operation on the distributed pessimistic lock added to the transaction request.

3. The method according to claim 1, characterized in that, the performing flow control judgment on the current distributed cache includes: Verify whether the number of consecutive failures to access the distributed cache exceeds a preset threshold. When the number of consecutive failures to access the distributed cache exceeds the preset threshold, it is judged that the distributed cache has a fault.

4. The method according to claim 3, characterized in that, step S6 further includes: When it is judged that the distributed cache has a fault, select any one transaction request as a trial request, and perform the operation of adding a distributed pessimistic lock on the trial request; When the distributed pessimistic lock of the trial request is added successfully, clear the number of consecutive failures to access the distributed cache.

5. The method according to claim 1, characterized in that, the performing the operation of adding a distributed pessimistic lock to the transaction request includes: Obtain the customer number corresponding to the transaction request, call the put method of the distributed cache to add a distributed pessimistic lock to the customer number corresponding to the transaction request, and set the survival time of the distributed pessimistic lock.

6. The method according to claim 5, characterized in that, the checking whether the distributed pessimistic lock is added successfully includes: Verify whether the put method of the distributed cache is called successfully. When the call is successful, the distributed pessimistic lock is added successfully; otherwise, the addition is unsuccessful.

7. The method according to claim 6, characterized in that the step S7 further includes: when the addition of the distributed pessimistic lock is unsuccessful, re-execute the operation of adding the distributed pessimistic lock to the transaction request according to a preset waiting interval and maximum number of retries; when the distributed pessimistic lock is added successfully within the maximum number of retries, mark the transaction request as locked; when the addition of the distributed pessimistic lock is still unsuccessful after exceeding the maximum number of retries, mark the transaction request as pending processing.

8. A high-concurrency transaction locking system combining optimistic lock and pessimistic lock, characterized in that it includes: a configuration file management module for establishing a distributed pessimistic lock configuration file; a distributed pessimistic lock status control module for checking the status of the current total switch of the distributed pessimistic lock and the status of the distributed pessimistic lock flag bit of the transaction code corresponding to the transaction request; a distributed cache verification module for performing flow control judgment on the current distributed cache; a distributed pessimistic lock addition module for executing the operation of adding the distributed pessimistic lock to the transaction request and checking whether the distributed pessimistic lock is added successfully; when the system runs, it implements the method described in any one of claims 1 to 7.

9. A computer-readable storage medium, characterized in that a computer program is stored on the storage medium, and when the computer program is executed by a processor, it implements the method described in any one of claims 1 to 7.

10. An electronic device, characterized in that it includes a processor and a memory; the memory is used for storing the distributed pessimistic lock configuration file and the transaction request; the processor is used for executing the method described in any one of claims 1 to 7 by calling the distributed pessimistic lock configuration file and the transaction request.

Images