CN115543655A

CN115543655A - Service request processing method and device

Info

Publication number: CN115543655A
Application number: CN202211158316.4A
Authority: CN
Inventors: 张彦宝; 李长亮
Original assignee: Beijing Kingsoft Digital Entertainment Co Ltd
Current assignee: Beijing Kingsoft Digital Entertainment Co Ltd
Priority date: 2022-09-22
Filing date: 2022-09-22
Publication date: 2022-12-30

Abstract

The application provides a service request processing method and a device, wherein the service request processing method comprises the following steps: receiving a to-be-processed order request aiming at a target task, wherein the to-be-processed order request carries task request parameters; verifying the validity of the order request to be processed in a business key value database according to the task request parameters; and under the condition that the order request to be processed is determined to be an effective request, updating the quantity information of the target tasks in the business key value database, sending the order request to be processed to a business database, and generating a business order corresponding to the order request to be processed in the business database, wherein business data in the business database are cached in the business key value database. By the method, the business data to be queried is synchronized to the high-speed cached business key value database in advance, and then subsequent query operation is carried out, so that the query efficiency is improved.

Description

Service request processing method and device

Technical Field

The present application relates to the field of computer technologies, and in particular, to a method and an apparatus for processing a service request, a computing device, and a computer-readable storage medium.

Background

When a business demander wants to rapidly collect a batch of available business data in a short time, task rewards are usually issued, the improvement of the task rewards can improve the enthusiasm of users for feeding back the business data, and based on the fact, a large number of client requests can be generated in the short time.

Therefore, a method for processing a service request is needed to reduce the server pressure and improve the user experience.

Disclosure of Invention

In view of this, embodiments of the present application provide a method and an apparatus for processing a service request, a computing device, and a computer-readable storage medium, so as to solve technical defects in the prior art.

According to a first aspect of an embodiment of the present application, a method for processing a service request is provided, including:

receiving a to-be-processed order request aiming at a target task, wherein the to-be-processed order request carries task request parameters;

verifying the validity of the order request to be processed in a business key value database according to the task request parameters; and under the condition that the to-be-processed order request is determined to be an effective request, updating the quantity information of the target tasks in the business key value database, simultaneously sending the to-be-processed order request to a business database, and generating a business order corresponding to the to-be-processed order request in the business database, wherein business data in the business database are cached in the business key value database.

According to a second aspect of the embodiments of the present application, there is provided a service request processing apparatus, including:

the system comprises a receiving module, a processing module and a processing module, wherein the receiving module is configured to receive a to-be-processed order request aiming at a target task, and the to-be-processed order request carries task request parameters;

the verification module is configured to verify the validity of the to-be-processed order request in a business key value database according to the task request parameters;

and the processing module is configured to update the quantity information of the target tasks in the business key value database under the condition that the to-be-processed order request is determined to be an effective request, simultaneously send the to-be-processed order request to a business database, and generate a business order corresponding to the to-be-processed order request in the business database, wherein business data in the business database are cached in the business key value database.

According to a third aspect of the embodiments of the present application, there is provided a computing device, including a memory, a processor, and computer instructions stored on the memory and executable on the processor, where the processor implements the steps of the service request processing method when executing the computer instructions.

According to a fourth aspect of embodiments herein, there is provided a computer-readable storage medium storing computer instructions, which when executed by a processor, implement the steps of the service request processing method.

According to a fifth aspect of the embodiments of the present application, there is provided a chip storing computer instructions, which when executed by the chip, implement the steps of the service request processing method.

The service request processing method provided by the application receives a to-be-processed order request aiming at a target task, wherein the to-be-processed order request carries task request parameters; verifying the validity of the order request to be processed in a business key value database according to the task request parameters; and under the condition that the to-be-processed order request is determined to be an effective request, updating the quantity information of the target tasks in the business key value database, simultaneously sending the to-be-processed order request to a business database, and generating a business order corresponding to the to-be-processed order request in the business database, wherein business data in the business database are cached in the business key value database. By the method, the service data are synchronized to the service key value database from the service database, I/O interaction of the order request to be processed is carried out in the service key value database, direct access to the service database is avoided by utilizing the characteristic that data in the service key value database is stored in the memory, effective order requests to be processed are sent to the service database to carry out actual service processing, access I/O of the service database is reduced, the problem of slow response and even overtime is solved, and the use experience of a user is improved.

Drawings

Fig. 1 is a flowchart of a service request processing method provided in an embodiment of the present application;

fig. 2 is a schematic diagram of a task interface issued by a service demander in a certain annotation platform according to an embodiment of the present application;

fig. 3 is a schematic diagram of a method for determining a set of user identifiers according to an embodiment of the present application;

fig. 4 is a schematic system architecture diagram of a service request processing method according to an embodiment of the present application;

fig. 5 is a flowchart of a service request processing method applied to a task issuing platform scenario according to an embodiment of the present application;

fig. 6 is a schematic structural diagram of a service request processing apparatus according to an embodiment of the present application;

fig. 7 is a block diagram of a computing device according to an embodiment of the present disclosure.

Detailed Description

In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present application. This application is capable of implementation in many different ways than those herein set forth and of similar import by those skilled in the art without departing from the spirit of this application and is therefore not limited to the specific implementations disclosed below.

The terminology used in the one or more embodiments of the present application is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of the present application. As used in one or more embodiments of the present application and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used in one or more embodiments of the present application is intended to encompass any and all possible combinations of one or more of the associated listed items.

It will be understood that, although the terms first, second, etc. may be used herein in one or more embodiments of the present application to describe various information, these information should not be limited by these terms. These terms are only used to distinguish one type of information from another. For example, a first can also be referred to as a second and, similarly, a second can also be referred to as a first without departing from the scope of one or more embodiments of the present application. The word "if," as used herein, may be interpreted as "responsive to a determination," depending on the context.

First, the noun terms to which one or more embodiments of the present invention relate are explained.

Killing in seconds: (Seconds Kill) refers to a sales mode for carrying out the robbery in the same time, and since some tasks are accompanied by higher income reports, the tasks are often more attractive to receive, and sometimes the task data can be robbed for one space in one second, so the second Kill is called.

Network I/O request: the abbreviation Input/Output means Input/Output request.

Relational database: the relational database is created by relying on a relational model, a series of rows and columns of the relational database are called as tables, one group of tables form the database, and the relational database realizes the query and storage of data by using data methods such as selection, projection, connection, combination, intersection, difference, deletion, addition, deletion, modification and the like.

NoSql: the method generally refers to a non-relational database, the non-relational database removes relational characteristics in the relational database, data have no relation, the expansion is convenient, the method has the characteristics of large data volume and high performance, and the NoSql database has high read-write performance.

QPS: (Queries Per Second, query rate) is the number of Queries a server can respond to Per Second, and is a measure of how much traffic a particular query server is handling in a given time.

Multithreading: the method refers to a technology for realizing the concurrent execution of a plurality of threads from software or hardware, and a computer with multithreading capability can complete a plurality of concurrent tasks in the same time.

And (3) concurrence: the method refers to that several programs are in the period from the start to the finish of the operation in one time period, the programs are operated on the same processor, and only one program is executed on the processor at any time point.

When a business demander wants to collect a batch of available business data quickly in a short time, the best method is to improve the business's return on solution welfare. This operation is similar to the discount sales promotion of the e-commerce, and at this time, a large number of customer requests may be gushed in a short time, and at this time, if the data inventory is deducted by real-time query in a conventional manner, frequent network I/O requests and data base requests may cause the pressure of the business system to be too high, the page response to be in time, or even the service to be down.

In addition, in practical application, when a user wants to participate in a certain business task, it is checked whether the user has the right to receive the task, and along with the complex business processing of the business system (calculating whether the user is used for killing the qualification of the current task in seconds), operations such as querying and processing from the relational database even if the user cannot be in real time should be avoided as much as possible. Because the QPS (query per second) is higher and higher as the system access increases, the QPS for a typical database server performs best at 800-1200, and beyond 2000, database-executing database statements become slower and slower, the dragged system responds more slowly, and it is easier for the card to be requested.

Based on this, in the present application, a service request processing method and apparatus, a computing device and a computer readable storage medium are provided, which are described in detail in the following embodiments one by one.

In the following, the method for processing service request provided by the present application is further explained with reference to fig. 1, and fig. 1 shows a flowchart of a method for processing service request according to an embodiment of the present application, which includes steps 102 to 106.

Step 102: receiving a to-be-processed order request aiming at a target task, wherein the to-be-processed order request carries task request parameters.

The target task specifically refers to a demand task issued by a business demander according to the demand of the business demander, for example, in a compliance detection scene, a merchant registers a shop on a certain platform, the platform needs to regularly perform compliance detection on the registered merchant, but the number of merchants is large, the platforms cannot verify one by one, and the merchant compliance detection task can be issued, a user can get the compliance detection task, the user who gets the task can help the platform to verify whether the merchant is compliant, and the platform gives a certain reward to the user after receiving the feedback of the user.

For another example, in the field of artificial intelligence models, when an artificial intelligence model needs to be trained, a large amount of marking data is needed, when the marking data is insufficient, a technician can issue a data marking task, a user can send a request to the data marking task to request to get the task, and after the user gets the data marking task, the technician is fed back marking data and gets rewards corresponding to the data marking task, so that the technician obtains the marking data, and the user obtains a win-win result of the rewards.

As an example, referring to fig. 2, fig. 2 is a schematic diagram of a task interface issued by a business demander in a certain annotation platform according to an embodiment of the present application, where information such as a task reward, a number of tasks that can be picked up, and a number limit that can be picked up by each person is annotated in a task.

The merchant compliance detection task and the data annotation task can be understood as the target task of the application, and in practical application, specific task contents of the target task are not limited, and the practical application is taken as a standard.

In practical application, a business demander can publish its own target task through a task publishing platform, and similarly, a user can also log in the same task publishing platform to browse and pick up a task that can be picked up by the user. The pending order request may also carry task request parameters, and specifically, the task request parameters may include information such as a user identifier, a task identifier, and a request timestamp.

In practical application, when a business demander issues a task on a task issuing platform, in order to improve the enthusiasm of users for participating in the task, rewards are set for the task, when the reward of a certain task is higher, the participation of a large number of users can be triggered, further, the condition that the stock quantity of target tasks is small and the quantity of participating users is large can occur, at this time, the condition that a large number of users rob the stock of a small number of target tasks can occur, namely, the users participate in the target tasks for a second time.

In a specific embodiment provided by the present application, before the task issuing platform receives the pending order request for the target task, the method further includes S1002-S1006:

s1002, issuing the target task, wherein the target task carries a task filtering rule.

As described above, the target task, that is, the task issued by the business demander in the task issuing platform according to the actual requirement of the business demander, sets some limiting conditions of the target task at the same time in the process of issuing the target task, that is, sets the task filtering rule of the target task, for example, for a certain target task, the user score corresponding to the user who needs to get the task exceeds the threshold; for another example, for a certain target task, the knowledge reserve of the user in the relevant field that needs to pick up the task meets the preset requirement, and so on.

In a specific embodiment provided by the present application, taking the service demander issuing the target task a as an example, the user score corresponding to the user who executes the target task a is required to be more than 1000 points.

S1004, determining a user identification set corresponding to the target task based on the task filtering rule.

In the application, in order to improve interaction efficiency, after a target task is issued, a user identifier set corresponding to the target task is screened out from registered users through a task filtering rule, wherein the user identifier set specifically refers to a set of user identifiers corresponding to users who can participate in target task activities. For example, when the task filtering rule is a user with a registration duration longer than 1 year, the user identifier set is a set of user identifiers corresponding to users with a registration duration longer than 1 year.

In a specific embodiment provided by the application, the above example is continued, screening is performed in registered users according to a task filtering rule that the user score is more than 1000, users with the scores of more than 1000 are screened out to serve as target users, and the user identifier of the target user is added to the user identifier set.

Specifically, determining the user identifier set corresponding to the target task based on the task filtering rule includes:

acquiring an initial user identifier set, and creating a thread pool corresponding to the task filtering rule;

adding the user identifiers in the initial user identifier set to a filtering task queue;

and the thread pool reads the user identification from the filtering task queue for filtering, and adds the user identification meeting the task filtering rule to a user identification set.

The initial user identifier set specifically refers to a set of user identifiers corresponding to users registered in the task issuing platform. The thread pool is a multithread processing form, and tasks are added to a queue in the processing process and then are automatically started after threads are created.

The thread pool comprises a plurality of preset threads, and the threads simultaneously process the identification filtering tasks of the user identification set corresponding to the target task based on the task filtering rule. Each thread has the ability to process the identified filtering task, while each thread has a limited ability to process requests.

The thread pool corresponds to a filtering task queue, and the filtering task queue is a message queue for storing user identifiers in the initial user identifier set. After the initial user identifier set is obtained, the user identifiers in the obtained initial user identifier set need to be added to the filtering task queue. And the thread used in the thread pool reads the user identification from the filtering task queue and filters the user identification. And adding the user identification which accords with the task filtering rule into the user identification set.

In practical application, after the initial user identifier set is obtained, it is required to verify whether each user identifier in the initial user identifier set meets a task filtering rule corresponding to a target task. Therefore, each user identifier in the initial user identifier set is added to the filtering task queue, a plurality of threads in the thread pool sequentially read the user identifiers from the filtering task queue, the user identifiers are identified and filtered according to the task filtering rule, the user identifiers meeting the task filtering rule are added to the user identifier set, and the user identifiers not meeting the task filtering rule are removed.

S1006, adding the user identification set to the service key value database.

After the initial user identifier set is screened, a user identifier set which accords with a task filtering rule is obtained, so that the user identifier set can be quickly and efficiently inquired when a to-be-processed order request is subsequently processed, the obtained user identifier set can be added into a business Key Value database, preferably, in the application, the business Key Value database adopts a Redis (Remote Dictionary Server) database, the Redis database is an open-source log-type and Key-Value database which is compiled by using C language, supports a network, can be based on an internal memory and can be also persisted, and APIs (application programming interfaces) of multiple languages are provided. The Redis database is a Key-Value storage system, sequencing in different modes is supported, in order to ensure efficiency, data in the Redis database is cached in an internal memory, updated data is periodically written into a disk or modification operation is written into an additional recording file, and the Redis database has the characteristic of high reading and writing.

Referring to fig. 3, fig. 3 is a schematic diagram illustrating a method for determining a set of user identifiers according to an embodiment of the present application. In the present embodiment, a task in which 5 threads in the thread pool process and determine the user identifier set is taken as an example for explanation. Firstly, acquiring an initial user identification set of all users registered in a task issuing platform. Meanwhile, the number of threads for executing the task of determining the user identifier set may also be determined to be 5, for example, each thread is fixedly allocated with 4 pieces of data that can be processed, 20 user identifiers may be obtained from the initial user identifier set first, and the 20 user identifiers are allocated to 5 threads for processing, at this time, all threads are fully executed, resources are maximally utilized, and a subsequent task is added to the filtering task queue for processing because no idle thread is available for processing temporarily. In practical application, the processing capacities of the 5 threads are different, some threads have high execution speed, some threads have low execution speed, and the threads which are processed first can continue to read new user identifiers from the filtering task queue for processing, so as to calculate the user identifiers meeting the conditions. And finally, correspondingly storing the user identification set after matching and filtering and the task identification of the target task into a Redis database, and verifying whether the user has the task qualification or not again when the user receives the task subsequently through one time of time-consuming calculation operation, thereby greatly improving the throughput capacity of the system.

With continued reference to fig. 1, step 104: and verifying the validity of the order request to be processed in a business key value database according to the task request parameters.

After receiving the to-be-processed order request, the validity of the to-be-processed order request needs to be verified, that is, whether the to-be-processed order request is a valid and valid request is to be determined, the business key value database may be a Redis database in the present application, and the Redis database has the characteristics of a high-level data structure, high performance, light weight without dependency relationship, and high availability. And periodically reading the service data from the service database in the service key value database, caching the service data into the service key value database, and performing frequent interaction and high I/O service requests in the service key value database so as to reduce frequent reading of the service database in a high concurrency scene.

The validity of the order requests to be processed is verified in the business key value database, the invalid order requests to be processed can be removed, the invalid order requests to be processed are prevented from accessing the business database, the access amount of the business database is reduced, and the business processing efficiency is improved.

In a specific embodiment provided by the present application, after performing the preliminary verification on the registered user mentioned in S1002-S1006 in the above steps, obtaining a user identifier set that satisfies a task filtering rule corresponding to the target task, and storing the user identifier set in a service key assignment database, where the order request to be processed may be verified through the user identifier, specifically, verifying the validity of the order request to be processed in the service key assignment database according to the task request parameter includes:

acquiring a target user identifier corresponding to the order request to be processed in the task request parameter;

judging whether the target user identification exists in a user identification set corresponding to the target task or not;

if yes, determining the order request to be processed as an effective request;

if not, determining that the order request to be processed is an invalid request.

The task request parameters specifically refer to parameters related to the to-be-processed order request carried in the to-be-processed order request, and include a user identifier corresponding to a user initiating the to-be-processed order request, and specifically, the target user identifier is the user identifier initiating the to-be-processed order request. For example, if a user sends a pending order request for the target task a with three pieces, the target user identifier corresponding to the pending order request is "three pieces".

After the target user identifier corresponding to the order request to be processed is obtained from the task parameter request, it is necessary to determine whether the target user identifier exists in the user identifier set. Furthermore, after the user identifier set is obtained in the above steps, the user identifier set is stored in the service key value database. And inquiring the target user identifier in a user identifier set in the service key value database, if the target user identifier is stored in the user identifier set, indicating that the target user identifier has the qualification of participating in the target task, and preliminarily judging that the order request to be processed is an effective request. If the target user identifier is not in the user identifier set, it indicates that the target user identifier does not qualify to participate in the target task, and the pending order request is an invalid request.

In a specific embodiment provided by the present application, before determining whether the target user identifier exists in the user identifier set corresponding to the target task, the method further includes:

verifying whether the target user identification is a registered user;

if yes, determining the order request to be processed as an effective request;

Specifically, before determining whether the target user identifier is located in the user identifier set, it may be further determined whether the target user identifier is a registered user of the task issuing platform, for example, in some malicious attack requests, an attacker may counterfeit the user identifier, and first verify whether the target user identifier is a registered user (including a login deadline of the target user), and only when the target user identifier is a registered user (or a current login state is successful in login), may the to-be-processed order request be preliminarily determined as a valid request. And when the target user identification is a non-registered user or the login state is the logout state, determining that the order request to be processed is an invalid request.

In practical application, the service request processing method provided by the application is also preloaded with a data filter. The apparently anomalous pending order requests are filtered through a data filter. Specifically, the method further comprises:

acquiring a target task identifier corresponding to the order request to be processed in the task request parameters;

judging whether the target task identifier meets a preset identifier rule or not;

if yes, determining the order request to be processed as an effective request;

The data filter is used for filtering designated data in the data source, preset identification rules which are configured in advance are set in the data filter, target task identifications corresponding to the order requests to be processed are input into the data filter and are compared with the preset identification rules, whether the target task identifications meet the preset identification rules or not is judged, and the target task identifications which do not meet the rules are filtered through the data filter. Specifically, the data filter may be a soft delete filter (isordetate), a multi-tenant filter (IMultiTenant), a bloom filter (BloomFilter), or the like.

In practical application, the data filter preferably uses a bloom filter (BloomFilter), the bloom filter has 2 characteristics, 1, data which does not exist in the filter does not exist in a database; 2. the data in the filter has a certain probability of not existing in the database. For example, the data identifier in the service database is an 8-digit number, and the data identifier in the task request parameter in the pending order request includes a letter, so that the pending order request does not conform to the filtering rule of the bloom filter, and the pending order request can be ended. The bloom filter can preliminarily screen the obviously abnormal order requests to be processed, and the processing pressure of the service database is reduced.

In practical application, the screening precision of the bloom filter can be set by a business demand party according to the practical demand, and if the screening precision is higher, the performance consumption is higher; the lower the screening accuracy, the smaller the performance consumption. The bloom filter is preloaded with configuration, and when a to-be-processed order request arrives, obviously abnormal orders can be removed through preliminary screening by the bloom filter. Task identifier filtering conditions can be set in the bloom filter, an identifier rule of the task identifier is stipulated, after the order request to be processed is obtained, a target task identifier in task request parameters is obtained, whether the target task identifier meets the identifier rule or not is judged, if yes, the order request to be processed is preliminarily judged to be an effective request, and otherwise, the order request to be processed can be determined to be an invalid request.

In a specific embodiment provided by the present application, a task identifier is set in a bloom filter as a 12-bit digital identifier, and after parsing an obtained to-be-processed order request, a target task identifier in an obtained task request parameter is an 8-bit digital identifier, and filtering by the bloom filter indicates that the to-be-processed order request is an invalid request.

In another specific embodiment provided by the present application, a 12-bit digital identifier is set in the bloom filter, where the first 4 bits are a year identifier, and in the obtained task request parameters of the to-be-processed order request, although the target task identifier is the 12-bit digital identifier, the first 4 bits are not the year identifier, and it may also be determined that the to-be-processed order request is an invalid request.

In another specific embodiment provided by the present application, a 12-bit numerical identifier is set in the bloom filter, where the first 4 bits are a year identifier, 5-6 bits are a month identifier, and 7-12 bits are a serial number, and in the obtained task request parameters of the to-be-processed order request, the name of the target task identifier conforms to the rule in the bloom filter, and it may be preliminarily determined that the to-be-processed order request is an effective request.

It should be noted that, in the foregoing determination process, the order of the verification is not limited, and in order to better save the computing resources, it is preferable that whether the target user identifier is the registered user is verified with the highest priority, then whether the target task identifier meets the preset identifier rule is determined, and finally, whether the target user identifier exists in the user identifier set corresponding to the target task is determined. Only if each verification passes can the pending order request be determined to be a valid request.

With continuing reference to FIG. 1, step 106: and under the condition that the order request to be processed is determined to be an effective request, updating the quantity information of the target tasks in the business key value database, sending the order request to be processed to a business database, and generating a business order corresponding to the order request to be processed in the business database, wherein business data in the business database are cached in the business key value database.

After the pending order request is determined to be an effective request, it is described that a corresponding service order can be generated for the pending order request, specifically, the method can be divided into two parts, one of which is to update the quantity information of the target tasks in the service key value database, that is, update the inventory information in the service key value database, so that whether the inventory of the target tasks still exists can be determined according to the service key value database, frequent access to the service database is avoided, and the I/O access frequency of the service database is reduced. Secondly, the order request to be processed is sent to a business database, and a business order corresponding to the order request to be processed is generated in the business database.

It should be noted that the processing in the service key database and the processing in the service database are two branches of parallel processing, which do not affect each other.

The processing of the business key database and the processing of the business database are explained and explained below, respectively.

In a specific embodiment provided by the present application, the updating the quantity information of the target tasks in the business key value database includes:

acquiring the current quantity information of the target tasks in the business key value database;

under the condition that the current quantity information is not 0, determining target quantity information according to the current quantity information and the quantity of unprocessed tasks in the order request to be processed, and updating the quantity information of the target tasks according to the target quantity information;

and under the condition that the current quantity information is 0, ending the target task.

In practical application, when it is determined that the order request to be processed is an effective request, the quantity information corresponding to the target task in the service key value database needs to be updated. The quantity information (namely inventory information) corresponding to the target task is stored in the business key value database, the inventory information in the business key value database is updated in real time, the inventory information of the target business can be conveniently and rapidly determined, and the user can be conveniently and timely informed when the inventory is cleared.

When the current quantity information corresponding to the target task in the business key value database is 0, it indicates that the inventory of the target task is cleared, and a corresponding business order cannot be created in the business key value database.

And when the current quantity information corresponding to the target tasks in the business key value database is not 0, acquiring the number of unprocessed tasks in the order request to be processed, and determining the target quantity information of the target tasks according to the current quantity information and the number of the unprocessed tasks in the order to be processed. The number information (stock information) of the target task is updated with the target number information. The current quantity information specifically refers to quantity information before updating, and the target quantity information specifically refers to updated quantity information. For example, if the current quantity information of the target tasks is the remaining 50, and 5 tasks are requested in the to-be-processed order request, it may be determined that the target quantity information is 45 according to the current quantity information 50 and the task quantity 5 in the to-be-processed order request, and it may be determined that there are 45 stock information of the target service. It should be noted that, in the business key value database, the quantity information of the target task is deducted through a distributed lock mode.

In a specific embodiment provided by the present application, sending the to-be-processed order request to a service database includes:

sending the order request to be processed to a service database through distributed message queue middleware;

and generating message sending information corresponding to the order request to be processed, and storing the message sending information to a message sending table.

After the inventory information is updated in the business key value database, a business order corresponding to the to-be-processed order needs to be generated in the business database, wherein the business order is specifically a business order generated after the to-be-processed order is distributed with tasks. Therefore, the pending order request needs to be sent to the service database, and specifically, the pending order request may be sent to the service database through a distributed message queue middleware (rockmq), and the message sending information is stored in a message sending table in the rockmq. The information in the message sending information specifically refers to that the order request to be processed has been sent to the service database, and the information specifically refers to related information sent by the message.

In a specific embodiment provided by the present application, an order request message of an order request to be processed is sent to a service database through a rockmq, message sending information corresponding to the order request message is generated, and the message sending information is stored in a message sending table corresponding to the rockmq.

In a specific embodiment provided by the present application, before generating a service order corresponding to the to-be-processed order request in the service database, the method includes:

judging whether the order request to be processed is a repeated order request;

if yes, deleting the order request to be processed;

and if not, generating a business order corresponding to the order request to be processed in the business database.

The service database is a database used for storing service data corresponding to a target task, and after receiving an order request message sent by the middleware, the service database needs to determine whether the order request to be processed is a repeated order request, where a repeated order request specifically means that, in actual application, a user continuously sends multiple identical requests, and needs to determine whether the request is a previously processed request, if so, it indicates that a service order corresponding to the request to be processed has been generated previously, and if not, the request does not need to be processed, the order request to be processed can be ignored, and if not, a service order corresponding to the order request to be processed needs to be generated in the service database.

In an embodiment provided by the present application, determining whether the to-be-processed order request is a repeat order request includes:

determining whether order processing information corresponding to the to-be-processed order request is stored in the business key value database; or determining whether the message sending information corresponding to the order request to be processed is stored in the message sending table.

Specifically, there are two ways to determine whether the to-be-processed order request is a repeat order request, one way is to store the order processing information of the to-be-processed order request in the service key value database after the to-be-processed order request is processed, so as to confirm that the to-be-processed order request is processed, and when the to-be-processed order request needs to be processed, it needs to determine whether the to-be-processed order request is a repeat request. Whether order processing information corresponding to the to-be-processed order request exists or not can be inquired in the business key value database, and if the order processing information exists, the to-be-processed order request is a repeated request.

The other method is to query whether there is message sending information corresponding to the to-be-processed order request in a message sending table corresponding to the rockmq, and if there is message sending information corresponding to the to-be-processed order in the message sending table, it is indicated that the to-be-processed order has been sent to the service database for corresponding processing, and the current to-be-processed order request is a repeat request.

It should be noted that, in order to avoid additional I/O overhead caused by an invalid pending order request reaching the service database, the step of determining whether the pending order request is a repeat order request further ensures that the pending order requests sent to the service database are all valid requests before sending the pending order request to the service database, thereby improving the processing efficiency of the service database, reducing the access pressure of the service database, and shortening the response time of the system.

In practical applications, the business demander may also set a feedback time for the target task, for example, the business demander completes the target task within 1 day, completes the target task within 12 hours, or the business demander may also have some other limit conditions for the target task, and if the user cannot complete the business order according to the requirements specified by the business demander, the business order that is not completed by the user needs to be released to be completed by another person, and based on this, in a specific embodiment provided in this application, the method further includes:

determining a service order to be released in the service database;

and releasing the business orders to be released, and updating the quantity information of the target tasks in the business key value database according to the quantity of the business orders to be released.

The service order to be released specifically refers to a service order which is not completed by the user according to the requirement, and the service order to be released needs to be distributed again and completed by other users. And determining that the mode of the service order to be released is related to the specification of the service demand side, and when the user does not complete the service order within the requirement specified by the service demand side after obtaining the service order, determining that the service order is the service order to be released. For example, in a compliance detection task, a business requiring party specifies that a business order must be completed within 1 day of receiving the business order. After receiving the service order, a certain user does not complete the service order within 1 day, and the user cannot execute the service order any more, and needs to submit the task of the service order to other users for execution, and the service order is the service order to be released at this time.

After the service order to be released is determined, the service order to be released needs to be released, and the task in the service order to be released is added to the order inventory again, it should be noted that, in the present application, releasing the service order to be released may be deleting the service order to be released, or marking the service order to be released as a deleted state, which is not limited in the present application. The operation of deleting the service order to be released is performed in the service database.

After the service order to be released is deleted, the inventory of the quantity corresponding to the service order to be released is released in the service database, that is, the quantity information of the target task can be updated in the service key value database according to the released inventory information. For example, after the service order to be released is determined, the service order to be released is deleted, 4 pieces of order inventory corresponding to the service order to be released are obtained, and 4 pieces of quantity information of the target task are added in the service key value database, so that other users can apply for the target task.

In another specific embodiment provided herein, the method further comprises:

and deleting the order request to be processed under the condition that the order request to be processed is determined to be an invalid request.

If the order request to be processed is determined to be an invalid request through the processing of the steps, the order request to be processed can be directly deleted, and the business database does not need to be accessed based on the order request to be processed, so that the access frequency of the business database is reduced, and the pressure of the business database is reduced.

The service request processing method provided by the application receives a to-be-processed order request aiming at a target task, wherein the to-be-processed order request carries task request parameters; verifying the validity of the order request to be processed in a business key value database according to the task request parameters; and under the condition that the to-be-processed order request is determined to be an effective request, updating the quantity information of the target tasks in the business key value database, simultaneously sending the to-be-processed order request to a business database, and generating a business order corresponding to the to-be-processed order request in the business database, wherein business data in the business database are cached in the business key value database. By the method, the service data are synchronized to the service key value database from the service database, I/O interaction of the order request to be processed is carried out in the service key value database, direct access to the service database is avoided by utilizing the characteristic that the data in the service key value database is stored in the memory, the effective order request to be processed is sent to the service database for actual service processing, the access I/O of the service database is reduced, the problem of slow response and even overtime is solved, and the use experience of a user is improved.

Referring to fig. 4, fig. 4 is a schematic diagram of a system architecture of a service request processing method according to an embodiment of the present application.

As shown in fig. 4, the service request processing method is applied to a server in which data pre-heating and filter pre-loading are performed in advance.

The data preheating process specifically refers to performing primary verification on all registered users in advance, screening out users meeting the task, and storing the users in a service key value database, for example, 5000 registered users in a task platform. The method comprises the steps that a business data demanding party issues business tasks according to business demands of the business data demanding party, user screening rules are set in the business tasks, 5000 registered users are screened through the user screening rules, 200 users meeting requirements are screened, user identifications of the 200 users are stored in a business key value database in advance, the business key value database is a non-relational database, and cache data of the business data in the business database are cached in the business key value database in advance.

The filter preloading specifically means creating a filter in advance, and preloading a data type with obvious exception in the filter, for example, specifying an order request as an 8-digit number, and the like, in practical application, the filter preferably uses a bloom filter, the screening precision of the bloom filter may be set according to an actual situation, the higher the screening precision is, the higher the performance consumption is, and the lower the screening precision is, the lower the performance consumption is.

After data preheating and filter preloading, the order request to be processed can be processed, the server receives the order request to be processed, and then the order request to be processed which obviously does not accord with the filter rule is filtered out through filter verification. And then, the order request to be processed is subjected to data verification of the business key value database.

Under the condition that the business key value database verifies that the order request to be processed fails, ending the order request to be processed; under the condition that the service key value database verifies that the order request to be processed is successful, performing parallel processing on two steps, wherein in the first step, the inventory in the service database is reduced through distributed locking; secondly, the message is sent to a service database through the message queue middleware, before the user order is generated, whether the message is a repeated message is verified, namely whether the message is processed before, and if not, the corresponding user order is generated according to the message.

According to the service request processing method, the service data are cached from the service database to the cached service key value database in advance, data preheating and filter preloading are carried out in advance, the order requests to be processed are processed in the service key value database preliminarily, the problem that the pressure of the service database is too large under the multi-user high-concurrency scene is solved, the system response time is shortened, and the processing efficiency is improved.

Fig. 5 is a flowchart illustrating a service request processing method applied to a task publishing platform scenario, where the service request processing method is described by taking a preemptive example for an annotated task M in a task publishing platform, and includes steps 502 to 526.

Step 502: and releasing the labeling task, wherein the labeling task carries a task filtering rule.

In this embodiment, a business demander needs to train an artificial intelligence model and 10000 image annotation data, so that the business demander issues an image annotation task on an annotation task platform, and it is specified that a user score reaches 5000 points in the platform, and the user has an image processing field label.

The 10000 image labeling data tasks are rewarded with 1 star for each labeling task, and users meeting the conditions can send order requests for the labeling tasks.

Step 504: and acquiring an initial user identifier set, and creating a thread pool corresponding to the task filtering rule.

In this embodiment, a set of all users registered on the annotation task platform is obtained, 5000 people are counted, a thread pool consisting of 5 threads is created, and the thread pool is used for screening and filtering 5000 people, and users who meet the point of 5000 and have image processing domain labels are screened out.

Step 506: and adding the user identifications in the initial user identification set to the filtering task queue.

In this embodiment, the user id of the 5000 people is added to a filtering task queue, and the filtering task queue is used for inputting the user id into the thread pool.

Step 508: and reading user identifications from a filtering task queue based on the thread pool for filtering, and adding the user identifications meeting the task filtering rule to a user identification set.

In this embodiment, the thread pool reads the user identifier from the filtering task queue, acquires the user attribute information according to the user identifier, determines whether the user meets the task filtering rule according to the user attribute information, and adds the user identifier meeting the task filtering rule to the user identifier set.

Step 510: and starting the Redis database, synchronizing the service data in the service database to the Redis database, and adding the user identifier set corresponding to the labeling task M to the Redis database.

In this embodiment, a Redis database is started, service data is read from the service database according to a preset time period, and the service data is synchronized to the Redis database. Meanwhile, the user identification set corresponding to the labeling task M is also added to the Redis database, so that retrieval and verification can be directly performed from the Redis database without accessing a service database when users are subsequently screened.

Step 512: pre-loading a bloom filter, wherein order request filtering rules are set in the bloom filter.

In this embodiment, a bloom filter is further provided, and the to-be-processed orders submitted by some abnormal channels are filtered by setting order request filtering rules in the bloom filter, and the bloom filter has 2 characteristics: 1. data that does not exist in the filter, which must not exist in the database; 2. the data in the filter has a certain probability of not existing in the database. For example, the data identifier in the service database is an 8-digit number, and the data identifier in the task request parameter in the pending order request includes a letter, so that the pending order request does not conform to the filtering rule of the bloom filter, and the pending order request can be ended. The bloom filter can preliminarily screen the obviously abnormal order requests to be processed, and the processing pressure of the server is relieved. In practical application, the bloom filter preliminarily screens the order requests to be processed, and if the screening precision is higher, the performance consumption is higher; the lower the screening accuracy, the lower the performance consumption.

Step 514: receiving a to-be-processed order request a for the labeling task M, wherein the to-be-processed order request a carries task request parameters such as target user identification, target task quantity and the like.

In this embodiment, taking an example that a user a wants to receive 6 tagged tasks in the tagged tasks M, the user a needs to send a to-be-processed order request a for the tagged tasks M, where the to-be-processed order request a at least carries task request parameters such as a target user identifier, user a, a target task identifier, tagged tasks M, and a target task number of-6.

Step 516: and judging whether the target user identifier is in the user identifier set, if so, executing a step 518, and if not, ending.

In this embodiment, after receiving a to-be-processed order request a sent by a user a, it may be determined whether the user a is in a user identifier set corresponding to the annotation task M, where the user identifier set is stored in a Redis database, so that the determination in this step is performed in the Redis database, and if the user a exists in the user identifier set, it indicates that the user a has a qualification for getting the annotation task M; and if the user A is not in the user identifier set, the user A cannot get the labeling task M.

Step 518: and filtering and verifying the target task identifier through the bloom filter, if the target task identifier passes through the bloom filter, executing the step 520, and if the target task identifier does not pass through the bloom filter, ending the step.

In this embodiment, if the user a has a qualification for getting the labeling task M, it further needs to determine whether the order request a to be processed is a valid order according to the bloom filter, specifically, the target task identifier may be verified, if the verification is passed, it indicates that the order is a valid order, the subsequent steps may be continuously executed, and if the verification is not passed, it indicates that the order is an invalid order, and the request is ended.

Step 520: and judging whether the order request a to be processed is a repeated message or not through the Redis database, if not, executing the step 522, and if so, ending.

In this embodiment, after the foregoing steps, it is further determined whether the order request a to be processed is a repeat message, that is, whether the order request a to be processed has already initiated a request before, specifically, it may be queried in a Redis database whether a task getting request sent by the user a for the annotation task M exists, if so, it indicates that the user a has got the task, and if not, it belongs to repeat getting, and if not, the subsequent operation steps are executed.

Step 522: and determining whether the inventory of the labeling task M is sufficient or not according to the target task quantity, if so, executing a step 524, and if not, ending.

In this embodiment, after the verification passes, it is further determined whether the inventory of the annotation task M is sufficient according to the target number of tasks in the order request a to be processed, for example, the user a wants to receive 6 annotation tasks, but if the inventory of the annotation task M is only 2, the inventory is insufficient, and if the inventory of the annotation task M is 20, the inventory of the annotation task M is sufficient, and only if the inventory is sufficient, the subsequent processing work can be performed.

Step 524: and reducing the stock corresponding to the target task quantity in the Redis database, and simultaneously sending the order request a to be processed to a service database through the RocketMQ.

In the embodiment, when the inventory is sufficient, the corresponding inventory corresponding to the target task quantity is deducted in the Redis database through a distributed lock mode, and meanwhile, the pending order request a is sent to the service database through the distributed message middleware RocktMQ. At this time, the really effective pending order request a is sent to the service database to complete the IO request of the service database once.

Step 526: and generating a corresponding business order for the target user identification according to the order request a to be processed in a business database.

In this embodiment, in the service database, the corresponding service order may be generated for the target user a according to the to-be-processed order request a.

According to the method provided by the application, the verification in the business database is carried out in the Redis database in advance by setting the Redis database, so that the resource waste caused by invalid orders to be processed of the business database is reduced, the access efficiency of the business database is improved, and the pressure of the business database is relieved. The use experience of the user is improved.

Corresponding to the foregoing method embodiment, the present application further provides an embodiment of a service request processing apparatus, and fig. 6 shows a schematic structural diagram of the service request processing apparatus according to an embodiment of the present application. As shown in fig. 6, the apparatus includes:

a receiving module 602, configured to receive a to-be-processed order request for a target task, where the to-be-processed order request carries task request parameters;

a verification module 604 configured to verify validity of the pending order request in a business key-value database according to the task request parameter;

the processing module 606 is configured to, when it is determined that the to-be-processed order request is an effective request, update the quantity information of the target tasks in the business key value database, send the to-be-processed order request to a business database, and generate a business order corresponding to the to-be-processed order request in the business database, where business data in the business database is cached in the business key value database.

Optionally, the apparatus further comprises:

the issuing module is configured to issue the target task, wherein the target task carries a task filtering rule; the determining module is configured to determine a user identification set corresponding to the target task based on the task filtering rule; an adding module configured to add the set of user identifications to the business key value database.

Optionally, the verification module 604 is further configured to:

acquiring a target user identifier corresponding to the to-be-processed order request in the task request parameter;

judging whether the target user identification exists in a user identification set corresponding to the target task;

if so, determining the order request to be processed as an effective request;

Optionally, the verification module 604 is further configured to:

judging whether the target task identifier accords with a preset identifier rule or not;

if so, determining the order request to be processed as an effective request;

Optionally, the verification module 604 is further configured to:

verifying whether the target user identification is a registered user;

if so, determining the order request to be processed as an effective request;

Optionally, the determining module is further configured to:

Optionally, the processing module 606 is further configured to:

and ending the target task under the condition that the current quantity information is 0.

Optionally, the processing module 606 is further configured to:

and generating message sending information corresponding to the order request to be processed, and storing the message sending information to a message sending table. Optionally, the processing module 606 is further configured to:

judging whether the order request to be processed is a repeated order request;

if yes, deleting the order request to be processed;

and if not, generating a service order corresponding to the order request to be processed in the service database.

Optionally, the processing module 606 is further configured to:

determining a service order to be released in the service database;

The service request processing device receives a to-be-processed order request aiming at a target task, wherein the to-be-processed order request carries task request parameters; verifying the validity of the order request to be processed in a business key value database according to the task request parameters; and under the condition that the order request to be processed is determined to be an effective request, updating the quantity information of the target tasks in the business key value database, sending the order request to be processed to a business database, and generating a business order corresponding to the order request to be processed in the business database, wherein business data in the business database are cached in the business key value database. Through the device provided by the application, the service data are synchronized to the service key value database from the service database, I/O interaction of the order request to be processed is carried out in the service key value database, the characteristic that the data in the service key value database is stored in the memory is utilized, direct access to the service database is avoided, the effective order request to be processed is sent to the service database to carry out actual service processing, the access I/O of the service database is reduced, the problem of slow response and even overtime is solved, and the use experience of a user is improved.

The foregoing is a schematic scheme of a service request processing apparatus according to this embodiment. It should be noted that the technical solution of the service request processing apparatus and the technical solution of the service request processing method belong to the same concept, and details that are not described in detail in the technical solution of the service request processing apparatus can be referred to the description of the technical solution of the service request processing method.

It should be noted that the components in the device claims should be understood as functional blocks which are necessary to implement the steps of the program flow or the steps of the method, and each functional block is not actually defined by functional division or separation. The device claims defined by such a set of functional modules should be understood as a functional module framework that mainly implements the solution by means of a computer program described in the specification, and should not be understood as a physical device that mainly implements the solution by means of hardware.

Fig. 7 illustrates a block diagram of a computing device 700 provided according to an embodiment of the present application. Components of the computing device 700 include, but are not limited to, a memory 710 and a processor 720. Processor 720 is coupled to memory 710 via bus 730, and database 750 is used to store data.

Computing device 700 also includes access device 740, access device 740 enabling computing device 700 to communicate via one or more networks 760. Examples of such networks include the Public Switched Telephone Network (PSTN), a Local Area Network (LAN), a Wide Area Network (WAN), a Personal Area Network (PAN), or a combination of communication networks such as the internet. Access device 740 may include one or more of any type of network interface (e.g., a Network Interface Card (NIC)) whether wired or wireless, such as an IEEE802.11 Wireless Local Area Network (WLAN) wireless interface, a worldwide interoperability for microwave access (Wi-MAX) interface, an ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a bluetooth interface, a Near Field Communication (NFC) interface, and so forth.

In one embodiment of the application, the above-described components of the computing device 700 and other components not shown in fig. 7 may also be connected to each other, for example, by a bus. It should be understood that the block diagram of the computing device structure shown in FIG. 7 is for purposes of example only and is not limiting as to the scope of the present application. Those skilled in the art may add or replace other components as desired.

Computing device 700 may be any type of stationary or mobile computing device, including a mobile computer or mobile computing device (e.g., tablet computer, personal digital assistant, laptop computer, notebook computer, netbook, etc.), mobile phone (e.g., smartphone), wearable computing device (e.g., smartwatch, smart glasses, etc.), or other type of mobile device, or a stationary computing device such as a desktop computer or PC. Computing device 700 may also be a mobile or stationary server.

Wherein, the processor 720 implements the steps of the service request processing method when executing the computer instructions.

The above is an illustrative scheme of a computing device of the present embodiment. It should be noted that the technical solution of the computing device and the technical solution of the service request processing method belong to the same concept, and details that are not described in detail in the technical solution of the computing device can be referred to the description of the technical solution of the service request processing method.

An embodiment of the present application further provides a computer-readable storage medium, which stores computer instructions, and when executed by a processor, the computer instructions implement the steps of the service request processing method described above.

The above is an illustrative scheme of a computer-readable storage medium of the embodiment. It should be noted that the technical solution of the storage medium belongs to the same concept as the technical solution of the service request processing method, and details that are not described in detail in the technical solution of the storage medium can be referred to the description of the technical solution of the service request processing method.

The embodiment of the application discloses a chip, which stores computer instructions, and the computer instructions, when executed by a processor, implement the steps of the service request processing method as described above.

The foregoing description of specific embodiments of the present application has been presented. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims can be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.

The computer instructions comprise computer program code which may be in source code form, object code form, an executable file or some intermediate form, or the like. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, usb disk, removable hard disk, magnetic disk, optical disk, computer Memory, read-Only Memory (ROM), random Access Memory (RAM), electrical carrier wave signals, telecommunications signals, software distribution medium, and the like. It should be noted that the computer-readable medium may contain suitable additions or subtractions depending on the requirements of legislation and patent practice in jurisdictions, for example, in some jurisdictions, computer-readable media may not include electrical carrier signals or telecommunication signals in accordance with legislation and patent practice.

It should be noted that, for the sake of simplicity, the above-mentioned method embodiments are described as a series of acts or combinations, but those skilled in the art should understand that the present application is not limited by the described order of acts, as some steps may be performed in other orders or simultaneously according to the present application. Further, those skilled in the art should also appreciate that the embodiments described in the specification are preferred embodiments and that the acts and modules referred to are not necessarily required in this application.

In the above embodiments, the descriptions of the respective embodiments have respective emphasis, and for parts that are not described in detail in a certain embodiment, reference may be made to related descriptions of other embodiments.

The preferred embodiments of the present application disclosed above are intended only to aid in the explanation of the application. Alternative embodiments are not exhaustive and do not limit the invention to the precise embodiments described. Obviously, many modifications and variations are possible in light of the teaching of this application. The embodiments were chosen and described in order to best explain the principles of the application and its practical application, to thereby enable others skilled in the art to best understand the application and its practical application. The application is limited only by the claims and their full scope and equivalents.

Claims

1. A service request processing method is characterized by comprising the following steps:

verifying the validity of the order request to be processed in a business key value database according to the task request parameters;

and under the condition that the order request to be processed is determined to be an effective request, updating the quantity information of the target tasks in the business key value database, sending the order request to be processed to a business database, and generating a business order corresponding to the order request to be processed in the business database, wherein business data in the business database are cached in the business key value database.

2. The method of claim 1, wherein prior to receiving a pending order request for a target task, the method comprises:

releasing the target task, wherein the target task carries a task filtering rule;

determining a user identification set corresponding to the target task based on the task filtering rule;

and adding the user identification set to the service key value database.

3. The method of claim 2, wherein verifying the validity of the pending order request in a business key database based on the task request parameters comprises:

if so, determining the order request to be processed as an effective request;

4. The method of claim 1 or 3, wherein the method further comprises:

if so, determining the order request to be processed as an effective request;

5. The method of claim 3, wherein prior to determining whether the target user identification is present in the set of user identifications corresponding to the target task, the method further comprises:

verifying whether the target user identification is a registered user;

if so, determining the order request to be processed as an effective request;

6. The method of claim 2, wherein determining the set of user identifications corresponding to the target task based on the task filtering rules comprises:

7. The method of claim 1, wherein updating the quantity information of the target task in the business key-value database comprises:

8. The method of claim 1, wherein the method further comprises:

9. The method of claim 1, wherein sending the pending order request to a business database comprises:

10. The method of claim 9, wherein before generating the service order corresponding to the pending order request in the service database, the method comprises:

judging whether the order request to be processed is a repeated order request;

if yes, deleting the order request to be processed;

11. The method of claim 10, wherein determining whether the pending order request is a repeat order request comprises:

determining whether order processing information corresponding to the to-be-processed order request is stored in the business key value database; or

And determining whether the message sending information corresponding to the order request to be processed is stored in the message sending table.

12. The method of claim 1, wherein the method further comprises:

determining a service order to be released in the service database;

13. A service request processing apparatus, comprising:

14. A computing device comprising a memory, a processor, and computer instructions stored on the memory and executable on the processor, wherein the processor implements the steps of the method of any one of claims 1-12 when executing the computer instructions.

15. A computer-readable storage medium storing computer instructions, which when executed by a processor, perform the steps of the method of any one of claims 1 to 12.