A data processing method and related device

Abstract

The embodiment of the present application discloses a data processing method and related devices. For the scenario of high concurrency in acquiring target objects, if an object acquisition request for the target object is acquired, the object acquisition request is written into a message queue in the cache space. When it can be processed, the object acquisition request is taken out from the message queue, thereby realizing asynchronous processing of the object acquisition request. Thereby, the effect of shaving peaks and filling valleys is achieved, and the impact on the database is reduced. During peak periods, in addition to the high concurrency of object acquisition requests, a large number of content query requests will also appear in association. By caching the processing results for the object acquisition requests in the cache space, it is possible to search directly in the cache space based on the content query results. There is no need for additional data interaction with the database that stores the processing results, which reduces the amount of access to the database, thereby effectively protecting the database during peak periods and improving the query response efficiency.

Description

Technical Field

[0001] The present application relates to the field of data processing, and in particular to a data processing method and related devices. Background Art

[0002] With the development of Internet technology, users can easily obtain the objects they need through the Internet platform, which can be products, virtual items, services, etc.

[0003] In some scenarios, a large number of users have strong demand for certain objects, such as when a specific public environmental issue occurs or a particular object is very popular. In this case, the internet platform that provides such objects will receive a large number of user requests for these objects in a short period of time. This high concurrency can easily cause the internet platform's servers to crash.

[0004] It can be seen that how to deal with high concurrency is an urgent problem that Internet platforms need to solve. Summary of the Invention

[0005] In order to solve the above technical problems, the present application provides a data processing method and related devices for coping with high concurrency situations on Internet platforms.

[0006] The embodiments of this application disclose the following technical solutions:

[0007] In one aspect, an embodiment of the present application provides a data processing method, the method comprising:

[0008] Get an object acquisition request for the target object;

[0009] Writing the object acquisition request into a message queue in the cache space;

[0010] Taking out the object acquisition request from the message queue and performing corresponding processing, and caching the obtained processing result in the cache space;

[0011] According to a content query request for the target object, a target processing result is queried in the cache space.

[0012] On the other hand, an embodiment of the present application provides a data processing device, the device including an acquisition unit, a writing unit, a first processing unit, and a second processing unit:

[0013] The acquisition unit is configured to acquire an object acquisition request for a target object;

[0014] The writing unit is used to write the object acquisition request into the message queue in the cache space;

[0015] The first processing unit is configured to retrieve the object acquisition request from the message queue, perform corresponding processing on it, and cache the obtained processing result in the cache space;

[0016] The second processing unit is configured to query the cache space for a target processing result according to a content query request for the target object.

[0017] On the other hand, an embodiment of the present application provides a device for data processing, the device including a processor and a memory:

[0018] The memory is used to store program code and transmit the program code to the processor;

[0019] The processor is configured to execute the method described above according to the instructions in the program code.

[0020] On the other hand, an embodiment of the present application provides a computer-readable storage medium, which is used to store a computer program, and the computer program is used to execute the method described in the above aspects.

[0021] In another aspect, embodiments of the present application provide a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the method described in the above aspects.

[0022] As can be seen from the above technical solution, in scenarios where there is high concurrency in acquiring a target object, if an object acquisition request for the target object is received, the decision to provide the target object is not performed synchronously. Instead, the object acquisition request is written to a message queue in the cache. The object acquisition request is then removed from the message queue when it can be processed, thereby achieving asynchronous processing of the object acquisition request. This asynchronous processing mechanism can thus achieve peak load shaving even during peak periods of receiving object acquisition requests, reducing the impact on the database. Furthermore, even if the number of object acquisition requests received decreases sharply after the peak period, the remaining object acquisition requests in the message queue can continue to be processed, achieving a valley-filling effect. During peak periods, in addition to the high concurrency of object acquisition requests, a large number of content query requests are also associated. By caching the processing results of the object acquisition requests in the cache, content-based query results can be directly searched in the cache. This eliminates the need for additional data interaction with the database that stores the processing results, reducing database access volume, effectively protecting the database during peak periods, and improving query response efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0024] Figure 1 A schematic diagram of a data processing method according to an embodiment of the present invention;

[0025] Figure 2 A flowchart of a data processing method provided in an embodiment of the present application;

[0026] Figure 3 A server layered architecture diagram provided for an embodiment of the present application;

[0027] Figure 4 A schematic diagram of a first mode provided in an embodiment of the present application;

[0028] Figure 5 A flowchart of a method of a first mode provided in an embodiment of the present application;

[0029] Figure 6 A flowchart of a method of a first mode provided in an embodiment of the present application;

[0030] Figure 7 A schematic diagram of a lottery method provided in an embodiment of the present application;

[0031] Figure 8 A schematic diagram of a lottery method provided in an embodiment of the present application;

[0032] Figure 9 A schematic diagram of a lottery method provided in an embodiment of the present application;

[0033] Figure 10 A schematic diagram of a switching mode provided in an embodiment of the present application;

[0034] Figure 11 A flowchart of purchasing masks through a mini program provided in an embodiment of the present application;

[0035] Figure 12 A schematic diagram of a mini-program page provided in an embodiment of the present application;

[0036] Figure 13 A schematic diagram of a mini-program page provided in an embodiment of the present application;

[0037] Figure 14 A flowchart of a data processing method provided in an embodiment of the present application;

[0038] Figure 15 A schematic diagram of a mini-program page provided in an embodiment of the present application;

[0039] Figure 16 A schematic diagram of a mini-program page provided in an embodiment of the present application;

[0040] Figure 17 A schematic diagram of a mini-program page provided in an embodiment of the present application;

[0041] Figure 18 A schematic diagram of a mini-program page provided in an embodiment of the present application;

[0042] Figure 19 A schematic diagram of a mini-program page provided in an embodiment of the present application;

[0043] Figure 20 A schematic diagram of a mini-program page provided in an embodiment of the present application;

[0044] Figure 21 A schematic diagram of a mini-program page provided in an embodiment of the present application;

[0045] Figure 22 A schematic diagram of a mini-program page provided in an embodiment of the present application;

[0046] Figure 23 A schematic diagram of a process flow of a rush purchase mode provided in an embodiment of the present application;

[0047] Figure 24 A flowchart of a lottery mode provided in an embodiment of the present application;

[0048] Figure 25 A schematic diagram of a data processing device provided in an embodiment of the present application;

[0049] Figure 26 A schematic diagram of the structure of the server provided in the embodiment of the present application;

[0050] Figure 27 A schematic diagram of the structure of the terminal device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0051] The embodiments of the present application are described below with reference to the accompanying drawings.

[0052] The development of internet technology has brought convenience to people's lives. Users can access the objects they need through internet platforms, such as clothing, gaming equipment, and article editing services. However, in high-concurrency scenarios such as the rush to buy masks, flash sales of popular products, and ticket grabs during the epidemic, the corresponding internet platforms not only receive a large number of user object retrieval requests for the target objects within a short period of time, but users also visit the corresponding internet platforms multiple times in a short period of time to obtain content query results related to the target objects, resulting in multiple causes of high concurrency.

[0053] In order to solve the above technical problems, the present application provides a data processing method, which can not only asynchronously process a large number of user acquisition requests for target objects based on a message queue, but also cache the corresponding processing results in a cache space so that users can directly obtain the corresponding processing results from the cache space, reducing the number of database accesses, thereby coping with target object acquisition scenarios with diverse reasons for high concurrency.

[0054] The data processing method provided in the embodiments of the present application can be applied to a processing device with data processing capabilities, for example, a terminal device or a server with data processing functions. The method can be executed independently by a terminal device or a server, or it can be applied to a network scenario where a terminal device and a server communicate, and executed by the terminal device and the server in cooperation. Among them, the terminal device can be a smart phone, a laptop computer, a desktop computer, a personal digital assistant (PDA), a tablet computer, and other devices. The server can be understood as an application server or a web server. In actual deployment, the server can be an independent physical server, a server cluster or a distributed system composed of multiple physical servers, or a cloud server that provides cloud computing services. The terminal and the server can be directly or indirectly connected through wired or wireless communication, and this application does not limit this.

[0055] In addition, the technical solutions provided by this application also involve the field of cloud technology, such as cloud computing, databases and other fields.

[0056] Cloud computing refers to the delivery and usage model of IT infrastructure, enabling on-demand, scalable access to required resources over the internet. In a broader sense, cloud computing refers to the delivery and usage model of services, enabling on-demand, scalable access to required services over the internet. These services can be IT-related, software-related, internet-related, or other services. Cloud computing is the product of the convergence of traditional computer and network technologies, including grid computing, distributed computing, parallel computing, utility computing, network storage technologies, virtualization, and load balancing.

[0057] Cloud computing has rapidly grown, driven by the internet, real-time data streams, the diversification of connected devices, and the growing demand for search services, social networks, mobile commerce, and open collaboration. Unlike previous parallel and distributed computing approaches, the emergence of cloud computing will fundamentally revolutionize the entire internet and enterprise management model.

[0058] A database, in short, can be thought of as a digital filing cabinet—a place where electronic files are stored, allowing users to add, query, update, and delete data. A database is a collection of data stored in a specific way, shared by multiple users, with minimal redundancy, and independent of applications.

[0059] A database management system (DBMS) is a computer software system designed for managing databases, typically providing basic functions such as storage, retrieval, security, and backup. DBMSs can be categorized by the database model they support, such as relational or XML (Extensible Markup Language); by the type of computer they support, such as server clusters or mobile phones; by the query language used, such as SQL (Structured Query Language) or XQuery; by performance priorities, such as maximum scale or maximum speed; or by other classification methods. Regardless of the classification method used, some DBMSs can cross categories, for example, supporting multiple query languages simultaneously.

[0060] In the embodiment of the present application, object acquisition requests and content query requests are acquired and processed through cloud computing technology, and the corresponding processing results are stored in a database.

[0061] In order to facilitate understanding of the technical solution of the present application, the data processing method provided in the embodiment of the present application will be introduced below in combination with actual application scenarios.

[0062] See also Figure 1 , Figure 1 This is a schematic diagram of a scenario for a data processing method provided in an embodiment of the present application. This practical application scenario can be a scenario where a large number of users rush to buy masks via electronic devices. The electronic devices can be smartphones, tablets, laptops, desktop computers, and other devices. In this scenario, the processing device is server 110, which can be a Content Delivery Network (CDN) server.

[0063] The server 110 includes at least a front-end service process 111, a cache space 112 configured with a message queue, a back-end service process 113, and a database 114. Among them, the front-end service process 111 is used to interact with electronic devices, the back-end service process 113 is used to interact with the database 114, and the cache space 112 is used to connect the front-end service process 111 and the back-end service process 113. For example, in the embodiment of the present application, two users are used to represent the scenario of a large number of users rushing to buy masks. Among them, user A rushes to buy masks through smartphone 121, and user B rushes to buy masks through smartphone 122.

[0064] When the front-end service process 111 of the server 110 receives the object acquisition request for the mask sent by the smartphone 121 and the smartphone 122, it will not process the object acquisition request immediately, but will write the object acquisition request I of user A and the object acquisition request II of user B into the message queue in the cache space 112 respectively. The back-end service process 113 can extract the object acquisition request I and the object acquisition request II from the message queue according to a certain mechanism, such as a first-in-first-out mechanism, and process the object acquisition request I and the object acquisition request II respectively. This allows the back-end service process 113 to process the object acquisition requests sent by different users through electronic devices in batches within its capabilities, that is, to asynchronously process a large number of object acquisition requests.

[0065] Thus, during the peak period of object acquisition requests, the asynchronous processing mechanism can achieve a peak-shaving effect, and during the subsequent valley period of object acquisition requests, the object acquisition requests that were not processed during the peak period can continue to be processed, achieving a valley-filling effect, thereby reducing the processing pressure of the server 110 and improving the response speed of the server 110. At the same time, the cache space 112 can also decouple the front-end service process 111 and the back-end service process 113, facilitating the independent maintenance of the front-end service process 111 and the back-end service process 113.

[0066] Not only do users send object acquisition requests for masks to the server 110 through electronic devices, they also send content query requests for masks to the server 110 through electronic devices, such as querying whether the masks were successfully purchased. The same user will access the server 110 multiple times through electronic devices in a short period of time. When the number of users increases sharply, that is, when a large number of electronic devices access the server 110 multiple times in a short period of time, the number of visits to the server 110 will increase exponentially in a short period of time, causing the server 110 to crash. In other words, the reason for high concurrency is not only related to the sharp increase in the number of users, but also related to users accessing the Internet platform multiple times in a short period of time.

[0067] Based on this, the backend service process 113 no longer stores the obtained processing results I and II only in the database 114. Instead, it stores the processing results I and II in the database 114 and caches them in the cache space 112. This allows user B to directly obtain the processing result II in the cache space 112 after sending a content query request for the mask through the smartphone 122, and also returns the corresponding content query response to the smartphone 122. This eliminates the need for additional data interaction with the database 114, reduces the number of accesses to the database 114, and effectively protects the database 114 during the peak period of object acquisition requests, improves query response efficiency, and reduces the burden on the server 110.

[0068] The following combination Figure 1 The application scenario shown introduces the data processing method provided by the embodiment of this application. Figure 2 , which is a flow chart of a data processing method provided by an embodiment of the present application. Figure 2 The method shown includes the following steps:

[0069] S201: Obtain an object acquisition request for a target object.

[0070] Massive user demand for certain objects can lead to a shortage of available resources. When these objects are made available to users via an internet platform, within a short period of time after the platform begins providing them, users will repeatedly send object requests to the platform's servers via their electronic devices, increasing the server's load and even causing server downtime.

[0071] To cope with the above high concurrency scenario, that is, to cope with the scenario where the number of object acquisition requests for the target object increases dramatically in a short period of time, see Figure 3 , this figure is a server layered architecture diagram provided by an embodiment of the present application. The present application designs the server so that it includes at least a front-end service process (preorder services) 111, a cache space 112, a back-end service process (spoorder services) 113 and a database 114. Among them, the front-end service process 111 is used to interact with the client, and the client sends an object acquisition request for the target object to the front-end service process 111 through a gateway (Gateway) 301, such as Rio Gateway. The back-end service process 113 is used to interact with the database 114. The cache space 112 is used to connect the front-end service process 111 and the back-end service process 113, and can adopt technologies such as Remote Dictionary Server (Remote Dictionary Server, Redis) and Kafka. For example, the front-end service process 111 writes operations of the modification class, such as object acquisition requests, into Kafka, and retrieves operations of the query class from Redis. The backend service process 112 retrieves object acquisition requests from Kafka and interacts with Redis. The cache space can decouple the frontend service process and the backend service process, facilitating independent maintenance of the frontend service process and the backend service process. The database 114 is used to store the processing results of the backend service process and can use a MySQL database.

[0072] The front-end service process receives object retrieval requests from clients for target objects. For example, it provides an interface for clients to submit registrations, query results, and other services. The front-end service process does not directly interact with the database, which can avoid database queries in extremely high concurrency situations and reduce the burden on the server.

[0073] S202: Writing the object acquisition request into a message queue in the cache space.

[0074] In the related art, after an object acquisition request for a target object is obtained, the object acquisition request is immediately processed, which causes the speed of obtaining subsequent object acquisition requests to become slower and slower, and even causes the server to crash.

[0075] In order to ensure the response speed of object acquisition requests, in this application, the front-end service process no longer processes the acquired object acquisition requests immediately, but writes the object acquisition requests into a message queue. The message queue is in a cache space and can temporarily store the object acquisition requests from the front-end service process in the form of a message queue, so that the back-end service process can take out the object acquisition requests from the message queue, thereby realizing asynchronous processing of object acquisition requests and ensuring that the server can respond to a large number of object acquisition requests without downtime.

[0076] The message queue can be constructed in the form of middleware in the cache space, or it can be constructed using other algorithm technologies that implement first-in-first-out.

[0077] This application does not specifically limit the number of front-end service processes. Figure 3 In the example, front-end service process 111 uses 16 virtual machines (VMs). To ensure the response speed of object retrieval requests, not only can the number of VMs be increased, but sharding technologies (such as Kafka Partitions and Redis Clusters) can also be used to distribute data across different shards (partitions) to achieve horizontal scaling, thereby allocating different numbers of server resources based on the amount of concurrency.

[0078] S203: Taking out the object acquisition request from the message queue and performing corresponding processing, and caching the obtained processing result in the cache space.

[0079] Regardless of whether the front-end service process is in a peak or low period of object acquisition requests, the back-end service process can retrieve object acquisition requests from the message queue and process them based on its own processing capabilities, thus achieving asynchronous processing. As a result, even during peak periods of object acquisition requests, this asynchronous processing mechanism can achieve a peak-shaving effect. After the peak period, when the number of object acquisition requests decreases sharply, the remaining object acquisition requests in the message queue can continue to be processed, achieving a valley-filling effect, thereby ensuring the server's response speed.

[0080] The backend service process can subscribe to the message queue to retrieve the object acquisition request from the message queue for corresponding processing, and cache the processing results in the cache space so that the frontend service process can directly search in the cache space. This reduces the concurrent query operations of the database and ensures the query speed under high concurrency. The backend service process can also configure the required number of server resources based on the processing time limit requirements of the object acquisition request and the pressure of the database. For example, in Figure 3 In the example, the backend service process 113 uses 4 VMs.

[0081] The backend service process not only caches the obtained processing results in the cache space, but also stores the obtained processing results in the corresponding database. For example, after the backend service process takes out the object acquisition request for the mask from the message queue, it performs corresponding processing and stores the processing results of each order, such as successful or failed mask acquisition, in the database and cached in the cache space. When the user wants to check whether his order is successful, he sends a query request for the mask order to the front-end service process through the client. The front-end service process can directly find the corresponding processing results in the cache space and return it to the corresponding client. In order to increase the speed of writing the processing results to the database, the obtained processing results can be updated in the database corresponding to the target object in the processing order. Since the sequential insertion of the processing results is adopted, the database does not need to modify and delete the processing results while storing the processing results, thereby maximizing the speed of writing the processing results to the database.

[0082] S204: Query the cache space for a target processing result according to the content query request for the target object.

[0083] During the peak period of object acquisition requests, in a short period of time, not only a large number of object acquisition requests for the target object are obtained, but also a large number of content query requests for the target object will appear, such as those used to query whether the object acquisition request is successful, the current processing status, etc., resulting in diversified causes of high concurrency.

[0084] To address the diverse causes of high concurrency, the backend service process retrieves object retrieval requests from the message queue and processes them accordingly, then caches the results in a cache space. This allows the frontend service process to directly query the cache for the corresponding target processing results. This eliminates the need for additional data interaction with the database that stores the processing results, thus avoiding database bottlenecks in extremely high concurrency situations, reducing concurrent database query operations, and ensuring query speed even in high-concurrency states.

[0085] When a content query request for a target object is received, not only can the corresponding target processing result be queried in the cache space based on the content query request, but the corresponding content query response can also be returned based on the target processing result, so that the content query requester can obtain the corresponding content query response result, thereby no longer sending content query requests multiple times, reducing the pressure on the server.

[0086] As can be seen from the above technical solution, in scenarios where there is high concurrency in acquiring a target object, if an object acquisition request for the target object is received, the decision to provide the target object is not performed synchronously. Instead, the object acquisition request is written to a message queue in the cache. The object acquisition request is then removed from the message queue when it can be processed, thereby achieving asynchronous processing of the object acquisition request. This asynchronous processing mechanism can thus achieve peak load shaving even during peak periods of receiving object acquisition requests, reducing the impact on the database. Furthermore, even if the number of object acquisition requests received decreases sharply after the peak period, the remaining object acquisition requests in the message queue can continue to be processed, achieving a valley-filling effect. During peak periods, in addition to the high concurrency of object acquisition requests, a large number of content query requests are also associated. By caching the processing results of the object acquisition requests in the cache, content query results can be directly searched and returned in the cache. This eliminates the need for additional data interaction with the database that stores the processing results, reducing database access volume, effectively protecting the database during peak periods, and improving query response efficiency.

[0087] Since users generally adopt a model of reducing inventory in order when acquiring target objects, a large number of users will continuously send object acquisition requests or content query requests to the server of the Internet platform within a short period of time after the target objects begin to be supplied on the Internet platform, resulting in increased server processing pressure. In order to reduce the burden on the server, the present application also provides a first mode, so that users no longer obtain target objects by competing for hand speed, but obtain target objects by lottery after making an appointment under the supervision of a TV station or a notary office, so that the winning users (i.e., users selected by lottery) send object acquisition requests to the server, reducing the number of object acquisition requests or content query requests sent by users to the server, thereby alleviating the pressure on the server. The following is combined with Figure 4 The first mode is introduced.

[0088] See also Figure 4 , which is a schematic diagram of a first mode provided in an embodiment of the present application.

[0089] The first mode is a reservation mode. Before the lottery, users need to register their identities. For example, Figure 4 Fill in the registration form through the client. It should be noted that other methods can also be used for identity registration. The registration form is sent to the front-end service process in the form of an object acquisition request. After obtaining the filled-in registration form, the front-end service process puts the registration form into the message queue so that the back-end service process can process the registration form. In order to quickly screen out the winning users from a large number of users, this application provides a first mode of quickly screening the winning users by using two lottery draws. The following is combined with Figure 5 Introduce the first lottery, combined with Figure 6 An introduction to the second lottery.

[0090] See also Figure 5 , this figure is a method flow chart of a first mode provided in an embodiment of the present application.

[0091] S501: Allocate a first lottery number value to the user identifier carried in the object acquisition request.

[0092] When the backend service process receives an object acquisition request from the message queue, a first lottery is performed for the user ID carried in the object acquisition request to assign a first lottery value. The object acquisition request carries the user ID of the corresponding user, so that the user to whom the registration form belongs can be determined through the user ID.

[0093] This application does not specifically limit the interval of the first lottery number value. For example, the interval of the first lottery number value can be 0-1023, and any integer between 0-1023 is randomly assigned to each user ID.

[0094] If the number of object acquisition requests is large, the object acquisition requests can also be written into the message queue in the cache space through the front-end service process, so that the back-end service process can take out the object acquisition requests from the message queue when drawing lots, and allocate the first lottery data to the user identifier carried by the object acquisition request.

[0095] S502: Divide the object acquisition request into multiple user sets based on the first lottery value.

[0096] Based on the first lottery number value for each user identifier in the object acquisition request, object acquisition requests with the same first lottery number value are grouped into the same user set. The total number of user sets determined can be equal to the number of integer values in the interval within which the first lottery number value falls. For example, if the interval for the first lottery number value is 0-1023, the object acquisition requests can be grouped into 1024 user sets.

[0097] S503: When determining the actual acquired user of the target object, according to determining the target value from the first lottery value, a first target user set corresponding to the target value is selected from the multiple user sets.

[0098] When determining the actual users to acquire the target object, a lottery (second lottery) is no longer conducted among all users. Instead, a target value is determined from multiple first lottery values. The lottery is then conducted from the user set corresponding to the target value, i.e., the first target user set. This reduces the number of users participating in the lottery and improves the efficiency of the lottery. For example, if 10 million users have registered, and the value interval length of the first lottery is 100, the object acquisition requests from these 10 million users are evenly divided into 100 user sets. When the target value is determined to be 1, the lottery is conducted using the first user set, rather than all users. This reduces the number of users participating in the lottery from 10 million to 100,000, improving the efficiency of the lottery.

[0099] The target object can be a collection of objects of a certain type or a collection of models within that type. For example, the target object can be a mask or an N95 mask within that type.

[0100] The first target user set may be determined not only based on the target value, but also based on conditions such as the store logo, the model of the target object, and whether the user obeys the allocation.

[0101] S504: According to the store ID provided for the target object, determine the allocable value of the target object in the store corresponding to the store ID.

[0102] When an internet platform centrally plans the distribution of all target items, for example, during the epidemic, the internet platform pooled masks from multiple stores and distributed them uniformly. A lottery was then conducted store by store, and the available quantity of target items was determined based on the store ID of the target item, ensuring that the number of target items supplied to users did not exceed the actual inventory of the store.

[0103] S505: Determine, from the first target user set, an actual user who acquires the target object provided by the store according to the assignable value.

[0104] Based on the allocable value, actual acquisition users are determined from the previously randomly selected first target user set. These actual acquisition users can acquire target objects in the store. For example, if the store has 100 target objects, and each user is allowed to acquire one target object, the allocable value can be set to 100, thus determining 100 actual acquisition users in the first target set. If the store has 100 target objects, and each user is allowed to acquire five target objects, the allocable value can be set to 20, thus determining 20 actual acquisition users in the first target set.

[0105] This application does not specifically limit the method by which a user obtains a target object. For example, a user may reserve a target object online through an internet platform and then obtain the target object offline at a physical store after the reservation is successful. For another example, a user may reserve a target object online through an internet platform and obtain the target object via online mail.

[0106] The following combination Figure 6 Introducing a method of selecting actual users from the first target set by lottery, namely Figure 6 The method shown is one of the methods in S505.

[0107] In order to further improve the efficiency of the lottery, continue to refer to Figure 4 , after the actual users are determined one by one from the inventory table of the target objects that can be allocated, the actual users are determined one by one for the target objects that can be allocated in the next store until the actual users are allocated.

[0108] Even after all the available numbers for the first target object model in a store have been determined and the actual users have been assigned, the available numbers for the next target object model can be determined and assigned one by one until all the available numbers for all target objects in that store have been assigned. By conducting a lottery one by one according to the order of each target object model and / or each store, there is no need to repeat the lottery, thereby improving the efficiency of the lottery.

[0109] See also Figure 6 , this figure is a method flow chart of a first mode provided in an embodiment of the present application.

[0110] S601: If the total number of target objects requested by the object acquisition request in the first target user set is greater than the allocable value, the actual acquisition user is determined from the first target user set by drawing lots again for the user identifiers in the first target user set.

[0111] If the total number of target objects requested by the object acquisition request in the first target user set is greater than the allocable value, it means that the target objects can be allocated to all users in the first target user set. Then, a lottery is conducted again, i.e., a lottery is conducted again for the user IDs in the first target user set. The actual acquisition user is determined from the first target user set through the second lottery. Figure 4 , the second lottery value can be recorded in the Roll point record table. For example, based on the value of the second lottery, the users in the first target user set are placed in the waiting lottery array in order, and then matched one by one from front to back in the array order until all the allocable values are allocated.

[0112] S602: If the total number of target objects requested by the object acquisition request in the first target user set is less than the allocatable value, a second target user set is acquired from the multiple user sets by adjusting the target value.

[0113] If the total number of target objects requested by the object acquisition request in the first target user set is less than the allocatable value, it means that the target objects cannot be fully allocated by the users in the first target user set. In this case, the number of users needs to be increased to ensure that all target objects can be fully allocated. This eliminates the need for multiple lottery draws for the target objects, improving lottery efficiency.

[0114] As a way to increase the number of object acquisition requests in a user set, the target value can be adjusted, and then a second target user set can be obtained from multiple user sets based on the adjusted target value. The second target user set can be multiple user sets to ensure that the total number of object acquisition requests in the first target user set and the second target user set exceeds the allocatable value, so that all target objects can be allocated.

[0115] As another way to expand the number of object retrieval requests in a user set, each user ID is randomly assigned an integer between 0 and 1023. This integer is then stored in quaternary form in a string of fixed length 5, such as 20121 or 00230. To expand the number of object retrieval requests in a user set, the string is matched by shifting it left one position. For example, if 31231 is retrieved, a left shift of one position yields a fuzzy query of 3123%, and a left shift of two positions yields 3122%. This continues until the number reaches or exceeds the allocatable value, ensuring that all target objects are allocated.

[0116] S603: Determine, based on the allocable value, from the first target user set and the second target user set an actual user who acquires the target object provided by the store.

[0117] Continue to see Figure 4 , the actual users can be written into the lottery result table and stored in the cache space so that the front-end service process can query the results.

[0118] The secondary lottery method can quickly screen out the winning users from a large number of users, thereby improving the efficiency of the lottery. Figure 7-Figure 9 , which is a schematic diagram of a lottery method provided in an embodiment of the present application. Figure 7 A diagram showing preparations for the lottery draw. Figure 8 This is a diagram of the lottery being drawn. Figure 9 This is a schematic diagram of the completed lottery, and the list of winners can also be downloaded.

[0119] In order to cope with high concurrency scenarios, this application provides two modes for obtaining target objects, namely the first mode and the second mode. The first mode and the second mode use different object acquisition methods. For example, the first mode obtains object acquisition requests by randomly drawing random numbers (such as the lottery mode), and the second mode obtains object acquisition requests by synchronously purchasing at the same time (such as the rush purchase mode) to reduce server pressure. Figure 10 , which is a schematic diagram of a switching mode provided by an embodiment of the present application. In order to be able to switch between two modes to meet different needs, the two modes are written into a configuration file that can identify the rule parameters of the target object. By obtaining the configuration file for the target object, if a mode switching request is obtained, the mode of obtaining the target object can be switched to the first mode or the second mode according to the configuration file.

[0120] The target objects are in short supply. If the rule parameters for the target objects are obtained by updating the client version, the update speed will be slow, which will affect users' ability to obtain the target objects in a timely manner. This is because client updates require an approval process, which takes a considerable amount of time. Moreover, users may not be able to use the latest version of the client immediately after the client is updated. Therefore, for some rule parameters that may change, such as the target object's copy, control switches, time variables, and winning probabilities, they are written into a configuration file and published to the server. When a rule parameter update request is received from the client, there is no need to modify the client version. Instead, the configuration file is updated according to the rule parameter update request instructions, thereby reducing the impact of the client version update on the launch of related functions and improving the update speed.

[0121] If a user views messages related to a target object through a client, the server will continuously receive content query requests for the target object from the client, thereby increasing the burden on the server. In order to reduce the number of interactions between the client and the server, after receiving the file acquisition request sent by the client, a configuration file can be sent to the client, so that the configuration file can be cached locally on the client for a first predetermined time period. Therefore, when the user views messages related to the target object again within the first predetermined time period, the client will not send a content query request for the target object to the server, but will read the locally cached configuration file to display relevant information about the target object, thereby reducing the number of interactions between the client and the server and reducing the burden on the server.

[0122] In order to reduce the burden on the server caused by the user constantly refreshing the query results through the client after obtaining the corresponding content query response, the content query response can be cached locally on the client for a second predetermined period of time. Therefore, after the client obtains the content query response request for the first time, it will not request the server to obtain the query response request again within the second predetermined period of time. Instead, it obtains the target processing result from the client's local cache and displays it to the user, thereby reducing the number of interactions between the client and the server and reducing the burden on the server.

[0123] In order to further reduce the burden on the server, this application optimizes the client so that the client can control the random sending of object acquisition requests for target objects to the server in batches, thereby reducing the pressure on the server. Figure 11 Let’s take the example of purchasing masks through the mini program for specific explanation.

[0124] See also Figure 11 , this figure is a flowchart of purchasing masks through a mini program provided in an embodiment of the present application.

[0125] Before sending an object acquisition request for the target object, the applet will go through three pages: the home page, the description page, and the registration form page.

[0126] On the homepage, when users start to buy masks, they obtain the configuration file for the masks through the mini program and cache the configuration file locally in the mini program, thereby reducing the number of interactions between the mini program and the server and alleviating the pressure on the server. Figure 12 As shown in the following example, on the homepage, after obtaining the mask configuration file, you can select the pharmacy, mask model, and purchase quantity, among other rule parameters. Furthermore, inventory verification is no longer performed when selecting these parameters, reducing server pressure.

[0127] On the instructions page, filling out a personal health declaration form is a prerequisite for pre-ordering masks, encouraging more users to report their health data promptly and helping regulators monitor the epidemic. Specifically, users are required to self-check and report during the epidemic. If they haven't done so, they are guided to do so. This diverts these users, reducing the number of people rushing to buy masks and, in turn, reducing server pressure. If users have self-checked and reported, the user is guided to determine whether they have the purchasing power. If they don't meet the requirements, a pop-up window will appear with the reason. If they do meet the requirements, they will be redirected to the registration form.

[0128] On the registration form page, you can use the mini program's information autofill capability to save the information the user filled in last time, so that the user can select the ID card, name, and other information that they filled in last time, to achieve the effect of quick filling and improve the user experience. When the user has entered all the information and submitted it, lossy service is implemented through a strategy of random release in batches. Specifically, in the configuration file, the success probability of submitting user information is set. For example, the success probability is set between 0-100%, so that users can submit form data to the server according to a certain probability. If the submission does not hit the success probability this time, the mini program will prompt the user to try again after a while. For example, when the success probability is set to 40%, 100 users send object acquisition requests for the target object through the mini program, and only 40 users can send them successfully. The mini program will prompt the remaining 60 users to try again after a while. If Figure 13 As shown in the figure, the mini program will not send object acquisition requests for masks to the server. This reduces the number of client-server interactions when there are many users, thereby reducing the server burden. If the server pressure is reduced during the current period, the success probability can be adjusted to 100%, so that the client will send all object acquisition requests for the target object to the server.

[0129] Next, the data processing method provided by the embodiment of the present application will be introduced in conjunction with a specific scenario, which is a scenario where users rush to buy masks through the mini program. Among them, the first mode is the lottery mode, and the second mode is the rush purchase mode.

[0130] Please see the table below for the functions provided by the mini program to users to facilitate their purchase of masks.

[0131]

[0132]

[0133]

[0134]

[0135] The following is an illustration of the process for users to obtain masks through the mini program.

[0136] See also Figure 14 , which is a flowchart of data processing provided in an embodiment of the present application.

[0137] S1401: Enter the mini program for buying masks.

[0138] See also Figure 15, which is a schematic diagram of a mini-program page provided by an embodiment of the present application. The mini-program may have options such as my health code, health self-reporting, epidemic clue reporting, and mask reservation purchase.

[0139] S1402: Send an object acquisition request for the target object to the front-end service process.

[0140] See also Figure 16 , which is a schematic diagram of a mini program page provided in an embodiment of the present application. The user is guided to fill in relevant information such as the region, mask model, mask quantity, mailing information, etc. After the information is successfully filled in, click Submit.

[0141] See also Figure 17 , which is a schematic diagram of a mini-program page provided by an embodiment of the present application. After the user submits relevant information, the user can choose whether to receive a mask reservation result notification to facilitate the user to know the purchase result in a timely manner.

[0142] S1403: The front end verifies the user's relevant information.

[0143] S1404: If the verification fails or the message queue fails to be stored, the applet is returned to display the result of the reservation purchase.

[0144] S1405: If the verification is successful, an object acquisition request is sent to the message queue in the cache space.

[0145] S1406: The backend service process takes out the object acquisition request to be processed from the message queue in the cache space according to the first-in-first-out mechanism.

[0146] S1407: The backend service process obtains the request for the corresponding processing object and obtains the corresponding processing result.

[0147] See also Figure 18 , which is a schematic diagram of a mini program page provided by an embodiment of the present application. When the backend service process asynchronously processes the object acquisition request, the mini program end can display the interface in the queue.

[0148] See also Figure 19 , which is a schematic diagram of a mini-program page provided by an embodiment of the present application. If the rush purchase mode is a lottery mode, the lottery results can be displayed to the user after the lottery is completed, such as information such as the user has won the lottery.

[0149] See also Figure 20 , which is a schematic diagram of a mini program page provided by an embodiment of the present application. If the rush purchase mode is the rush purchase mode, the rush purchase result can be displayed to the user after the rush purchase ends, such as information such as the user's rush purchase has ended. Figure 24The similarities and differences between the lottery mode and the rush purchase mode are explained in detail and will not be repeated here.

[0150] The following describes the combination Figure 21 and Figure 22 Two ways for users to obtain masks are introduced respectively.

[0151] See also Figure 21 , which is a schematic diagram of a mini-program page provided in an embodiment of the present application. After the user wins the lottery, the user can choose to receive the mask by mail. At this time, the user needs to make a payment in the "My Appointment" interface and view information such as the mailing address.

[0152] See also Figure 22 This figure is a schematic diagram of a mini-program page provided in an embodiment of the present application. After winning the lottery, users can choose to receive masks by mail. In this case, users need to make a payment in the "My Reservation" interface and receive a reservation code, which can be used to obtain masks at offline pharmacies. The mini-program can also provide relevant information such as navigation to the destination to facilitate users to obtain masks.

[0153] S1408: The backend service process stores the corresponding processing results in the cache space and the database respectively.

[0154] Therefore, during the epidemic, the mini program provides users with mask reservation and purchase functions. On the one hand, the online mask reservation and purchase service meets the users' urgent need for masks and supplies. At the same time, on the basis of supporting users to purchase at pharmacies, the home mail service is added to effectively avoid the epidemic risk caused by queuing to buy masks; on the other hand, the mask reservation and purchase service collects the health status of users, supports regulatory agencies to arrange relevant services according to specific symptoms, thereby ensuring the health and safety of users. Figure 23 and Figure 24 Explain the similarities and differences between the two methods of purchasing masks through mini programs.

[0155] See also Figure 23 , this figure is a flow chart of a rush purchase mode provided in an embodiment of the present application.

[0156] On the mini program side:

[0157] User registration: If the user is registering for the first time, you can obtain the user's mobile phone number by calling WeChat; if the user is not registering for the first time, you can skip this step.

[0158] Enter the mini program: 1. First, review the purchase instructions. 2. Before the purchase time X, the purchase button will be grayed out and users will not be able to click it. When the time reaches X, users will be able to click the purchase button. 3. Determine whether the user has completed a personal health declaration within Y days. If not, guide the user to submit a personal health declaration first.

[0159] Obtaining the configuration file: 1. This step does not require inventory verification, and users can select any mask model. 2. Provide the option to "If the selected model is out of stock, receive a random allocation of another model."

[0160] Send object acquisition request: allocate random release: 1. Release at a ratio of XX%, XX can be dynamically configured. 2. If not released, prompt "There are currently too many users rushing to buy, please try again later"; and the button will be grayed out and unclickable within 5 seconds, and the button will display a countdown "Please try again in (5) seconds".

[0161] On the server side:

[0162] Resale: 1. The backend returns whether the sale has started. If not, it returns a "not started" message. 2. The backend returns whether the sale has ended. This is done if one of the following two conditions is met: a. The sale inventory has run out. b. The set end time has arrived. 3. If it has ended, the reservation end page will be displayed directly; if it has not ended, the user will proceed to the next step.

[0163] Registration for the rush purchase is completed: the system is queuing for processing and the purchase result will be announced in half an hour. Please check it later in "Personal Center-》My Purchase".

[0164] Queue processing: The model selected by the user will be given priority. If it is insufficient and the user selects "accept allocation", other models will be allocated to the user in order from the highest inventory to the lowest.

[0165] Return results to the user: The user can view them in "Personal Center -> My Purchases".

[0166] See also Figure 24 , this figure is a flow chart of a lottery mode provided in an embodiment of the present application.

[0167] On the mini program side:

[0168] User registration: If the user is registering for the first time, you can obtain the user's mobile phone number by calling WeChat; if the user is not registering for the first time, you can skip this step.

[0169] Enter the mini program: 1. View the pre-order purchase instructions. 2. The button will be grayed out if you are not within the pre-order period, but will be clickable if you are within the pre-order period.

[0170] Get the configuration file: 1. This step does not do inventory verification, and users can choose any model of masks. 2. Provide the option "If the selected model is out of stock, receive a random allocation of other models." 3. Add the option of payment upon arrival or mail (for orders). 4. If mail is chosen, the mailing address will be determined by the city, and it cannot be submitted outside the city. Sending object acquisition request: Allocation release: 1. Release at a ratio of XX%, XX can be dynamically configured. 2. The user must allow the receipt of notifications, otherwise the submission cannot be made; if the user chooses, and the notification receipt confirmation box does not appear, the submission is released.

[0171] On the server side:

[0172] Snap-up: 1. The backend returns whether the reservation has started. If not, it returns a "not started" message. 2. If it has ended, it directly displays the reservation end page; if not, it proceeds to the next step.

[0173] Registration for the rush purchase is completed: inform "Registration for the rush purchase is completed, and there is no need to submit an appointment again within X days. The lottery results will be announced at XX:XX every day. Please check in "Personal Center-》My Appointment".

[0174] Queue Processing: 1. The lottery will be conducted using a public lottery algorithm. 2. Users who have already won a lottery within X days are not eligible to participate in the lottery again (including those aged XX and above). 3. Reservations submitted within X days but not winning the lottery do not need to be submitted again. 4. Users aged XX and above only need to submit once, and the record will remain valid. 5. The lottery website will be provided to the notary office the day after tomorrow for use.

[0175] Return the results to the user: Push notifications to users via subscriptions. This requires a web backend trigger. 2. Display the results in the personal center, adjust the text, and add a reservation code.

[0176] The mailing options are divided into mailing to users and users picking up in store (pick up at the offline store with my appointment information).

[0177] Provide management backend to modify the status, which can be changed to mailed or received.

[0178] The status will be updated synchronously in My Appointments.

[0179] Based on the data processing method provided in the aforementioned embodiment, the relevant device provided in the embodiment of the present application is introduced.

[0180] This embodiment provides a data processing device 2500, see Figure 25 The device 2500 includes an acquisition unit 2501, a writing unit 2502, a first processing unit 2503 and a second processing unit 2504:

[0181] The acquisition unit 2501 is used to acquire an object acquisition request for a target object;

[0182] The writing unit 2502 is configured to write the object acquisition request into a message queue in a cache space;

[0183] The first processing unit 2503 is configured to retrieve the object acquisition request from the message queue, perform corresponding processing on it, and cache the obtained processing result in the cache space;

[0184] The second processing unit 2504 is configured to query the cache space for a target processing result according to a content query request for the target object.

[0185] In a possible implementation, the writing unit 2502 is specifically configured to update the obtained processing results into the database corresponding to the target object in sequence according to the processing order.

[0186] In one possible implementation, if the object acquisition request is obtained through a first mode, the device also includes a lottery unit, which is specifically used to assign a first lottery value to the user identifier carried by the object acquisition request; divide the object acquisition request into multiple user sets based on the first lottery value; when determining the actual acquisition user of the target object, according to the target value determined from the first lottery value, select a first target user set corresponding to the target value from the multiple user sets; according to the store identifier that provides the target object, determine the allocatable value of the target object in the store corresponding to the store identifier; according to the allocatable value, determine from the first target user set the actual acquisition user of the target object provided by the store.

[0187] In one possible implementation, the lottery unit is also used to determine the actual acquisition user from the first target user set by drawing again for the user identifiers in the first target user set if the total number of target objects requested by the object acquisition request in the first target user set is greater than the allocable value; if the total number of target objects requested by the object acquisition request in the first target user set is less than the allocable value, obtain a second target user set from the multiple user sets by adjusting the target value; and determine the actual acquisition user who acquires the target object provided by the store from the first target user set and the second target user set according to the allocable value.

[0188] In one possible implementation, the device further includes a configuration file unit for obtaining a configuration file for the target object, wherein the configuration file identifies rule parameters for obtaining the target object; if a mode switching request is obtained, the mode for obtaining the target object is switched according to the configuration file, and the mode includes a first mode or a second mode.

[0189] In a possible implementation, the configuration file unit is further configured to obtain a rule parameter update request from a client; and update the configuration file according to an instruction of the rule parameter update request.

[0190] In a possible implementation, the configuration file unit is further configured to obtain a file acquisition request sent by a client; and send the configuration file to the client to instruct the client to locally cache the configuration file for a first predetermined duration.

[0191] In a possible implementation, the content query response is further used to instruct the client that obtains the content query response to locally cache the target processing result for a second predetermined time period.

[0192] In a possible implementation, the device further includes a probability indication unit for sending probability indication information to the client before obtaining the object acquisition request for the target object, wherein the probability indication information is used to indicate the probability of success of the client submitting the object acquisition request.

[0193] The data processing device provided in the above embodiment addresses scenarios involving high-concurrency target object acquisition. When an object acquisition request for a target object is received, the device does not synchronously determine whether to provide the target object. Instead, the object acquisition request is written to a message queue in a cache. The object acquisition request is then removed from the message queue when it can be processed, thereby achieving asynchronous processing of the object acquisition request. This asynchronous processing mechanism can thus achieve peak load shaving, reducing the impact on the database, even during peak periods of receiving object acquisition requests. Furthermore, even if the number of object acquisition requests received decreases sharply after the peak period, the remaining object acquisition requests in the message queue can continue to be processed, achieving a valley-filling effect. During peak periods, in addition to the high concurrency of object acquisition requests, a large number of content query requests are also associated. By caching the processing results of the object acquisition requests in the cache, queries based on the content query results can be directly searched and returned in the cache. This eliminates the need for additional data interaction with the database storing the processing results, reducing database access volume, effectively protecting the database during peak periods, and improving query response efficiency.

[0194] The embodiment of the present application also provides a device for data processing. The device for data processing provided by the embodiment of the present application will be introduced below from the perspective of hardware instantiation.

[0195] See also Figure 26 , Figure 26 This is a schematic diagram of a server structure provided by an embodiment of the present application. The server 1400 may vary significantly due to different configurations or performance, and may include one or more central processing units (CPUs) 1422 (e.g., one or more processors) and memory 1432, and one or more storage media 1430 (e.g., one or more mass storage devices) storing application programs 1442 or data 1444. The memory 1432 and storage medium 1430 may be either transient or persistent storage. The program stored in the storage medium 1430 may include one or more modules (not shown), each of which may include a series of instruction operations on the server. Furthermore, the CPU 1422 may be configured to communicate with the storage medium 1430 to execute the series of instruction operations in the storage medium 1430 on the server 1400.

[0196] The server 1400 may also include one or more power supplies 1426, one or more wired or wireless network interfaces 1450, one or more input and output interfaces 1458, and / or one or more operating systems 1441, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0197] The steps performed by the server in the above embodiment can be based on the Figure 26 The server structure shown.

[0198] The CPU 1422 is configured to execute the following steps:

[0199] Get an object acquisition request for the target object;

[0200] Writing the object acquisition request into a message queue in the cache space;

[0201] Taking out the object acquisition request from the message queue and performing corresponding processing, and caching the obtained processing result in the cache space;

[0202] According to a content query request for the target object, a target processing result is queried in the cache space.

[0203] Optionally, the CPU 1422 may also execute the method steps of any specific implementation of the data processing method in the embodiments of the present application.

[0204] In response to the data processing method described above, an embodiment of the present application further provides a terminal device for data processing, so that the above data processing method can be implemented and applied in practice.

[0205] See also Figure 27 , Figure 27 This is a schematic diagram of the structure of a terminal device provided in an embodiment of the present application. For ease of explanation, only the parts related to the embodiment of the present application are shown. For specific technical details not disclosed, please refer to the method section of the embodiment of the present application. The terminal device can be any terminal device including a mobile phone, tablet computer, personal digital assistant (PDA), etc. Taking the terminal device as a mobile phone as an example:

[0206] Figure 27 The block diagram shows a partial structure of a mobile phone related to the terminal device provided in the embodiment of the present application. Figure 27 The mobile phone includes components such as a radio frequency (RF) circuit 1510, a memory 1520, an input unit 1530, a display unit 1540, a sensor 1550, an audio circuit 1560, a wireless fidelity (WiFi) module 1570, a processor 1580, and a power supply 1590. Those skilled in the art will appreciate that Figure 27 The mobile phone structure shown in the figure does not constitute a limitation to the mobile phone, and may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently.

[0207] The following combination Figure 27 A detailed introduction to the various components of a mobile phone:

[0208] RF circuitry 1510 can be used to receive and transmit signals during information transmission or calls. Specifically, it receives downlink information from the base station and transmits it to processor 1580 for processing. It also transmits uplink data to the base station. Typically, RF circuitry 1510 includes, but is not limited to, an antenna, at least one amplifier, a transceiver, a coupler, a low-noise amplifier (LNA), a duplexer, and the like. RF circuitry 1510 can also communicate with the network and other devices via wireless communications. Such wireless communications can utilize any communication standard or protocol, including but not limited to Global System of Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Long Term Evolution (LTE), email, and Short Messaging Service (SMS).

[0209] Memory 1520 can be used to store software programs and modules. Processor 1580 executes the software programs and modules stored in memory 1520 to implement various functional applications and data processing of the mobile phone. Memory 1520 may primarily include a program storage area and a data storage area. The program storage area may store an operating system and at least one application required for a function (such as sound playback or image playback). The data storage area may store data generated based on the use of the mobile phone (such as audio data and a phone book). Memory 1520 may also include high-speed random access memory and non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state memory device.

[0210] The input unit 1530 is used to receive input digital or character information and generate key signal input related to user settings and function control of the mobile phone. Specifically, the input unit 1530 may include a touch panel 1531 and other input devices 1532. The touch panel 1531, also known as a touch screen, can detect user touch operations on or near it (for example, operations performed on or near the touch panel 1531 using a finger, stylus, or any other suitable object or accessory) and drive corresponding connected devices according to pre-set programs. Optionally, the touch panel 1531 may include a touch detection device and a touch controller. The touch detection device detects the user's touch direction and detects signals generated by the touch operation, transmitting the signals to the touch controller. The touch controller receives the touch information from the touch detection device, converts it into touch point coordinates, and then sends it to the processor 1580. The touch controller can also receive and execute commands from the processor 1580. Furthermore, the touch panel 1531 can be implemented using various types of sensors, including resistive, capacitive, infrared, and surface acoustic wave. In addition to the touch panel 1531, the input unit 1530 may further include other input devices 1532. Specifically, the other input devices 1532 may include, but are not limited to, one or more of a physical keyboard, function keys (such as volume control keys, power keys, etc.), a trackball, a mouse, and a joystick.

[0211] The display unit 1540 can be used to display information input by the user or information provided to the user and various menus of the mobile phone. The display unit 1540 may include a display panel 1541. Optionally, the display panel 1541 may be configured in the form of a liquid crystal display (LCD), an organic light-emitting diode (OLED), etc. Further, the touch panel 1531 may cover the display panel 1541. When the touch panel 1531 detects a touch operation on or near it, it is transmitted to the processor 1580 to determine the type of touch event. Subsequently, the processor 1580 provides corresponding visual output on the display panel 1541 according to the type of touch event. Although in Figure 27 In the embodiment, the touch panel 1531 and the display panel 1541 are used as two independent components to realize the input and output functions of the mobile phone, but in some embodiments, the touch panel 1531 and the display panel 1541 can be integrated to realize the input and output functions of the mobile phone.

[0212] The mobile phone may also include at least one sensor 1550, 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, wherein the ambient light sensor can adjust the brightness of the display panel 1541 according to the brightness of the ambient light, and the proximity sensor can turn off the display panel 1541 and / or the backlight when the mobile phone is moved to the ear. As a type of motion sensor, the accelerometer sensor can detect the magnitude of acceleration in all directions (generally three axes), and can detect the magnitude and direction of gravity when stationary. It can be used for applications that identify the posture of the mobile phone (such as switching between horizontal and vertical screens, related games, magnetometer posture calibration), vibration recognition related functions (such as pedometer, tapping), etc.; as for other sensors that the mobile phone can also be configured with, such as gyroscopes, barometers, hygrometers, thermometers, infrared sensors, etc., they will not be described here.

[0213] Audio circuit 1560, speaker 1561, and microphone 1562 provide an audio interface between the user and the phone. Audio circuit 1560 converts received audio data into electrical signals and transmits them to speaker 1561, which then converts them into sound signals for output. Microphone 1562, on the other hand, converts collected sound signals into electrical signals, which are then received by audio circuit 1560 and converted into audio data. The audio data is then processed by processor 1580 and transmitted to, for example, another phone via RF circuit 1510, or stored in memory 1520 for further processing.

[0214] WiFi is a short-range wireless transmission technology. Mobile phones can help users send and receive emails, browse the web, and access streaming media through the WiFi module 1570. It provides users with wireless broadband Internet access. Figure 27 A WiFi module 1570 is shown, but it is understandable that it is not an essential component of the mobile phone and can be omitted as needed without changing the essence of the invention.

[0215] Processor 1580 is the control center of the phone, connecting all parts of the phone using various interfaces and circuits. It executes software programs and / or modules stored in memory 1520 and accesses data stored in memory 1520 to perform various phone functions and process data. Optionally, processor 1580 may include one or more processing units. Preferably, processor 1580 integrates an application processor and a modem processor. The application processor primarily handles the operating system, user interface, and application programs, while the modem processor primarily handles wireless communications. It is understood that the modem processor may not be integrated into processor 1580.

[0216] The mobile phone also includes a power supply 1590 (such as a battery) for supplying power to various components. Preferably, the power supply can be logically connected to the processor 1580 through a power management system, so that the power management system can manage charging, discharging, power consumption and other functions.

[0217] Although not shown, the mobile phone may also include a camera, a Bluetooth module, etc., which will not be described in detail here.

[0218] In the embodiment of the present application, the memory 1520 included in the mobile phone can store program codes and transmit the program codes to the processor.

[0219] The processor 1580 included in the mobile phone can execute the data processing method provided in the above embodiment according to the instructions in the program code.

[0220] An embodiment of the present application further provides a computer-readable storage medium for storing a computer program, which is used to execute the data processing method provided in the above embodiment.

[0221] The present application also provides a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the data processing method provided in various optional implementations of the above aspects.

[0222] Those skilled in the art will understand that all or part of the steps of implementing the above-mentioned method embodiments may be accomplished by hardware related to program instructions, and the aforementioned program may be stored in a computer-readable storage medium. When the program is executed, the program executes the steps of the above-mentioned method embodiments; and the aforementioned storage medium may be at least one of the following media: read-only memory (ROM), RAM, magnetic disk, optical disk, or other media that can store program codes.

[0223] It should be noted that the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device and system embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiments. The device and system embodiments described above are merely schematic, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the scheme of this embodiment. A person of ordinary skill in the art can understand and implement it without expending creative work.

[0224] The above is merely one specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.

Claims

1. A data processing method, characterized in that: The method comprises: Get an object acquisition request for the target object; Writing the object acquisition request into a message queue in the cache space; Taking out the object acquisition request from the message queue and performing corresponding processing, and caching the obtained processing result in the cache space; Querying the cache space for a target processing result according to a content query request for the target object; If the object acquisition request is obtained through the first mode, the method further includes: Allocating a first lottery number value to the user identifier carried in the object acquisition request; dividing the object acquisition request into multiple user sets based on the first lottery number value; When determining the actual acquired user of the target object, according to determining the target value from the first lottery value, selecting a first target user set corresponding to the target value from the multiple user sets; Determining, based on the store identifier of the target object provided, an allocable value of the target object in the store corresponding to the store identifier; According to the allocable value, an actual acquiring user who acquires the target object provided by the store is determined from the first target user set.

2. The method according to claim 1, characterized in that The method further comprises: The obtained processing results are updated in sequence to the database corresponding to the target object according to the processing order.

3. The method according to claim 1, characterized in that The step of determining, from the first target user set according to the assignable value, an actual acquiring user who acquires the target object provided by the store comprises: If the total number of target objects requested by the object acquisition request in the first target user set is greater than the allocable value, the actual acquisition user is determined from the first target user set by drawing lots again for the user identifiers in the first target user set; If the total number of target objects requested by the object acquisition request in the first target user set is less than the allocatable value, acquiring a second target user set from the multiple user sets by adjusting the target value; According to the assignable value, an actual acquiring user who acquires the target object provided by the store is determined from the first target user set and the second target user set.

4. The method according to any one of claims 1 to 3, characterized in that The method further comprises: Acquire a configuration file for the target object, where the configuration file identifies rule parameters for acquiring the target object; If a mode switching request is received, the mode for acquiring the target object is switched according to the configuration file, the mode including a first mode or a second mode, and the first mode and the second mode use different object acquisition methods.

5. The method according to claim 4, characterized in that The method further comprises: Get the rule parameter update request from the client; The configuration file is updated according to the instruction of the rule parameter update request.

6. The method according to claim 4, characterized in that The method further comprises: Get the file acquisition request sent by the client; The configuration file is sent to the client, to instruct the client to locally cache the configuration file for a first predetermined duration.

7. The method according to any one of claims 1 to 3, characterized in that The method further includes returning a corresponding content query response based on the target processing result, wherein the content query response is used to instruct a client that obtains the content query response to locally cache the target processing result for a second predetermined period of time.

8. The method according to claim 1, characterized in that Before obtaining the object acquisition request for the target object, the method further includes: Probability indication information is sent to the client, where the probability indication information is used to indicate a probability of success of the client submitting the object acquisition request.

9. A data processing device, characterized in that: The device includes an acquisition unit, a writing unit, a first processing unit and a second processing unit: The acquisition unit is configured to acquire an object acquisition request for a target object; The writing unit is used to write the object acquisition request into the message queue in the cache space; The first processing unit is configured to retrieve the object acquisition request from the message queue, perform corresponding processing on it, and cache the obtained processing result in the cache space; The second processing unit is configured to query the cache space for a target processing result according to a content query request for the target object; If the object acquisition request is obtained through the first mode, the device further includes a lottery unit, specifically configured to: Allocating a first lottery number value to the user identifier carried in the object acquisition request; dividing the object acquisition request into multiple user sets based on the first lottery number value; When determining the actual acquired user of the target object, according to determining the target value from the first lottery value, selecting a first target user set corresponding to the target value from the multiple user sets; Determining, based on the store identifier of the target object provided, an allocable value of the target object in the store corresponding to the store identifier; According to the allocable value, an actual acquiring user who acquires the target object provided by the store is determined from the first target user set.

10. The device according to claim 9, characterized in that The writing unit is specifically used for: The obtained processing results are updated in sequence to the database corresponding to the target object according to the processing order.

11. The device according to claim 9, characterized in that The lottery unit is also used for: If the total number of target objects requested by the object acquisition request in the first target user set is greater than the allocable value, the actual acquisition user is determined from the first target user set by drawing lots again for the user identifiers in the first target user set; If the total number of target objects requested by the object acquisition request in the first target user set is less than the allocatable value, acquiring a second target user set from the multiple user sets by adjusting the target value; According to the assignable value, an actual acquiring user who acquires the target object provided by the store is determined from the first target user set and the second target user set.

12. The device according to any one of claims 9 to 11, characterized in that The device also includes a configuration file unit for obtaining a configuration file for the target object, wherein the configuration file identifies rule parameters for obtaining the target object; if a mode switching request is obtained, the mode for obtaining the target object is switched according to the configuration file, wherein the mode includes a first mode or a second mode.

13. The device according to claim 12, characterized in that The configuration file unit is further configured to obtain a rule parameter update request from a client; and update the configuration file according to an instruction of the rule parameter update request.

14. The device according to claim 12, characterized in that The configuration file unit is further configured to obtain a file acquisition request sent by a client; and send the configuration file to the client to instruct the client to locally cache the configuration file for a first predetermined duration.

15. The device according to any one of claims 9 to 11, characterized in that The apparatus further includes returning a corresponding content query response based on the target processing result, where the content query response is used to instruct a client that obtains the content query response to locally cache the target processing result for a second predetermined time period.

16. The device according to claim 9, characterized in that The device further includes a probability indication unit configured to send probability indication information to the client before obtaining the object acquisition request for the target object, wherein the probability indication information is used to indicate a probability of success of the client submitting the object acquisition request.

17. A device for data processing, characterized in that The device includes a processor and a memory: The memory is used to store program code and transmit the program code to the processor; The processor is configured to execute the method according to any one of claims 1 to 8 according to instructions in the program code.

18. A computer-readable storage medium, characterized in that The computer-readable storage medium is used to store a computer program, and the computer program is used to execute the method according to any one of claims 1 to 8.

19. A computer program product, characterized in that The computer program product comprises instructions, which, when executed on a computer device, cause the computer device to perform the method according to any one of claims 1 to 8.

Images