A data updating method and device, a terminal device, and a storage medium

Abstract

Embodiments of the application disclose a data updating method and device, terminal equipment and a storage medium, wherein the method comprises: receiving at least one data updating request of a user, adding a distributed lock for a target data updating request in the request based on a user identifier in the request, accessing a database through the target data updating request after the lock is added, obtaining historical business associated data and a version corresponding to the user identifier, obtaining business associated data and a data processing mode in the target updating request, determining target business associated data based on the business associated data, the historical business associated data and the data processing mode, determining a target version based on the version and a preset version change rule, updating the historical business associated data in the database to the target business associated data and updating the version in the database to the target version based on an optimistic lock mechanism preset by the database. Through the above method, the problem of concurrency is solved and the consistency of data is ensured.

Description

Technical Field

[0001] This application relates to the field of database technology, and in particular to a data update method, apparatus, terminal device and storage medium. Background Technology

[0002] A database is a repository for storing data in a specific format; it's a warehouse on a computer. Data updating is the process of replacing corresponding old data items or records in a data file or database with new data items or records. After a data update, the corresponding data stored in the database will change.

[0003] Data updates can be achieved by initiating requests. However, since the number of requests input into a computer at any given moment is enormous, and the same user may input a large number of requests at the same time or within the same time period, concurrency issues can easily arise. Without concurrency control, data inconsistency can easily occur.

[0004] In existing technologies, concurrency issues are typically addressed by updating the database first and then deleting cached data from the cache database to achieve consistency requirements. However, this approach is not suitable for data update processing in high-concurrency scenarios, as existing methods cannot achieve data consistency under high-concurrency conditions. Summary of the Invention

[0005] This application provides a data update method, apparatus, terminal device, and storage medium that can be used in the financial industry, aiming to solve the problem of data consistency in high-concurrency scenarios in the prior art.

[0006] In a first aspect, embodiments of this application provide a data update method, the method comprising:

[0007] Receive at least one data update request from a user, wherein the data update request includes a user identifier;

[0008] Based on the user identifier, a distributed lock is added to one of the target data update requests in the at least one data update request;

[0009] Access the database through the target data update request after locking, and obtain the historical business-related data and the version of the historical business-related data corresponding to the user identifier in the database.

[0010] Obtain the business-related data and data processing method from the target update request, and determine the target business-related data based on the business-related data, the historical business-related data, and the data processing method;

[0011] Based on the version and the preset version change rules, determine the target version corresponding to the data associated with the target business;

[0012] Based on the optimistic locking mechanism pre-set in the database, a data update operation is performed to update the historical business-related data in the database to the target business-related data, and to update the version in the database to the target version.

[0013] Secondly, embodiments of this application also provide a data updating device, the system comprising:

[0014] A receiving module is configured to receive at least one data update request from a user, wherein the data update request includes a user identifier;

[0015] The locking module is used to add a distributed lock to one of the target data update requests in the at least one data update request based on the user identifier;

[0016] The access module is used to access the database through the target data update request after locking processing, and to obtain the historical business-related data corresponding to the user identifier and the version of the historical business-related data in the database.

[0017] The data determination module is used to obtain the business-related data and data processing method in the target update request, and determine the target business-related data based on the business-related data, the historical business-related data and the data processing method;

[0018] The version determination module is used to determine the target version corresponding to the target business-related data based on the version and preset version change rules;

[0019] The data update module is used to perform data update operations based on the optimistic locking mechanism pre-set in the database, update the historical business-related data in the database to the target business-related data, and update the version in the database to the target version.

[0020] Thirdly, embodiments of this application also provide a terminal device, including a memory and a processor, wherein the memory is used to store instructions and data, and the processor is used to execute the data update method described above.

[0021] Fourthly, embodiments of this application also provide a storage medium storing a plurality of instructions adapted for loading by a processor to execute the data update method described above.

[0022] The data update method in this embodiment configures a distributed lock based on the user's identifier when receiving data update requests from the same user, and generates a lock key for the distributed lock. Each data update request competes for the lock based on the lock key. The data update request that acquires the distributed lock is locked and used as the target data update request to solve the high concurrency problem. The target data update request accesses the database to obtain the corresponding historical business-related data and its version. Based on the business-related data, data processing method, and historical business-related data in the target data update request, the target business-related data is obtained. Based on the version and preset version change rules, the target version is obtained. Then, based on the database's preset optimistic locking mechanism, the data is updated, updating the historical business-related data to the target business-related data and the version to the target version, thus realizing data update and version update and ensuring data consistency. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 This is a flowchart of a data update method provided in an embodiment of this application.

[0025] Figure 2 This is a schematic diagram of a data update device provided in an embodiment of this application.

[0026] Figure 3 This is another structural schematic diagram of a data update device provided in an embodiment of this application.

[0027] Figure 4 This is a schematic diagram of the structure of a terminal device provided in an embodiment of this application. Detailed Implementation

[0028] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0029] In the description of the embodiments of this application, it should be understood that the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, features defined with "first" and "second" may explicitly or implicitly include one or more of the stated features. In the description of the embodiments of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0030] To enable any person skilled in the art to implement and use this application, the following description is provided. In this description, details are set forth for purposes of explanation. It should be understood that those skilled in the art will recognize that this application can be implemented without using these specific details. In other instances, well-known processes will not be described in detail to avoid obscuring the description of the embodiments of this application with unnecessary detail. Therefore, this application is not intended to be limited to the embodiments shown, but is consistent with the broadest scope of the principles and features disclosed in the embodiments of this application.

[0031] This application provides a data update method, apparatus, terminal device, and storage medium, which will be described in detail below.

[0032] Please see Figure 1 , Figure 1 A flowchart of a data update method provided in this application embodiment includes the following:

[0033] 101. Receive at least one data update request from a user, wherein the data update request includes a user identifier.

[0034] 102. Add a distributed lock to one of the target data update requests in the at least one data update request based on the user identifier.

[0035] In the embodiments of this application, a Redis database and an MQSQL database are included. The Redis database is used to configure, generate, and release distributed locks. The MQSQL database is used to store data and is equipped with an optimistic locking mechanism.

[0036] Since there are no concurrency issues between different users, concurrency problems only arise when the same user submits multiple requests at the same time or within the same time period. Therefore, the data update method of this application will be explained below based on a data update request submitted by the same user.

[0037] When a user initiates a data update request, the request includes information such as the user identifier, business-related data, and data processing method. The user identifier can be the user's login account or ID card number. The data processing method can be data addition, data subtraction, or data replacement.

[0038] The data addition, data subtraction, and data replacement methods described above are merely some data processing methods proposed in the embodiments of this application. In other embodiments, the data processing methods may be methods of processing data according to other rules, which are not limited here.

[0039] Optionally, in some embodiments, step 102 includes: generating a lock key for at least one data update request based on a user identifier; acquiring a corresponding distributed lock for the at least one data update request based on the lock key; determining the data update request that has acquired a distributed lock among the at least one data update requests as the target data update request; and performing locking processing on the target data update request based on the distributed lock.

[0040] When a user's data update request is received, using the user identifier as the primary key, the Redis database configures and generates a distributed lock for these requests based on the user identifier. Each user inputs one or more data update requests, each corresponding to a unique user identifier and a separate distributed lock. After generating the distributed lock based on the user identifier, a lock key is also generated. Each data update request can compete for the lock based on this key. The data update request that successfully acquires the lock becomes the target data update request, and the distributed lock is then applied to this target data update request.

[0041] After a user inputs multiple data update requests, the data update request that successfully acquires the lock can be used as the target data update request for subsequent data update processing, resolving concurrency issues. Furthermore, after a data update request successfully acquires the lock, a confirmation message can be returned to the user's terminal interface that initiated the request, informing the user that the data update request has successfully acquired the lock. For example, a "Processing" message could be displayed at the click location where the data update request that has acquired the lock was initiated.

[0042] After a user enters multiple data update requests, those that fail to acquire the lock cannot proceed with further data update processing. For these failed data update requests, a corresponding message can be returned to the user's terminal interface, indicating that the request failed. For example, the message "System busy, please try again later" could be displayed at the location where the failed data update request was initiated.

[0043] For example, in a reward system, a user's initial total reward is 0. After completing three activities, the user can claim 100, 200, and 300 gold coins respectively. The user can then claim these three rewards in batches through the corresponding app. The app interface has buttons to initiate requests for claiming 100, 200, and 300 gold coins respectively. If the user clicks all three buttons simultaneously, three data update requests are sent. The Redis database automatically generates a distributed lock and lock key based on the user's identifier. All three requests compete for the distributed lock based on the lock key. If the data update request for claiming 100 gold coins successfully acquires the distributed lock, it becomes the target data update request for subsequent processing. Correspondingly, a "Processing" message is displayed relative to the "Claim 100" button, while a "System busy, please try again later" message is displayed relative to the "Claim 200" and "Claim 300" buttons.

[0044] Optionally, in some embodiments, after determining that the data update request for the distributed lock obtained from the at least one data update request is the target data update request, the number of requests for the data update request for the distributed lock is calculated, and the number of requests is compared with a preset number of requests. If the number of requests is equal to the preset number of requests, the distributed lock is normal; if the number of requests is greater than the preset number of requests, the distributed lock is invalid.

[0045] Since only one distributed lock is generated based on the user's identifier after a single user submits one or more data update requests, and only one data update request can acquire this distributed lock, the default request count should be 1. If the calculated request count is 1, it indicates that the distributed lock is working correctly, and the Redis configuration and generation mechanism for distributed locks is functioning properly. Otherwise, it indicates that the distributed lock is malfunctioning, and there is a problem with the Redis configuration and generation mechanism. In this case, the relevant personnel should be notified to manually analyze and address the Redis configuration and generation mechanism for distributed locks.

[0046] For example, in a reward system, a user's initial total reward is 0. The user completes three activities, earning 100, 200, and 300 gold coins respectively. The user can then claim these three rewards in batches through the corresponding app. The app interface has buttons to initiate requests for each reward. If the user clicks all three buttons simultaneously, three data update requests are sent. The Redis database automatically generates a distributed lock and lock key based on the user's identifier. All three requests attempt to acquire the distributed lock based on the lock key. If only one request acquires the distributed lock, the distributed lock is functioning correctly, and the Redis distributed lock configuration and generation mechanism is working properly. If all three requests acquire the distributed lock, the distributed lock is malfunctioning, and there is a problem with the Redis distributed lock configuration and generation mechanism.

[0047] Optionally, in some embodiments, after the distributed lock fails, the request order of each data update request in at least one data update request is confirmed, and data update processing is performed on each data update request based on the request order and the database's preset optimistic locking mechanism.

[0048] Under the optimistic locking mechanism of the database, data update requests are received and processed one by one in the order of requests. The data update request that is received and processed is the target update request. The target update request is processed, and the corresponding "Processing" message is displayed at the click location where the data update request was initiated. Other requests display the corresponding "System busy, please try again later" message at the click location where they were initiated.

[0049] In addition to processing requests in the order they are requested, the optimistic locking mechanism of a database can also process requests sequentially based on the order in which the database is accessed.

[0050] In the embodiments of this application, a distributed lock and an optimistic locking mechanism are provided. Both distributed and optimistic locking mechanisms have the ability to solve concurrency problems, with the distributed lock having a stronger ability to solve concurrency. However, the distributed lock does not have the function of updating versions, while the optimistic locking mechanism does. After receiving multiple requests from the same user at the same time or within the same time period, the distributed lock can solve the concurrency problem, and the optimistic locking mechanism can realize version updates to ensure data consistency. Furthermore, in the event of a distributed lock failure, the optimistic locking mechanism can solve both the concurrency and version update problems, achieving a dual solution to the concurrency problem and ensuring data consistency.

[0051] Optionally, in some embodiments, after step 102, the method further includes: setting a timed task for the distributed lock; if the timed task ends before the target data update request has completed the data update, then the processing of the target data update request is stopped, and the target data update request is unlocked to release the distributed lock.

[0052] If a target data update request that has not been completed within the time limit corresponding to the scheduled task stops processing and the distributed lock is released, a message "System busy, please try again later" can be displayed. In this case, the target data update request needs to be re-initiated.

[0053] 103. Access the database through the target data update request after locking, and obtain the historical business-related data and the version of the historical business-related data corresponding to the user identifier in the database.

[0054] After being locked, the target data update request has permission to access the database. By accessing the database, it can obtain the historical business-related data corresponding to the user identifier and the version of that historical business-related data. The historical business-related data can be considered as the data stored when the database was last updated; the version changes every time the database is updated.

[0055] Optionally, in some embodiments, after step 103, the method further includes: adding the version as an update condition to the target data update request.

[0056] By adding the version obtained from accessing the database as an update condition to the target data update request, the data and version in the database can be updated based on the version in the update condition during data updates, ensuring data consistency.

[0057] 104. Obtain the business-related data and data processing method in the target update request, and determine the target business-related data based on the business-related data, the historical business-related data, and the data processing method.

[0058] 105. Based on the version and the preset version change rules, determine the target version corresponding to the data associated with the target business.

[0059] When the same user initiates multiple data update requests, each data update request will carry a user identifier, business-related data, and data processing method. The user identifier is the same in each data update request, but the business-related data and data processing method may be different.

[0060] If multiple data update requests from the same user originate from the same location, the user identifier, business-related data, and data processing method may all be identical across these requests. If multiple data update requests from the same user originate from different locations, only the user identifier will necessarily be the same across the requests; the business-related data and data processing method may differ.

[0061] After the target data update request accesses the database to obtain historical business-related data and its version, the version is added as an update condition to the target data update request. The business-related data and data processing method in the target data update request are obtained, and the preset version change rules are obtained to determine the target business-related data and target version used for data update.

[0062] For example, in a benefits system, a user completes three activities and can receive 100, 200, and 300 gold coins respectively. The user can then claim these three benefits in batches through the corresponding app. The app interface has buttons to initiate requests to claim 100, 200, and 300 gold coins respectively. If the user clicks the "claim 100" button, the initiated data update request is the target data update request. If the database access retrieves historical business-related data of 0, version N, and the preset version change rule is incrementing by 1, and the business-related data for the target data update request is 100, with data processing using addition, then the target business-related data is determined to be 100, and the target version is N+1.

[0063] 106. Based on the optimistic locking mechanism pre-set in the database, perform a data update operation to update the historical business-related data in the database to the target business-related data, and update the version in the database to the target version.

[0064] Optionally, in some embodiments, step 106 includes: determining whether the current version stored in the database is consistent with the version in the update conditions; if consistent, updating the current version to the target version; if inconsistent, the target data update request fails to update.

[0065] When updating data, an instruction containing the target business-related data, the target version, and update conditions is sent to the database equipped with an optimistic locking mechanism. Upon receiving the instruction, the database compares the version in the update conditions with the currently stored version to determine if the current version matches the version in the update conditions. If they match, it means that no data update was performed during the process of receiving and processing the target data update request after the previous successful data update. In this case, a data update operation is executed, replacing the historical business-related data with the target business-related data and changing the version to the target version. If they do not match, it means that the data was updated during the process of receiving and processing the target data update request after the previous successful data update. In this case, the target data update request is not processed, meaning no data update operation is performed for the target data update request to avoid data inconsistency.

[0066] For example, in a benefits system, a user completes three activities and can receive 100, 200, and 300 gold coins respectively. The user can then claim these three benefits in batches through the corresponding app. The app interface has buttons to initiate requests for claiming 100, 200, and 300 gold coins respectively. If the user clicks the "claim 100" button, the initiated data update request is the target data update request. If the database retrieves historical business-related data as 0, with version N, version N is added as an update condition to the target data update request. When executing the data update operation, an instruction with the update condition of version N is sent to the database. If the database retrieves the current version as N+1, the current version is inconsistent with the version in the update condition. Therefore, the data update operation for the target data update request is not executed, and an "update failed" message is returned.

[0067] Optionally, in some embodiments, after step 106, the method further includes: unlocking the target data update request, releasing the distributed lock, and determining whether the data update operation was successfully executed based on the current data and current version stored in the database corresponding to the user identifier.

[0068] After performing the data update operation on the target data update request, the target data update request is unlocked, releasing the distributed lock. Alternatively, the data update operation on the target data update request is not performed, and the target data update request is unlocked, releasing the distributed lock.

[0069] Release the distributed lock so that other users who failed to acquire the lock can re-acquire it and have their data update requests processed.

[0070] For example, in a reward system, a user's initial total reward is 0. The user completes three activities, earning rewards of 100, 200, and 300 coins respectively. The user can then claim these rewards in batches through the corresponding app. The app interface has buttons to initiate requests for each reward. If the user clicks all three buttons simultaneously, three data update requests are sent. The Redis database automatically generates a distributed lock and lock key based on the user's identifier. All three requests compete for the distributed lock based on the lock key. If the request to claim 100 coins successfully acquires the lock, it becomes the target request for locking and data update processing. After the target request to claim 100 coins is processed, the distributed lock is released, and the user can then initiate requests to claim 200 and 300 coins, which will then compete for the lock again. If the request to claim 200 coins successfully acquires the lock, it is processed accordingly.

[0071] For example, in a reward system, a user's initial total reward is 0. The user completes three activities, earning 100, 200, and 300 gold coins respectively. If the database stores 0 gold coins (version N), then after the user claims 100, 200, and 300 gold coins, the database should store 600 gold coins (version N+3).

[0072] After determining whether the data update operation was executed successfully, if the data update operation was executed successfully, the corresponding prompt message "Update successful" can be returned. If the data update operation was not executed successfully, the corresponding prompt message "System busy, please try again later" can be returned.

[0073] The data update method of this application includes: receiving at least one data update request from a user, the data update request including a user identifier; adding a distributed lock to a target data update request among the at least one data update requests based on the user identifier; accessing a database through the locked target data update request to obtain historical business-related data and its version corresponding to the user identifier in the database; obtaining business-related data and data processing methods in the target update request, and determining target business-related data based on the business-related data, historical business-related data, and data processing methods; determining a target version corresponding to the target business-related data based on the version and preset version change rules; and performing a data update operation based on a pre-set optimistic locking mechanism in the database to update the historical business-related data in the database to the target business-related data and update the version in the database to the target version. In this application, a distributed lock is used to process requests to solve the high concurrency problem, and an optimistic locking mechanism is used to update data to achieve both data updates and version updates, ensuring data consistency. Furthermore, if the distributed lock fails, the optimistic locking mechanism can be used independently to update the data and version, improving the reliability of the data update process.

[0074] Please see Figure 2 , Figure 2 A schematic diagram of a data update device provided in this application embodiment is shown. The data update device 200 includes the following modules:

[0075] The receiving module 201 is used to receive at least one data update request from a user, wherein the data update request includes a user identifier.

[0076] The locking module 202 is used to add a distributed lock to one of the target data update requests in the at least one data update request based on the user identifier.

[0077] Access module 203 is used to access the database through a target data update request after locking, and to obtain the historical business-related data and the version of the historical business-related data corresponding to the user identifier in the database.

[0078] The data determination module 204 is used to obtain the business-related data and data processing method in the target update request, and determine the target business-related data based on the business-related data, historical business-related data and data processing method;

[0079] Version determination module 205 is used to determine the target version corresponding to the data associated with the target business based on the version and preset version change rules.

[0080] The data update module 206 is used to perform data update operations based on the optimistic locking mechanism pre-set in the database, update the historical business-related data in the database to the target business-related data, and update the version in the database to the target version.

[0081] Optionally, the locking module 202 described above may include the following sub-modules:

[0082] The generation submodule is used to generate a lock key for at least one data update request based on the user identifier.

[0083] The `get` submodule is used to acquire the corresponding distributed lock for at least one data update request based on the lock key.

[0084] The locking submodule is used to determine that the data update request that has obtained a distributed lock among at least one data update request is the target data update request, and to perform locking processing on the target data update request based on the distributed lock.

[0085] The calculation submodule is used to calculate the number of data update requests that have been obtained from the distributed lock.

[0086] The comparison submodule is used to compare the number of requests with the preset number of requests. If the number of requests is equal to the preset number of requests, the distributed lock is normal; if the number of requests is greater than the preset number of requests, the distributed lock is invalid.

[0087] The confirmation submodule is used to confirm the request order of each data update request in at least one data update request.

[0088] The processing submodule is used to process data update requests based on the request order and the database's default optimistic locking mechanism.

[0089] Optionally, the data update device 200 may further include the following modules:

[0090] Add a submodule to add the version as the update condition to the target data update request after obtaining the historical business-related data and the version of the historical business-related data corresponding to the user identifier in the database.

[0091] Based on the processing of adding submodules, the data update module 206 mentioned above may include the following submodules:

[0092] The judgment submodule is used to determine whether the current version stored in the database is consistent with the version in the update conditions; if they are consistent, the current version is updated to the target version; if they are inconsistent, the target data update request fails.

[0093] Optionally, the data update device 200 may further include the following modules:

[0094] The task setting module is used to set up scheduled tasks for distributed locks.

[0095] The task monitoring module is used to stop processing the target data update request and release the distributed lock if the target data update request has not been updated before the scheduled task ends.

[0096] Optionally, the above-mentioned data update device may further include the following modules:

[0097] The unlock module is used to unlock target data update requests and release the distributed lock.

[0098] The update judgment module is used to determine whether the data update operation was successfully executed based on the current data and current version corresponding to the user identifier stored in the database.

[0099] The task setting module is processed after the locking module 202, and the unlocking module is processed after the data update module 206.

[0100] Optionally, the data update device 200 in this embodiment may also include other modules and sub-modules, which will not be described in detail here.

[0101] The data update apparatus 200 of this application embodiment includes: a receiving module 201, configured to receive at least one data update request from a user, the data update request including a user identifier; a locking module 202, configured to add a distributed lock to a target data update request among the at least one data update requests based on the user identifier; an access module 203, configured to access a database through the locked target data update request, and obtain historical business-related data and its version corresponding to the user identifier in the database; a data determination module 204, configured to obtain the business-related data and data processing method in the target update request, and determine the target business-related data based on the business-related data, historical business-related data, and data processing method; a version determination module 205, configured to determine the target version corresponding to the target business-related data based on the version and a preset version change rule; and a data update module 206, configured to perform a data update operation based on an optimistic locking mechanism preset in the database, updating the historical business-related data in the database to the target business-related data, and updating the version in the database to the target version. This application employs a distributed lock to process requests, addressing high concurrency issues. An optimistic locking mechanism is used to update data, ensuring both data updates and version updates, thus guaranteeing data consistency. Furthermore, even if the distributed lock fails, the optimistic locking mechanism can still be used independently to update the data and version, improving the reliability of data update processing.

[0102] Please see Figure 3 , Figure 3This is another schematic diagram of the data update device provided in an embodiment of this application. The data update device 200 includes a memory 120, one or more processors 180, and one or more application programs, wherein the one or more application programs are stored in the memory 120 and configured to be executed by the processors 180. The processors 180 may include a receiving module 201, a locking module 202, an access module 203, a data determination module 204, a version determination module 205, and a data update module 206. For example, the structure and connection relationship of the above components can be as follows:

[0103] Memory 120 can be used to store applications and data. The applications stored in memory 120 contain executable code, and these applications can be composed of various functional modules. Processor 180 executes various functional applications and data update methods by running the applications stored in memory 120. Furthermore, memory 120 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, memory 120 may also include a memory controller to provide processor 180 with access to memory 120.

[0104] The processor 180 is the control center of the device, connecting various parts of the terminal through various interfaces and lines. It performs various functions and processes data by running or executing applications stored in the memory 120 and calling data stored in the memory 120, thereby providing overall monitoring of the device. Optionally, the processor 180 may include one or more processing cores; preferably, the processor 180 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications.

[0105] Specifically, in this embodiment, the processor 180 loads the executable code corresponding to one or more application processes into the memory 120 according to the following instructions, and the processor 180 runs the application stored in the memory 120 to achieve various functions:

[0106] Receive at least one data update request from a user, wherein the data update request includes a user identifier;

[0107] Based on the user identifier, a distributed lock is added to one of the target data update requests in the at least one data update request;

[0108] Access the database through the target data update request after locking, and obtain the historical business-related data and the version of the historical business-related data corresponding to the user identifier in the database.

[0109] Obtain the business-related data and data processing method from the target update request, and determine the target business-related data based on the business-related data, the historical business-related data, and the data processing method;

[0110] Based on the version and the preset version change rules, determine the target version corresponding to the data associated with the target business;

[0111] Based on the optimistic locking mechanism pre-set in the database, a data update operation is performed to update the historical business-related data in the database to the target business-related data, and to update the version in the database to the target version.

[0112] In some embodiments, adding a distributed lock to a target data update request among the at least one data update requests based on the user identifier includes:

[0113] The lock key for the at least one data update request is generated based on the user identifier;

[0114] Based on the lock key, the at least one data update request acquires the corresponding distributed lock;

[0115] The data update request for which the distributed lock is obtained is identified as the target data update request, and the target data update request is locked based on the distributed lock.

[0116] In some embodiments, after determining that the data update request of the distributed lock obtained from the at least one data update request is the target data update request, the method further includes:

[0117] Calculate the number of data update requests obtained from the distributed lock;

[0118] The number of requests is compared with the preset number of requests. If the number of requests is equal to the preset number of requests, the distributed lock is normal.

[0119] If the number of requests exceeds the preset number of requests, the distributed lock becomes invalid.

[0120] In some embodiments, after the distributed lock fails, the method further includes:

[0121] Confirm the request order of each data update request in the at least one data update request;

[0122] Based on the request order and the database's preset optimistic locking mechanism, each data update request is processed for data update.

[0123] In some embodiments, after obtaining the historical service association data corresponding to the user identifier and the version of the historical service association data in the database, the method further includes:

[0124] The version is used as the update condition and added to the target data update request;

[0125] The step of updating the historical business-related data in the database to the target business-related data, and updating the version in the database to the target version, includes:

[0126] Determine whether the current version stored in the database is consistent with the version in the update conditions;

[0127] If they match, update the current version to the target version;

[0128] If there is a discrepancy, the target data update request will fail.

[0129] In some embodiments, after adding a distributed lock to a target data update request among the at least one data update requests based on the user identifier, the method further includes:

[0130] Set a timed task for the distributed lock;

[0131] If the scheduled task ends before the target data update request has completed the data update, then the processing of the target data update request will stop, and the target data update request will be unlocked to release the distributed lock.

[0132] In some embodiments, after performing the data update operation, updating the historical business-related data in the database to the target business-related data, and updating the version in the database to the target version, the method further includes:

[0133] The target data update request is unlocked to release the distributed lock;

[0134] Based on the current data and current version corresponding to the user identifier stored in the database, determine whether the data update operation was successfully executed.

[0135] Please see Figure 4 , Figure 4 A schematic diagram of a terminal device provided in an embodiment of this application is shown. This terminal device can be used to implement the data update method provided in the above embodiments. The terminal device 1200 can be a smartphone or a tablet computer.

[0136] like Figure 4As shown, the terminal device 1200 may include an RF (Radio Frequency) circuit 110, a memory 120 including one or more (only one is shown in the figure) computer-readable storage media, an input unit 130, a display unit 140, a sensor 150, an audio circuit 160, a transmission module 170, a processor 180 including one or more (only one is shown in the figure) processing cores, and a power supply 190, etc. Those skilled in the art will understand that... Figure 4 The structure of the terminal device 1200 shown does not constitute a limitation on the terminal device 1200, and may include more or fewer components than shown, or combine certain components, or have different component arrangements. Wherein:

[0137] RF circuit 110 is used to receive and transmit electromagnetic waves, realizing the mutual conversion between electromagnetic waves and electrical signals, thereby enabling communication with communication networks or other devices. RF circuit 110 may include various existing circuit elements used to perform these functions, such as antennas, radio frequency transceivers, digital signal processors, encryption / decryption chips, Subscriber Identity Module (SIM) cards, memory, etc. RF circuit 110 can communicate with various networks such as the Internet, corporate intranets, and wireless networks, or communicate with other devices via wireless networks.

[0138] The memory 120 can be used to store software programs and modules, such as the program instructions / modules corresponding to the data update method in the above embodiments. The processor 180 executes various functional applications and steps of the data update method by running the software programs and modules stored in the memory 120. The memory 120 may include high-speed random access memory and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 120 may further include memory remotely located relative to the processor 180, and these remote memories can be connected to the terminal device 1200 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0139] Input unit 130 can be used to receive input numerical or character information, and to generate keyboard, mouse, joystick, optical, or trackball signal inputs related to user settings and function control. Specifically, input unit 130 may include touch-sensitive surface 131 and other input devices 132. Touch-sensitive surface 131, also known as a touch display screen or touchpad, can collect user touch operations on or near it (such as user operations using fingers, styluses, or any suitable object or accessory on or near touch-sensitive surface 131), and drive corresponding connection devices according to a pre-set program. Optionally, touch-sensitive surface 131 may include two parts: a touch detection device and a touch controller. The touch detection device detects the user's touch position and the signal generated by the touch operation, and transmits the signal to the touch controller; the touch controller receives touch information from the touch detection device, converts it into touch point coordinates, sends it to processor 180, and can receive and execute commands from processor 180. In addition, the touch-sensitive surface 131 can be implemented using various types such as resistive, capacitive, infrared, and surface acoustic wave. Besides the touch-sensitive surface 131, the input unit 130 may also include other input devices 132. Specifically, other input devices 132 may include, but are not limited to, one or more of the following: a physical keyboard, function keys (such as volume control buttons, power buttons, etc.), a trackball, a mouse, and a joystick.

[0140] Display unit 140 can be used to display information input by the user or information provided to the user, as well as various graphical user interfaces of terminal device 1200. These graphical user interfaces can be composed of graphics, text, icons, video, and any combination thereof. Display unit 140 may include display panel 141, optionally configured as LCD (Liquid Crystal Display), OLED (Organic Light-Emitting Diode), etc. Further, touch-sensitive surface 131 may cover display panel 141. When touch-sensitive surface 131 detects a touch operation on or near it, it transmits the information to processor 180 to determine the type of touch event. Subsequently, processor 180 provides corresponding visual output on display panel 141 according to the type of touch event. Although in Figure 4 In this embodiment, the touch-sensitive surface 131 and the display panel 141 are implemented as two separate components to realize input and output functions. However, in some embodiments, the touch-sensitive surface 131 and the display panel 141 can be integrated to realize input and output functions.

[0141] The terminal device 1200 may also include at least one sensor 150, such as a light sensor, a motion sensor, and other sensors. Specifically, the light sensor may include an ambient light sensor and a proximity sensor. The ambient light sensor can adjust the brightness of the display panel 141 according to the ambient light level, and the proximity sensor can turn off the display panel 141 and / or backlight when the terminal device 1200 is moved to the ear. As a type of motion sensor, a gravity acceleration sensor can detect the magnitude of acceleration in various directions (generally three axes). When stationary, it can detect the magnitude and direction of gravity and can be used for applications that recognize the phone's posture (such as landscape / portrait switching, related games, magnetometer posture calibration), vibration recognition-related functions (such as pedometer, tapping), etc. Other sensors that the terminal device 1200 may also be configured with, such as a gyroscope, barometer, hygrometer, thermometer, and infrared sensor, will not be described in detail here.

[0142] Audio circuitry 160, speaker 161, and microphone 162 provide an audio interface between the user and terminal device 1200. Audio circuitry 160 converts received audio data into electrical signals, which are then transmitted to speaker 161, where they are converted into sound signals for output. Conversely, microphone 162 converts collected sound signals into electrical signals, which are received by audio circuitry 160, converted back into audio data, and then processed by processor 180 before being transmitted via RF circuitry 110 to, for example, another terminal, or output to memory 120 for further processing. Audio circuitry 160 may also include an earphone jack to facilitate communication between peripheral headphones and terminal device 1200.

[0143] Terminal device 1200, through transmission module 170 (e.g., Wi-Fi module), can help users send and receive emails, browse web pages, and access streaming media, providing users with wireless broadband internet access. Although Figure 4 The transmission module 170 is shown, but it is understood that it is not a necessary component of the terminal device 1200 and can be omitted as needed without changing the nature of the invention.

[0144] The processor 180 is the control center of the terminal device 1200. It connects to various parts of the mobile phone via various interfaces and lines. By running or executing software programs and / or modules stored in the memory 120, and by calling data stored in the memory 120, it performs various functions of the terminal device 1200 and processes data, thereby providing overall monitoring of the mobile phone. Optionally, the processor 180 may include one or more processing cores; in some embodiments, the processor 180 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may also not be integrated into the processor 180.

[0145] The terminal device 1200 also includes a power supply 190 that supplies power to the various components. In some embodiments, the power supply can be logically connected to the processor 180 through a power management system, thereby enabling functions such as discharge management and power consumption management through the power management system. The power supply 190 may also include one or more DC or AC power supplies, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0146] Although not shown, the terminal device 1200 may also include a camera (such as a front-facing camera and a rear-facing camera), a Bluetooth module, etc., which will not be described in detail here. Specifically, in this embodiment, the display unit 140 of the terminal device 1200 is a touch screen display, and the terminal device 1200 also includes a memory 120 and one or more programs, wherein one or more programs are stored in the memory 120 and configured to be executed by one or more processors 180, and the one or more programs include steps for performing the following operations:

[0147] Receive at least one data update request from a user, wherein the data update request includes a user identifier;

[0148] Based on the user identifier, a distributed lock is added to one of the target data update requests in the at least one data update request;

[0149] Access the database through the target data update request after locking, and obtain the historical business-related data and the version of the historical business-related data corresponding to the user identifier in the database.

[0150] Obtain the business-related data and data processing method from the target update request, and determine the target business-related data based on the business-related data, the historical business-related data, and the data processing method;

[0151] Based on the version and the preset version change rules, determine the target version corresponding to the data associated with the target business;

[0152] Based on the optimistic locking mechanism pre-set in the database, a data update operation is performed to update the historical business-related data in the database to the target business-related data, and to update the version in the database to the target version.

[0153] In some embodiments, adding a distributed lock to a target data update request among the at least one data update requests based on the user identifier includes:

[0154] The lock key for the at least one data update request is generated based on the user identifier;

[0155] Based on the lock key, the at least one data update request acquires the corresponding distributed lock;

[0156] The data update request for which the distributed lock is obtained is identified as the target data update request, and the target data update request is locked based on the distributed lock.

[0157] In some embodiments, after determining that the data update request of the distributed lock obtained from the at least one data update request is the target data update request, the method further includes:

[0158] Calculate the number of data update requests obtained from the distributed lock;

[0159] The number of requests is compared with the preset number of requests. If the number of requests is equal to the preset number of requests, the distributed lock is normal.

[0160] If the number of requests exceeds the preset number of requests, the distributed lock becomes invalid.

[0161] In some embodiments, after the distributed lock fails, the method further includes:

[0162] Confirm the request order of each data update request in the at least one data update request;

[0163] Based on the request order and the database's preset optimistic locking mechanism, each data update request is processed for data update.

[0164] In some embodiments, after obtaining the historical service association data corresponding to the user identifier and the version of the historical service association data in the database, the method further includes:

[0165] The version is used as the update condition and added to the target data update request;

[0166] The step of updating the historical business-related data in the database to the target business-related data, and updating the version in the database to the target version, includes:

[0167] Determine whether the current version stored in the database is consistent with the version in the update conditions;

[0168] If they match, update the current version to the target version;

[0169] If there is a discrepancy, the target data update request will fail.

[0170] In some embodiments, after adding a distributed lock to a target data update request among the at least one data update requests based on the user identifier, the method further includes:

[0171] Set a timed task for the distributed lock;

[0172] If the scheduled task ends before the target data update request has completed the data update, then the processing of the target data update request will stop, and the target data update request will be unlocked to release the distributed lock.

[0173] In some embodiments, after performing the data update operation, updating the historical business-related data in the database to the target business-related data, and updating the version in the database to the target version, the method further includes:

[0174] The target data update request is unlocked to release the distributed lock;

[0175] Based on the current data and current version corresponding to the user identifier stored in the database, determine whether the data update operation was successfully executed.

[0176] This application also provides a storage medium storing a computer program. When the computer program is run on a computer, the computer executes the data update method described in any of the above embodiments.

[0177] It should be noted that, for the data update method described in this application, those skilled in the art will understand that all or part of the process of the data update method described in the embodiments of this application can be implemented by a computer program controlling the relevant hardware. The computer program can be stored in a computer-readable storage medium, such as in the memory of a terminal device, and executed by at least one processor within the terminal device. During execution, it can include the process of the embodiments of the data update method described. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), random access memory (RAM), etc.

[0178] For the data update device described in this application embodiment, its functional modules can be integrated into a single processing chip, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0179] The data update method, apparatus, medium, and device provided in the embodiments of this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only for the purpose of helping to understand the methods and core ideas of this application; at the same time, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A data update method, characterized in that, The method includes: Receive at least one data update request from a user, wherein the data update request includes a user identifier; Based on the user identifier, a distributed lock is added to one of the target data update requests in the at least one data update request; Access the database through the target data update request after locking, and obtain the historical business-related data and the version of the historical business-related data corresponding to the user identifier in the database. Obtain the business-related data and data processing method from the target data update request, and determine the target business-related data based on the business-related data, the historical business-related data, and the data processing method; Based on the version and the preset version change rules, determine the target version corresponding to the data associated with the target business; Based on the optimistic locking mechanism pre-set in the database, a data update operation is performed to update the historical business-related data in the database to the target business-related data, and to update the version in the database to the target version; The number of data update requests obtained from the distributed lock is calculated. If the number of requests is greater than a preset number of requests, the distributed lock fails. After the distributed lock fails, the request order of each data update request in at least one data update request is determined. Based on the request order and the optimistic locking mechanism preset by the database, data update processing is performed on each data update request.

2. The data update method according to claim 1, characterized in that, The step of adding a distributed lock to a target data update request among the at least one data update requests based on the user identifier includes: The lock key for the at least one data update request is generated based on the user identifier; Based on the lock key, the at least one data update request acquires the corresponding distributed lock; The data update request for which the distributed lock is obtained is identified as the target data update request, and the target data update request is locked based on the distributed lock.

3. The data update method according to claim 2, characterized in that, After determining that the data update request of the distributed lock is the target data update request among the at least one data update request, the method further includes: The number of requests is compared with the preset number of requests. If the number of requests equals the preset number of requests, the distributed lock is functioning normally.

4. The data update method according to claim 1, characterized in that, After obtaining the historical business-related data corresponding to the user identifier and the version of the historical business-related data from the database, the method further includes: The version is used as the update condition and added to the target data update request; The step of updating the historical business-related data in the database to the target business-related data, and updating the version in the database to the target version, includes: Determine whether the current version stored in the database is consistent with the version in the update conditions; If they match, update the current version to the target version; If there is a discrepancy, the target data update request will fail.

5. The data update method according to claim 1, characterized in that, After adding a distributed lock to a target data update request among the at least one data update requests based on the user identifier, the method further includes: Set a timed task for the distributed lock; If the scheduled task ends before the target data update request has completed the data update, then the processing of the target data update request will stop, and the target data update request will be unlocked to release the distributed lock.

6. The data update method according to claim 1, characterized in that, After performing the data update operation, updating the historical business-related data in the database to the target business-related data, and updating the version in the database to the target version, the method further includes: The target data update request is unlocked to release the distributed lock; Based on the current data and current version corresponding to the user identifier stored in the database, determine whether the data update operation was successfully executed.

7. A data update device, characterized in that, The device includes: A receiving module is configured to receive at least one data update request from a user, wherein the data update request includes a user identifier; The locking module is used to add a distributed lock to one of the target data update requests in the at least one data update request based on the user identifier; The access module is used to access the database through the target data update request after locking processing, and to obtain the historical business-related data corresponding to the user identifier and the version of the historical business-related data in the database. The data determination module is used to obtain the business-related data and data processing method in the target data update request, and determine the target business-related data based on the business-related data, the historical business-related data and the data processing method; The version determination module is used to determine the target version corresponding to the target business-related data based on the version and preset version change rules; The data update module is used to perform data update operations based on the optimistic locking mechanism preset in the database, updating the historical business-related data in the database to the target business-related data, and updating the version in the database to the target version; calculating the number of data update requests obtained from the distributed lock, and if the number of requests is greater than a preset number of requests, the distributed lock fails; after the distributed lock fails, confirming the request order of each data update request in at least one data update request, and performing data update processing on each data update request based on the request order and the optimistic locking mechanism preset in the database.

8. A terminal device, characterized in that, It includes a memory and a processor, the memory being used to store instructions and data, and the processor being used to execute the data update method according to any one of claims 1-6.

9. A storage medium, characterized in that, The storage medium stores a plurality of instructions, which are adapted to be loaded by a processor to execute the data update method according to any one of claims 1-6.

Images