A data request processing method, device, equipment and medium

Abstract

The present invention relates to the field of data processing technology, and discloses a method, apparatus, device, and medium for processing data requests, including: the user end, in response to initial request information input by the user, performs tagging processing on the initial request information to generate data request information carrying an identifier; the user end sends the data request information to the server end; the server end parses and processes the data request information to obtain request type information corresponding to the data request information; if the data request information is real-time transaction request information, the server end sends the real-time transaction request information to a master server for processing; if the data request information is non-real-time transaction request information, the server end sends the non-real-time transaction request information to a slave server for processing. The present invention can improve the server's response efficiency to users' data requests in real-time transactions.

Description

Technical Field

[0001] The present invention relates to the field of data processing technology, and in particular to a method, device, equipment and medium for processing a data request. Background Art

[0002] With the development of internet businesses, business data has increased significantly. Clients from ordinary users, developers, and operations personnel initiate various data requests to servers to read or modify data in databases. For example, developers initiate data requests when viewing table structures, ordinary users initiate data requests when viewing historical consumption records, and ordinary users initiate data requests when making payments. For data requests for transactions like payments and order placement, users often expect real-time, synchronized data feedback.

[0003] However, when the server processes a large number of data requests, the server's database load is too heavy, and the data processing efficiency is reduced, making it difficult to respond to users' data requests in some real-time transactions in a timely manner, reducing the user experience. Summary of the Invention

[0004] In view of the above-mentioned shortcomings of the prior art, an object of the present invention is to provide a method, apparatus, device and medium for processing data requests, which can improve the response efficiency of the server to the data requests of users in real-time transactions.

[0005] In a first aspect, the present invention provides a method for processing a data request, comprising:

[0006] The user terminal performs tagging processing on the initial request information input by the user in response to the initial request information, and generates data request information carrying an identifier, wherein the identifier includes a real-time transaction identifier and a non-real-time transaction identifier;

[0007] The user terminal sends the data request information to the server terminal;

[0008] The server parses the data request information to obtain request type information corresponding to the data request information, wherein the request type information includes real-time transaction request information and non-real-time transaction request information;

[0009] If the data request information is a real-time transaction request information, the server sends the real-time transaction request information to the main server for processing;

[0010] If the data request information is non-real-time transaction request information, the server sends the non-real-time transaction request information to the slave server for processing.

[0011] In a second aspect, the present invention provides a data request processing device, wherein the user terminal includes:

[0012] a marking module, configured for the user terminal to mark the initial request information in response to the initial request information input by the user, and generate data request information carrying an identifier, wherein the identifier includes a real-time transaction identifier and a non-real-time transaction identifier;

[0013] A transmission module, configured for the user end to send the data request information to the server end;

[0014] a parsing module, configured for the server to parse the data request information to obtain request type information corresponding to the data request information, wherein the request type information includes real-time transaction request information and non-real-time transaction request information;

[0015] a processing module, configured to, if the data request information is real-time transaction request information, send the real-time transaction request information to a main server for processing by the service end;

[0016] The distribution module is configured to, if the data request information is non-real-time transaction request information, cause the server to send the non-real-time transaction request information to a slave server for processing.

[0017] In a third aspect, the present invention provides a computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the above-mentioned data request processing method when executing the computer program.

[0018] In a fourth aspect, the present invention provides a computer-readable storage medium storing a computer program, which implements the steps of the above-mentioned data request processing method when executed by a processor.

[0019] In the scheme implemented by the above-mentioned data request processing method, device, equipment and medium, the request type of the data request information can be obtained based on the identifier pre-carried by the user's data request information. If the data request information is a real-time transaction request, the data request information can be sent to the master server to perform a data request operation on the master database. If the data request information is a non-real-time transaction request, the data request information can be sent to the slave server to perform a data request operation on the slave server. The present invention distributes real-time transaction requests and non-real-time transaction requests to different servers for processing by setting up multiple servers, thereby reducing the database load and improving data processing efficiency, thereby improving the server's response efficiency to users' data requests in real-time transactions. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0021] Figure 1 This is a schematic diagram of an application environment of a method for processing a data request in an embodiment of the present invention;

[0022] Figure 2 1 is a flow chart of a method for processing a data request in one embodiment of the present invention;

[0023] Figure 3 yes Figure 2 A schematic flow chart of a specific implementation of step S10;

[0024] Figure 4 yes Figure 2 A schematic flow chart of a specific implementation of step S30;

[0025] Figure 5 yes Figure 2 A schematic flow chart of a specific implementation method after step S40;

[0026] Figure 6 yes Figure 5 A schematic flow chart of a specific implementation of step S52;

[0027] Figure 7 yes Figure 5 A schematic flow chart of a specific implementation method after step S53;

[0028] Figure 8 is a structural diagram of a data request processing device in one embodiment of the present invention;

[0029] Figure 9 is a structural diagram of a computer device in one embodiment of the present invention;

[0030] Figure 10 FIG. 2 is another structural diagram of a computer device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0031] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making any creative efforts shall fall within the scope of protection of the present invention.

[0032] See also Figure 1-10 It should be noted that the diagrams provided in this embodiment are merely schematic illustrations of the basic concept of the present invention. Therefore, the diagrams only show components related to the present invention and are not drawn according to the number, shape, and size of components in actual implementation. In actual implementation, the type, quantity, and proportion of each component may be changed arbitrarily, and the component layout may also be more complex.

[0033] First, it should be noted that with the development of internet services, end-users can initiate various data requests to servers to read or modify data in databases. When end-users make data requests to servers, they can accept a certain data delay for all data requests in transactions such as operations personnel retrieving yesterday's task forms, ordinary users viewing historical payment records, and developers reviewing database table structures. Data requests for these transactions can be set as non-real-time transaction requests. In transactions such as ordinary user orders and payments, some real-time data requests occur. For these real-time data requests, users expect extremely fast data feedback. For example, in an ordinary user order transaction, when initiating a real-time data request to view order results, users expect extremely fast order data feedback. If data is delayed, users cannot immediately view order results, resulting in a reduced user experience. For transactions involving such real-time data requests, all data requests within the transaction can be set as real-time transaction requests. However, when servers process a large number of data requests, data processing efficiency decreases, making it difficult to respond to users' real-time transaction requests in a timely manner, thus reducing the user experience. To address the above issues, embodiments of the present invention provide a method for processing data requests.

[0034] Specifically, see Figure 1As shown, the user terminal 110 can communicate with the server terminal 120 through the network. The users of the user terminal 110 can be developers, operators and ordinary users. The user terminal 110 can pre-add an identifier to the initial request information input by the user, generate data request information and send it to the server terminal 120, so that the server terminal 120 can perform data diversion based on the identifier. Furthermore, the server terminal 120 can obtain the request type information corresponding to the data request information based on the identifier carried by the data request information. For real-time transaction request information, the real-time transaction request information is sent to the main server 130, so that the main server 130 executes the request operation corresponding to the real-time transaction request information. If the data request information is non-real-time transaction request information, the non-real-time transaction request information is sent to the slave server 140, so that the slave server 140 executes the request operation corresponding to the non-real-time transaction request information. The present invention distributes real-time transaction request information and non-real-time transaction request information to the master server 130 and the slave server 140 for processing, respectively. The slave server 140 synchronizes the data in the master server 130 based on the master-slave synchronization rules, reducing the data load of the master server 130, thereby improving the data response efficiency of the master server 130 for real-time transaction request information. Moreover, even if the slave server 140 crashes or the slave server 140 fails to synchronize the data in the master server 130 in a timely manner, it will only affect the data request of the non-real-time transaction request information for the slave server 140. The master server 130 can still quickly process the real-time transaction request sent by the user terminal, ensuring the user experience. Among them, the user terminal 110 can be, but is not limited to, various personal computers, laptops, smart phones, tablet computers, and portable wearable devices. The present invention is described in detail below through specific embodiments.

[0035] See also Figure 2 As shown, Figure 2 A flowchart of a method for processing a data request provided in an embodiment of the present invention is provided. The method for processing a data request may include the following steps:

[0036] Step S10: The user terminal, in response to the initial request information input by the user, performs tagging processing on the initial request information to generate data request information carrying an identifier, wherein the identifier includes a real-time transaction identifier and a non-real-time transaction identifier;

[0037] Step S20: The user terminal sends the data request information to the server terminal;

[0038] Step S30: The server parses the data request information to obtain request type information corresponding to the data request information, wherein the request type information includes real-time transaction request information and non-real-time transaction request information;

[0039] Step S40: If the data request information is a real-time transaction request information, the server sends the real-time transaction request information to the main server for processing;

[0040] Step S50: If the data request information is non-real-time transaction request information, the server sends the non-real-time transaction request information to the slave server for processing, wherein the slave server synchronizes the data in the master server based on the master-slave synchronization rule.

[0041] In one embodiment of the present invention, when step S10 is executed, that is, the user terminal responds to the initial request information input by the user, marks the initial request information, and generates data request information carrying an identifier. Specifically, the user's initial request information can be a data request initiated when a developer queries the table structure of the database, a data request initiated when a developer retrieves a task bill, a data request initiated when an operator exports a bill, a data request initiated when a user views a consumption record list, a data request initiated when a user pays, etc. For data requests of the query data type, such as a data request initiated when querying the table structure of the database, a data request initiated when a user views a consumption record list, such data requests are query requests to the database. For data requests of the add data, delete data, and modify data type, such as a data request initiated when a user pays, such data requests will cause data changes in the database. When a user of the user terminal 110 initiates a data request to the server, it is actually a query to the data in the server's database or an add, delete, or modify operation on the data in the database.

[0042] Each initial request message is essentially request data generated in a real-time or non-real-time transaction. Initial request messages in real-time transactions can be configured as real-time transaction requests and distributed to master server 130 for processing. Initial request messages in non-real-time transactions can be configured as non-real-time transaction requests and distributed to slave server 140 for processing. To facilitate server 120's ability to distribute initial request messages in different transactions to different servers, client 110 can pre-add identifiers to the initial request messages to indicate real-time and non-real-time transaction requests.

[0043] See also Figure 3 As shown, when step S10 is executed, the user terminal, in response to the initial request information input by the user, performs tagging processing on the initial request information and generates data request information carrying an identifier. Step S10 may include the following steps:

[0044] Step S11: The user terminal performs field extraction processing on the initial request information to obtain key fields of the initial request information;

[0045] Step S12: The user terminal obtains an identifier corresponding to the key field in a preset field correspondence table based on the key field, wherein the field correspondence table includes multiple key fields and an identifier corresponding to each key field, and the identifier includes a real-time transaction identifier and a non-real-time transaction identifier.

[0046] Step S13: The user terminal adds the identifier to the initial request information to generate the data request information.

[0047] In one embodiment of the present invention, when step S11 is executed, the user terminal performs field extraction processing on the initial request information to obtain the key fields of the initial request information. Specifically, in order to facilitate subsequent data diversion based on the type of data request information, the user terminal 110 may pre-add an identifier to the initial request information to form data request information. This identifier can be used to indicate whether the corresponding data request information is a real-time transaction request or a non-real-time transaction request, so as to subsequently identify the type of data request information. It should be noted that in order to facilitate the user terminal 110 to add an identifier to the initial request information, the developer may pre-set multiple key fields and the identifier that needs to be added corresponding to each key field in the user terminal 110. After receiving the initial request information input by the user, the user terminal 110 can determine the identifier that needs to be added to the initial request information by extracting the key fields in the initial request information.

[0048] It should be understood that when the user terminal 110 performs field extraction processing on the initial request information, the position of the extracted field can be preset, for example, the 8th to 12th characters from the left. The user terminal 110 can count from the left to the right and extract the field at the preset position as the key field of the initial request information.

[0049] In one embodiment of the present invention, when executing step S12, the user terminal retrieves the identifier corresponding to the key field from a preset field correspondence table based on the key field. Specifically, the field correspondence table may be a correspondence table pre-established by developers based on statistics of daily business traffic. Developers can collect each data request from daily business and set the request type for each data request based on the user's data feedback time requirements. The request type can include real-time transaction requests and non-real-time transaction requests. Key fields representing the transaction content in each data request can be pre-set with a real-time transaction identifier, while non-real-time transaction requests can be pre-set with a non-real-time transaction identifier. Furthermore, developers can summarize the key fields and identifiers for each data request to form a field correspondence table. When a user enters a new initial data request, the key fields of the request are extracted and the identifiers corresponding to the key fields are searched in the field correspondence table to be added. For example, if the initial data request address is http: / / alipay.com / papay / pay.php, the key field may be "alipay," indicating that the primary transaction content of the initial data request is a user payment transaction. The corresponding identifier to be added is a real-time transaction identifier. For another example, the address of the initial data request is https: / / sqlserver.tencentcloudapi.com / ?Action=DescribeOrders, and the key field may be sqlserver, indicating that the main transaction content of the initial data request is a database management transaction, and the corresponding identifier is a non-real-time transaction identifier.

[0050] In one embodiment of the present invention, when step S13 is executed, the user terminal adds the identifier to the initial request information to generate the data request information. Specifically, if the address of the initial request information is http: / / alipay.com / papay / pay.php, the real-time transaction identifier that needs to be added is RT. When the user terminal adds the real-time transaction identifier RT to the initial request information, the data request information formed can be http: / / alipay.com / papay / pay.phpRT. If the address of the initial request information is https: / / sqlserver.tencentcloudapi.com / Action=DescribeOrders, the non-real-time transaction identifier that needs to be added is NRT. When the user terminal adds the non-real-time transaction identifier NRT to the initial request information, the data request information formed can be https: / / sqlserver.tencentcloudapi.com / NRTAction=DescribeOrdersNRT.

[0051] In one embodiment of the present invention, when step S20 is executed, the client sends the data request information to the server. Specifically, to ensure the server's efficient data response to real-time transaction requests, the client 110 may first send the data request information to the server 120. The server 120 may then process the real-time transaction requests separately from the non-real-time transaction requests, dispatching the real-time transaction requests to the master server 130 for processing and dispatching the non-real-time transaction requests to the slave server 140 for processing, thereby reducing the data load on the master server 130.

[0052] See also Figure 4 As shown, when step S30 is executed, the server parses the data request information to obtain the request type information corresponding to the data request information, wherein the request type information includes real-time transaction request information and non-real-time transaction request information. Specifically, step S30 may include the following steps:

[0053] Step S31: The server performs identification processing on the data request information to obtain an identifier of the data request information;

[0054] Step S32: The server determines the request type information corresponding to the data request information based on the identifier.

[0055] In one embodiment of the present invention, when step S31 and step S32 are executed, the server performs identification processing on the data request information to obtain an identifier of the data request information, and determines the request type information corresponding to the data request information based on the identifier. Specifically, the server 120 may pre-store real-time transaction identifiers and non-real-time transaction identifiers to form an identifier set. When the server 120 performs identification processing on the data request information, it may extract an identifier at a preset position in the data request information, and query the identifier character in the identifier set. If the identifier character is the same as the real-time transaction identifier, the data request information is determined to be real-time transaction request information. If the identifier is the same as the non-real-time transaction identifier, the data request information is determined to be non-real-time transaction request information.

[0056] It should be noted that for real-time transaction request information, users expect to receive real-time synchronous feedback. After identifying the real-time transaction request information, the server 120 can distribute the real-time transaction request information to the master server 130 for processing. For non-real-time transaction request information, users can accept a certain delay in the feedback time for such request information. The time delay here can be 10 milliseconds, 15 milliseconds, or other values. After identifying the non-real-time transaction request information, the server 120 can distribute the non-real-time transaction request information to the slave server 140 for processing.

[0057] In one embodiment of the present invention, when step S40 is executed, that is, if the data request information is a real-time transaction request information, the server sends the real-time transaction request information to the master server for processing. Specifically, it should be noted that in actual application services, the concurrent traffic of non-real-time transaction requests initiated by the client 110 is far greater than the concurrent traffic of real-time transaction requests. A large number of non-real-time transaction requests can easily reduce server response efficiency, affecting the user experience. To improve the response efficiency of real-time transaction requests, data request information can be pre-classified, and real-time transaction requests can be sent only to the master server 130 for processing, while non-real-time transaction request information can be sent to the slave server 140 for processing. This reduces the data load on the master server 130 and improves the response efficiency for real-time transaction request data. Even if a large number of non-real-time transaction requests causes the slave server to crash, or the slave database 140 fails to synchronize data with the master database 130 in a timely manner, only the non-real-time transaction request information will be affected. The master server 130 can still quickly process the real-time transaction request information sent by the client.

[0058] In one embodiment of the present invention, when executing step S50, if the data request information is a non-real-time transaction request information, the server sends the non-real-time transaction request information to the slave server for processing. Specifically, the non-real-time transaction request information is sent to the slave server 140 for processing to reduce the data load on the master server 130 and improve the master server 130's efficiency in responding to real-time transaction request data.

[0059] It should be noted that the database on the slave server 140 can synchronize the data of the database on the master server 130 based on the master-slave synchronization rule. The master-slave synchronization rule means that all data operations in the master server 130 are recorded in its log file, and the slave server 140 pulls the log file in the master server 130 and writes it into its own data. Through this master-slave synchronization rule, the data in the master database of the master server 130 and the slave database of the slave server 140 can be kept consistent. Since the slave server 140 needs to pull data from the master server 130, there may be a certain data delay between the data in the slave database and the master database. When receiving the data request, the slave database may not have completed the synchronization of the data in the master database, resulting in a long data feedback time. Since users can accept that the feedback data of non-real-time transaction requests is delayed within a certain range, non-real-time transaction requests can be sent to the slave server 140 for processing.

[0060] Based on the above method embodiment, the present invention reduces the data load on master server 130 by sending real-time transaction requests only to master server 130 for processing, while sending non-real-time transaction requests to slave server 140 for processing. This improves the efficiency of responding to real-time transaction requests. Furthermore, master server 130 and slave server 140 are physically isolated. If a problem occurs on slave server 140, only the data feedback for non-real-time transaction requests is affected. Master server 130 can still quickly process real-time transaction requests sent by client 110, ensuring a rapid server response to real-time transaction requests.

[0061] It's worth noting that real-time transaction requests include some immediate data requests and a large number of non-immediate data requests. It's important to understand that for immediate data requests, for example, when a user initiates a data request to view order results in a real-time transaction involving an ordinary user placing an order, the user expects extremely fast order data feedback. If data is delayed, the user cannot immediately view the order results, resulting in a reduced user experience. This type of data request is considered an immediate data request within a real-time transaction. Similarly, in a real-time transaction involving an ordinary user placing an order, when the order system initiates a data request to retrieve the user's basic information, the user may experience data delays within a certain range. This type of data request is considered a non-immediate data request within a real-time transaction. Non-immediate data requests within a real-time transaction do not require extremely fast data feedback, and processing non-immediate data requests reduces the data processing efficiency of master server 130 for immediate data requests. To further improve the processing efficiency of immediate data requests within real-time transaction requests, master server 130 can forward non-immediate data requests within the real-time transaction request information to slave server 140 for processing, thereby avoiding the centralization of non-immediate data requests within the real-time transaction request information on master server 130.

[0062] For details, please refer to Figure 5 As shown, after executing step S40, that is, if the data request information is a real-time transaction request information, the server sends the real-time transaction request information to the main server for processing, the following steps may be included:

[0063] Step S51: The main server obtains real-time transaction request information sent by the server, wherein the real-time transaction request information is either an instant data request or a non-instant data request;

[0064] Step S52: The main server identifies and processes the real-time transaction request information to determine whether the real-time transaction request information is an instant data request;

[0065] Step S53: If it is an instant data request, the primary server performs a data request operation on a preset primary database based on the real-time transaction request information, wherein the primary database runs on the primary server;

[0066] Step S54: If it is not an instant data request, the master server forwards the real-time transaction request information to the slave server.

[0067] In one embodiment of the present invention, when step S51 is executed, the main server obtains real-time transaction request information sent by the service end. It should be noted that the main server 130 can be used to process real-time transaction requests, such as all data requests in a user's order transaction. The real-time transaction requests received by the main server 130 may be instantaneous data requests or non-instantaneous data requests. For example, during the user's order process, the order system of the user terminal 110 will request the user's basic information from the server to perform the order operation. In this case, the data request for the user's basic information is a non-instantaneous data request in the real-time transaction request, and the user can accept a certain delay in the basic information feedback data. When the user completes the payment operation and requests payment result data in the order process, the user terminal 110 will also request data from the server. In this case, the data request for payment result data is an immediate data request in the real-time transaction request.

[0068] See also Figure 6 As shown, when step S52 is executed, the main server identifies and processes the real-time transaction request information to determine whether the real-time transaction request information is an instant data request. Specifically, step S52 may include the following steps:

[0069] Step S521: The main server extracts a target field at a preset position from the real-time transaction request information;

[0070] Step S522: The master server queries a preset instant field table to determine whether there is an instant field identical to the target field in the instant field table, wherein the instant field table includes a plurality of instant fields.

[0071] Step S523: If there is an instant field that is the same as the target field, the host server determines that the real-time transaction request information is an instant data request;

[0072] Step S524: If there is no instant field identical to the target field, the host server determines that the real-time transaction request information is not an instant data request.

[0073] In one embodiment of the present invention, when step S521 is executed, the primary server extracts a target field at a preset location within the real-time transaction request message. Specifically, a real-time transaction request may be represented by a string of data request information formed by the initial request message entered by the user and the real-time transaction identifier added by the user. The target field in the real-time transaction request may be a field inherent in the initial request message entered by the user, located at the target location within the real-time transaction request, and may indicate whether the real-time transaction request is an instant data request within a real-time transaction. For example, the address of the initial request message may be http: / / alipay.com / papay / pay_order02.php. The address formed by adding the real-time transaction identifier to the initial request message is http: / / alipay.com / papay / pay_order02.phpRT, and the target field may be pay_order02 within the initial request message. After receiving the real-time transaction request message, the primary server 130 may first extract the target field at a preset location, such as pay_order02, to determine whether the real-time transaction request message is an instant data request within a real-time transaction.

[0074] In one embodiment of the present invention, when step S522 is executed, the main server queries the preset instant field table to determine whether there is an instant field identical to the target field in the instant field table, and the instant field table includes multiple instant fields. Specifically, all target fields representing instant data requests can be preset in the main server 130, such as pay_order02, PAY_SUBJECTD, etc. For example, if the target field is pay_order02, it represents a data request for payment results in the order placement process. When the main server 130 finds that there is an instant field identical to the target field in the instant field table, the real-time transaction request information is an instant data request in the real-time transaction. If the target field is READ_User, it represents a data request for user basic information in the order placement process. When the main server 130 finds that there is no instant field identical to the target field in the instant field table, the real-time transaction request information is a non-instant data request.

[0075] In one embodiment of the present invention, when executing step S523, if there exists an instantaneous field that is identical to the target field, the master server determines that the real-time transaction request information is an instantaneous data request. It should be noted that when the master server 130 determines that the received real-time transaction request information is an instantaneous data request, the master server 130 directly processes the instantaneous data request and feeds back data to the server 120.

[0076] In one embodiment of the present invention, when executing step S524, if there is no real-time field identical to the target field, the master server determines that the real-time transaction request information is not a real-time data request. It should be noted that when the master server 130 determines that the received real-time transaction request information is a non-real-time data request within a real-time transaction, the non-real-time data request is forwarded to the slave server 140 for processing, further reducing the data load on the master server and improving the master server 130's efficiency in responding to real-time data requests within the real-time transaction request information.

[0077] In one embodiment of the present invention, when executing step S53, i.e., if it is an instant data request, the master server, based on the real-time transaction request information, performs a data request operation on a pre-defined master database, where the master database runs on the master server. Specifically, the master database may be a database that stores all application data in real time and runs on master server 130. If the real-time transaction request information is an instant data request within a real-time transaction, for example, a request for payment results initiated during a user payment transaction, master server 130 will retrieve the payment result data from the master database based on the instant data request and feed the payment result data back to server 120.

[0078] See also Figure 7 As shown, after executing step S53, that is, if it is an instant data request, the primary server performs a data request operation on the preset primary database based on the real-time transaction request information, the following steps may be included after step S53:

[0079] Step S531: When there is data update in the primary database, the primary server performs log backup processing on the data request operation to generate operation log data;

[0080] Step S532: The master server sends the operation log data to the slave server;

[0081] Step S533: The slave server performs data synchronization processing on the slave database based on the operation log data.

[0082] In one embodiment of the present invention, when step S531 is executed, the master server determines whether there is a data update in the master database; if there is a data update, the master server performs log backup processing on the data request operation and generates operation log data; if there is no data update, the next step of processing is not performed. It should be noted that the slave database on the slave server replicates the data of the master database on the master server so that the master database on the master server and the slave database on the slave server are consistent. When the data in the master database is updated, the updated data needs to be synchronized to the slave database.

[0083] Specifically, when master server 130 performs a data request operation on a pre-set master database based on the real-time data request information, if the real-time data request is a database query, master server 130 performs a data query on the master database and feeds the retrieved user basic information back to server 120, without causing any data updates in the master database. If the real-time data request causes data in the master database to be updated, master server 130 will need to log this data request operation and generate operation log data, which slave server 140 can then retrieve to update its own data, completing master-slave data synchronization.

[0084] In one embodiment of the present invention, when steps S532 and S533 are executed, the master server sends the operation log data to the slave server, and the slave server performs data synchronization processing on the slave database based on the operation log data. Specifically, when the master database is updated, the master server 130 needs to log the data request operation that caused the master database to be updated, generating operation log data for the slave server 140 to perform the same data operation on the slave database based on the operation log data, thereby updating the data in the slave database and completing master-slave data synchronization.

[0085] In one embodiment of the present invention, when executing step S54, if the real-time transaction request is not an immediate data request, the master server forwards the real-time transaction request information to the slave server. It should be noted that when the master server 130 determines that the received real-time transaction request information is a non-immediate data request, it forwards the non-immediate data request to the slave server 140 for processing, further reducing the data load on the master server 130 and ensuring the master server 130's efficiency in responding to immediate data requests in the real-time transaction request information.

[0086] It should be noted that there may be a connection between the immediate data requests and non-immediate data requests in a real-time transaction. For example, in a real-time transaction where an ordinary user places an order, before the user places the order, the order system will initiate a non-immediate data request to retrieve the user's basic information, and the user may receive data with a certain delay. After the user places the order, an immediate data request is initiated to view the order results, and the user expects extremely fast data feedback. However, if the retrieval of the user's basic information fails, the entire real-time transaction of placing the order cannot be completed. Therefore, by separating real-time transaction requests from non-real-time transaction requests on different servers, even if the slave server 140 crashes and is unable to process the non-immediate data request of the real-time transaction request, the data request can be directly processed by the master server 130 without further forwarding. The master server 130 can still complete the entire real-time transaction process normally, ensuring normal data feedback for the real-time transaction request.

[0087] In one embodiment of the present invention, after executing step S54, i.e., after the master server determines to forward the real-time transaction request information to the slave server for processing if the request is not an immediate data request, the following step may be included: the slave server, based on the real-time transaction request information, performs a data request operation on a preset slave database, wherein the slave database runs on the slave server. Specifically, in actual business operations, for non-immediate data requests within real-time transaction requests, the corresponding data request operation is merely a data query operation, such as a request for basic user information when placing an order or a request for user information when making a payment. Users may tolerate a certain time delay in data feedback for such requests. This time delay may be 10 milliseconds, 15 milliseconds, or another preset threshold. After receiving the non-immediate data request, the slave server may perform a data query operation corresponding to the data request on the slave database and feed the retrieved data back to the server 120, which may then transmit the data to the user terminal 110.

[0088] As can be seen, in the above scheme, by sending real-time transaction requests only to master server 130 for processing, while sending non-real-time transaction request information to slave server 140 for processing, the data load on master server 130 is reduced, and the efficiency of responding to real-time transaction request data is improved. Furthermore, master server 130 can forward non-real-time data requests within real-time transaction requests to slave server 140, further improving the efficiency of master server 130's data feedback for real-time data requests within real-time transaction requests. Furthermore, master server 130 is physically isolated from slave server 140. If a problem occurs with slave server 140, only the data feedback for non-real-time transaction requests is affected. Master server 130 can still quickly process real-time transaction request information sent by client 110, ensuring a rapid response to real-time transaction request information.

[0089] See also Figure 8 As shown, the present invention also provides a data request processing device, which corresponds to the generation method in the above embodiment. The data request processing device can include a marking module 10, a transmission module 20, a parsing module 30, a processing module 40 and a distribution module 50.

[0090] In one embodiment of the present invention, the marking module 10 can be used by the user end to perform marking processing on the initial request information in response to the initial request information input by the user, and generate data request information carrying an identifier, wherein the identifier includes a real-time transaction identifier and a non-real-time transaction identifier. The marking module 10 can be specifically used by the user end to perform field extraction processing on the initial request information to obtain the key fields of the initial request information; based on the key fields, the user end obtains the identifier corresponding to the key field in a preset field correspondence table, wherein the field correspondence table includes multiple key fields and identifiers corresponding to each key field, and the identifiers include a real-time transaction identifier and a non-real-time transaction identifier. The user end adds the identifier to the initial request information to generate the data request information.

[0091] In one embodiment of the present invention, the transmission module 20 can be used to send data request information from the user end to the server end. When the user of the user end 110 initiates a data request to the server, it actually queries the data in the server database or performs addition, deletion, and modification operations on the data in the database.

[0092] In one embodiment of the present invention, the parsing module 30 may be configured to parse the data request information on the server side to obtain request type information corresponding to the data request information, wherein the request type information includes real-time transaction request information and non-real-time transaction request information. Specifically, the parsing module 30 may be configured to identify the data request information on the server side to obtain an identifier for the data request information. Based on the identifier, the server side determines the request type information corresponding to the data request information.

[0093] In one embodiment of the present invention, processing module 40 is configured to, if the data request information is a real-time transaction request information, cause the server to send the real-time transaction request information to the master server for processing. Real-time transaction requests are sent only to master server 130 for processing, while non-real-time transaction request information is sent to slave server 140 for processing, thereby reducing the data load on master server 130 and improving the efficiency of responding to real-time transaction requests.

[0094] In one embodiment of the present invention, the distribution module 50 is configured to, if the data request information is a non-real-time transaction request information, cause the server to send the non-real-time transaction request information to a slave server for processing. Sending the non-real-time transaction request to the slave server 140 for processing reduces the data load on the master server 130 and improves the master server 130's efficiency in responding to real-time transaction requests.

[0095] The present invention provides a data request processing device. By sending real-time transaction requests only to a master server 130 for processing, while sending non-real-time transaction request information to a slave server 140 for processing, this reduces the data load on the master server 130 and improves the efficiency of responding to real-time transaction request data. Furthermore, the master server 130 and slave servers 140 are physically isolated. If a problem occurs on a slave server 140, only the data feedback for non-real-time transaction requests is affected. The master server 130 can still quickly process real-time transaction requests sent by the client 110, ensuring a rapid response to real-time transaction requests.

[0096] For specific definitions of the data request processing device, please refer to the definitions of the data request processing method above and will not be repeated here. The various modules in the above-mentioned data request processing device can be implemented in whole or in part through software, hardware, or a combination thereof. The above-mentioned modules can be embedded in or independent of the processor in the computer device in hardware form, or can be stored in the memory of the computer device in software form, so that the processor can call and execute the corresponding operations of the above-mentioned modules.

[0097] In one embodiment, a computer device is provided, which can be a server, and its internal structure diagram can be as follows: Figure 9 As shown. The computer device includes a processor, memory, network interface and database connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external client via a network connection. When the computer program is executed by the processor, it implements the functions or steps on the server side of a data request processing method.

[0098] In one embodiment, a computer device is provided. The computer device may be a client, and its internal structure diagram may be as follows: Figure 10 As shown. The computer device includes a processor, memory, a network interface, a display screen, and an input device connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external server via a network connection. When executed by the processor, the computer program implements the functions or steps on the user side of a method for processing data requests.

[0099] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the following steps are performed:

[0100] The user terminal performs tagging processing on the initial request information input by the user in response to the initial request information, and generates data request information carrying an identifier, wherein the identifier includes a real-time transaction identifier and a non-real-time transaction identifier;

[0101] The user terminal sends the data request information to the server terminal;

[0102] The server parses the data request information to obtain request type information corresponding to the data request information, wherein the request type information includes real-time transaction request information and non-real-time transaction request information;

[0103] If the data request information is a real-time transaction request information, the server sends the real-time transaction request information to the main server for processing;

[0104] If the data request information is non-real-time transaction request information, the server sends the non-real-time transaction request information to the slave server for processing, wherein the slave server synchronizes the data in the master server based on the master-slave synchronization rule.

[0105] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the following steps are implemented:

[0106] The user terminal performs tagging processing on the initial request information input by the user in response to the initial request information, and generates data request information carrying an identifier, wherein the identifier includes a real-time transaction identifier and a non-real-time transaction identifier;

[0107] The user terminal sends the data request information to the server terminal;

[0108] The server parses the data request information to obtain request type information corresponding to the data request information, wherein the request type information includes real-time transaction request information and non-real-time transaction request information;

[0109] If the data request information is a real-time transaction request information, the server sends the real-time transaction request information to the main server for processing;

[0110] If the data request information is non-real-time transaction request information, the server sends the non-real-time transaction request information to the slave server for processing, wherein the slave server synchronizes the data in the master server based on the master-slave synchronization rule.

[0111] It should be noted that the above functions or steps that can be implemented by the computer-readable storage medium or computer device can be found in the relevant descriptions of the server side and the client side in the aforementioned method embodiment. To avoid repetition, they will not be described one by one here.

[0112] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0113] Those skilled in the art will clearly understand that for the sake of convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0114] The embodiments described above are only used to illustrate the technical solutions of the present invention, rather than to limit the same. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present invention, and should all be included in the scope of protection of the present invention.

Claims

1. A method for processing a data request, characterized in that: include: In response to the initial request information input by the user, the user end matches the key fields of the initial request information with the identifiers in the preset field correspondence table, and generates data request information carrying the identifiers, wherein the identifiers include the real-time transaction identifier and the non-real-time transaction identifier; The user terminal sends the data request information to the server terminal; The server parses the data request information to obtain request type information corresponding to the data request information, wherein the request type information includes real-time transaction request information and non-real-time transaction request information; If the data request information is a real-time transaction request information, the server sends the real-time transaction request information to the master server for processing; the master server obtains the real-time transaction request information sent by the server, wherein the real-time transaction request information is either an instant data request or a non-instant data request; the master server identifies and processes the target field of the real-time transaction request information, and determines whether the real-time transaction request information is an instant data request based on a matching result between the target field and an instant field in a preset instant field table; if it is an instant data request, the master server performs a data request operation on a preset master database based on the real-time transaction request information, wherein the master database runs on the master server; if it is not an instant data request, the master server forwards the real-time transaction request information to the slave server; the key field is different from the target field; If the data request information is non-real-time transaction request information, the server sends the non-real-time transaction request information to the slave server for processing, wherein the slave server synchronizes the data in the master server based on the master-slave synchronization rule.

2. The method for processing a data request according to claim 1, wherein: The user terminal, in response to the initial request information input by the user, matches the key fields of the initial request information with the identifiers in the preset field correspondence table to generate data request information carrying the identifiers, including: The user terminal performs field extraction processing on the initial request information to obtain key fields of the initial request information; The user terminal performs a match in a preset field correspondence table based on the key field to obtain an identifier corresponding to the key field, wherein the field correspondence table includes multiple key fields and an identifier corresponding to each key field, and the identifier includes a real-time transaction identifier and a non-real-time transaction identifier; The user terminal adds the identifier to the initial request information to generate the data request information.

3. The method for processing a data request according to claim 1, wherein: The server parses the data request information to obtain request type information corresponding to the data request information, including: The server performs identification processing on the data request information to obtain an identifier of the data request information; The server determines the request type information corresponding to the data request information based on the identifier.

4. The method for processing a data request according to claim 1, wherein: The main server identifies the target field of the real-time transaction request information, and determines whether the real-time transaction request information is an instant data request based on a matching result between the target field and an instant field in a preset instant field table. The steps include: The main server extracts a target field at a preset position from the real-time transaction request information; The master server queries a preset instant field table, matches the target field with the preset instant field table, and determines whether there is an instant field identical to the target field in the instant field table, wherein the instant field table includes a plurality of instant fields; If there is an instant field that is identical to the target field, the host server determines that the real-time transaction request information is an instant data request; If there is no immediate field identical to the target field, the main server determines that the real-time transaction request information is not an immediate data request.

5. The method for processing a data request according to claim 1, wherein: After the step of the master server determining to forward the real-time transaction request information to the slave server for processing if the request is not an instant data request, the method further includes: The slave server performs a data request operation on a preset slave database based on the real-time transaction request information, wherein the slave database runs on the slave server.

6. The method for processing data request according to claim 1, wherein: If it is an instant data request, after the step of the primary server performing a data request operation on a preset primary database based on the real-time transaction request information, the following steps are included: When there is data update in the primary database, the primary server performs log backup processing on the data request operation to generate operation log data; The master server sends the operation log data to the slave server; The slave server performs data synchronization processing on the slave database based on the operation log data.

7. A data request processing device, characterized in that: include: a marking module configured to, in response to an initial request message input by a user, match key fields of the initial request message with identifiers in a preset field correspondence table, and generate data request messages carrying identifiers, wherein the identifiers include real-time transaction identifiers and non-real-time transaction identifiers; A transmission module, configured for the user end to send the data request information to the server end; a parsing module, configured for the server to parse the data request information to obtain request type information corresponding to the data request information, wherein the request type information includes real-time transaction request information and non-real-time transaction request information; a processing module configured to, if the data request information is a real-time transaction request information, send the real-time transaction request information to a master server for processing by the server; the master server obtains the real-time transaction request information sent by the server, wherein the real-time transaction request information is either an instant data request or a non-instant data request; the master server identifies and processes a target field of the real-time transaction request information, and determines whether the real-time transaction request information is an instant data request based on a match result between the target field and an instant field in a preset instant field table; if it is an instant data request, the master server performs a data request operation on a preset master database based on the real-time transaction request information, wherein the master database runs on the master server; if it is not an instant data request, the master server forwards the real-time transaction request information to a slave server; the key field is different from the target field; A distribution module is used for, if the data request information is non-real-time transaction request information, the server sends the non-real-time transaction request information to the slave server for processing, wherein the slave server synchronizes the data in the master server based on the master-slave synchronization rule.

8. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the steps of the method for processing a data request according to any one of claims 1 to 6 are implemented.

9. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the method for processing a data request according to any one of claims 1 to 6 are implemented.

Images