Request processing method and device based on secondary preposition, storage medium and system

Abstract

The invention discloses a second-level preposition-based request processing method and device, a storage medium and a system, relates to the technical field of data transmission, can be applied to the field of financial futures, and mainly aims at solving the problem that the processing efficiency of an existing risk control service request is relatively low. The method mainly comprises the following steps: receiving a service request sent by a client through a secondary front node, and analyzing the data type of target service data requested by the service request; under the condition that the data type is matched with a local storage data type of the second-level front node, obtaining target business data from a local storage space through the second-level front node; under the condition that the data type is not matched with the local storage data type, forwarding the service request to a first-level front node, so that the first-level front node obtains target service data and feeds back the target service data to a second-level front node; and returning the target service data as a request response to the client through the second-level front node. The method is mainly used for processing business requests.

Description

Technical Field

[0001] This invention relates to the field of data transmission technology and can be applied to the financial futures field. In particular, it relates to a request processing method, apparatus, storage medium, and system based on a two-level front-end. Background Technology

[0002] As futures companies expand their business, deploying their trading systems in remote data centers has become commonplace. However, this has led to strained dedicated line bandwidth resources and system performance bottlenecks. In the current system architecture, all business requests and alert message pushes are transmitted via dedicated lines. When users log in, they need to download all initial cached data (such as investor information and contract data) from the remote server, resulting in a large amount of dedicated line bandwidth being consumed in a short period, hindering intraday business operations. At the same time, alert messages subscribed to in real time by online clients are pushed by the backend service, further exacerbating bandwidth pressure. However, the existing dedicated line bandwidth is limited and cannot meet the needs of high-concurrency scenarios, resulting in low processing efficiency for risk control business requests. Summary of the Invention

[0003] In view of this, the present invention provides a request processing method, apparatus, storage medium, and system based on a two-level front-end, the main purpose of which is to solve the problem of low processing efficiency of existing risk control business requests.

[0004] According to one aspect of the present invention, a request processing method based on a two-level front-end is provided. The method processes business requests based on a two-level front-end structure, the two-level front-end structure including a first-level front-end node and a second-level front-end node. The method includes:

[0005] The secondary front-end node receives service requests sent by the client and parses the data type of the target service data requested by the service request.

[0006] If the data type matches the data type of the local storage data of the secondary front-end node, the target business data is obtained from the local storage space through the secondary front-end node;

[0007] If the data type does not match the local storage data type, the business request is forwarded to the first-level front-end node through the second-level front-end node, so that the first-level front-end node can obtain the target business data from the back-end server through the risk control data transmission dedicated line and feed it back to the second-level front-end node.

[0008] The target business data is sent back to the client as a request response through the secondary front-end node.

[0009] Furthermore, before receiving the service request sent by the client through the secondary front-end node, the method further includes:

[0010] The full amount of static data is loaded from the backend server through the secondary front-end node and stored in the local storage space.

[0011] Establish a proxy dialogue between the secondary front-end node and the primary front-end node, and subscribe to risk control early warning data from the primary front-end node through the secondary front-end node;

[0012] Receive risk control early warning data sent in real time by the first-level front-end node, and store the risk control early warning data in the local storage space.

[0013] Furthermore, storing the full amount of static data in local storage space includes:

[0014] Static data with an access frequency greater than a preset access threshold are stored in the hot data layer, which is configured in memory storage space.

[0015] Static data with an access frequency less than or equal to the preset access threshold will be stored on disk in the form of a file.

[0016] The step of storing the risk control early warning data in the local storage space includes:

[0017] The risk control and early warning data is stored in the hot data layer.

[0018] Furthermore, when the data type is risk control early warning data, the step of obtaining target business data from local storage space through the secondary front-end node includes:

[0019] The user permission information of the client is parsed based on the business request;

[0020] Identify target risk control warning data that matches the user permission information from the risk control warning data;

[0021] The target risk control and early warning data is used as the target business data.

[0022] Furthermore, the step of receiving service requests sent by clients through a secondary front-end node includes:

[0023] In response to a business request sent by a client, the request forwarding strategy is retrieved through the load balancer, and the target secondary front-end node is determined from the secondary front-end nodes according to the request forwarding strategy. The request forwarding strategy includes at least one of the following: round-robin strategy, weighted round-robin strategy, hash strategy, and least connections strategy.

[0024] The service request is distributed to the target secondary front-end node, so that the service request can be forwarded or the target service data can be queried locally through the target secondary front-end node.

[0025] Furthermore, before receiving the service request sent by the client through the secondary front-end node, the method further includes:

[0026] Monitor the running status of the secondary front-end node;

[0027] In the event of an abnormal operating state, the client is connected to the first-level front-end node, and the target business data is obtained from the back-end server through the first-level front-end node and then sent back to the client.

[0028] After the target service data is transmitted back to the client via the first-level front-end node, the method further includes:

[0029] If the operation of the secondary front-end node is detected to have returned to normal, the client will reconnect to the secondary front-end node.

[0030] Furthermore, the method also includes:

[0031] In response to the static data update message from the backend server;

[0032] The updated static data is obtained from the backend server through the secondary front-end node, and the static data in the local storage space is updated based on the updated static data.

[0033] According to another aspect of the present invention, a request processing apparatus based on a two-level front-end is provided. The apparatus processes service requests based on a two-level front-end structure, the two-level front-end structure including a first-level front-end node and a second-level front-end node. The apparatus includes:

[0034] The parsing module is used to receive business requests sent by the client through the secondary front-end node and parse the data type requested by the business request;

[0035] The first acquisition module is used to acquire target business data from the local storage space through the second-level front-end node when the data type matches the data type of the local storage data of the second-level front-end node.

[0036] The second acquisition module is used to forward the business request to the first-level front-end node through the second-level front-end node when the data type does not match the local storage data type, so that the first-level front-end node can obtain the target business data from the back-end server through the risk control data transmission dedicated line and feed it back to the second-level front-end node.

[0037] The backhaul module is used to send the target business data back to the client as a request response through the secondary front-end node.

[0038] Furthermore, the device also includes:

[0039] The first storage module is used to load all static data from the backend server through the secondary front-end node and store the all static data in the local storage space.

[0040] The first connection module is used to establish a proxy dialogue between the secondary front-end node and the primary front-end node, and to subscribe to risk control early warning data from the primary front-end node through the secondary front-end node;

[0041] The second storage module is used to receive the risk control early warning data sent in real time by the first-level front-end node and store the risk control early warning data in the local storage space.

[0042] Further, the first storage module includes:

[0043] The first storage unit is used to store static data with an access frequency greater than a preset access threshold to the hot data layer, wherein the hot data layer is configured in the memory storage space;

[0044] The second storage unit is used to store static data with an access frequency less than or equal to the preset access threshold on a disk in the form of writing files.

[0045] The second storage module is used to store the risk control early warning data in the hot data layer.

[0046] Furthermore, when the data type is risk control early warning data, the first acquisition module includes:

[0047] The parsing unit is used to parse the user permission information of the client based on the business request;

[0048] The identification unit is used to identify target risk control early warning data that matches the user permission information from the risk control early warning data, and to use the target risk control early warning data as target business data.

[0049] Furthermore, the parsing module includes:

[0050] The retrieval unit is used to respond to a business request sent by the client, retrieve the request forwarding strategy through the load balancer, and determine the target secondary front-end child node from the secondary front-end child nodes according to the request forwarding strategy. The request forwarding strategy includes at least one of the following: round-robin strategy, weighted round-robin strategy, hash strategy, and least connections strategy.

[0051] The distribution unit is used to distribute the service request to the target secondary front-end node, so that the target secondary front-end node can perform the forwarding of the service request or the local query of the target service data.

[0052] Furthermore, the device also includes:

[0053] The monitoring module is used to monitor the running status of the secondary front-end node;

[0054] The second connection module is used to connect the client to the first-level front-end node when the running state is abnormal, and to obtain target business data from the back-end server through the first-level front-end node and send the target business data back to the client.

[0055] The reconnection module is used to reconnect the client to the secondary front-end node when the operating status of the secondary front-end node is detected to have returned to normal.

[0056] Furthermore, the device also includes:

[0057] The third acquisition module is used to respond to the static data update message from the backend server and acquire the updated static data from the backend server through the secondary front-end node;

[0058] The update module is used to update the static data in the local storage space based on the updated static data.

[0059] According to another aspect of the present invention, a storage medium is provided, wherein at least one executable instruction is stored therein, the executable instruction causing a processor to perform an operation corresponding to the above-described request processing method based on a two-level pre-processing layer.

[0060] According to another aspect of the present invention, a system is provided, comprising: a processor, a memory, a communication interface, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other via the communication bus;

[0061] The memory is used to store at least one executable instruction that causes the processor to perform the operation corresponding to the above-described request processing method based on the second-level pre-processing.

[0062] By employing the above-described technical solutions, the technical solutions provided by the embodiments of the present invention have at least the following advantages:

[0063] This invention provides a request processing method, apparatus, storage medium, and system based on a two-level front-end node. In this embodiment, a two-level front-end node receives a business request from a client and parses the data type of the target business data requested. If the data type matches the data type of the local storage data of the two-level front-end node, the target business data is retrieved from the local storage space through the two-level front-end node. If the data type does not match the local storage data type, the business request is forwarded to the first-level front-end node through the two-level front-end node. The first-level front-end node then retrieves the target business data from the backend server via a dedicated risk control data transmission line and sends it back to the two-level front-end node. The two-level front-end node then sends the target business data back to the client as a request response. By deploying a two-level front-end node, repetitive data transmission between remote clients and risk control services is converted to local transmission, significantly shortening data transmission time. Simultaneously, it avoids the occupation of dedicated line bandwidth by a large amount of repetitive data transmission, improving the transmission rate of dedicated line bandwidth and thus improving the overall processing efficiency of business requests.

[0064] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention, it can be implemented according to the contents of the specification. Furthermore, in order to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0065] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0066] Figure 1 A flowchart of a request processing method based on a two-level preprocessing step provided by an embodiment of the present invention is shown;

[0067] Figure 2 This diagram illustrates a request processing system architecture based on a two-level front-end, according to an embodiment of the present invention.

[0068] Figure 3 A flowchart of another request processing method based on a two-level pre-processing mechanism provided by an embodiment of the present invention is shown;

[0069] Figure 4 This diagram illustrates a system architecture based on a two-level front-end cluster as a proxy, according to an embodiment of the present invention.

[0070] Figure 5This diagram illustrates a system architecture provided by an embodiment of the present invention, in which a primary front-end node is directly connected to a client.

[0071] Figure 6 The diagram shows a block diagram of a request processing device based on a two-level front-end, according to an embodiment of the present invention. Detailed Implementation

[0072] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0073] To address the issue of low efficiency in existing risk control business requests, this invention provides a request processing method based on a two-level pre-processing mechanism, such as... Figure 1 As shown, the method includes:

[0074] 101. Receive the service request sent by the client through the secondary front-end node, and parse the data type of the target service data requested by the service request.

[0075] In this embodiment of the invention, the two-level front-end structure acts as an intermediary between the client and the back-end system server. It first receives business requests sent by the client, such as querying contract information or investor positions. The two-level front-end structure includes a first-level front-end node and a second-level front-end node. For example... Figure 2 As shown, the business request sent by the client is first received by the secondary front-end node. If a data query from the backend server is required, the secondary front-end node forwards the request to the primary front-end node. The primary front-end node then retrieves the target business data from the backend server based on the business request. To determine whether a data request from the backend server is needed, the data type of the target business data needs to be parsed. Specifically, this can be done by extracting keywords from the business request to determine the data type, such as "historical transaction records," "risk control warning data," or "contract information." The business request can be a request generated by the client based on user actions, or it can be an automatically generated request during client startup for data initialization; this embodiment of the invention does not impose specific limitations.

[0076] 102. If the data type matches the data type of the local storage data of the secondary front-end node, the target business data is obtained from the local storage space through the secondary front-end node.

[0077] In this embodiment of the invention, the secondary front-end node is configured with local storage space to store pre-loaded business data, such as static data used for client initialization, risk control and early warning data, etc. This storage space can be a cache space in memory or disk space. When the data type of the request matches the data type stored locally, it indicates that the requested business data has already been stored in the local storage space of the secondary front-end node and can be directly retrieved from the local storage space without needing to retrieve it from the backend server, and therefore without needing to forward this business request to the primary front-end node.

[0078] It's important to note that much of the data transmitted between the client and the backend server is repetitive. For example, there's static data used to initialize remote clients, and risk control clients need to download all initialization data from the remote server each time they log in. By deploying a secondary front-end node, repetitive data transmission between remote clients and the backend server is redirected to local transmission, reducing dedicated line bandwidth usage. Furthermore, local data transmission is mostly conducted over a local area network (LAN), which offers better bandwidth than dedicated lines, further reducing data transmission latency.

[0079] 103. If the data type matches the data type of the local storage data of the secondary front-end node, the target business data is obtained from the local storage space through the secondary front-end node.

[0080] In this embodiment of the invention, if the data type does not match the locally stored data type, it indicates that the target business data currently requested does not exist in the local storage space of the secondary front-end node and needs to be requested from the backend server. In this case, the secondary front-end node forwards the business request to the primary front-end node. Through the deployment of the secondary and primary front-end nodes, when a client accesses the backend server through the secondary front-end structure, only network communication between the client and the secondary front-end node, and between the secondary and primary front-end nodes, needs to be enabled. This achieves network isolation between the client and the primary front-end node, thereby improving the security of data communication.

[0081] 104. The target business data is sent back to the client as a request response through the secondary front-end node.

[0082] In this embodiment of the invention, whether the target business data is obtained from the local storage space of the secondary front-end node or from the backend server through the primary front-end node, it is ultimately returned to the client by the secondary front-end node. By deploying a secondary front-end structure, when a business request is received from the client, the business data query strategy can be determined based on the location where the requested business data was obtained, thereby achieving intelligent distribution of business requests and further reducing the server load on the backend server.

[0083] In one embodiment of the present invention, for further illustration and limitation, such as Figure 3 As shown, before receiving the service request sent by the client through the secondary front-end node as described in step [example step], the method further includes:

[0084] 201. Load all static data from the backend server through the secondary front-end node and store the all static data in the local storage space.

[0085] 202. Establish a proxy dialogue between the secondary front-end node and the primary front-end node, and subscribe to risk control early warning data from the primary front-end node through the secondary front-end node.

[0086] 203. Receive the risk control early warning data sent in real time by the first-level front-end node, and store the risk control early warning data in the local storage space.

[0087] In this embodiment of the invention, the locally stored data includes risk control and early warning data and static data. Static data refers to data that does not change in real time and may include terminal initialization data, such as investor information and contract data. After the secondary front-end node starts, it directly loads all static data from the backend server and stores it locally. When clients connected to it need to log in and require initialization data, the data is retrieved directly from local storage, avoiding remote retrieval of initialization data, which would otherwise lead to long client initialization times and negatively impact user experience.

[0088] When the requested data needs to be remotely retrieved from the backend server, the secondary front-end node, acting as a proxy between the primary front-end node and the client, needs to forward the client's business request to the primary front-end node. Therefore, before executing the business request, a proxy session needs to be established between the secondary front-end node and the primary front-end node. By establishing a proxy session between the secondary and primary front-end nodes, and forwarding the client's request and returning the response through the secondary front-end node, redundancy in the data transmission link can be ensured, guaranteeing data transmission security.

[0089] In this embodiment of the invention, the secondary front-end node is also used to push risk control early warning information to various clients. Therefore, the secondary front-end node needs to subscribe to the risk control early warning data sent by the primary front-end node, so that the secondary front-end node can receive the risk control early warning data sent by the primary front-end node in real time and dynamically update its local early warning data cache in real time. It should be noted that the risk control early warning data sent by the primary front-end node in real time also carries user permission information, so that when the secondary front-end node receives an early warning data query request from a client, it can return early warning data that the client has the permission to access based on the client's user permissions.

[0090] In addition, locally stored data can also include frequently accessed data. Frequently accessed data can be filtered by access frequency. If the access frequency of a certain piece of data exceeds a preset access frequency threshold, then this data is identified as frequently accessed data. For example, if the preset access frequency is 5 times / minute, and a piece of data is accessed 10 times in 1 minute, the calculated access frequency for this data is 10 times / minute. Therefore, this data is identified as frequently accessed data. The next time this data is loaded, it can be stored locally through the secondary front-end node, and the local storage data type can be updated. This allows the data to be retrieved directly from the local storage space of the secondary front-end node the next time it is requested, avoiding the need to use a remote dedicated line for access.

[0091] In one embodiment of the present invention, for further explanation and limitation, storing the full amount of static data in local storage space includes:

[0092] Static data with an access frequency greater than a preset access threshold are stored in the hot data layer, which is configured in memory storage space.

[0093] Static data with an access frequency less than or equal to the preset access threshold will be stored on disk in the form of a file.

[0094] The step of storing the risk control early warning data in the local storage space includes:

[0095] The risk control and early warning data is stored in the hot data layer.

[0096] In this embodiment of the invention, a tiered cache management mechanism is adopted for local storage space. The local cache is divided into a hot data layer and a cold data layer. Hot data layer data is stored in memory to return a response based on the memory cache when a data request is received. Cold data layer data is stored by writing to files; when a data request is received, the file content is loaded and a response is returned. Risk control and early warning data, which is frequently accessed, is stored in the hot data layer so that when a user needs to push risk control and early warning data, a quick response can be given based on the data in the memory cache. For static data with low access frequency, such as contract data, it is stored by writing to files, which can significantly reduce the local memory usage of the secondary front-end nodes. The preset access threshold can be customized according to the specific application scenario, and can be as low as 5 times / minute; this embodiment of the invention does not impose a specific limitation.

[0097] In one embodiment of the present invention, for further explanation and limitation, when the data type is risk control early warning data, the step of obtaining target business data from local storage space through the secondary front-end node includes:

[0098] The user permission information of the client is parsed based on the business request;

[0099] Identify target risk control warning data that matches the user permission information from the risk control warning data;

[0100] The target risk control and early warning data is used as the target business data.

[0101] In this embodiment of the invention, when the data type is risk control early warning data, during the process of the secondary front-end node pushing the risk control early warning data to the client, it is also necessary to obtain the current client's user permission information. Based on the user permission information, risk control early warning data matching the current user's permission information is identified from the full amount of risk control early warning data as the target risk control early warning data, and the target risk control early warning data is returned to the client as the target business data. Based on the identification of user permissions, the retrieval and transmission of risk control early warning data can be accurately realized, ensuring that users with different permissions can see risk control early warning data matching their permissions.

[0102] In one embodiment of the present invention, for further explanation and limitation, the step of receiving service requests sent by clients through a secondary front-end node includes:

[0103] In response to a service request sent by the client, the request forwarding policy is retrieved through the load balancer, and the target secondary front-end node is determined from the secondary front-end nodes according to the request forwarding policy.

[0104] The service request is distributed to the target secondary front-end node, so that the service request can be forwarded or the target service data can be queried locally through the target secondary front-end node.

[0105] In this embodiment of the invention, the secondary front-end node is a node cluster (secondary front-end cluster) configured with a load balancing forwarding strategy, that is, the secondary front-end node includes multiple secondary front-end child nodes and a load balancer (APACHE). Figure 4 As shown, client requests first reach the load balancer, which then determines which secondary front-end node in the secondary front-end cluster to distribute the request to. The selected target secondary front-end node is the designated target secondary front-end node. The front-end nodes and backend servers are located in the central server room. The secondary front-end nodes act as proxies for the primary front-end nodes. If the requested data is locally stored, the target secondary front-end node retrieves it from the local storage. If the requested data is not locally stored, the target secondary front-end node forwards it to the primary front-end node. The local storage space is a central repository shared by all secondary front-end nodes.

[0106] It should be noted that request forwarding strategies include at least one of the following: round-robin, weighted round-robin, hash, and least connections. The choice of request forwarding strategy can be determined based on the business scenario. When the business request is for independent risk control rule verification data, and the performance parameters of each secondary front-end node are within the same range, a round-robin strategy is used for request forwarding. Since risk control rules do not need to be associated across requests (e.g., checking margin deposits one by one), the round-robin method can effectively and evenly distribute the load. When the business request is for real-time volatility calculation results, and the performance parameters of each secondary front-end node are not within the same range, a weighted round-robin strategy is used for request forwarding. For example, setting the weight of the latest server in the secondary front-end cluster to 3 and the weight of the older server to 1 concentrates complex risk control model calculations on high-performance nodes, allowing high-performance sub-nodes to be used preferentially for handling complex calculations, thereby improving overall throughput. When the business request points to the latest risk control status data of a specific user, a hash strategy is used for request forwarding, ensuring the session is processed on the same sub-node and avoiding duplicate calculations. When the growth rate of business requests reaches a historical peak, and the performance parameters of each secondary front-end node are not in the same range, requests are forwarded according to the least connection strategy, and relatives are routed to idle nodes to improve response speed.

[0107] In one embodiment of the present invention, for further explanation and limitation, before receiving the service request sent by the client through the secondary front-end node, the method further includes:

[0108] Monitor the running status of the secondary front-end node;

[0109] In the event of an abnormal operating state, the client is connected to the first-level front-end node, and the target business data is obtained from the back-end server through the first-level front-end node and then sent back to the client.

[0110] After the target service data is transmitted back to the client via the first-level front-end node, the method further includes:

[0111] If the operation of the secondary front-end node is detected to have returned to normal, the client will reconnect to the secondary front-end node.

[0112] In embodiments of the present invention, such as Figure 5As shown, in the event of an anomaly in the secondary front-end node, the client directly connects to the primary front-end node, which then takes over the role of the secondary front-end node. This allows for a seamless switch to the direct connection mode between the primary front-end node and the client in the event of a single node failure, preventing server termination due to a single point of failure and improving the system's disaster recovery capabilities and reliability. Once the secondary front-end node's operational status is detected to have returned to normal, the system switches back to the two-tier front-end mode, where the secondary front-end node acts as the primary front-end node.

[0113] In one embodiment of the present invention, for further explanation and limitation, the method further includes:

[0114] In response to the static data update message from the backend server;

[0115] The updated static data is obtained from the backend server through the secondary front-end node, and the static data in the local storage space is updated based on the updated static data.

[0116] In this embodiment of the invention, upon receiving an update message, the secondary front-end node proactively establishes a data transmission channel with the backend server to obtain the updated static data. This static data covers various basic and relatively stable information in the financial futures market, such as basic parameters of futures contracts (contract code, contract multiplier, delivery month, etc.), detailed information of trading instruments (instrument name, trading unit, minimum price fluctuation, etc.), and basic information of market participants (member information, customer information, etc.). After obtaining the updated static data, the secondary front-end node comprehensively updates the corresponding static data in its local storage space based on this new data. By acquiring and updating local data in real time, it is ensured that the static data stored locally by the secondary front-end node remains consistent with the data in the backend server, providing an accurate and reliable data foundation for subsequent business processing.

[0117] This invention provides a request processing method based on a two-level front-end node. In this embodiment, a two-level front-end node receives a business request from a client and parses the data type of the target business data requested. If the data type matches the data type of the local storage data of the two-level front-end node, the target business data is retrieved from the local storage space through the two-level front-end node. If the data type does not match the local storage data type, the business request is forwarded to the first-level front-end node through the two-level front-end node. The first-level front-end node then retrieves the target business data from the backend server via a dedicated risk control data transmission line and sends it back to the two-level front-end node. Finally, the two-level front-end node sends the target business data back to the client as a request response. By deploying a two-level front-end node, repetitive data transmission between remote clients and the risk control service is converted to local transmission, significantly shortening data transmission time. Simultaneously, it avoids the occupation of dedicated line bandwidth by a large amount of repetitive data transmission, improving the transmission rate of the dedicated line bandwidth and thus improving the overall processing efficiency of business requests.

[0118] Furthermore, as a response to the above Figure 1 The implementation of the method shown in this invention provides a request processing device based on a two-level front-end, such as... Figure 6 As shown, the device processes requests based on a two-level front-end structure, which includes a two-level front-end node and a first-level front-end node. The device includes:

[0119] The parsing module 31 is used to receive business requests sent by the client through the secondary front-end node and parse the data type requested by the business request;

[0120] The first acquisition module 32 is used to acquire target business data from the local storage space through the secondary front-end node when the data type matches the data type of the local storage data of the secondary front-end node.

[0121] The second acquisition module 33 is used to forward the business request to the first-level front-end node through the second-level front-end node when the data type does not match the local storage data type, so that the first-level front-end node can obtain the target business data from the back-end server through the risk control data transmission dedicated line and feed it back to the second-level front-end node.

[0122] The return module 34 is used to return the target business data as a request response to the client through the secondary front-end node.

[0123] Furthermore, the device also includes:

[0124] The first storage module is used to load all static data from the backend server through the secondary front-end node and store the all static data in the local storage space.

[0125] The first connection module is used to establish a proxy dialogue between the secondary front-end node and the primary front-end node, and to subscribe to risk control early warning data from the primary front-end node through the secondary front-end node;

[0126] The second storage module is used to receive the risk control early warning data sent in real time by the first-level front-end node and store the risk control early warning data in the local storage space.

[0127] Further, the first storage module includes:

[0128] The first storage unit is used to store static data with an access frequency greater than a preset access threshold to the hot data layer, wherein the hot data layer is configured in the memory storage space;

[0129] The second storage unit is used to store static data with an access frequency less than or equal to the preset access threshold on a disk in the form of writing files.

[0130] The second storage module is used to store the risk control early warning data in the hot data layer.

[0131] Furthermore, when the data type is risk control early warning data, the first acquisition module includes:

[0132] The parsing unit is used to parse the user permission information of the client based on the business request;

[0133] The identification unit is used to identify target risk control early warning data that matches the user permission information from the risk control early warning data, and to use the target risk control early warning data as target business data.

[0134] Furthermore, the parsing module 31 includes:

[0135] The retrieval unit is used to respond to a business request sent by the client, retrieve the request forwarding strategy through the load balancer, and determine the target secondary front-end child node from the secondary front-end child nodes according to the request forwarding strategy. The request forwarding strategy includes at least one of the following: round-robin strategy, weighted round-robin strategy, hash strategy, and least connections strategy.

[0136] The distribution unit is used to distribute the service request to the target secondary front-end node, so that the target secondary front-end node can perform the forwarding of the service request or the local query of the target service data.

[0137] Furthermore, the device also includes:

[0138] The monitoring module is used to monitor the running status of the secondary front-end node;

[0139] The second connection module is used to connect the client to the first-level front-end node when the running state is abnormal, and to obtain target business data from the back-end server through the first-level front-end node and send the target business data back to the client.

[0140] The reconnection module is used to reconnect the client to the secondary front-end node when the operating status of the secondary front-end node is detected to have returned to normal.

[0141] Furthermore, the device also includes:

[0142] The third acquisition module is used to respond to the static data update message from the backend server and acquire the updated static data from the backend server through the secondary front-end node;

[0143] The update module is used to update the static data in the local storage space based on the updated static data.

[0144] This invention provides a request processing device based on a two-level front-end. In this embodiment, a two-level front-end node receives a business request sent by a client and parses the data type of the target business data requested by the request. If the data type matches the data type of the local storage data of the two-level front-end node, the target business data is retrieved from the local storage space through the two-level front-end node. If the data type does not match the local storage data type, the business request is forwarded to the first-level front-end node through the two-level front-end node, so that the first-level front-end node retrieves the target business data from the backend server through a dedicated risk control data transmission line and feeds it back to the two-level front-end node. The target business data is then sent back to the client as a request response through the two-level front-end node. By deploying a two-level front-end node, repetitive data transmission between remote clients and risk control services is converted to local transmission, greatly shortening the data transmission time. Simultaneously, it avoids the occupation of dedicated line bandwidth by a large amount of repetitive data transmission, improving the transmission rate of dedicated line bandwidth, thereby improving the overall processing efficiency of business requests. According to one embodiment of the invention, a storage medium is provided, which stores at least one executable instruction that can execute the request processing method based on a two-level front-end in any of the above method embodiments.

[0145] Figure 2The diagram illustrates the structure of a system according to an embodiment of the present invention. The system includes a client 410, a secondary front-end structure 420, and a back-end server 430. The secondary front-end structure 420 includes a secondary front-end node 421 and a primary front-end node 422. The secondary front-end structure 420 is used to execute the above-described request processing method based on the secondary front-end. The specific implementation of the present invention is not limited to the specific implementation of the system.

[0146] It is obvious to those skilled in the art that the modules or steps of the present invention described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. Optionally, they can be implemented using computer-executable program code, thereby storing them in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the present invention is not limited to any particular combination of hardware and software.

[0147] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A request processing method based on a two-level pre-processing mechanism, characterized in that, The method for processing business requests based on a two-level front-end structure, wherein the two-level front-end structure includes a first-level front-end node and a second-level front-end node, includes: The secondary front-end node receives service requests sent by the client and parses the data type of the target service data requested by the service request. If the data type matches the data type of the local storage data of the secondary front-end node, the target business data is obtained from the local storage space through the secondary front-end node; If the data type does not match the local storage data type, the business request is forwarded to the first-level front-end node through the second-level front-end node, so that the first-level front-end node can obtain the target business data from the back-end server through the risk control data transmission dedicated line and feed it back to the second-level front-end node. The target business data is sent back to the client as a request response through the secondary front-end node.

2. The method according to claim 1, characterized in that, The local storage data types include risk control and early warning data and static data. Before receiving business requests sent by clients through the secondary front-end node, the method further includes: The full amount of static data is loaded from the backend server through the secondary front-end node and stored in the local storage space. Establish a proxy dialogue between the secondary front-end node and the primary front-end node, and subscribe to risk control early warning data from the primary front-end node through the secondary front-end node; Receive risk control early warning data sent in real time by the first-level front-end node, and store the risk control early warning data in the local storage space.

3. The method according to claim 2, characterized in that, The local storage space includes a hot data layer and a cold data layer. The step of storing the full amount of static data in the local storage space includes: Static data with an access frequency greater than a preset access threshold are stored in the hot data layer, which is configured in memory storage space. Static data with an access frequency less than or equal to the preset access threshold will be stored on disk in the form of a file. The step of storing the risk control early warning data in the local storage space includes: The risk control and early warning data is stored in the hot data layer.

4. The method according to claim 2, characterized in that, When the data type is risk control early warning data, the step of obtaining target business data from local storage space through the secondary front-end node includes: The user permission information of the client is parsed based on the business request; Identify target risk control warning data that matches the user permission information from the risk control warning data, and use the target risk control warning data as target business data.

5. The method according to claim 1, characterized in that, The secondary front-end node includes multiple secondary front-end sub-nodes and a load balancer. Receiving service requests sent by clients through the secondary front-end node includes: In response to a business request sent by a client, the request forwarding strategy is retrieved through the load balancer, and the target secondary front-end node is determined from the secondary front-end nodes according to the request forwarding strategy. The request forwarding strategy includes at least one of the following: round-robin strategy, weighted round-robin strategy, hash strategy, and least connections strategy. The service request is distributed to the target secondary front-end node, so that the service request can be forwarded or the target service data can be queried locally through the target secondary front-end node.

6. The method according to claim 5, characterized in that, Before receiving the service request sent by the client through the secondary front-end node, the method further includes: Monitor the running status of the secondary front-end node; In the event of an abnormal operating state, the client is connected to the first-level front-end node, and the target business data is obtained from the back-end server through the first-level front-end node and then sent back to the client. After the target service data is transmitted back to the client via the first-level front-end node, the method further includes: If the operation of the secondary front-end node is detected to have returned to normal, the client will reconnect to the secondary front-end node.

7. The method according to any one of claims 1-6, characterized in that, The method further includes: In response to the static data update message from the backend server, the updated static data is obtained from the backend server through the secondary frontend node; The static data in the local storage space will be updated based on the updated static data.

8. A request processing apparatus based on a two-level front-end, characterized in that, The device processes service requests based on a two-level front-end structure, which includes a first-level front-end node and a second-level front-end node. The parsing module is used to receive business requests sent by the client through the secondary front-end node and parse the data type requested by the business request; The first acquisition module is used to acquire target business data from the local storage space through the second-level front-end node when the data type matches the data type of the local storage data of the second-level front-end node. The second acquisition module is used to forward the business request to the first-level front-end node through the second-level front-end node when the data type does not match the local storage data type, so that the first-level front-end node can obtain the target business data from the back-end server through the risk control data transmission dedicated line and feed it back to the second-level front-end node. The backhaul module is used to send the target business data back to the client as a request response through the secondary front-end node.

9. A storage medium, characterized in that, The storage medium stores at least one executable instruction that causes the processor to perform the operation corresponding to the request processing method based on the second-level pre-processing method as described in any one of claims 1-7.

10. A system, characterized in that, The system includes: a client, a two-level front-end structure, and a back-end server. The two-level front-end structure includes a two-level front-end node and a first-level front-end node. The two-level front-end structure is used to perform the operation corresponding to the request processing method based on the two-level front-end as described in any one of claims 1-7.

Images