Business request processing methods and devices, storage media and electronic devices

Abstract

This invention provides a business request processing method, apparatus, storage medium, and electronic device, comprising: receiving a business request sent by a front-end device; determining whether the business request is a valid request; when the business request is determined to be valid, determining whether the business request meets preset caching conditions; when the business request meets the caching conditions, setting a caching duration for the business request and caching the business request; when the caching time of the business request reaches the caching duration, sending the business request to the corresponding business system. This invention effectively controls the business requests sent to the business system by filtering out valid business requests and determining whether to cache the business requests for a period of time before sending them to the business system, thereby reducing the request traffic to the business system, avoiding business system failures due to high traffic, and ensuring stable operation of the business system.

Description

Technical Field

[0001] This invention relates to the field of information technology, and in particular to a business request processing method and apparatus, storage medium and electronic device. Background Technology

[0002] The civil aviation sector is one of the earliest areas to apply information technology. Airlines, agents, and airports worldwide connect to civil aviation business systems through various front-end systems to process business. With the rapid development of the civil aviation industry and the rapid growth in passenger volume, the business volume that civil aviation business systems need to handle is increasing.

[0003] With the advancement of information technology, the automation level of various front-end systems is becoming increasingly higher. As a result, more and more requests are being sent from these front-end systems to the civil aviation business systems. The excessive request traffic entering the civil aviation business systems can easily cause them to malfunction. Summary of the Invention

[0004] In view of this, the present invention provides a business processing request method and apparatus, storage medium and electronic device. The solution provided by the present invention can cache business requests before sending them to the business system, thereby reducing the pressure of request traffic on the business system and avoiding failure of the business system due to excessive traffic.

[0005] To achieve the above objectives, the embodiments of the present invention provide the following technical solutions:

[0006] A business request processing method, comprising:

[0007] Receive business requests sent by the front-end device;

[0008] Determine whether the service request is a valid request;

[0009] When the business request is determined to be a valid request, it is determined whether the business request meets the preset caching conditions;

[0010] When it is determined that the service request meets the caching conditions, a caching duration is set for the service request, and the service request is cached.

[0011] When the caching time of the service request reaches the caching duration, the service request is sent to the corresponding business system.

[0012] Optionally, in the above method, determining whether the business request is a valid request includes:

[0013] Determine whether the previous service request from the front-end device has received a response message;

[0014] When the previous service request from the front-end device has been responded to with a response message, the service request is determined to be a valid message.

[0015] When the previous service request from the front-end device does not return a response message, the time interval between the service request and the previous service request is determined;

[0016] Determine whether the time interval is greater than the preset response time.

[0017] When the time interval is greater than the response duration, the service request is determined to be a valid request;

[0018] If the time interval is not greater than the response duration, the service request is determined to be an invalid request.

[0019] The above methods may also include:

[0020] When the service request is determined to be invalid, the service request is discarded.

[0021] Optionally, in the above method, determining whether the business request meets the preset caching conditions includes:

[0022] Based on the device identifier of the front-end device, obtain the traffic control parameters of the front-end device;

[0023] Based on the rate level identifier in the flow control parameters, the flow rate control level of the front-end device is determined;

[0024] Determine whether the time interval is less than the duration corresponding to the flow rate control level;

[0025] When the time interval is not less than the duration corresponding to the traffic rate control level, it is determined that the service request does not meet the caching condition;

[0026] When the time interval is less than the duration corresponding to the traffic rate control level, it is determined that the service request meets the caching condition.

[0027] Optionally, in the above method, determining the time interval between the service request and the previous service request includes:

[0028] Determine the first request time of the service request;

[0029] Determine the second request time of the previous service request;

[0030] The time interval is obtained by calculating the first request time and the second request time.

[0031] A business request processing apparatus, comprising:

[0032] The receiving unit is used to receive service requests sent by the front-end device;

[0033] The first judgment unit is used to determine whether the service request is a valid request;

[0034] The second judgment unit is used to determine whether the business request meets the preset caching conditions when it is determined that the business request is a valid request.

[0035] A caching unit is configured to set a caching duration for the service request and cache the service request when it is determined that the service request meets the caching conditions.

[0036] The sending unit is used to send the service request to the corresponding service system when the caching time of the service request reaches the caching duration.

[0037] Optionally, in the aforementioned apparatus, the first determining unit includes:

[0038] The first judgment subunit is used to determine whether the previous service request of the front-end device has returned a response message;

[0039] The first determining subunit is used to determine that the service request is a valid message when the previous service request of the front-end device has returned a response message;

[0040] The second determining subunit is used to determine the time interval between the service request and the previous service request when the previous service request of the front-end device has not returned a response message;

[0041] The second judgment subunit is used to determine whether the time interval is greater than the preset response duration;

[0042] The third determining subunit is used to determine that the service request is a valid request when the time interval is greater than the response duration;

[0043] The fourth determining subunit is used to determine that the service request is invalid when the time interval is not greater than the response duration.

[0044] The aforementioned apparatus may optionally further include:

[0045] The discarding unit is used to discard the service request when it is determined that the service request is invalid.

[0046] Optionally, the second determining unit in the aforementioned apparatus includes:

[0047] The acquisition subunit is used to acquire the flow control parameters of the front-end device based on the device identifier of the front-end device;

[0048] The fifth determining subunit is used to determine the flow rate control level of the front-end device based on the rate level identifier in the flow control parameters;

[0049] The third judgment subunit is used to determine whether the time interval is less than the duration corresponding to the flow rate control level;

[0050] The sixth determining subunit is used to determine that the service request does not meet the caching condition when the time interval is not less than the duration corresponding to the traffic rate control level;

[0051] The seventh determining subunit is used to determine that the service request meets the caching condition when the time interval is less than the duration corresponding to the traffic rate control level.

[0052] Optionally, the second determining subunit of the aforementioned apparatus includes:

[0053] The first determining module is used to determine the first request time of the business request;

[0054] The second determining module is used to determine the second request time of the previous service request;

[0055] The calculation module is used to perform calculations on the first request time and the second request time to obtain the time interval.

[0056] Compared with the prior art, the present invention has the following advantages:

[0057] This invention provides a service request processing method, apparatus, storage medium, and electronic device, comprising: receiving a service request sent by a front-end device; determining whether the service request is a valid request; when the service request is determined to be a valid request, determining whether the service request meets a preset caching condition; when the service request meets the caching condition, setting a caching duration for the service request and caching the service request; when the caching time of the service request reaches the preset caching duration, sending the service request to the corresponding business system. Upon receiving a service request, determining whether the service request is a valid request, and when the service request is determined to be a valid request, determining whether the request sending rate of the front-end device meets the preset caching condition, caching the service request when the request sending rate of the front-end device meets the caching condition, and only sending the service request to the business system when the caching time reaches the preset caching duration, thereby controlling the service requests sent to the business system, reducing the request traffic of the business system, avoiding business system failures, and ensuring the stable operation of the business system. Attached Figure Description

[0058] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0059] Figure 1 A flowchart of a business request processing method provided in an embodiment of the present invention;

[0060] Figure 2 A flowchart of a method for determining whether a business request is a valid request, provided in an embodiment of the present invention;

[0061] Figure 3 A flowchart illustrating a method for determining the time interval between a service request and a previous service request, provided in an embodiment of the present invention.

[0062] Figure 4 A flowchart of a method for determining whether the request sending rate of a front-end device meets preset caching conditions, provided in an embodiment of the present invention;

[0063] Figure 5 This is a system framework diagram for implementing the business request processing method provided in an embodiment of the present invention;

[0064] Figure 6 This is a schematic diagram of the structure of a service request processing device provided in an embodiment of the present invention;

[0065] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0066] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0067] In this application, the terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0068] Technical terms:

[0069] Flow rate control: Controlling the rate of input or output messages;

[0070] Equipment Identifier: A string of numbers that identifies the equipment;

[0071] Traffic policing: Monitor incoming traffic to ensure that it does not abuse network resources, and discard or downgrade packets that do not meet the rate requirements.

[0072] Traffic shaping: Monitor the outflow of traffic from the system to ensure that the traffic is limited to an acceptable range, buffer packets that do not meet the rate requirements, and then send the buffered packets evenly.

[0073] As the background technology shows, a large influx of requests into civil aviation business systems can easily cause system failures. Therefore, in order to maintain the stable operation of civil aviation business systems and ensure the continuity of civil aviation business processing, the business systems need to control the flow rate of business requests from the front-end systems. The solution provided by this invention can effectively control the request flow, alleviate the influx of requests into the business system, reduce the processing pressure on the business system, avoid business system failures caused by a large influx of requests, and improve the availability of the business system.

[0074] This invention can be used in numerous general-purpose or special-purpose computing device environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor devices, distributed computing environments including any of the above devices, etc. The method provided by this invention can be applied to civil aviation information systems, and the executing entity can be the processor of the civil aviation information system.

[0075] Reference Figure 1 The following is a flowchart of a business request processing method provided by an embodiment of the present invention, which is described in detail below:

[0076] S101, Receive service requests sent by the front-end device.

[0077] Users can initiate business requests through front-end devices. Preferably, the front-end device is the device that allows users to access the civil aviation information system, which can be a client, a browser, or a front-end system.

[0078] Preferably, the parameters in the business request include, but are not limited to, the command name and command options of the business request itself. For example, in AV PEKCAN, the command name is AV (flight query), and the command options are PEKSHA (originating airport and arrival airport are Beijing Capital Airport and Shanghai Hongqiao Airport, respectively). In addition, the configuration information and status information related to the user who initiated the business request include, such as device identification information PID (the number that identifies the front-end device, such as PID 10686), the airline AIRLINE (such as AIRLINE CA indicating Air China), and the work number login status (logged in or not logged in).

[0079] The access server in the civil aviation information processing system can be used to receive business requests. The received business request can be considered the current business request. Preferably, after receiving a business request, a transaction serial number can be generated to identify the business request. For example, when a business request arrives at the access server, the access server generates a transaction serial number according to a certain serial number generation rule. The transaction serial number is a string used to identify the business request; for example, CXXMCSS029202206161252363529258581. The generated transaction serial number and the business request have a one-to-one correspondence.

[0080] S102. Determine whether the business request is a valid request; if the business request is determined to be a valid request, execute S103; if the business request is determined to be an invalid request, execute S106.

[0081] Upon receiving a business request, in order to control traffic, the system prioritizes processing valid requests. Therefore, it is necessary to determine whether a business request is valid.

[0082] Reference Figure 2 The flowchart below shows a method for determining whether a business request is a valid request, as provided in an embodiment of the present invention. The details are as follows:

[0083] S201. Determine whether the previous service request from the front-end device has received a response message; if the previous service request from the front-end device has received a response message, execute S204; if the previous service request from the front-end device has not received a response message, execute S202.

[0084] Preferably, if the current business request is the first request from the front-end device, the business request can be directly determined as a valid request.

[0085] Based on the device identifier in the business request, obtain the request record of the front-end device, and determine the request information of the previous business request of the front-end device based on the request record. It should be noted that when the request record does not yet record the information of the currently received business request, the request information of the most recently saved business request in the request record can be used as the request information of the previous business request of the front-end device.

[0086] The request information includes information such as the request status and request type of the corresponding business request. For example, the request type can be divided into valid request type and invalid request type, and the request status can be divided into discarded, no response message yet, and response message already sent.

[0087] The request status in the request information of the previous business request can be used to determine whether the front-end device has sent a response message for the previous business request.

[0088] S202. Determine the time interval between the business request and the previous business request.

[0089] When it is determined that the previous service request from the front-end device has not yet returned a response message, it is necessary to determine the time interval between the service request and the previous service request. The specific process is as follows: Figure 3 The specific details are as follows:

[0090] S301. Determine the first request time for the business request.

[0091] S302. Determine the second request time of the previous business request.

[0092] S303. Calculate the time interval between the first request time and the second request time.

[0093] The first request time is the request time of the business request; the second request time is the request time of the previous business request.

[0094] The first request time and the second request time are subtracted, and the difference is determined as the time interval. Specifically, the first request time is subtracted from the second request time, and the difference is determined as the time interval.

[0095] The time interval here refers to the duration between a business request and the previous business request.

[0096] S203. Determine whether the time interval is greater than the preset response duration; if the time interval is greater than the response duration, execute S204; if the time interval is not greater than the response duration, execute S205.

[0097] The preset response time can be set globally according to actual needs. Preferably, the response time can be set to 3 seconds. The response time can be understood as the maximum time that the system can spend in sending a response message to a business request, or the maximum time that a business request can wait for the corresponding response message.

[0098] The time interval and response time can be compared to determine whether the time interval is greater than the response time.

[0099] Furthermore, when the time interval is less than the response duration, it indicates that the previous business request is still waiting for the response message, so the currently received business request can be determined to be an invalid request.

[0100] S204. Confirm that the business request is a valid request.

[0101] S205. The business request is determined to be invalid.

[0102] It should be noted that if the previous business request from the current device has received a response message, the current business request from the front-end device can be determined to be a valid request; if the previous business request from the current device has not received a response message, and the time interval between the previous business request and the current business request is greater than the response duration, the current business request from the front-end device is determined to be a valid request; if the previous business request from the current device has not received a response message, and the time interval between the previous business request and the current business request is not greater than the response duration, the current business request from the front-end device is determined to be an invalid request.

[0103] This invention categorizes business requests, thereby discarding invalid requests directly without sending them to the business system, effectively reducing the traffic of business requests and thus reducing the processing pressure on the business system.

[0104] S103. Determine whether the business request meets the preset caching conditions; if the business request meets the caching conditions, execute S104; if the business request does not meet the caching conditions, execute S107.

[0105] refer to Figure 4 The flowchart below illustrates a method for determining whether the request sending rate of a front-end device meets preset caching conditions, as provided in an embodiment of the present invention.

[0106] S401. Obtain the flow control parameters of the front-end device based on the device identifier of the front-end device.

[0107] Traffic control parameters can be understood as traffic configuration. Each front-end device has corresponding traffic control parameters, which can be customized according to actual needs.

[0108] Flow control parameters include, but are not limited to, front-end identifiers and rate level identifiers.

[0109] The traffic control parameters belonging to the front-end identifier that matches the device identifier in the traffic configuration database are determined as the traffic control parameters of the front-end device.

[0110] S402. Determine the flow rate control level of the front-end device based on the rate level identifier in the flow control parameters.

[0111] Different flow rate control levels have different rate level identifiers. For example, when the rate level identifier is 1, it means that the flow rate control level is level 1; when the rate level identifier is 2, it means that the flow rate control level is level 2.

[0112] S403. Determine whether the time interval is less than the duration corresponding to the flow rate control level; if the time interval is not less than the duration corresponding to the flow rate control level, execute S404; if the time interval is less than the duration corresponding to the flow rate control level, execute S405.

[0113] Different flow rate control levels correspond to different durations. For example, when the flow rate control level is 1, the corresponding duration is 5000 milliseconds, and when the flow rate control level is 2, the corresponding duration is 3000 milliseconds. The duration corresponding to the flow rate control level can be configured globally according to actual needs. Examples will not be given here.

[0114] S404. The business request does not meet the caching conditions.

[0115] S405. Determine if the business request meets the caching conditions.

[0116] The time interval is compared with the duration corresponding to the flow rate control level to determine whether the time interval is less than the duration corresponding to the flow rate control level.

[0117] Preferably, the duration corresponding to the time interval and traffic rate control level can be used to determine whether the front-end device is sending requests too fast. When the time interval is not less than the duration corresponding to the traffic rate control level, it is determined that the front-end device is not sending requests too fast, that is, the speed at which the front-end device sends requests is normal, or the frequency at which the front-end device sends requests is normal. This can further determine that the currently received business request does not meet the caching conditions. When the time interval is less than the duration corresponding to the traffic rate control level, it is determined that the front-end device is sending requests too fast, or the frequency at which the front-end device sends requests is too high. That is, the speed at which the front-end device sends requests is abnormal, and the frequency at which the front-end device sends requests is too high. In this case, it is determined that the currently received business request meets the caching conditions.

[0118] Once a business request is determined to be valid, it needs to be further filtered to reduce the request traffic flowing into the business system.

[0119] S104. Set the cache duration for business requests and cache the business requests.

[0120] It should be noted that the cache duration can be set for business requests based on the actual caching situation. For example, if there are many requests in the queue used to cache business requests, the cache duration can be set to be shorter, and if there are few requests in the queue used to cache business requests, the cache duration can be set to be longer. In this way, when there are many business requests, the storage pressure of the cache can be avoided, and a large space can be used to cache many business requests.

[0121] Preferably, business requests can be cached in a delayed queue.

[0122] S105. When the caching time of a business request reaches the caching duration, the business request will be sent to the corresponding business system.

[0123] When the cumulative time a business request has been cached in the delay queue reaches the cache duration, the business request can be sent to the business system. This allows control over the request traffic of the business system, preventing excessive request traffic that could cause the business system to malfunction.

[0124] S106. Discard the business request.

[0125] S107. Send the business request to the corresponding business system.

[0126] The method provided in this embodiment of the invention receives a service request sent by a front-end device; determines whether the service request is a valid request; when the service request is determined to be a valid request, determines whether the service request meets a preset caching condition; when the service request meets the caching condition, sets a caching duration for the service request and caches the service request; when the caching time of the service request reaches the preset caching duration, the service request is sent to the corresponding business system. After receiving a service request, it is determined whether the service request is a valid request. When the service request is determined to be a valid request, it is determined whether the request sending rate of the front-end device meets the preset caching condition. When the request sending rate of the front-end device meets the caching condition, the service request is cached, and the service request is only sent to the business system when the caching time reaches the preset caching duration. This controls the service requests sent to the business system, reduces the request traffic of the business system, avoids business system failures, and ensures the stable operation of the business system.

[0127] Reference Figure 5The diagram shows a system framework for implementing a business request processing method according to an embodiment of the present invention. The user front-end in the diagram can be understood as the front-end device mentioned above. The access server, routing engine, and back-end core system can form the civil aviation information system in the present invention, and the back-end core system can be the business system.

[0128] User front-end: A client, browser, or front-end system used to access civil aviation information system services. Users initiate business requests through the user front-end.

[0129] Access Server: The boundary of the civil aviation information system, receiving business requests from users, generating transaction serial numbers to identify the business requests, and forwarding the business requests to the backend core system through the routing engine.

[0130] Optionally, it can also receive response messages for business requests from the routing engine and return them to the user.

[0131] Preferably, users need to pass identity authentication in order to truly establish a connection with the access server and thus access civil aviation information system services through the access server.

[0132] Routing engine: Receives business requests from users from the access server, performs flow control and access control checks on the business requests based on the parameters of the business requests, forwards them to the system carrying the backend core services, and receives response messages returned by the system carrying the backend core services.

[0133] During the traffic control check phase, based on the traffic configuration and device identifier, the time interval of requests initiated by the front-end device is controlled, invalid requests are discarded in a timely manner, valid requests with excessively high rates are placed in the traffic cache, valid requests with rates that meet the requirements are forwarded directly, and valid requests in the traffic cache whose delay time has expired are also forwarded directly through the routing engine, thereby achieving traffic control and reducing the traffic pressure on the business system.

[0134] Backend core system: processes business requests from users and returns response messages to users through the routing engine and access server.

[0135] It should be noted that the traffic configuration includes traffic rate control parameters; the traffic cache is used to cache valid requests with excessively high rates and can be a delayed queue.

[0136] In this invention, flow control configuration parameters can be configured via configuration files, databases, or a combination of both. Configuration files are typically suitable for global, uniform configuration, applying the same flow control parameters to all devices, such as the number of delay queues for caching user requests or the selection of flow rate control strategies. Databases are suitable for personalized configurations, allowing for a "one-person-one-policy" approach, directly setting different flow control parameters for different devices. The combination of databases and configuration files combines the two methods, setting general global configurations in configuration files and personalized configurations in the database.

[0137] For example, the contents of the flow control parameters are as follows:

[0138] USE_FC_FREQUENCY = 1

[0139] FC_DISCONNECT=0

[0140] MAX_PID_TRANS_NUM = 1000000

[0141] DELAY_QUEUE_NUM=4

[0142] MAX_RESPONSE_TIME = 3

[0143] PID_TRANS_INTERVAL_MS=1 / 5000,2 / 200,3 / 300,4 / 400,5 / 500,6 / 600,7 / 700,8 / 800,9 / 900,10 / 1000,11 / 1100,12 / 1200,13 / 1300,14 / 1400,15 / 1500

[0144] The specific meanings are as follows:

[0145] USE_FC_FREQUENCY specifies whether to implement flow rate control, with 1 indicating implementation and 0 indicating no implementation. In the example, it is implemented.

[0146] FC_DISCONNECT is one of the parameters of the flow rate control policy, which indicates whether to disconnect the user. 1 means disconnect, 0 means not disconnect. In the example, it means not disconnect.

[0147] MAX_PID_TRANS_NUM specifies the maximum number of device identifiers that the traffic cache can handle for traffic rate control. This parameter determines the amount of cache space required to record the personalized traffic control parameters, request times, and other information for the device corresponding to each device identifier. In this example, the maximum manageable number of device identifiers is 1 million.

[0148] DELAY_QUEUE_NUM specifies the number of delayed queues used to cache user requests; in this example, it is 4.

[0149] MAX_RESPONSE_TIME specifies the upper limit of the response time, which is used to determine whether a user request is a valid request. In the example, it is 3 seconds.

[0150] PID_TRANS_INTERVAL_MS specifies the time interval (in milliseconds) corresponding to each flow rate control setting. For example, setting 3 represents a time interval of 300 milliseconds, and setting 6 represents 600 milliseconds. The actual time interval can be modified; for example, setting 1 can represent a time interval of 5000 milliseconds.

[0151] Taking the rate level identifier in the flow control configuration parameters of three front-end devices with device identifiers 35316, 35217, and 35218 as an example, preferably, the rate level identifier can be stored in the level field, and the device identifier can be stored in the PID field. The level field indicates the level at which the device corresponding to the device identifier performs flow rate control. The value range of level is [0, 15], where 0 indicates no rate control, and the time intervals corresponding to the other values ​​are specified by the configuration file. According to the aforementioned configuration file fragment, the following database record indicates that the flow rate control levels of the three device identifiers 35316, 35217, and 35218 are 1, 3, and 5, respectively, indicating that when this device initiates a subsequent request, the time interval between the previous request and the subsequent request needs to be greater than 5000 milliseconds, 300 milliseconds, and 500 milliseconds, respectively. Preferably, the subsequent request is the current request.

[0152] In this invention, the traffic cache consists of two parts: traffic information and a request delay queue. Traffic information is a collection of traffic records. Each traffic record records personalized traffic control parameters, request time, and other information for a device corresponding to a device identifier. The number of traffic records in the traffic information can be set via the configuration parameter (MAX_PID_TRANS_NUM) in the configuration file. The request delay queue is used to cache valid requests that require traffic rate control. The number of delay queues can be set via the configuration parameter (DELAY_QUEUE_NUM) in the configuration file.

[0153] Referring to Table 1, here is an example of traffic recording provided in an embodiment of the present invention.

[0154]

[0155] Table 1

[0156] This invention proposes a flow rate control method and device for civil aviation information systems based on device identifiers. In the inbound direction of the flow, the time interval between two consecutive requests initiated by the front-end device is controlled based on the device identifier. Invalid requests are discarded in a timely manner, and valid requests with excessively high flow rates are cached for an appropriate period of time before being forwarded. This reduces the pressure on the back-end core system and improves the availability and security of the system.

[0157] The following three scenarios illustrate the workflow of controlling traffic rate based on device identification.

[0158] Scenario 1: This scenario involves discarding invalid requests.

[0159] (1) At 12:52:36.143053 on 2022-06-16, the routing engine received a request from device with device ID PID=35216. It should be noted that 12:52:36.143053 on 2022-06-16 is the current processing time currentTime, and the transaction serial number is CXXMCSS029202206161252363529252081, which is then parsed.

[0160] (2) The routing engine queries the traffic record of device PID=35216 from the traffic cache and finds that the last request time of this device, lastCmdTime, is 2022-06-16 12:52:35.143053 and fcStatus is 0. That is, the device initiated the last request at lastCmdTime and has not yet received a response. Since the time interval between the current request and the previous request (diff=currentTime-lastCmdTime) is 1 second, which does not exceed the response time limit MAX_RESPONSE_TIME, preferably 3 seconds, and the previous request has not yet returned a response, the routing engine determines that the current request is an invalid request, directly discards the packet, and returns an error response to the user.

[0161] The processing log is as follows:

[0162] 20220616125236:143 CXXMCSS029202206161252363529252081pid=35216interval=5000(ms) now=2022-06-16 12:52:36.143053lastCmdTime=2022-06-16 12:52:35.143053diff=1000(ms)<3s,discard message

[0163] The log indicates that at the current time 20220616125236:143, a message with transaction serial number CXXMCSS029202206161252363529252081 was received. The device identifier (PID) is 35216. The time interval between the previous and subsequent requests from this device must be greater than 5000 milliseconds. The current time is 2022-06-16 12:52:36.143053. The last request time of this device is lastCmdTime. The difference between the two is 1000 milliseconds, which is less than 3 seconds. Therefore, the message is discarded.

[0164] Scenario 2: This scenario involves caching valid requests with excessively high speeds for an appropriate period before forwarding them.

[0165] (1) At 12:52:36.740407 on 2022-06-16, the routing engine received a request from device with device ID PID=35217. The time 2022-06-16 12:52:36.740407 is the current processing time currentTime; the transaction serial number is CXXMCSS029202206161252363529256881, which is parsed.

[0166] (2) The routing engine queries the traffic record of device PID=35217 from the traffic cache and finds that the last request time of this device, lastCmdTime, is 2022-06-16 12:52:36.640407 and fcStatus is 1. That is, at lastCmdTime, this device initiated the last request and has received a response. The routing engine determines that the current request is a valid request.

[0167] (3) The routing engine queries the traffic record of the device with PID=35217 from the traffic cache and finds that the minimum time interval between the previous and next requests of this device is 300 milliseconds. Since the time interval between the current request and the previous request is 100 milliseconds, preferably, the time interval can be expressed as: diff=currentTime-lastCmdTime, which is less than the interval. The router puts the request packet into the traffic cache and sets the cache time to 300 milliseconds according to the traffic control configuration parameters. The expiration time dueTime is 2022-06-16 12:52:37.040407.

[0168] (4) When dueTime is 2022-06-16 12:52:37.040407, the delay expires, the routing engine continues the subsequent processing and forwards the packet to the backend core system.

[0169] For example, the processing log is as follows:

[0170] 20220616125236:740CXXMCSS029202206161252363529256881pid=35217interval=300(ms)diff=100(ms)now=2022-06-16 12:52:36.740407dueTime=2022-06-16 12:52:37.040407.

[0171] Scenario 3: This scenario is one where the rate at which valid requests are sent is compliant.

[0172] (1) At 20220616125236:908, the routing engine received a request initiated by the device with device identifier PID=35218 and transaction serial number CXXMCSS029202206161252363529258581, and parsed it.

[0173] (2) The routing engine queries the traffic record of device PID=35218 from the traffic cache and finds that the last request time of this device, lastCmdTime, is 2022-06-16 12:52:36.908966 and fcStatus is 1. That is, at lastCmdTime, the device initiated the last request and has received a response. The routing engine determines that the current request is a valid request.

[0174] (3) The routing engine queries the traffic records of the device with PID=35218 from the traffic cache and finds that the minimum time interval between the previous and next requests of this device is 500 milliseconds. Since the time interval between the current request and the previous request (diff=currentTime-lastCmdTime) is 1000.

[0175] (4) If the millisecond is greater than interval, the routing engine determines that there is no need to control the traffic rate of the request and directly forwards the packet to the backend core system.

[0176] For example, the processing log is as follows:

[0177] 20220616125236:908CXXMCSS029202206161252363529258581pid=35218interval=500(ms)diff=1000(ms)now=2022-06-16 12:52:36.908966no delay.

[0178] The present invention has the following advantages:

[0179] 1. Traffic rate control based on device identifiers at the inlet direction allows for personalized control of different devices, resulting in finer granularity of control and more precise implementation of control measures.

[0180] 2. Timely discarding of invalid requests significantly reduces the system load and avoids wasting limited system resources on invalid requests. To a certain extent, it can also prevent malicious users from launching denial-of-service attacks and affecting normal users, thereby improving system availability and security.

[0181] 3. By caching and forwarding high-speed valid requests for an appropriate period of time, the system load was optimized, reducing the pressure on the backend core system. At the same time, by not simply discarding requests, the stability of the system and the continuity of business were ensured.

[0182] This invention also provides a scenario example for illustration, as follows:

[0183] The first step is to receive and parse the user's business requests.

[0184] The second step is to check if the request is invalid. Business processing in the civil aviation information system follows a request / response model. If the time interval between a subsequent request and a previous request does not exceed the response time limit (usually 3 seconds), and the previous request has not yet returned a response, the subsequent request is considered invalid. For the device corresponding to the device identifier, the request time of the previous request is obtained, and the current request is checked to see if it is invalid. For invalid requests, the request message is discarded directly, and an error response is returned to the user.

[0185] The third step is to check if the request is too fast based on the traffic control configuration parameters. If the time interval between the current request and the previous request is greater than or equal to the time interval required by the traffic control configuration parameters, continue processing. If the time interval between the current request and the previous request is less than the time interval required by the traffic control configuration parameters, it is considered too fast, the request packet is placed in the traffic cache, and the cache time is set according to the traffic control configuration parameters. After the cache expires, continue processing.

[0186] The fourth step involves forwarding the user request to the system carrying the backend core service according to the routing rules, receiving the business response returned by the system carrying the backend core service, and updating the response status of the device corresponding to the device identifier.

[0187] and Figure 1 Corresponding to the method shown, this embodiment of the invention also provides a business request processing apparatus, which is used to support... Figure 1 The specific implementation of the method shown can be implemented in a civil aviation information system.

[0188] Reference Figure 6 The following is a schematic diagram of a business request processing device provided in an embodiment of the present invention, and is described in detail below:

[0189] The receiving unit 601 is used to receive service requests sent by the front-end device;

[0190] The first judgment unit 602 is used to determine whether the service request is a valid request;

[0191] The second judgment unit 603 is used to determine whether the service request meets the preset caching conditions when it is determined that the service request is a valid request.

[0192] The caching unit 604 is used to set a caching duration for the service request and cache the service request when it is determined that the service request meets the caching conditions;

[0193] The sending unit 605 is used to send the service request to the corresponding service system when the caching time of the service request reaches the caching duration.

[0194] In the apparatus provided in this embodiment of the invention, a service request sent by a front-end device is received; it is determined whether the service request is a valid request; when the service request is determined to be a valid request, it is determined whether the service request meets a preset caching condition; when the service request meets the caching condition, a caching duration is set for the service request, and the service request is cached; when the caching time of the service request reaches the preset caching duration, the service request is sent to the corresponding business system. After receiving a service request, it is determined whether the service request is a valid request. When the service request is determined to be a valid request, it is determined whether the request sending rate of the front-end device meets the preset caching condition. When the request sending rate of the front-end device meets the caching condition, the service request is cached, and the service request is sent to the business system only when the caching time reaches the preset caching duration. This can control the service requests sent to the business system, reduce the request traffic of the business system, avoid business system failures, and ensure the stable operation of the business system.

[0195] In another embodiment of the present invention, the first determining unit 602 of the device includes:

[0196] The first judgment subunit is used to determine whether the previous service request of the front-end device has returned a response message;

[0197] The first determining subunit is used to determine that the service request is a valid message when the previous service request of the front-end device has returned a response message;

[0198] The second determining subunit is used to determine the time interval between the service request and the previous service request when the previous service request of the front-end device has not returned a response message;

[0199] The second judgment subunit is used to determine whether the time interval is greater than the preset response duration;

[0200] The third determining subunit is used to determine that the service request is a valid request when the time interval is greater than the response duration;

[0201] The fourth determining subunit is used to determine that the service request is invalid when the time interval is not greater than the response duration.

[0202] In another embodiment of the present invention, the device further includes:

[0203] The discarding unit is used to discard the service request when it is determined that the service request is invalid.

[0204] In another embodiment of the present invention, the second determination unit 603 of the device includes:

[0205] The acquisition subunit is used to acquire the flow control parameters of the front-end device based on the device identifier of the front-end device;

[0206] The fifth determining subunit is used to determine the flow rate control level of the front-end device based on the rate level identifier in the flow control parameters;

[0207] The third judgment subunit is used to determine whether the time interval is less than the duration corresponding to the flow rate control level;

[0208] The sixth determining subunit is used to determine that the service request does not meet the caching condition when the time interval is not less than the duration corresponding to the traffic rate control level;

[0209] The seventh determining subunit is used to determine that the service request meets the caching condition when the time interval is less than the duration corresponding to the traffic rate control level.

[0210] In another embodiment provided by the present invention, the second determining subunit of the device includes:

[0211] The first determining module is used to determine the first request time of the business request;

[0212] The second determining module is used to determine the second request time of the previous service request;

[0213] The calculation module is used to perform calculations on the first request time and the second request time to obtain the time interval.

[0214] This invention also provides a storage medium, which includes stored instructions, wherein the execution of the instructions controls the device where the storage medium is located to execute the above-described service request processing method.

[0215] This invention also provides an electronic device, the structural schematic of which is shown below. Figure 7 As shown, it specifically includes a memory 701 and one or more instructions 702, wherein one or more instructions 702 are stored in the memory 701 and are configured to be executed by one or more processors 703 to perform the above-mentioned service request processing method.

[0216] The specific implementation processes and derivative methods of the above embodiments are all within the protection scope of this invention.

[0217] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for system or system embodiments, since they are basically similar to method embodiments, the description is relatively simple, and relevant parts can be referred to the descriptions in the method embodiments. The systems and system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0218] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0219] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A service request processing method characterized by comprising: include: Receive business requests sent by the front-end device; Determine whether the service request is a valid request; When the business request is determined to be a valid request, it is determined whether the business request meets the preset caching conditions; The step of determining whether the service request meets the preset caching conditions includes: Based on the device identifier of the front-end device, obtain the traffic control parameters of the front-end device; Based on the rate level identifier in the flow control parameters, the flow rate control level of the front-end device is determined; Determine whether the time interval is less than the duration corresponding to the traffic rate control level; wherein, the duration corresponding to the traffic rate control level is the minimum interval between the previous request and the next request initiated by the front-end device under the current traffic rate control level; different traffic rate control levels correspond to different minimum interval durations; the time interval is the time interval between the service request and the previous service request; When the time interval is not less than the duration corresponding to the traffic rate control level, it is determined that the service request does not meet the caching condition; When the time interval is less than the duration corresponding to the traffic rate control level, it is determined that the service request meets the caching condition; When it is determined that the service request meets the caching conditions, a caching duration is set for the service request, and the service request is cached. When the caching time of the service request reaches the caching duration, the service request is sent to the corresponding business system.

2. The method according to claim 1, characterized in that, The determination of whether the service request is a valid request includes: Determine whether the previous service request from the front-end device has received a response message; When the previous service request from the front-end device has been responded to with a response message, the service request is determined to be a valid message. When the previous service request from the front-end device does not return a response message, the time interval between the service request and the previous service request is determined; Determine whether the time interval is greater than the preset response time. When the time interval is greater than the response duration, the service request is determined to be a valid request; If the time interval is not greater than the response duration, the service request is determined to be an invalid request.

3. The method according to claim 1, characterized in that, Also includes: When the service request is determined to be invalid, the service request is discarded.

4. The method according to claim 2, characterized in that, Determining the time interval between the service request and the previous service request includes: Determine the first request time of the service request; Determine the second request time of the previous service request; The time interval is obtained by calculating the first request time and the second request time.

5. A business request processing device, characterized in that, include: The receiving unit is used to receive service requests sent by the front-end device; The first judgment unit is used to determine whether the service request is a valid request; The second judgment unit is used to determine whether the business request meets the preset caching conditions when it is determined that the business request is a valid request. The second judgment unit includes: The acquisition subunit is used to acquire the flow control parameters of the front-end device based on the device identifier of the front-end device; The fifth determining subunit is used to determine the flow rate control level of the front-end device based on the rate level identifier in the flow control parameters; The third judgment subunit is used to determine whether the time interval is less than the duration corresponding to the traffic rate control level; wherein, the duration corresponding to the traffic rate control level is the minimum interval between the previous request and the next request initiated by the front-end device under the current traffic rate control level; different traffic rate control levels correspond to different minimum interval durations; the time interval is the time interval between the service request and the previous service request. The sixth determining subunit is used to determine that the service request does not meet the caching condition when the time interval is not less than the duration corresponding to the traffic rate control level; The seventh determining subunit is used to determine that the service request meets the caching condition when the time interval is less than the duration corresponding to the traffic rate control level; A caching unit is configured to set a caching duration for the service request and cache the service request when it is determined that the service request meets the caching conditions. The sending unit is used to send the service request to the corresponding service system when the caching time of the service request reaches the caching duration.

6. The apparatus according to claim 5, characterized in that, The first determination unit includes: The first judgment subunit is used to determine whether the previous service request of the front-end device has returned a response message; The first determining subunit is used to determine that the service request is a valid message when the previous service request of the front-end device has returned a response message; The second determining subunit is used to determine the time interval between the service request and the previous service request when the previous service request of the front-end device has not returned a response message; The second judgment subunit is used to determine whether the time interval is greater than the preset response duration; The third determining subunit is used to determine that the service request is a valid request when the time interval is greater than the response duration; The fourth determining subunit is used to determine that the service request is invalid when the time interval is not greater than the response duration.

7. The apparatus according to claim 5, characterized in that, Also includes: The discarding unit is used to discard the service request when it is determined that the service request is invalid.

8. A storage medium, characterized in that, The storage medium includes stored instructions, wherein, when the instructions are executed, the device where the storage medium is located is controlled to perform the service request processing method as described in any one of claims 1-4.

9. An electronic device, characterized in that, It includes a memory, and one or more instructions, wherein one or more instructions are stored in the memory and configured to be executed by one or more processors as described in any one of claims 1-4.

Images