Traffic management and control system and traffic management and control system method

Abstract

A method, an electronic device, a computer readable medium, and a computer program product are provided. The flow management and control system comprises a request processing unit which is used for periodically obtaining an exception list from a strategy center unit and performing local caching, performing legality check on a received request according to the exception list, and reporting request related information to a computing center unit; the computing center unit is used for receiving the requests reported by the request processing unit, distributing the requests received in a preset time period to the same processing equipment according to a timestamp partitioning algorithm, and aggregating and computing the traffic indexes corresponding to the preset time period in the memory of the processing equipment; and the strategy center unit is used for storing a global exception list, receiving the traffic index exception list reported by the calculation center unit to update the global exception list, and synchronizing the updated exception list to each request processing unit.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a traffic control system, traffic control method, electronic device, computer-readable medium, and computer program product. Background Technology

[0002] Open platforms such as live video streaming websites are becoming increasingly important due to their ability to provide rich API services to external developers and vendors. These platforms typically expose hundreds of APIs to support diverse business needs and innovative applications. However, the openness of APIs also brings potential security risks, such as abnormal API calls that could lead to service outages and disrupt normal business operations. To address these challenges, open platforms need an effective API call management architecture to detect abnormal user traffic in real time and intercept it accordingly.

[0003] However, existing traffic control systems often have certain limitations in their design. Some systems, while simple and easy to use, are mainly suitable for monolithic applications and struggle to meet the control requirements of distributed environments. Other systems, while powerful, are complex and may result in high deployment and maintenance costs. Summary of the Invention

[0004] This application aims to provide a traffic control system, traffic control method, electronic device, computer-readable medium, and computer program product, which are designed to solve the problems of poor real-time performance of traffic anomaly detection, high consumption of computing resources, and high complexity of cross-machine aggregation calculation when massive interface calls occur in a distributed environment.

[0005] One aspect of this application provides a traffic control system, characterized in that the system comprises: The request processing unit is used to periodically obtain an exception list from the strategy center unit and cache it locally, perform a validity check on the received requests based on the exception list, and report the request-related information to the computing center unit. The computing center unit is used to receive requests reported by the request processing unit, and allocate the requests received within a preset time period to the same processing device according to the timestamp partitioning algorithm, and aggregate and calculate the traffic indicators corresponding to the preset time period in the memory of the processing device. The strategy center unit is used to store the global anomaly list, receive the traffic metric anomaly list reported by the computing center unit to update the global anomaly list, and synchronize the updated anomaly list to each request processing unit.

[0006] One aspect of this application provides a traffic control method, wherein the method is executed by a request processing unit, a computing center unit, and a policy center unit in a traffic control system, the method comprising: The request processing unit periodically retrieves the exception list from the strategy center unit and caches it locally. Based on the exception list, it performs a validity check on the received requests and reports the relevant request information to the computing center unit. The computing center unit receives the requests reported by the request processing unit and allocates the requests received within a preset time period to the same processing device according to the timestamp partitioning algorithm. The processing device then aggregates and calculates the traffic metrics corresponding to the preset time period in its memory. The strategy center unit receives the list of abnormal traffic metrics reported by the computing center unit to update the global abnormal list, and synchronizes the updated abnormal list with each request processing unit.

[0007] In another aspect, this application provides an electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the methods of embodiments of this application.

[0008] In another aspect, this application provides a computer-readable storage medium having stored thereon computer program instructions that can be executed by a processor to implement the methods of the embodiments of this application.

[0009] Another aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements the methods of embodiments of this application.

[0010] The solution provided in this application embodiment offers a traffic management system comprising a request processing unit, a computing center unit, and a policy center unit. The request processing unit periodically retrieves an exception list from the policy center unit and caches it locally, reducing frequent access to the policy center and lowering the frequency of interaction with different components. By aggregating and calculating traffic metrics such as QPS in the processing device's memory, traffic metric calculation can be completed efficiently without relying on database I / O, ensuring efficient resource utilization and avoiding resource idleness and waste. The computing center unit employs a timestamp partitioning algorithm to allocate requests within a preset time period to the same processing device, improving scheduling efficiency, significantly reducing the time resources are idle, and further enhancing resource utilization. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 A schematic diagram of a traffic control system according to an embodiment of this application is shown; Figure 2(a) shows a schematic diagram of the architecture of an exemplary traffic control system according to an embodiment of this application; Figure 2(b) illustrates an exemplary traffic control process according to an embodiment of this application; Figure 3 A flowchart illustrating a traffic control method according to an embodiment of this application is shown; Figure 4 A schematic diagram of the structure of a device suitable for implementing the scheme in the embodiments of this application is shown.

[0013] The same or similar reference numerals in the accompanying drawings represent the same or similar parts. Detailed Implementation

[0015] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0016] In a typical configuration of this application, the terminal and the service network devices each include one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0017] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0018] Computer-readable media include permanent and non-permanent, removable and non-removable media, which can store information by any method or technology. Information can be computer program instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, read-only optical disc (CD-ROM), digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0019] Figure 1 A schematic diagram of a traffic control system according to an embodiment of this application is shown.

[0020] Reference Figure 1 The traffic control system includes a request processing unit, a computing center unit, and a policy control unit.

[0021] According to one embodiment, the traffic control system is a distributed system. The distributed system includes a group of independent computers that collaborate through a network to achieve a common goal, appearing externally as a unified whole, but its internal components may run on different physical or logical nodes. Distributed computing in a distributed system is a technique that breaks down computational tasks and distributes them across multiple computers for parallel processing, aiming to improve computational efficiency and processing power. It connects multiple nodes through a network to work collaboratively, share resources, and coordinate task execution. Distributed computing can be used to process large-scale data, complex calculations, or high-concurrency requests, and is a fundamental supporting technology for fields such as cloud computing, big data, and artificial intelligence. Common architectures include distributed task queues, computing frameworks, and service orchestration systems.

[0022] The request processing unit is used to periodically obtain an exception list from the strategy center unit and cache it locally, perform a validity check on the received requests based on the exception list, and report the request-related information to the computing center unit.

[0023] Optionally, the request unit is implemented using an SDK.

[0024] The request processing unit in this embodiment runs on a gateway device to achieve efficient management and control of received requests. The gateway device includes, but is not limited to, network routers, network switches, load balancers, firewalls, and dedicated media gateway devices. These devices are widely used in various network environments, from enterprise intranets to large data centers, and from traditional wired networks to modern wireless network infrastructure.

[0025] Specifically, the request processing unit periodically retrieves the latest anomaly list from the policy center unit and stores it in a local cache. This anomaly list records traffic sources identified as abnormal, including but not limited to IP addresses, user IDs, and device identifiers. This approach allows the request processing unit to respond quickly to requests without needing to query the policy center unit in real time for each request, thus improving system response speed and efficiency. The locally cached anomaly list forms the basis for the system's legitimacy checks.

[0026] According to one embodiment, in response to receiving a request, the request processing unit performs a validity check on the request. If the request matches the exception list, the request processing unit intercepts the request and returns a corresponding rejection response message, thereby preventing the exception request from entering the subsequent processing flow. If the request does not match the exception list, the request processing unit will allow the request to proceed with subsequent processing.

[0027] According to one embodiment, the request is a service request. The service request can originate from various devices. Specifically, the service request can originate from a client device, which is the terminal through which the user interacts with the network system and is the initiating point of the service request. The client device includes, but is not limited to, various terminal devices such as computers, mobile phones, tablets, smartwatches, and wristbands. These devices communicate with the gateway device through various network connection methods (such as Wi-Fi, 4G / 5G, wired networks, etc.) to send service requests to obtain the required services or data.

[0028] Besides client devices, service requests can also originate from other devices, such as servers, middleware, and IoT devices. These devices perform different functions in the network architecture; they may act as service providers, data processing nodes, or data acquisition terminals, sending service requests to interact with other system components. For example, IoT devices may periodically send sensor data to backend servers for processing, while middleware may forward service requests to enable communication and collaboration between different systems. These service requests also need to undergo validity checks and traffic control by the request processing unit to ensure the secure and stable operation of the entire network system.

[0029] According to one embodiment, the request processing unit is further configured to report request-related information to the computing center unit. By reporting the request-related information to the computing center unit, the computing center unit can collect and analyze traffic data in real time, thereby achieving dynamic monitoring and management of traffic. Request-related information includes, but is not limited to, the request's timestamp, request source (such as IP address, user identifier, or device identifier), request type (such as GET, POST), and request size.

[0030] The computing center unit is used to receive requests reported by the request processing unit, and allocate the requests received within a preset time period to the same processing device according to the timestamp partitioning algorithm, and aggregate and calculate the traffic index corresponding to the preset time period in the memory of the processing device.

[0031] The computing center unit can be deployed on various types of devices, including but not limited to high-performance server clusters, cloud servers, and containerized environments. These devices can have high-performance CPUs and large-capacity memory to meet the needs of real-time computing and data processing. The size of the computing center unit can be horizontally scaled according to actual traffic volume and business needs, increasing the system's processing capacity by adding more processing devices.

[0032] Optionally, the computing center unit may distribute requests received within a preset time period to the same process on the same processing device for processing, thereby further optimizing computing efficiency and reducing the overhead of inter-process communication. By processing requests received within a preset time period in the same process, the memory space and computing resources within the process can be fully utilized, improving the speed and efficiency of data processing.

[0033] The timestamp partitioning algorithm of this application embodiment will be described below. The core idea of ​​this timestamp partitioning algorithm is to allocate requests received within a preset time period to the same processing device through the modulo operation of the timestamp.

[0034] According to one embodiment, the process of the timestamp partitioning algorithm includes: For each received request, obtain its timestamp. Each request carries a timestamp indicating the time the request was sent or arrived. The timestamp can be in milliseconds or microseconds, precisely recording the request's time information.

[0035] Next, the number of processing devices capable of handling the request is determined. The number of processing devices (N) can be pre-configured based on the actual system size and business needs. Alternatively, the number of machines (N) can be dynamically changed.

[0036] Optionally, a pre-configured processing device can be used as the processing device capable of handling the request.

[0037] Optionally, based on the real-time load of the processing devices, processing devices with lower loads are selected as those capable of handling the request. Real-time load can be assessed by monitoring metrics such as CPU and memory utilization, queue length, and response time for each processing device. If the load of a processing device exceeds a preset threshold (e.g., CPU utilization exceeds 80% or queue length exceeds a certain value), the device is determined to be under high load and unsuitable for handling the request. If the device's load does not exceed the preset threshold, it is considered a suitable device for handling the request.

[0038] Next, a modulo operation is performed on the timestamp and the number of processing devices. Specifically, the timestamp of the request is divided by the number of machines (N), and the remainder is taken. This remainder can be used as an index for allocating the target machine.

[0039] Next, the requests are allocated to the corresponding processing devices based on the modulo result, so that all requests received within the preset time period are allocated to the same processing device.

[0040] For example, to allocate requests within the same preset time period (e.g., 2 seconds) to the same machine for processing, an allocation strategy based on timestamps and modulo operations is adopted. Specifically, the timestamp of each request is first obtained. The timestamp is usually in milliseconds, accurately recording the time information of the request. For example, suppose three requests are received, with timestamps of 123456789, 123456790, and 123456791, all corresponding to the second part of 123456.

[0041] To ensure that requests within the same preset time period are assigned to the same machine, the seconds portion of the timestamp is divided by the preset time period length (2 seconds), and the integer part is taken. Then, this result is moduloed by the number of machines N. Assuming 10 processing devices are pre-configured (N=10), for these three requests, the following calculation is performed: For timestamp 123456, 123456 / 2 = 61728 is calculated, and then 61728%10 = 8 is calculated, ensuring that all three requests will be assigned to the 8th machine.

[0042] According to one embodiment, the computing center unit monitors changes in the number of available processing devices. If the number of available processing devices changes, a modulo operation is performed in the timestamp partitioning algorithm based on the current number of available processing devices, and processing devices are allocated.

[0043] In distributed systems, the number of machines (available processing devices) may change dynamically (e.g., due to machine failures or the addition of new machines). When the number of machines changes, the mapping relationship of timestamp partitions needs to be recalculated. For example, if the number of machines decreases from 10 to 9, the system needs to reallocate requests to ensure that requests within the same time period are still correctly assigned to the same machine.

[0044] Optionally, the computing center unit uses a load balancing algorithm (such as consistent hashing) to optimize the allocation of requests when redistributing them, thereby avoiding some machines from being overloaded while others are idle by taking load balancing into account.

[0045] Optionally, to cope with machine failures, the system adopts a primary / standby mode, whereby the standby machine can take over its tasks when the primary machine fails, ensuring continuous system operation. Furthermore, distributed consensus protocols (such as Raft or Paxos) can be used to ensure data consistency and reliability.

[0046] According to one embodiment, after requests are allocated to the same processing device, aggregation calculations are performed in the memory of the processing device to obtain the traffic metrics corresponding to the preset time period. Since all requests within the preset time period are allocated to the same processing device, aggregation calculations can be performed directly in the processing device's memory without relying on an external database. This in-memory calculation method improves calculation speed, reduces dependence on storage systems, and lowers system latency.

[0047] Optionally, the traffic metric is the number of requests received within a preset time period. The computing center unit determines whether the traffic metric is abnormal by comparing the number of requests received within the preset time period with a preset threshold. Specifically, if the number of requests received within the preset time period exceeds the preset threshold, the computing center unit determines that the traffic metric is abnormal.

[0048] Optionally, the traffic metric is the number of interface requests received per second (QPS). The process of calculating QPS by the computing center unit includes: the computing center unit aggregating requests within the same time period in the memory of the processing device. Optionally, an in-memory data structure (such as a hash table or array) is maintained in the processing device to record the number of requests within each time period; then, the computing center unit counts the number of requests received within 1 second and calculates the QPS. The formula for calculating QPS is: for example, if 100 requests are received within 1 second, the QPS is 100.

[0049] If an abnormal traffic metric is determined, the computing center unit also generates a corresponding abnormal traffic metric list and reports it to the policy center unit. The abnormal metric list may include request sources (such as IP addresses, user identifiers, etc.) that exhibited abnormal traffic within a preset time period.

[0050] Optionally, the computing center unit employs a sliding window algorithm when calculating QPS to smooth the calculation results. The sliding window algorithm maintains a fixed-size time window and dynamically calculates the QPS within the window, thereby avoiding misjudgments caused by sudden traffic surges.

[0051] Optionally, the computing center unit uses the exponential moving average (EMA) algorithm when calculating QPS. The EMA algorithm dynamically adjusts the QPS calculation results by assigning higher weights to recent data, thereby more accurately reflecting the current traffic situation.

[0052] Optionally, the computing center unit integrates monitoring and alarm mechanisms to monitor the system's operating status and traffic metrics in real time. When traffic metrics exceed preset thresholds or system anomalies occur, the system can automatically trigger alarms to notify maintenance personnel for handling.

[0053] The computing center unit in this embodiment can efficiently process and analyze requests, calculate traffic metrics in real time, and generate an anomaly list and report it to the policy center when traffic is abnormal. This improves the system's performance and reliability, enhances its adaptability and scalability, and enables it to cope with various complex network environments and business needs.

[0054] The strategy center unit is used to store the global anomaly list, receive the traffic metric anomaly list reported by the computing center to update the global anomaly list, and synchronize the updated anomaly list to each request processing unit to achieve traffic control.

[0055] The policy center unit can be deployed on various types of devices, including but not limited to high-performance servers, cloud servers, and containerized environments. These devices typically have high-performance CPUs, large-capacity memory, and high-speed storage devices to meet data storage and processing needs. Optionally, the policy center unit can be horizontally scaled according to actual business requirements, increasing system processing capacity by adding more processing devices. Furthermore, the policy center unit can also be deployed in a high-availability architecture, such as master-slave failover and load balancing, to ensure system reliability and stability.

[0056] The strategy center unit in this embodiment has efficient data storage and management capabilities to ensure the accuracy and completeness of the anomaly list. The anomaly list can be stored in a high-performance database, such as a relational database (MySQL, PostgreSQL) or a non-relational database (Redis, MongoDB), to meet the requirements of fast read and write operations.

[0057] Optionally, the policy center unit verifies and processes the received list of anomalies to ensure its accuracy and reliability.

[0058] The strategy center unit synchronizes the updated exception list with each request processing unit to achieve traffic control. The synchronization mechanism can be implemented in various ways, such as through HTTP / HTTPS interfaces, message queues (e.g., RabbitMQ, Kafka), or WebSockets, to ensure efficient and reliable data transmission.

[0059] Optionally, in order to ensure the consistency of the global anomaly list, the policy center unit may use a distributed consistency protocol (such as Raft or Paxos) to implement data consistency management.

[0060] Optionally, to ensure that the request processing unit can obtain the latest exception list in a timely manner, the policy center unit uses technologies such as message queues or WebSockets to achieve real-time data synchronization and efficient communication.

[0061] Optionally, the strategy center unit adopts an incremental update method, only synchronizing the updated part of the data to reduce the amount of data transmission.

[0062] Optionally, to prevent unauthorized access, the policy center unit can authenticate and authorize the accessing request processing unit.

[0063] According to one embodiment, the policy center unit provides personalized exception list management and services for different traffic control users, such as setting different traffic indicators or indicator thresholds, thereby achieving more granular traffic control for different users.

[0064] The policy center unit in this embodiment can efficiently manage the global anomaly list, receive and update the anomaly list, and promptly synchronize the updated anomaly list to each request processing unit. This approach improves system performance and reliability, enhances system adaptability and scalability, and can cope with various complex network environments and business requirements.

[0065] According to the traffic control system of this application embodiment, the request processing unit periodically obtains the abnormal list from the policy center unit and caches it locally, thereby reducing the frequent access to the policy center and lowering the interaction frequency with different components. By aggregating and calculating traffic indicators such as QPS in the memory of the processing device, the calculation of traffic indicators can be completed efficiently without relying on database I / O, ensuring efficient use of resources and avoiding resource idleness and waste. By using a timestamp partitioning algorithm by the calculation center unit to allocate requests within a preset time period to the same processing device, scheduling efficiency is improved, the time when resources are idle is significantly reduced, and resource utilization is further improved.

[0066] The traffic control system of this application will be described below with reference to Figures 2(a) and 2(b).

[0067] Figure 2(a) shows an architectural diagram of an exemplary traffic control system according to an embodiment of the present application; Figure 2(b) shows an exemplary traffic control process according to an embodiment of the present application.

[0068] This example traffic management system is a distributed architecture designed to effectively manage and control network traffic. The system consists of three core components: an SDK, a compute center, and a policy center, which work together to identify, intercept, and handle abnormal traffic. Figure 2(a) also illustrates the two tasks, Job-0 and Job-1, within the compute center. Job-0 receives request records from the SDK, while Job-1 performs aggregation calculations on these request records. Job-1 has three time windows (T1, T2, T3), each responsible for calculating the QPS value over a given period. If the QPS value within a time window exceeds a threshold, Job-1 reports the list to the policy center so that the policy center can update the abnormal traffic list.

[0069] Referring to Figures 2(a) and 2(b), the operation flow of the SDK, the computing center, and the policy center, and their interaction flow in this example are as follows: As the interface for gateway access control, the SDK is responsible for receiving external requests and performing initial processing. The SDK periodically retrieves the latest exception list from the policy center and stores it in the local cache (SDK.Cache). When a new request is received, the SDK checks if the request matches the exception list. If the request matches the exception list, the SDK intercepts the request and prevents further processing; if it does not match, the SDK allows the request to pass and performs normal business processing. After processing, the SDK reports the request record to the computing center.

[0070] The computing center is responsible for receiving request records from the SDK and performing traffic aggregation calculations. Using a timestamp partitioning algorithm, the computing center aggregates all requests within the same second into the same process on the same machine, thereby calculating the queries per second (QPS) in the machine's memory. If the calculated QPS value exceeds a preset threshold (MaxQps), the computing center reports this list to the policy center so that the policy center can update the abnormal list.

[0071] The policy center serves as the storage and distribution hub for the global anomaly list. It periodically retrieves the latest anomaly lists from the anomaly list database and distributes these lists to various SDKs, enabling the SDKs to update their cached anomaly lists promptly and achieve real-time interception of abnormal traffic.

[0072] Throughout the process, the SDK retrieves the exception list from the strategy center via a scheduled task and reports the processed request records to the computing center. The computing center is responsible for aggregating the computational QPS and, when necessary, reporting the exception list back to the strategy center. Upon receiving the report, the strategy center updates the exception list and distributes it to the SDK, ensuring that the SDK can respond promptly to the latest changes in the exception list.

[0073] This example traffic management system, through the collaborative work of the SDK, computing center, and policy center, achieves real-time monitoring of network traffic, identification and interception of abnormal traffic, and dynamic updates to the abnormal traffic list. This design not only improves the system's response speed and processing capacity but also ensures the timely interception and handling of abnormal traffic.

[0074] Figure 3 A flowchart illustrating a traffic control method according to an embodiment of this application is shown. The method includes at least steps S101, S102, and S103. The method is executed by a request processing unit, a computing center unit, and a policy center unit in the traffic control system of this application embodiment.

[0075] In step S101, the request processing unit periodically retrieves the exception list from the policy center unit and caches it locally. Based on the exception list, it performs a validity check on the received requests and reports the relevant request information to the computing center unit.

[0076] Specifically, the request processing unit periodically retrieves the latest anomaly list from the policy center unit and stores it in a local cache. This anomaly list records traffic sources identified as abnormal, including but not limited to IP addresses, user IDs, and device identifiers. This approach allows the request processing unit to respond quickly to requests without needing to query the policy center unit in real time for each request, thus improving system response speed and efficiency. The locally cached anomaly list forms the basis for the system's legitimacy checks.

[0077] According to one embodiment, in response to receiving a request, the request processing unit performs a validity check on the request. If the request matches the exception list, the request processing unit intercepts the request and returns a corresponding rejection response message, thereby preventing the exception request from entering the subsequent processing flow. If the request does not match the exception list, the request processing unit will allow the request to proceed with subsequent processing.

[0078] According to one embodiment, the request is a service request, which can originate from various devices. The devices from which the request originates have been described above and will not be repeated here.

[0079] According to one embodiment, the request processing unit reports request-related information to the computing center unit. By reporting the request-related information to the computing center unit, the computing center unit can collect and analyze traffic data in real time, thereby achieving dynamic monitoring and management of traffic. The request-related information includes, but is not limited to, the request timestamp, request source (such as IP address, user identifier, or device identifier), request type (such as GET, POST), and request size.

[0080] In step S102, the computing center unit receives the request reported by the request processing unit, and allocates the requests received within a preset time period to the same processing device according to the timestamp partitioning algorithm, and aggregates and calculates the traffic index corresponding to the preset time period in the memory of the processing device.

[0081] Optionally, the computing center unit may distribute requests received within a preset time period to the same process on the same processing device for processing, thereby further optimizing computing efficiency and reducing the overhead of inter-process communication. By processing requests received within a preset time period in the same process, the memory space and computing resources within the process can be fully utilized, improving the speed and efficiency of data processing.

[0082] The timestamp partitioning algorithm of this application embodiment will be described below. The core idea of ​​this timestamp partitioning algorithm is to allocate requests received within a preset time period to the same processing device through the modulo operation of the timestamp.

[0083] According to one embodiment, the process of the timestamp partitioning algorithm includes: For each received request, obtain its timestamp. Each request carries a timestamp indicating the time the request was sent or arrived. Timestamps are typically measured in milliseconds or microseconds, precisely recording the request's time information.

[0084] Next, the number of processing devices capable of handling the request is determined. The number of processing devices (N) can be pre-configured based on the actual system size and business needs. Alternatively, the number of machines (N) can be dynamically changed.

[0085] Optionally, a pre-configured processing device can be used as the processing device capable of handling the request.

[0086] Optionally, based on the real-time load of the processing devices, processing devices with lower loads are selected as those capable of handling the request. Real-time load can be assessed by monitoring metrics such as CPU and memory utilization, queue length, and response time for each processing device. If the load of a processing device exceeds a preset threshold (e.g., CPU utilization exceeds 80% or queue length exceeds a certain value), the device is determined to be under high load and unsuitable for handling the request. If the device's load does not exceed the preset threshold, it is considered a suitable device for handling the request.

[0087] Next, a modulo operation is performed on the timestamp and the number of processing devices. Specifically, the timestamp of the request is divided by the number of machines (N), and the remainder is taken. This remainder can be used as an index for allocating the target machine.

[0088] Next, the requests are allocated to the corresponding processing devices based on the modulo result, so that all requests received within the preset time period are allocated to the same processing device.

[0089] According to one embodiment, the computing center unit monitors changes in the number of available processing devices. If the number of processing devices changes, a modulo operation is performed in the timestamp partitioning algorithm based on the current number of available processing devices, and processing devices are allocated.

[0090] In distributed systems, the number of machines (available processing devices) may change dynamically (e.g., machine failure or the addition of new machines). When the number of machines changes, the mapping relationship of timestamp partitions needs to be recalculated.

[0091] Optionally, the computing center unit uses a load balancing algorithm (such as consistent hashing) to optimize the allocation of requests when redistributing them, thereby avoiding some machines from being overloaded while others are idle by taking load balancing into account.

[0092] Optionally, to cope with machine failures, the system adopts a primary / standby mode, whereby the standby machine can take over its tasks when the primary machine fails, ensuring continuous system operation. Furthermore, distributed consensus protocols (such as Raft or Paxos) can be used to ensure data consistency and reliability.

[0093] According to one embodiment, after requests are allocated to the same processing device, aggregation calculations are performed in the memory of the processing device to obtain the traffic metrics corresponding to the preset time period. Since all requests within the preset time period are allocated to the same processing device, aggregation calculations can be performed directly in the processing device's memory without relying on an external database. This in-memory calculation method improves calculation speed, reduces dependence on storage systems, and lowers system latency.

[0094] Optionally, the traffic metric is the number of requests received within a preset time period. The computing center unit determines whether the traffic metric is abnormal by comparing the number of requests received within the preset time period with a preset threshold. Specifically, if the number of requests received within the preset time period exceeds the preset threshold, the computing center unit determines that the traffic metric is abnormal.

[0095] Optionally, the traffic metric is the number of interface requests received per second (QPS). The process of calculating QPS by the computing center unit includes: the computing center unit aggregating requests within the same time period in the memory of the processing device. Optionally, an in-memory data structure (such as a hash table or array) is maintained in the processing device to record the number of requests within each time period; then, the computing center unit counts the number of requests received within 1 second and calculates the QPS.

[0096] If an abnormal traffic metric is identified, the computing center unit generates a corresponding list of abnormal traffic metrics and reports it to the policy center unit. This list may include the request sources (such as IP addresses, user identifiers, etc.) that caused the abnormal traffic within a preset time period.

[0097] Optionally, the computing center unit employs a sliding window algorithm when calculating QPS to smooth the calculation results. The sliding window algorithm maintains a fixed-size time window and dynamically calculates the QPS within the window, thereby avoiding misjudgments caused by sudden traffic surges.

[0098] Optionally, the computing center unit uses the exponential moving average (EMA) algorithm when calculating QPS. The EMA algorithm dynamically adjusts the QPS calculation results by assigning higher weights to recent data, thereby more accurately reflecting the current traffic situation.

[0099] Optionally, the computing center unit monitors the system's operating status and traffic metrics in real time. When traffic metrics exceed preset thresholds or system anomalies occur, the system can automatically trigger alarms to notify maintenance personnel for handling.

[0100] In step S103, the strategy center unit receives the abnormal traffic indicator list reported by the computing center unit to update the global abnormal list, and synchronizes the updated abnormal list with each request processing unit.

[0101] The strategy center unit in this embodiment has efficient data storage and management capabilities to ensure the accuracy and completeness of the anomaly list. The anomaly list can be stored in a high-performance database, such as a relational database (MySQL, PostgreSQL) or a non-relational database (Redis, MongoDB), to meet the requirements of fast read and write operations.

[0102] Optionally, the policy center unit verifies and processes the received list of anomalies to ensure its accuracy and reliability.

[0103] The strategy center unit synchronizes the updated exception list with each request processing unit to achieve traffic control. The synchronization mechanism can be implemented in various ways, such as through HTTP / HTTPS interfaces, message queues (e.g., RabbitMQ, Kafka), or WebSockets, to ensure efficient and reliable data transmission.

[0104] Optionally, to ensure data consistency in the global anomaly list, the policy center unit uses a distributed consistency protocol (such as Raft or Paxos) to implement data consistency management.

[0105] Optionally, to ensure that the request processing unit can obtain the latest exception list in a timely manner, the policy center unit uses technologies such as message queues or WebSockets to achieve real-time data synchronization and efficient communication.

[0106] Optionally, the strategy center unit adopts an incremental update method, only synchronizing the updated part of the data to reduce the amount of data transmission.

[0107] Optionally, to prevent unauthorized access, the policy center unit can authenticate and authorize the accessing request processing unit.

[0108] According to one embodiment, the policy center unit provides personalized exception list management and services for different traffic control users, such as setting different traffic indicators or indicator thresholds, thereby achieving more granular traffic control for different users.

[0109] The policy center unit in this embodiment can efficiently manage the global anomaly list, receive and update the anomaly list, and promptly synchronize the updated anomaly list to each request processing unit. This approach improves system performance and reliability, enhances system adaptability and scalability, and can cope with various complex network environments and business requirements.

[0110] According to the traffic control method of this application embodiment, the request processing unit periodically obtains the exception list from the policy center unit and caches it locally, which reduces the frequent access of the system to the policy center and reduces the interaction frequency between different components. By aggregating and calculating traffic indicators such as QPS in the memory of the processing device, the calculation of traffic indicators can be completed efficiently without relying on database I / O, ensuring efficient use of resources and avoiding resource idleness and waste. By using a timestamp partitioning algorithm by the calculation center unit to allocate requests within a preset time period to the same processing device, scheduling efficiency is improved, the time when resources are idle is significantly reduced, and resource utilization is further improved.

[0111] Based on the same inventive concept, this application also provides an electronic device. The method corresponding to the electronic device can be the method in the foregoing embodiments, and its problem-solving principle is similar to that method. The electronic device provided in this application includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the methods and / or technical solutions of the foregoing embodiments of this application.

[0112] The electronic device can be a user device, or a device formed by integrating user devices and network devices through a network, or it can be an application running on the aforementioned devices. The user device includes, but is not limited to, various terminal devices such as computers, mobile phones, tablets, smartwatches, and wristbands. The network device includes, but is not limited to, network hosts, single network servers, multiple network server sets, or cloud computing-based computer sets, and can be used to implement some processing functions when setting an alarm clock. Here, the cloud consists of a large number of hosts or network servers based on cloud computing. Cloud computing is a type of distributed computing, consisting of a virtual computer composed of a group of loosely coupled computer sets.

[0113] Figure 4 The diagram illustrates the structure of an apparatus suitable for implementing the methods and / or technical solutions in the embodiments of this application. The apparatus 1200 includes a Central Processing Unit (CPU) 1201, which can perform various appropriate actions and processes based on a program stored in a Read Only Memory (ROM) 1202 or a program loaded from a storage portion 1208 into a Random Access Memory (RAM) 1203. The RAM 1203 also stores various programs and data required for system operation. The CPU 1201, ROM 1202, and RAM 1203 are interconnected via a bus 1204. An Input / Output (I / O) interface 1205 is also connected to the bus 1204.

[0114] The following components are connected to I / O interface 1205: an input section 1206 including a keyboard, mouse, touchscreen, microphone, infrared sensor, etc.; an output section 1207 including a cathode ray tube (CRT), liquid crystal display (LCD), LED display, OLED display, etc., and speakers, etc.; a storage section 1208 including one or more computer-readable media such as hard disk, optical disk, magnetic disk, semiconductor memory, etc.; and a communication section 1209 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 1209 performs communication processing via a network such as the Internet.

[0115] In particular, the methods and / or embodiments in this application can be implemented as computer software programs. For example, the embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowchart. When the computer program is executed by the central processing unit (CPU) 1201, it performs the functions defined in the methods of this application.

[0116] Another embodiment of this application provides a computer-readable storage medium having computer program instructions stored thereon, which can be executed by a processor to implement the methods and / or technical solutions of any one or more embodiments of this application described above.

[0117] Specifically, this embodiment may employ any combination of one or more computer-readable media. A computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0118] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0119] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0120] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0121] The flowcharts or block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of devices, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-specific system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0122] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0123] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or page components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between devices or units through some interfaces, and may be electrical, mechanical, or other forms.

[0124] 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 units can be selected to achieve the purpose of this embodiment according to actual needs.

[0125] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in a combination of hardware and software functional units.

[0126] The integrated units implemented as software functional units described above can be stored in a computer-readable storage medium. These software functional units, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0127] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

[0128] Furthermore, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices described in an apparatus may also be implemented by a single unit or device through software or hardware. Terms such as "first," "second," etc., are used to indicate names and do not indicate any specific order.

Claims

1. A flow management system, characterized by, The system includes: The request processing unit is used to periodically obtain an exception list from the strategy center unit and cache it locally, perform a validity check on the received requests based on the exception list, and report the request-related information to the computing center unit. The computing center unit is used to receive requests reported by the request processing unit, and allocate the requests received within a preset time period to the same processing device according to the timestamp partitioning algorithm, and aggregate and calculate the traffic indicators corresponding to the preset time period in the memory of the processing device. The strategy center unit is used to store the global anomaly list, receive the traffic metric anomaly list reported by the computing center unit to update the global anomaly list, and synchronize the updated anomaly list to each request processing unit.

2. The system of claim 1, wherein, The timestamp partitioning algorithm performs a modulo operation based on the request's timestamp and the number of processing devices to ensure that all requests received within a preset time period are assigned to the same processing device. The process of the timestamp partitioning algorithm includes: For each received request, obtain the timestamp of that request; Determine the number of processing devices that can handle the request; Perform a modulo operation on the timestamp and the number of processing devices; The requests are assigned to the corresponding processing devices based on the modulus result, so that all requests received within a preset time period are assigned to the same processing device.

3. The system of claim 1 or 2, wherein, The computing center unit will distribute requests received within a preset time period to the same process on the same processing device for processing.

4. The system according to claim 1 or 2, characterized in that, The traffic metric is the number of requests received within a preset time period, and the computing center unit is also used for: The system determines whether traffic metrics are abnormal by comparing the number of requests received within a preset time period with a preset threshold.

5. The system according to claim 1, characterized in that, If an abnormal traffic metric is identified, the computing center unit generates a corresponding list of abnormal traffic metrics and reports it to the strategy center unit.

6. A traffic control method, wherein, The method is executed by the request processing unit, computing center unit, and policy center unit of the traffic control system, and the method includes: The request processing unit periodically retrieves the exception list from the strategy center unit and caches it locally. Based on the exception list, it performs a validity check on the received requests and reports the relevant request information to the computing center unit. The computing center unit receives the requests reported by the request processing unit and allocates the requests received within a preset time period to the same processing device according to the timestamp partitioning algorithm. The processing device then aggregates and calculates the traffic metrics corresponding to the preset time period in its memory. The strategy center unit receives the list of abnormal traffic metrics reported by the computing center unit to update the global abnormal list, and synchronizes the updated abnormal list with each request processing unit.

7. The method according to claim 6, wherein, The timestamp partitioning algorithm performs a modulo operation based on the request's timestamp and the number of processing devices to ensure that all requests received within a preset time period are assigned to the same processing device. The process of the timestamp partitioning algorithm includes: For each received request, obtain the timestamp of that request; Determine the number of machines that can handle the request; Perform a modulo operation on the timestamp and the number of processing devices; The requests are assigned to the corresponding processing devices based on the modulus result, so that all requests received within a preset time period are assigned to the same processing device.

8. An electronic device, the electronic device comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 6 or 7.

9. A computer-readable medium having stored thereon computer program instructions that can be executed by a processor to implement the method as described in any one of claims 6 or 7.

10. A computer program product comprising a computer program that, when executed by a processor, implements the method as described in any one of claims 6 or 7.

Images