Method, device and equipment for processing high-concurrency data request and storage medium

Abstract

The embodiment of the present application relates to the technical field of computer data processing, and discloses a kind of processing methods of high concurrency data request, the method comprises: in response to resource subscription request on target activity page;Target activity page is generated in advance according to the activity configuration information in the first cache;Activity configuration information is synchronized from the second cache into the first cache;First cache includes front-end cache;Second cache includes virtual machine cache;Target user identifier and target activity identifier are included in resource subscription request;Target activity data corresponding to target activity identifier is obtained from the first cache;Target activity data is synchronized from the third cache into the first cache;Third cache includes in-memory database cache;According to target activity data and target user identifier, resource subscription request is verified;When resource subscription request is verified, target activity data is updated. Through the above-mentioned mode, the processing efficiency of high concurrency data request is improved.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of computer data processing technology, specifically to a method, apparatus, device, and storage medium for processing high-concurrency data requests. Background Technology

[0002] Internet platforms frequently employ marketing campaigns such as lotteries or flash sales to attract user participation and purchases. During these campaigns, a large number of users send requests simultaneously and multiple times within a short period. Therefore, to ensure the smooth operation of internet marketing campaigns, the system needs to possess high-concurrency data processing capabilities.

[0003] In the process of implementing the prior art, the inventors discovered that traditional database solutions in the prior art could not effectively solve the problem of low processing efficiency for high-concurrency data requests. Summary of the Invention

[0004] In view of the above problems, embodiments of the present invention provide a method, apparatus, device and storage medium for processing high-concurrency data requests, in order to solve the problem of low efficiency in the prior art.

[0005] According to one aspect of the present invention, a method for processing high-concurrency data requests is provided, the method comprising:

[0006] In response to a resource ordering request on a target activity page; wherein the target activity page is pre-generated based on activity configuration information in a first cache; the activity configuration information is synchronized from a second cache to the first cache; the first cache includes a front-end cache; the second cache includes a virtual machine cache; the resource ordering request includes a target user identifier and a target activity identifier;

[0007] The target activity data corresponding to the target activity identifier is obtained from the first cache; the target activity data is synchronized from the third cache to the first cache; the third cache includes an in-memory database cache;

[0008] The resource ordering request is verified based on the target activity data and the target user identifier;

[0009] When the resource ordering request is verified, the target activity data is updated.

[0010] In an alternative approach, the method further includes:

[0011] In response to an activity page access request, the activity page access request includes the target activity identifier;

[0012] Obtain the activity configuration information corresponding to the target activity identifier from the first cache;

[0013] The activity configuration information is verified;

[0014] When the activity configuration information is determined to be valid, the target activity page is generated based on the activity configuration information.

[0015] In one alternative approach, the front-end cache includes a web cache, and the virtual machine cache includes a JVM cache; the method further includes:

[0016] Retrieve the activity configuration information from the relational database;

[0017] The activity configuration information is stored in the JVM cache;

[0018] When the activity page access request is received, the activity configuration information is synchronized from the JVM cache to the Web cache.

[0019] In one optional approach, the activity page access request includes the access time; the activity configuration information includes the activity validity period; the target activity data includes target inventory information; the target inventory information is periodically synchronized from the third cache to the web cache; the method further includes:

[0020] Verify the target inventory information;

[0021] When the target inventory information meets the preset inventory conditions, the step of verifying the activity configuration information is executed; wherein, the step of verifying the activity configuration information includes: when it is determined that the access time matches the activity validity time, the activity configuration information is determined to be valid.

[0022] In an optional embodiment, the target activity data further includes activity order data; the activity order data includes multiple participation opportunity identifiers and historical order information associated with each participation opportunity identifier; the historical order information includes historical order identifiers and associated user identifiers associated with the historical order identifiers; the method further includes:

[0023] In the activity order data, the target user identifier is matched with the associated user identifier;

[0024] The target number of opportunities is determined based on the historical order identifier associated with the matched associated user identifier and the participation opportunity identifier;

[0025] When the number of target opportunities is greater than zero, the resource ordering request is deemed to have passed verification.

[0026] In one alternative approach, the in-memory database cache includes a first in-memory database and a second in-memory database; the first in-memory database includes Redis; the second in-memory database includes MongoDB; the method further includes: retrieving the target inventory information and the activity order data from the relational database;

[0027] The target inventory information is stored in the first memory database, and the active order data is stored in the second memory database.

[0028] In one optional approach, the resource ordering request further includes a target resource type and a target resource quantity; the target inventory information further includes multiple optional resource types and the optional resource quantity corresponding to each optional resource type; the method further includes:

[0029] The target resource type is matched with the optional resource type, and the number of optional resources corresponding to the matched optional resource type is updated according to the target resource data; the update operation is atomic.

[0030] Generate target order data corresponding to the target user identifier; the target order data includes a target order identifier; the target order identifier is idempotent.

[0031] The activity order data is updated based on the target order data, and the target order data is sent to the target resource management system corresponding to the target resource type via an asynchronous queue.

[0032] According to another aspect of the present invention, a processing apparatus for high-concurrency data requests is provided, comprising:

[0033] A response module is used to respond to a resource ordering request on a target activity page; wherein the target activity page is pre-generated based on activity configuration information in a first cache; the activity configuration information is synchronized from a second cache to the first cache; the first cache includes a front-end cache; the second cache includes a virtual machine cache; and the resource ordering request includes a target user identifier and a target activity identifier.

[0034] The acquisition module is configured to acquire target activity data corresponding to the target activity identifier from the first cache; the target activity data is synchronized from the third cache to the first cache; the third cache includes an in-memory database cache;

[0035] The verification module is used to verify the resource ordering request based on the target activity data and the target user identifier;

[0036] The update module is used to update the target activity data when the resource ordering request is verified.

[0037] According to another aspect of the present invention, a high-concurrency data request processing device is provided, comprising: a processor, a memory, a communication interface, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other through the communication bus;

[0038] The memory is used to store at least one executable instruction that causes the processor to perform the operation of the high-concurrency data request processing method.

[0039] According to another aspect of the present invention, a computer-readable storage medium is provided, the storage medium storing at least one executable instruction that causes a high-concurrency data request processing device to perform the operation of the high-concurrency data request processing method.

[0040] This invention, in its embodiment, pre-generates a target activity page based on activity configuration information in a first cache. The activity configuration information is synchronized from a second cache to the first cache. The first cache includes a front-end cache, and the second cache includes a virtual machine cache. Then, in response to a resource subscription request on the target activity page, the resource subscription request includes a target user identifier and a target activity identifier. Target activity data corresponding to the target activity identifier is retrieved from the first cache. The target activity data is synchronized from a third cache to the first cache. The third cache includes a memory database cache. The resource subscription request is then verified based on the target activity data and the target user identifier. When the resource subscription request is verified, the target activity data is updated.

[0041] This invention differs from existing technologies that use traditional databases for data storage in high-concurrency environments, which suffer from low processing efficiency for high-concurrency data requests. Instead, it pre-retrieves activity configuration information and target activity data from the second and third caches into the first cache, the closest front-end cache to the user. Based on the data's usage frequency and importance, and considering the read efficiency and storage performance of different cache types, earlier-used activity configuration information is stored in the second cache (including a virtual machine cache) for faster read speeds. High-importance target activity data is stored in the third cache (including a memory database cache) for stable performance. Therefore, when a resource ordering request is received, it can be directly processed and returned from the front-end cache, improving the processing efficiency of high-concurrency data requests and thus enhancing the user experience of internet marketing activities in high-concurrency environments.

[0042] The above description is merely an overview of the technical solutions of the embodiments of the present invention. In order to better understand the technical means of the embodiments of the present invention and to implement them in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the embodiments of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0043] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0044] Figure 1 A flowchart illustrating a high-concurrency data request processing method provided in an embodiment of the present invention is shown.

[0045] Figure 2 A schematic diagram of the structure of a high-concurrency data request processing device provided in an embodiment of the present invention is shown;

[0046] Figure 3 A schematic diagram of the structure of a high-concurrency data request processing device provided in an embodiment of the present invention is shown. Detailed Implementation

[0047] Exemplary embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention can be implemented in various forms and should not be limited to the embodiments set forth herein.

[0048] Before describing the high-concurrency data request processing method of this embodiment of the invention, the relevant terms are first explained:

[0049] Front-end caching includes HTTP caching and browser caching. Browser caching includes web caching. Browser caching refers to the process where, when a browser requests a website, it loads various resources. For content that does not change frequently, the browser saves it in local files. The next time the same website is accessed, these resources are loaded directly, thereby speeding up the access.

[0050] There are two main reasons for using web caching: First, it reduces latency. Because web caches are closer to the client, requesting content from the cache takes less time than from the origin server, resulting in faster rendering and a more responsive website. Second, it reduces network traffic. Since copies are reused, it significantly reduces bandwidth usage for users, while keeping bandwidth requests at a low level, making it easier to maintain.

[0051] JVM caching, a cache on the Java Virtual Machine, is non-distributed. Its characteristics are: when a client query request is received, it first checks if the data exists in the JVM cache. If it does, it returns the data to the client; otherwise, it sends a JDBC request to the database to query the data. The data retrieved from the database is first stored in the JVM cache and then returned to the client. This way, the data can be directly found in the JVM cache the next time it is queried, improving data retrieval efficiency and reducing the pressure on the server to access the database.

[0052] Redis is a non-relational open-source database that stores data in memory and can periodically synchronize the memory data to disk, thus persisting the data. It features rich support for data structures, high accuracy, and distributed support.

[0053] MongoDB, an in-memory database similar to relational databases, is easy to maintain and supports field indexes and cursor operations. Its advantages lie in its powerful query capabilities, particularly excelling at querying JSON data, and its ability to store massive amounts of data. However, it does not support transactions. Because relational databases experience a significant performance drop when dealing with large datasets, MongoDB is often used as an alternative. Unlike Redis, MongoDB stores data in memory; when memory is insufficient, it only loads frequently accessed data into memory, storing the rest on disk.

[0054] Figure 1 A flowchart illustrating a high-concurrency data request processing method provided in an embodiment of the present invention is shown. This method is executed by a computer processing device. The computer processing device may include a mobile phone, a laptop computer, etc. Figure 1 As shown, the method includes the following steps:

[0055] Step 101: Respond to a resource ordering request on the target activity page; the resource ordering request includes the target user identifier and the target activity identifier.

[0056] In one embodiment of the present invention, the target activity page may include an activity display page for an internet marketing activity, wherein the internet marketing activity may include activities with high concurrency characteristics, such as flash sales or lucky draws, where users send data requests.

[0057] The event display page shows event configuration information and available resource information. The event configuration information is used to configure basic event information such as the event's validity period and type. The validity period can be a preset time interval or time period, such as 2021.5.28 00:00:00-2021.6.2 23:59:59, or every weekend from June to August 2021. The event type can be such as a flash sale or a lottery.

[0058] The optional resource information may include the types of resources currently available for flash sales or lotteries, and their remaining quantity. A resource ordering request is used to request the ordering of the resources corresponding to the optional resource information. In another embodiment of the invention, the resource ordering request may be triggered by a user clicking a "Participate" button on the target activity page.

[0059] In another embodiment of the present invention, the target activity page is pre-generated based on the activity configuration information in the first cache; the activity configuration information is synchronized from the second cache to the first cache.

[0060] The second cache and the first cache are different types of caches. The first cache is characterized by being stored locally on the device where the activity display page is located, while the second cache is characterized by fast read / write speed, low cost, and relatively simple structure. Therefore, in another embodiment of the present invention, the first cache includes a front-end cache; the second cache includes a virtual machine cache.

[0061] Therefore, prior to step 101, the process of generating the target activity page includes at least the following:

[0062] Step 1011: In response to an activity page access request, the activity page access request includes the target activity identifier.

[0063] In one embodiment of the invention, the target activity identifier is specific and is used to identify data related to different internet marketing campaigns.

[0064] Step 1012: Obtain the activity configuration information corresponding to the target activity identifier from the first cache.

[0065] In one embodiment of the present invention, when querying the first cache based on the target activity identifier, if no activity is found, a prompt message indicating that the activity does not exist is returned.

[0066] In another embodiment of the present invention, the front-end cache includes a web cache, and the virtual machine cache includes a JVM cache; step 1012 further includes: step 121: obtaining the activity configuration information from a relational database.

[0067] In one embodiment of the present invention, a relational database is used to store all data related to the internet marketing campaign corresponding to the target campaign identifier described in step 1011. The relational database includes MySQL.

[0068] Step 122: Store the activity configuration information in the JVM cache.

[0069] Considering the slow read speed of relational databases, and that activity configuration information is data that needs to be verified every time a user's activity page access request is received, in one embodiment of the present invention, the activity configuration information is pre-stored from the relational database into the JVM cache, making the read of the activity configuration information faster, thereby improving the processing efficiency of requests in a high-concurrency environment.

[0070] Step 123: When the activity page access request is received, the activity configuration information is synchronized from the JVM cache to the Web cache.

[0071] It should be noted that, in another embodiment of the present invention, the activity configuration information may be obtained from the JVM cache periodically, and the Web cache may be refreshed based on the obtained activity configuration information.

[0072] Since the Web cache is a front-end cache, it is closest to the user and therefore has the highest reading efficiency. When verifying the existence of an activity before generating the target activity page, the activity configuration information can be directly obtained from the Web cache for verification, avoiding sending data requests to the back-end JVM cache or relational database. This saves the time spent querying the back-end cache or database and waiting for the results, thereby improving the data processing efficiency in a high-concurrency environment.

[0073] Step 1013: Verify the activity configuration information.

[0074] In one embodiment of the present invention, verifying the activity configuration information includes checking whether the sending time of the activity page access request is within the activity's valid time, and whether the resource inventory corresponding to the activity can support the activity.

[0075] In another embodiment of the present invention, the activity page access request includes the access time; the activity configuration information includes the activity validity period; the target activity data includes target inventory information; and the target inventory information is periodically synchronized from the third cache to the Web cache.

[0076] Considering that in actual internet marketing activities such as flash sales or lotteries, resource inventory may be depleted in a short time due to high user participation, subsequent users, even if they have the opportunity or qualification to participate, will not be able to obtain resources. Therefore, in another embodiment of the present invention, in this case, it is sufficient to directly notify the user that the activity has ended, without further generating an activity page. This eliminates the need to receive and process resource order requests sent by users, thereby further simplifying the marketing activity process and improving the processing efficiency of high-concurrency data requests.

[0077] Therefore, in another embodiment of the present invention, before verifying the activity configuration information, the method further includes: step 131: verifying the target inventory information.

[0078] In one embodiment of the present invention, the target inventory information can be compared with a preset inventory threshold.

[0079] Step 132: When the target inventory information meets the preset inventory conditions, execute the step of verifying the activity configuration information.

[0080] In another embodiment of the present invention, the step of verifying the activity configuration information includes:

[0081] Step 132: When it is determined that the access time matches the activity validity time, the activity configuration information is determined to be valid.

[0082] The matching of access time and activity validity period means that the access time is included within the activity validity period. For example, if the activity validity period is from now until 23:59:59 on June 1, 2021, and the access time is 20:00:00 on June 1, 2021, then the two match.

[0083] In another embodiment of the present invention, a prompt page can also be generated. The activity page is used to display prompt messages such as "You're too late, the prizes have been snapped up" when it is determined that the target inventory information does not meet the preset inventory conditions, or to display prompt messages such as "The activity has ended" or "The activity has not started" when the access time does not match the activity's valid time.

[0084] Step 1014: When it is determined that the activity configuration information is valid, generate the target activity page according to the activity configuration information.

[0085] In another embodiment of the present invention, the Web cache also stores some static page information related to page display, such as page style information, page multimedia resource information, etc. This static page information can be obtained in advance from the aforementioned relational database. When it is determined that the activity configuration information is valid, the target activity page is generated based on the above static page information and activity configuration information.

[0086] Step 102: Obtain the target activity data corresponding to the target activity identifier from the first cache; synchronize the target activity data from the third cache to the first cache.

[0087] In internet marketing campaigns, target activity data is the core and foundation for normal business processing. The correct allocation of resources and the correct response to user requests all rely on target activity data. Meanwhile, considering that in-memory databases have the advantages of supporting multiple data structures, stable performance, persistence, and distributed processing, unlike relational databases and virtual machine caches, in one embodiment of the present invention, the target activity data is cached in a third cache; wherein, the third cache includes an in-memory database cache.

[0088] It should be noted that the timing of synchronizing target activity data from the third cache to the first cache can be either timed or every time an activity page access request is received. This avoids inaccurate target activity data caused by the refresh latency of the first cache and improves the processing accuracy of high-concurrency data requests.

[0089] Step 103: Verify the resource ordering request based on the target activity data and the target user identifier.

[0090] Verification of resource ordering requests mainly includes two aspects: firstly, verifying whether the user is eligible to participate based on the target user identifier; secondly, verifying whether the resource inventory corresponding to the resource ordering request can meet the user's ordering request.

[0091] Therefore, in one embodiment of the present invention, the target activity data further includes activity order data; the activity order data includes multiple participation opportunity identifiers and historical order information associated with each participation opportunity identifier; the historical order information includes historical order identifiers and associated user identifiers associated with the historical order identifiers.

[0092] Step 103 further includes: Step 1031: Matching the target user identifier with the associated user identifier in the activity order data.

[0093] Unlike existing technologies that store participation opportunity-related order data and corresponding user and resource data for each order in two separate tables, resulting in high storage costs and low query efficiency, in another embodiment of the present invention, the activity order data corresponding to each activity identifier is stored in a single data table. The primary key of this data table is the participation opportunity identifier. Thus, a query in a single table can complete the response to resource ordering requests, thereby improving the efficiency of high-concurrency data processing.

[0094] Step 1032: Determine the target number of opportunities based on the historical order identifier associated with the matched associated user identifier and the participation opportunity identifier.

[0095] In one embodiment of the present invention, the process of determining the target number of opportunities includes at least: step 321: counting the number of historical order identifiers associated with the matched associated user identifier to obtain the number of used opportunities.

[0096] Step 322: Count the number of participation opportunity identifiers associated with the matched associated user identifier to obtain the initial number of opportunities.

[0097] It should be noted that, in another embodiment of the present invention, the process of determining the participation opportunity identifier may further include:

[0098] Step 3221: Obtain user participation data; the user participation data includes the identifier of the participating user.

[0099] Step 3222: When it is determined that the user participation data meets the preset opportunity conditions, the participation opportunity identifier is generated, and the participating user identifier is determined as the associated user identifier associated with the participation opportunity identifier.

[0100] User participation data includes user participation in related activities. These related activities are other activities associated with the marketing campaign corresponding to the target activity page. For example, if the marketing campaign is a lottery for a telecommunications operator's product vouchers, the related activity could be a user's phone credit points redemption activity. Other related activities could include user participation when spending or points reach a preset threshold, or when a user completes a preset action, such as sharing on social media, saving an item, or commenting.

[0101] Step 323: Determine the target number of opportunities as the difference between the initial number of opportunities and the number of opportunities used.

[0102] For example, when the associated user identifier is U001, the associated order identifiers can include O001 and O002, while the associated opportunity identifiers can include C001, C002, and C003. Therefore, the target opportunity count is 3 - 2 = 1.

[0103] Step 1033: When the number of target opportunities is greater than zero, the resource ordering request is confirmed to have passed verification.

[0104] Given that the resource inventory information in the target activity data is read and written frequently, each time a resource request is verified, it is necessary to first verify whether the resource inventory information meets the preset inventory conditions. At the same time, the activity order data is of even greater importance, as it is the core business support data for the entire internet marketing activity. It needs to be persisted and stored in a manner similar to a relational database.

[0105] Therefore, in another embodiment of the present invention, in order to meet the above-mentioned storage requirements, two memory database caches with different storage performance and characteristics can be used to store resource inventory information and activity order data respectively.

[0106] The memory database cache includes a first memory database and a second memory database; wherein, the first memory database should have the characteristics of high data storage and read / write performance, and the second memory database should have the characteristics of easy maintenance, simple structure, and approximation of a relational database.

[0107] In another embodiment of the invention, the first in-memory database includes Redis; the second in-memory database includes MongoDB. The active order data is persisted in MongoDB, i.e., snapshots of the dataset in MongoDB memory are written to disk at specified time intervals.

[0108] Before generating the target activity page based on the activity configuration information, the method further includes:

[0109] Step 1034: Obtain the target inventory information and the activity order data from the relational database.

[0110] Step 1035: Store the target inventory information in the first memory database and store the active order data in the second memory database.

[0111] Step 104: When the resource ordering request is verified, update the target activity data.

[0112] In one embodiment of the present invention, the resource ordering request further includes a target resource type and a target resource quantity; the target inventory information further includes multiple optional resource types and the optional resource quantity corresponding to each optional resource type. The target resource type can be a virtual or physical item such as data vouchers, phone credit vouchers, or small home appliances.

[0113] Step 104 further includes: Step 1041: Matching the target resource type with the optional resource type, and updating the number of optional resources corresponding to the matched optional resource type according to the target resource data; the update operation is atomic.

[0114] In one embodiment of the present invention, the update operation includes deducting the number of optional resources according to the number of target resources.

[0115] In another embodiment of the present invention, when the activity type corresponding to the target activity identifier is a lottery activity, the resource ordering request may further include the target winning probability, and the target inventory information may further include the optional resource level corresponding to each of the optional resource types, and the winning probability range corresponding to each optional resource level.

[0116] When a resource ordering request is received, the target winning probability is matched with each of the resource probability intervals, and the available resource level corresponding to the matched resource probability interval is obtained as the target resource level. When the number of available resources corresponding to the target resource level is zero, the number of available resources corresponding to the next lower level can be queried sequentially, or the number of available resources can be queried in a loop starting from the smallest available resource level. If the number of available resources for all levels is empty, the user is notified that the lottery activity has ended.

[0117] Step 1042: Generate target order data corresponding to the target user identifier; the target order data includes the target order identifier; the target order identifier is idempotent.

[0118] By sending the idempotent target order identifier to the relevant backend system for resource allocation, such as the resource management system, the resource allocation status corresponding to each order is easy to verify and trace, thereby improving the accuracy of resource allocation and thus improving the accuracy of processing high-concurrency data requests.

[0119] Step 1043: Update the activity order data according to the target order data, and send the target order data to the target resource management system corresponding to the target resource type through an asynchronous queue.

[0120] The target resource management system is used to manage the lifecycle of resources, such as the generation, storage, and distribution of resources corresponding to the target resource type. For example, when the target resource type is traffic vouchers, the target resource management system can be a communication network billing system.

[0121] Considering that the notification method of asynchronous queues may result in the failure of resource allocation due to network or other reasons, in another embodiment of the present invention, after notifying the target resource management system through asynchronous queues, resource auditing can also be performed to ensure that resources are allocated to users 100% and improve user experience.

[0122] The resource audit process may include at least the following: obtaining asynchronous processing results, initiating audit reconciliation through a scheduled task, verifying whether the target order identifier is consistent between the target resource management system and the current high-concurrency processing system, and if they are inconsistent or the processing result returned by the target resource management system is a failure, then sending the resource allocation request to the target resource management system again through an asynchronous queue, wherein the resource allocation request includes the target order identifier.

[0123] Unlike existing technologies that use traditional databases and suffer from low processing efficiency for high-concurrency data requests, the high-concurrency data request processing method provided in this invention pre-retrieves activity configuration information and target activity data from the second and third caches into the front-end cache closest to the user, namely the first cache. Furthermore, based on the data's usage frequency and importance, and considering the read efficiency and storage performance of different types of caches, the activity configuration information is stored in the second cache, including a virtual machine cache; the target activity data is stored in the third cache, including an in-memory database cache. Therefore, when a resource subscription request is received, it can be directly processed and returned from the front-end cache. This method improves the processing efficiency of high-concurrency data requests, thereby enhancing the user experience of marketing activities in high-concurrency environments.

[0124] Figure 2 A schematic diagram of the structure of a high-concurrency data request processing device provided in an embodiment of the present invention is shown. Figure 2 As shown, the device 200 includes: a response module 201, an acquisition module 202, a verification module 203, and an update module 204.

[0125] The response module 201 is configured to respond to a resource ordering request on a target activity page; wherein the target activity page is pre-generated based on activity configuration information in a first cache; the activity configuration information is synchronized from a second cache to the first cache; the first cache includes a front-end cache; the second cache includes a virtual machine cache; and the resource ordering request includes a target user identifier and a target activity identifier.

[0126] The acquisition module 202 is used to acquire target activity data corresponding to the target activity identifier from the first cache; the target activity data is synchronized from the third cache to the first cache; the third cache includes an in-memory database cache;

[0127] Verification module 203 is used to verify the resource ordering request based on the target activity data and the target user identifier;

[0128] The update module 204 is used to update the target activity data when the resource ordering request is verified.

[0129] In an alternative embodiment, the response module 201 is further configured to: respond to an activity page access request, the activity page access request including the target activity identifier;

[0130] Obtain the activity configuration information corresponding to the target activity identifier from the first cache;

[0131] The activity configuration information is verified;

[0132] When the activity configuration information is determined to be valid, the target activity page is generated based on the activity configuration information.

[0133] In one alternative approach, the front-end cache includes a web cache, and the virtual machine cache includes a JVM cache; the response module 201 is further configured to:

[0134] Retrieve the activity configuration information from the relational database;

[0135] The activity configuration information is stored in the JVM cache;

[0136] When the activity page access request is received, the activity configuration information is synchronized from the JVM cache to the Web cache.

[0137] In one alternative approach, the activity page access request includes the access time; the activity configuration information includes the activity validity period; the target activity data includes target inventory information; and the target inventory information is periodically synchronized from the third cache to the Web cache.

[0138] The response module 201 is also used to: verify the target inventory information;

[0139] When the target inventory information meets the preset inventory conditions, the step of verifying the activity configuration information is executed; wherein, the step of verifying the activity configuration information includes: when it is determined that the access time matches the activity validity time, the activity configuration information is determined to be valid.

[0140] In an optional embodiment, the target activity data further includes activity order data; the activity order data includes multiple participation opportunity identifiers and historical order information associated with each participation opportunity identifier; the historical order information includes historical order identifiers and associated user identifiers associated with the historical order identifiers; the verification module 203 is further configured to:

[0141] In the activity order data, the target user identifier is matched with the associated user identifier;

[0142] The target number of opportunities is determined based on the historical order identifier associated with the matched associated user identifier and the participation opportunity identifier;

[0143] When the number of target opportunities is greater than zero, the resource ordering request is deemed to have passed verification.

[0144] In one alternative approach, the in-memory database cache includes a first in-memory database and a second in-memory database; the first in-memory database includes Redis; and the second in-memory database includes MongoDB.

[0145] The acquisition module 202 is further configured to: acquire the target inventory information and the activity order data from the relational database;

[0146] The target inventory information is stored in the first memory database, and the active order data is stored in the second memory database.

[0147] In an optional manner, the resource ordering request further includes a target resource type and a target resource quantity; the target inventory information further includes multiple optional resource types and the optional resource quantity corresponding to each optional resource type; the update module 204 is further configured to:

[0148] The target resource type is matched with the optional resource type, and the number of optional resources corresponding to the matched optional resource type is updated according to the target resource data; the update operation is atomic.

[0149] Generate target order data corresponding to the target user identifier; the target order data includes a target order identifier; the target order identifier is idempotent.

[0150] The activity order data is updated based on the target order data, and the target order data is sent to the target resource management system corresponding to the target resource type via an asynchronous queue.

[0151] Unlike existing technologies that use traditional databases and suffer from low processing efficiency for high-concurrency data requests, the high-concurrency data request processing device provided in this embodiment of the invention obtains activity configuration information and target activity data from the second and third caches in advance and stores them in the front-end cache closest to the user, namely the first cache. Furthermore, based on the data's usage frequency and importance, and considering the read efficiency and storage performance of different types of caches, the activity configuration information is stored in the second cache, including a virtual machine cache; and the target activity data is stored in the third cache, including a memory database cache. Therefore, when a resource subscription request is received, it can be directly processed and returned from the front-end cache. Thus, the high-concurrency data request processing device provided in this embodiment of the invention improves the processing efficiency of high-concurrency data requests, thereby enhancing the user experience of marketing activities in high-concurrency environments.

[0152] Figure 3 The diagram shows a structural schematic of a high-concurrency data request processing device provided in an embodiment of the present invention. The specific implementation of the high-concurrency data request processing device is not limited by the specific embodiments of the present invention.

[0153] like Figure 3 As shown, the processing device for the high-concurrency data request may include: a processor 302, a communications interface 304, a memory 306, and a communications bus 308.

[0154] The processor 302, communication interface 304, and memory 306 communicate with each other via communication bus 308. Communication interface 304 is used to communicate with other network elements such as clients or other servers. The processor 302 executes program 310, specifically performing the relevant steps in the above-described embodiment of the processing method for high-concurrency data requests.

[0155] Specifically, program 310 may include program code, which includes computer-executable instructions.

[0156] Processor 302 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present invention. The high-concurrency data request processing device includes one or more processors, which may be processors of the same type, such as one or more CPUs; or processors of different types, such as one or more CPUs and one or more ASICs.

[0157] Memory 306 is used to store program 310. Memory 306 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0158] Specifically, program 310 can be called by processor 302 to cause the processing device for high-concurrency data requests to perform the following operations:

[0159] In response to a resource ordering request on a target activity page; wherein the target activity page is pre-generated based on activity configuration information in a first cache; the activity configuration information is synchronized from a second cache to the first cache; the first cache includes a front-end cache; the second cache includes a virtual machine cache; the resource ordering request includes a target user identifier and a target activity identifier;

[0160] The target activity data corresponding to the target activity identifier is obtained from the first cache; the target activity data is synchronized from the third cache to the first cache; the third cache includes an in-memory database cache;

[0161] The resource ordering request is verified based on the target activity data and the target user identifier;

[0162] When the resource ordering request is verified, the target activity data is updated.

[0163] In an alternative approach, the program 310 is invoked by the processor 302 to cause the processing device handling high-concurrency data requests to perform the following operations:

[0164] In response to an activity page access request, the activity page access request includes the target activity identifier;

[0165] Obtain the activity configuration information corresponding to the target activity identifier from the first cache;

[0166] The activity configuration information is verified;

[0167] When the activity configuration information is determined to be valid, the target activity page is generated based on the activity configuration information.

[0168] In one alternative approach, the front-end cache includes a web cache, and the virtual machine cache includes a JVM cache; the program 310 is invoked by the processor 302 to cause the processing device for high-concurrency data requests to perform the following operations:

[0169] Retrieve the activity configuration information from the relational database;

[0170] The activity configuration information is stored in the JVM cache;

[0171] When the activity page access request is received, the activity configuration information is synchronized from the JVM cache to the Web cache.

[0172] In one alternative approach, the activity page access request includes the access time; the activity configuration information includes the activity validity period; the target activity data includes target inventory information; the target inventory information is periodically synchronized from the third cache to the Web cache; the program 310 is invoked by the processor 302 to cause the high-concurrency data request processing device to perform the following operations:

[0173] Verify the target inventory information;

[0174] When the target inventory information meets the preset inventory conditions, the step of verifying the activity configuration information is executed; wherein, the step of verifying the activity configuration information includes: when it is determined that the access time matches the activity validity time, the activity configuration information is determined to be valid.

[0175] In an optional manner, the target activity data further includes activity order data; the activity order data includes multiple participation opportunity identifiers and historical order information associated with each participation opportunity identifier; the historical order information includes historical order identifiers and associated user identifiers associated with the historical order identifiers; the program 310 is invoked by the processor 302 to cause the processing device for high-concurrency data requests to perform the following operations:

[0176] In the activity order data, the target user identifier is matched with the associated user identifier;

[0177] The target number of opportunities is determined based on the historical order identifier associated with the matched associated user identifier and the participation opportunity identifier;

[0178] When the number of target opportunities is greater than zero, the resource ordering request is deemed to have passed verification.

[0179] In one alternative approach, the in-memory database cache includes a first in-memory database and a second in-memory database; the first in-memory database includes Redis; the second in-memory database includes MongoDB; the program 310 is invoked by the processor 302 to cause the processing device for high-concurrency data requests to perform the following operations:

[0180] Retrieve the target inventory information and the activity order data from the relational database;

[0181] The target inventory information is stored in the first memory database, and the active order data is stored in the second memory database.

[0182] In one alternative approach, the resource ordering request further includes a target resource type and a target resource quantity; the target inventory information further includes multiple optional resource types and the optional resource quantity corresponding to each optional resource type;

[0183] The program 310 is invoked by the processor 302 to cause the processing device for high-concurrency data requests to perform the following operations:

[0184] The target resource type is matched with the optional resource type, and the number of optional resources corresponding to the matched optional resource type is updated according to the target resource data; the update operation is atomic.

[0185] Generate target order data corresponding to the target user identifier; the target order data includes a target order identifier; the target order identifier is idempotent.

[0186] The activity order data is updated based on the target order data, and the target order data is sent to the target resource management system corresponding to the target resource type via an asynchronous queue.

[0187] Unlike existing technologies that use traditional databases and suffer from low processing efficiency for high-concurrency data requests, the high-concurrency data request processing device provided in this embodiment of the invention obtains activity configuration information and target activity data from the second and third caches in advance and stores them in the front-end cache closest to the user, namely the first cache. Furthermore, based on the data's usage frequency and importance, and considering the read efficiency and storage performance of different types of caches, the activity configuration information is stored in the second cache, including a virtual machine cache; and the target activity data is stored in the third cache, including a memory database cache. Therefore, when a resource subscription request is received, it can be directly processed and returned from the front-end cache. Thus, the high-concurrency data request processing device provided in this embodiment of the invention improves the processing efficiency of high-concurrency data requests, thereby enhancing the user experience of marketing activities in high-concurrency environments.

[0188] This invention provides a computer-readable storage medium storing at least one executable instruction. When the executable instruction is executed on a high-concurrency data request processing device, the high-concurrency data request processing device performs the high-concurrency data request processing method described in any of the above method embodiments.

[0189] Specifically, the executable instructions can be used to cause the processing device for high-concurrency data requests to perform the following operations:

[0190] In response to a resource ordering request on a target activity page; wherein the target activity page is pre-generated based on activity configuration information in a first cache; the activity configuration information is synchronized from a second cache to the first cache; the first cache includes a front-end cache; the second cache includes a virtual machine cache; the resource ordering request includes a target user identifier and a target activity identifier;

[0191] The target activity data corresponding to the target activity identifier is obtained from the first cache; the target activity data is synchronized from the third cache to the first cache; the third cache includes an in-memory database cache;

[0192] The resource ordering request is verified based on the target activity data and the target user identifier;

[0193] When the resource ordering request is verified, the target activity data is updated.

[0194] In one alternative approach, the executable instructions cause the processing device for the high-concurrency data request to perform the following operations:

[0195] In response to an activity page access request, the activity page access request includes the target activity identifier;

[0196] Obtain the activity configuration information corresponding to the target activity identifier from the first cache;

[0197] The activity configuration information is verified;

[0198] When the activity configuration information is determined to be valid, the target activity page is generated based on the activity configuration information.

[0199] In one alternative approach, the front-end cache includes a web cache, and the virtual machine cache includes a JVM cache; the executable instructions cause the processing device for the high-concurrency data requests to perform the following operations:

[0200] Retrieve the activity configuration information from the relational database;

[0201] The activity configuration information is stored in the JVM cache;

[0202] When the activity page access request is received, the activity configuration information is synchronized from the JVM cache to the Web cache.

[0203] In one alternative approach, the activity page access request includes the access time; the activity configuration information includes the activity validity period; the target activity data includes target inventory information; the target inventory information is periodically synchronized from the third cache to the Web cache; and the executable instruction causes the processing device for the high-concurrency data request to perform the following operations:

[0204] Verify the target inventory information;

[0205] When the target inventory information meets the preset inventory conditions, the step of verifying the activity configuration information is executed; wherein, the step of verifying the activity configuration information includes: when it is determined that the access time matches the activity validity time, the activity configuration information is determined to be valid.

[0206] In an optional manner, the target activity data further includes activity order data; the activity order data includes multiple participation opportunity identifiers and historical order information associated with each participation opportunity identifier; the historical order information includes historical order identifiers and associated user identifiers associated with the historical order identifiers; the executable instruction causes the processing device for the high-concurrency data request to perform the following operations:

[0207] In the activity order data, the target user identifier is matched with the associated user identifier;

[0208] The target number of opportunities is determined based on the historical order identifier associated with the matched associated user identifier and the participation opportunity identifier;

[0209] When the number of target opportunities is greater than zero, the resource ordering request is deemed to have passed verification.

[0210] In one alternative approach, the in-memory database cache includes a first in-memory database and a second in-memory database; the first in-memory database includes Redis; the second in-memory database includes MongoDB; and the executable instructions cause the processing device for the high-concurrency data requests to perform the following operations:

[0211] Retrieve the target inventory information and the activity order data from the relational database;

[0212] The target inventory information is stored in the first memory database, and the active order data is stored in the second memory database.

[0213] In one alternative approach, the resource ordering request further includes a target resource type and a target resource quantity; the target inventory information further includes multiple optional resource types and the optional resource quantity corresponding to each optional resource type; the executable instruction causes the processing device for the high-concurrency data request to perform the following operations:

[0214] The target resource type is matched with the optional resource type, and the number of optional resources corresponding to the matched optional resource type is updated according to the target resource data; the update operation is atomic.

[0215] Generate target order data corresponding to the target user identifier; the target order data includes a target order identifier; the target order identifier is idempotent.

[0216] The activity order data is updated based on the target order data, and the target order data is sent to the target resource management system corresponding to the target resource type via an asynchronous queue.

[0217] Unlike existing technologies that use traditional databases and suffer from low processing efficiency for high-concurrency data requests, the computer storage medium provided in this embodiment of the invention obtains activity configuration information and target activity data from the second and third caches and stores them in the front-end cache (the first cache) closest to the user. Furthermore, based on the data's usage frequency and importance, and considering the read efficiency and storage performance of different types of caches, the activity configuration information is stored in the second cache, including a virtual machine cache; and the target activity data is stored in the third cache, including a memory database cache. Therefore, when a resource subscription request is received, it can be directly processed and returned from the front-end cache. This computer storage medium provided in this embodiment of the invention improves the processing efficiency of high-concurrency data requests, thereby enhancing the user experience of marketing activities in high-concurrency environments.

[0218] This invention provides a high-concurrency data request processing apparatus for executing the above-described high-concurrency data request processing method.

[0219] This invention provides a computer program that can be invoked by a processor to cause a high-concurrency data request processing device to execute the high-concurrency data request processing method in any of the above method embodiments.

[0220] This invention provides a computer program product, which includes a computer program stored on a computer-readable storage medium. The computer program includes program instructions that, when executed on a computer, cause the computer to perform the high-concurrency data request processing method described in any of the above method embodiments.

[0221] The algorithms or displays provided herein are not inherently related to any particular computer, virtual system, or other device. Various general-purpose systems can also be used in conjunction with the teachings herein. The required structure for constructing such systems is apparent from the above description. Furthermore, the embodiments of the present invention are not directed to any particular programming language. It should be understood that the content of the invention described herein can be implemented using various programming languages, and the above description of specific languages ​​is for the purpose of disclosing the best mode of implementation of the invention.

[0222] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of the invention may be practiced without these specific details. In some instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification.

[0223] Similarly, it should be understood that, in order to streamline the invention and aid in understanding one or more of the various aspects of the invention, features of the embodiments of the invention are sometimes grouped together in a single embodiment, figure, or description thereof in the above description of exemplary embodiments of the invention. However, this disclosure should not be construed as reflecting an intention that the claimed invention requires more features than are expressly recited in each claim.

[0224] Those skilled in the art will understand that modules in the device of the embodiments can be adaptively changed and placed in one or more devices different from that embodiment. Modules, units, or components in the embodiments can be combined into a single module, unit, or component, and can be divided into multiple sub-modules, sub-units, or sub-components. Except where at least some of such features and / or processes or units are mutually exclusive, any combination can be used to combine all features disclosed in this specification (including the accompanying claims, abstract, and drawings) and all processes or units of any method or device so disclosed. Unless expressly stated otherwise, each feature disclosed in this specification (including the accompanying claims, abstract, and drawings) may be replaced by an alternative feature that serves the same, equivalent, or similar purpose.

[0225] It should be noted that the above embodiments are illustrative of the invention and not restrictive, and that those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The invention can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names. The steps in the above embodiments, unless otherwise specified, should not be construed as limiting the order of execution.

Claims

1. A method for processing high-concurrency data requests, characterized in that, The method includes: In response to an activity page access request, the activity page access request includes a target activity identifier; retrieve the activity configuration information corresponding to the target activity identifier from a first cache; verify the activity configuration information; when it is determined that the activity configuration information is valid, generate the target activity page according to the activity configuration information; In response to a resource ordering request on a target activity page; wherein the target activity page is pre-generated based on activity configuration information in a first cache; the activity configuration information is synchronized from a second cache to the first cache; the first cache includes a front-end cache; the second cache includes a virtual machine cache; the resource ordering request includes a target user identifier and a target activity identifier; The target activity data corresponding to the target activity identifier is obtained from the first cache; the target activity data is synchronized from the third cache to the first cache; the third cache includes an in-memory database cache; The resource ordering request is verified based on the target activity data and the target user identifier; When the resource ordering request is verified, the target activity data is updated.

2. The method according to claim 1, characterized in that, The front-end cache includes a web cache, and the virtual machine cache includes a JVM cache; before generating the target activity page based on the activity configuration information, the process includes: Retrieve the activity configuration information from the relational database; The activity configuration information is stored in the JVM cache; When the activity page access request is received, the activity configuration information is synchronized from the JVM cache to the Web cache.

3. The method according to claim 2, characterized in that, The activity page access request includes the access time; the activity configuration information includes the activity validity period; the target activity data includes target inventory information; The target inventory information is periodically synchronized from the third cache to the Web cache; Before verifying the activity configuration information, the method further includes: Verify the target inventory information; When the target inventory information meets the preset inventory conditions, the step of verifying the activity configuration information is executed; wherein, the step of verifying the activity configuration information includes: when it is determined that the access time matches the activity validity time, the activity configuration information is determined to be valid.

4. The method according to claim 2, characterized in that, The target activity data also includes activity order data; the activity order data includes multiple participation opportunity identifiers and historical order information associated with each participation opportunity identifier; the historical order information includes historical order identifiers and associated user identifiers associated with the historical order identifiers; the step of verifying the resource order request based on the target activity data and the target user identifier includes: In the activity order data, the target user identifier is matched with the associated user identifier; The target number of opportunities is determined based on the historical order identifier associated with the matched associated user identifier and the participation opportunity identifier; When the number of target opportunities is greater than zero, the resource ordering request is deemed to have passed verification.

5. The method according to claim 4, characterized in that, The in-memory database cache includes a first in-memory database and a second in-memory database; the first in-memory database includes Redis; the second in-memory database includes MongoDB; Before generating the target activity page based on the activity configuration information, the method further includes: Retrieve the target inventory information and the activity order data from the relational database; The target inventory information is stored in the first memory database, and the active order data is stored in the second memory database.

6. The method according to claim 4, characterized in that, The resource ordering request also includes a target resource type and a target resource quantity; the target inventory information also includes multiple optional resource types and the optional resource quantity corresponding to each optional resource type; updating the target activity data includes: The target resource type is matched with the optional resource type, and the number of optional resources corresponding to the matched optional resource type is updated according to the target resource data; the update operation is atomic. Generate target order data corresponding to the target user identifier; the target order data includes a target order identifier; the target order identifier is idempotent. The activity order data is updated based on the target order data, and the target order data is sent to the target resource management system corresponding to the target resource type via an asynchronous queue.

7. A processing apparatus for high-concurrency data requests, characterized in that, The device includes: A response module is configured to respond to an activity page access request, the activity page access request including a target activity identifier; retrieve activity configuration information corresponding to the target activity identifier from a first cache; validate the activity configuration information; when the activity configuration information is determined to be valid, generate a target activity page based on the activity configuration information; and respond to a resource ordering request on the target activity page; wherein the target activity page is pre-generated based on the activity configuration information in the first cache; the activity configuration information is synchronized from a second cache to the first cache; the first cache includes a front-end cache; the second cache includes a virtual machine cache; and the resource ordering request includes a target user identifier and a target activity identifier. The acquisition module is configured to acquire target activity data corresponding to the target activity identifier from the first cache; the target activity data is synchronized from the third cache to the first cache; the third cache includes an in-memory database cache; The verification module is used to verify the resource ordering request based on the target activity data and the target user identifier; The update module is used to update the target activity data when the resource ordering request is verified.

8. A processing device for high-concurrency data requests, characterized in that, include: The processor, memory, communication interface, and communication bus are provided, wherein the processor, memory, and communication interface communicate with each other via the communication bus. The memory is used to store at least one executable instruction that causes the processor to perform the operation of the high-concurrency data request processing method as described in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The storage medium stores at least one executable instruction, which, when executed on a high-concurrency data request processing device, causes the data processing device in a high-concurrency scenario to perform the operation of the high-concurrency data request processing method as described in any one of claims 1-6.

Images