A hybrid thread-based event processing method and related device

Abstract

The application discloses a hybrid thread-based event processing method and related equipment, and relates to the technical field of computer networks. The method comprises the following steps: acquiring event parameters for a client, wherein the event parameters comprise a plurality of events; performing delay analysis based on the events to obtain delay types of the events; and performing hybrid thread processing on the event parameters based on the delay types of the plurality of events to obtain response parameters for the client, wherein the hybrid thread processing represents thread processing in which an epoll working thread and a Busy Polling dedicated thread are mixed. The method solves the problem that a single thread cannot meet event delay requirements when processing a large number of concurrent tasks.

Description

Technical Field

[0001] This application relates to the field of computer network technology, and in particular to an event processing method and related device based on hybrid threads. The related device includes: hybrid threads, a hybrid thread-based event processing system, a computing device, and a computer-readable storage medium. Background Technology

[0002] With the rapid development of computer technology and the increasing demand for multitasking, thread event processing is widely used in various computer systems, application software, and embedded devices. Existing thread processing methods often use a single thread to handle event tasks.

[0003] However, when a single thread handles a large number of concurrent tasks, it is easy to cause event backlog and queuing delays, resulting in untimely responses to high-priority tasks. When a thread is blocked or encounters an exception due to an individual task, the entire event processing flow will come to a standstill, which will seriously affect system availability and make it impossible to meet event delay requirements. Summary of the Invention

[0004] To overcome the problem that existing single-threaded systems cannot meet event latency requirements when handling a large number of concurrent tasks, this application provides an event processing method and related devices based on hybrid threads. The related devices include: hybrid threads, a hybrid thread-based event processing system, a computing device, and a computer-readable storage medium.

[0005] Firstly, in order to solve the aforementioned technical problems, this application provides an event handling method based on hybrid threads, including:

[0006] Retrieve event parameters for the client, which include multiple events;

[0007] Delay analysis is performed based on events to determine the type of delay in an event;

[0008] Event parameters are processed using a hybrid thread based on the delay type of multiple events to obtain response parameters for the client. The hybrid thread processing characterizes the thread processing that combines epoll worker threads and Busy Polling dedicated threads.

[0009] Secondly, a hybrid thread, applying the aforementioned event handling method based on a hybrid thread, wherein the hybrid thread includes:

[0010] A classifier is used to perform latency analysis based on events and determine the latency type of the events.

[0011] epoll worker threads;

[0012] The Busy Polling dedicated thread, together with the epoll worker thread, is used to perform mixed thread processing of event parameters based on the delay types of multiple events, to obtain the response parameters for the client.

[0013] Thirdly, this application also provides a hybrid thread-based event processing system. Applying the aforementioned hybrid thread-based event processing method, the hybrid thread-based event processing system includes:

[0014] The acquisition module is used to acquire event parameters for the client, which include multiple events;

[0015] The type determination module is used to perform delay analysis based on events and obtain the delay type of the events;

[0016] The hybrid thread processing module is used to perform hybrid thread processing on event parameters based on the delay type of multiple events to obtain response parameters for the client. Hybrid thread processing represents thread processing that combines epoll worker threads and Busy Polling dedicated threads.

[0017] Fourthly, this application also provides a computing device, including a memory, a processor, and a program stored in the memory and running on the processor, wherein the processor executes the program to implement the steps of the hybrid thread-based event handling method described above.

[0018] Fifthly, this application also provides a computer-readable storage medium storing instructions that, when executed on a terminal device, cause the terminal device to perform steps of a hybrid thread-based event handling method.

[0019] The beneficial effects of this application are as follows: By performing latency analysis on the event parameters for the client, the latency type of each event in the event parameters is obtained. Based on the latency types of multiple events, the event parameters are processed using a hybrid thread that combines epoll worker threads and Busy Polling dedicated threads to obtain the response parameters for the client. In this way, the hybrid thread can support massive long connections (concurrency of over 10,000) and microsecond-level ultra-low latency request processing within the same client service process, thereby meeting the latency requirements of different events while handling a large number of concurrent tasks. Attached Figure Description

[0020] Figure 1 This is a flowchart illustrating an exemplary embodiment of an event handling method based on hybrid threads.

[0021] Figure 2 This is a flowchart illustrating the event handling method based on hybrid threads provided by the application in an exemplary embodiment of this application;

[0022] Figure 3 This is a schematic diagram illustrating the structure of an event processing system based on hybrid threads, as shown in an exemplary embodiment of this application.

[0023] Figure 4 This is a schematic diagram of the structure of a computer system of a computing device, illustrating an exemplary embodiment of this application. Detailed Implementation

[0024] The following embodiments are further explanations and supplements to this application and do not constitute any limitation on this application.

[0025] In existing technologies, single-threaded processing solutions can be input / output multiplexing frameworks based on epoll (the input / output event notification mechanism provided by the Linux kernel) / kqueue (an event notification interface provided by BSD-like systems), or frameworks based on busy polling.

[0026] An input / output multiplexing framework based on epoll / kqueue: Principle: A single thread monitors tens of thousands of socket events simultaneously through epoll_wait, and the events are dispatched to worker threads for processing after they are triggered; Advantages: A single thread can manage more than 100,000 connections, with high processor utilization, suitable for large-scale concurrent scenarios; Disadvantages: Event scheduling latency is usually in the millisecond range, and it is difficult to optimize kernel context switching and network stack processing latency to the microsecond level.

[0027] Framework based on busy polling: Principle: A dedicated thread is bound to the processor core to poll the network card receive queue (such as the DPDK data plane development kit) or socket buffer at full load on the corresponding processor core; Advantages: Latency can be reduced to the microsecond level (less than 10 microseconds) with minimal jitter; Disadvantages: Each thread can only handle a small number of connections (usually less than 100 connections), resulting in serious waste of CPU resources and making it unsuitable for large-scale deployment.

[0028] It is evident that existing technologies cannot simultaneously satisfy resource efficiency, dynamic identification, hot migration, and hot migration within the same service. Resource efficiency: Supporting hundreds of thousands of ordinary connections while providing ultra-low latency only for a few critical clients; Dynamic identification: Unable to automatically identify which clients require ultra-low latency service; Hot migration: Unable to dynamically adjust client processing modes at runtime; CPU isolation: Busy polling threads are susceptible to system scheduling interference.

[0029] To address the aforementioned problems, embodiments of this application provide an event processing method and related apparatus based on hybrid threads. The related apparatus includes: hybrid threads, a hybrid thread-based event processing system, a computing device, and a computer-readable storage medium. These embodiments will be described in detail below.

[0030] The event handling method based on hybrid threads provided in this application can be specifically executed by a server. It should be noted that the server can be a standalone server, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms; no limitation is imposed here.

[0031] The application scenarios of this application can include financial transaction systems, cloud gaming servers, IoT gateways, and advertising bidding systems. Specifically, financial transaction systems consist of 99% regular orders and 1% high-frequency trading; cloud gaming servers utilize regular players (epoll) and professional esports players (busy polling); IoT gateways utilize massive amounts of sensor data and real-time control commands; and advertising bidding systems utilize regular bidding and real-time RTB bidding by top advertisers.

[0032] Please see Figure 1 , Figure 1 An exemplary embodiment of this application illustrates an event handling method based on hybrid threads, such as... Figure 1 As shown, this application provides an event handling method based on hybrid threads, including:

[0033] S11, retrieve event parameters for the client, which include multiple events;

[0034] S12, perform delay analysis based on the event to obtain the delay type of the event;

[0035] S13, based on the delay type of multiple events, performs mixed thread processing on the event parameters to obtain the response parameters for the client. Mixed thread processing represents the thread processing that combines epoll worker threads and Busy Polling dedicated threads.

[0036] The hybrid thread-based event processing method provided in this application analyzes the latency of event parameters for the client to obtain the latency type of each event parameter. Based on the latency types of multiple events, it performs hybrid thread processing on the event parameters, combining epoll worker threads and Busy Polling dedicated threads, to obtain the response parameters for the client. In this way, hybrid threads can support massive long-lived connections (concurrency exceeding ten thousand) and microsecond-level ultra-low latency request processing within the same client service process, thereby meeting the latency requirements of different events while handling a large number of concurrent tasks.

[0037] Optionally, the event includes the source IP segment, the TCP Option field, and current event statistics; latency analysis is performed based on the event to obtain the event's latency type, including:

[0038] Analyze the source IP range and find the first latency pattern that matches the source IP range from the preset IP range;

[0039] The delay information is read from the TCP Option field to obtain the second delay mode;

[0040] Based on current event statistics, a third delay pattern is obtained through delay matching.

[0041] If the first, second, and third delay modes are all normal delay modes, then the delay type of the event is determined to be the default delay mode; otherwise, the delay type is determined to be the ultra-low latency mode.

[0042] In the embodiment provided in this application, for each event in the event parameters, its source IP segment is analyzed, and its TCP Option field is read for latency information to obtain a first latency mode, a second latency mode, and a third latency mode. If all three modes are normal latency modes, it indicates that the current event does not have a low latency requirement, and only regular thread processing is needed to meet the client's event latency requirements. In this case, its latency type is determined to be the default latency mode. Otherwise, it indicates that the current event has a low latency requirement, and low-latency thread processing is needed to meet the client's event latency requirements. In this case, its latency type is determined to be the ultra-low latency mode. This allows for subsequent targeted mixed thread processing of time parameters based on the latency type of each event, ensuring that the client's event parameters always meet latency requirements during processing. The normal latency mode includes default latency settings, and the ultra-low latency mode includes set latency reduction settings. The latency duration of the normal latency mode is greater than the latency duration of the ultra-low latency mode.

[0043] Optionally, a third delay pattern is obtained by performing delay matching based on current event statistics, including:

[0044] Retrieve historical statistics data from the client;

[0045] By analyzing the patterns in historical statistical data, we can obtain the historical lag pattern.

[0046] Based on historical delay patterns, a third delay pattern is identified that matches the current event statistics.

[0047] In the embodiment provided in this application, historical delay patterns are obtained by performing regularity analysis on historical statistical data to understand the reasons for the delay of each historical event. Based on the historical delay patterns, a third delay pattern that matches the current event statistical data can be directly found, thereby reducing the difficulty of determining the delay type of the current event statistical data and improving the efficiency of subsequent mixed thread processing of the overall event parameters.

[0048] In an exemplary embodiment provided in this application, delay analysis is performed based on events to obtain the delay type of the events. This is achieved by inserting classification logic into the TCP (Transmission Control Protocol) three-way handshake phase using an Intelligent Connection Classifier. The specific implementation method is as follows:

[0049] Based on the source IP range (such as a list of transaction server IPs), and according to the inclusion relationship between the source IP and the set IP range, the first latency pattern that matches the source IP range is found and marked accordingly.

[0050] Based on the TCP Option field (custom option 0xXX identifier), the second delay mode that matches the delay information in the field is obtained by reading the result of this field, and then marked accordingly.

[0051] Based on historical statistical data (automatically identified for response time-sensitive clients), the system intelligently categorizes and identifies a third latency pattern that matches the current event statistics, and then marks it accordingly.

[0052] Classification results and classification mechanism: The connection is marked as NORMAL (normal latency mode) or ULTRA_LOW_LATENCY (ultra-low latency mode). It can be configured as needed, allowing for any combination of the three mechanisms; as long as one of them meets the ultra-low latency mode standard, it will be marked as ultra-low latency mode.

[0053] In this embodiment, the classification pseudocode example of the intelligent connection classifier is as follows:

[0054] enum conn_type {

[0055] CONN_NORMAL, / / General delay mode flag, followed by normal processing logic (e.g., the processing logic of epoll worker threads).

[0056] CONN_ULTRA_LOW_LATENCY / / Ultra-low latency mode flag, used for busy polling processing logic (e.g., processing logic of a dedicated BusyPolling thread).

[0057] };

[0058] struct connection {

[0059] int fd; / / File descriptor

[0060] enum conn_type type; / / Connection delay mode identifier

[0061] struct cpu_affinity×affinity; / / Processor core affinity, only valid for ultra-low latency mode

[0062] Optionally, event parameters are processed using a mixed thread based on the delay types of multiple events to obtain response parameters for the client, including:

[0063] For events whose delay type in the event parameters is general delay mode, a first TCP connection is established between the event and the preset epoll worker thread based on the event's file descriptor.

[0064] The corresponding event is transmitted to the epoll worker thread via the first TCP connection for event processing, and the first response parameters are obtained.

[0065] For events with an ultra-low latency mode in the event parameters, a second TCP connection is established between the event and the pre-configured Busy Polling dedicated thread based on the event's file descriptor.

[0066] The corresponding event is transmitted to the Busy Polling dedicated thread via a second TCP connection for event processing, and the second response parameters are obtained.

[0067] Based on the first and second response parameters, response parameters for the client are formed.

[0068] In this embodiment provided by the application, for events with a general latency mode in the event parameters, the event corresponding to the first TCP connection established based on the event's file descriptor and a preset epoll worker thread is transmitted to the epoll worker thread for event processing to obtain a first response parameter. Simultaneously, for events with an ultra-low latency mode in the event parameters, the corresponding event is transmitted to the Busy Polling dedicated thread for event processing through a second TCP connection established based on the event's file descriptor and a preset Busy Polling dedicated thread to obtain a second response parameter, forming a response parameter that includes both the first and second response parameters. In this way, by constructing TCP connections for events with different latency types in the event parameters, the epoll worker thread and the Busy Polling dedicated thread can perform targeted thread processing based on the latency requirements of each event, achieving hybrid thread processing. This allows for handling a large number of concurrent tasks while meeting the latency requirements of different events.

[0069] Optionally, event parameters are processed using a mixed thread based on the delay types of multiple events to obtain response parameters for the client, including:

[0070] For each event in the event parameters, a third TCP connection is established between the event and the pre-configured epoll worker thread based on the event's file descriptor;

[0071] The event parameters are input into the epoll worker thread through multiple corresponding third TCP connections. The epoll worker thread processes events with a general delay mode and obtains the third response parameters.

[0072] In the epoll worker thread, when there is an event with the ultra-low latency mode, event migration is triggered, and the event with the ultra-low latency mode is migrated to the preset Busy Polling dedicated thread for event processing to obtain the fourth response parameter.

[0073] Based on the third and second response parameters, response parameters for the client are formed.

[0074] In the embodiment provided in this application, a third TCP connection is established between the event and a preset epoll worker thread based on the file descriptor of each event in the event parameters. The event parameters are then input into the epoll worker thread through multiple corresponding third TCP connections. The epoll worker thread processes events with a general latency mode to obtain a third response parameter. When an event with an ultra-low latency mode exists, event migration is triggered, migrating the ultra-low latency event to a preset Busy Polling dedicated thread for event processing to obtain a fourth response parameter, forming a response parameter that includes both the third and fourth response parameters. In this way, by constructing TCP connections for events with different latency types in the event parameters, the epoll worker thread and the Busy Polling dedicated thread can perform targeted thread processing based on the latency requirements of each event, achieving hybrid thread processing. This allows for handling a large number of concurrent tasks while meeting the latency requirements of different events. Meanwhile, the connection type can be dynamically switched based on fd (file descriptor) migration without rebuilding the connection (because the file descriptor is obtained after the first connection is established, and subsequent connection type switching only uses the file descriptor for migration, so there is no need to rebuild the connection), thereby greatly reducing latency and overhead, improving network utilization, and achieving low latency for thread processing.

[0075] In this embodiment, the event migration is triggered by a dynamic migration mechanism pre-built in the Dual-Mode RuntimeSwitcher engine: mode switching without interrupting the connection is achieved through socket migration technology, and the specific steps are as follows:

[0076] The dup3() system call is used to copy the fd (file descriptor) to the target thread;

[0077] Sequential locks (seqlocks) are used to ensure no data loss during the migration process.

[0078] The migration takes less than 1 millisecond and is transparent to the client.

[0079] In an exemplary embodiment provided in this application, the implementation code example of the epoll worker thread is as follows:

[0080] void×epoll_worker_main(void×arg) {

[0081] int epfd = epoll_create1(EPOLL_CLOEXEC); / / Create an epoll instance and obtain the file descriptor of the epoll instance.

[0082] struct epoll_event events

[1024] ; / / An array of size 1024 used to store epoll instance events.

[0083] while (1) {

[0084] int n = epoll_wait(epfd, events, 1024, 10); / / Copies the events generated by the epoll instance pointed to by the epoll instance file descriptor into the event array. The event array has a maximum size of 1024. The timeout is set to 10 milliseconds, and n is the number of ready events obtained.

[0085] / / Handle ready events

[0086] for (int i = 0; i <n; i++) {

[0087] int fd = events[i].data.fd; / / Get the file descriptor

[0088] struct connection×conn = fd_to_conn(fd); / / Convert a file descriptor into a connection

[0089] / / Check if this connection is marked as ultra-low latency mode

[0090] if (conn->type == CONN_ULTRA_LOW_LATENCY) {

[0091] / / If so, then trigger migration, moving the connection to the Busy Polling thread (a dedicated Busy Polling thread).

[0092] migrate_to_polling(conn);

[0093] / / Continue processing the event array

[0094] continue?

[0095] }

[0096] Otherwise, use the normal event handling logic.

[0097] handle_request(fd);

[0098] }

[0099] }

[0100] }

[0101] In this embodiment, the implementation code example of the Busy Polling dedicated thread is as follows:

[0102] void×polling_worker_main(void×arg) {

[0103] int cpu_id = (int)(long)arg; / / Convert the parameter to the ID of the processor core.

[0104] / / 1. Processor binding

[0105] cpu_set_t mask; / / Creates a set of processor affinities.

[0106] CPU_ZERO(&mask); / / Initialize the collection

[0107] CPU_SET(cpu_id,&mask); / / Adds the processor core corresponding to cpu_id to the set.

[0108] pthread_setaffinity_np(pthread_self(), sizeof(mask), &mask); / / Sets the thread's kernel affinity.

[0109] / / 2. Configure real-time scheduling strategy

[0110] struct sched_param param = { .sched_priority = 99}; / / Set the scheduling priority parameter

[0111] pthread_setschedparam(pthread_self(), SCHED_FIFO, ¶m); / / Apply scheduling priority parameters

[0112] / / 3. Memory locking (prevents memory swapping)

[0113] mlockall(MCL_CURRENT | MCL_FUTURE);

[0114] / / 4. Main polling loop

[0115] while (1) {

[0116] for (int i = 0; i <polling_conn_count; i++) {

[0117] struct connection×conn = polling_conns[i];

[0118] / / Non-blocking read, CPU consumption approximately 5-10%

[0119] int n = recv(conn->fd, buf, sizeof(buf), MSG_DONTWAIT);

[0120] if (n>0) {

[0121] / / Microsecond-level processing

[0122] process_ultra_low_latency(req);

[0123] / / Immediate response, without using the Nagle algorithm

[0124] send(conn->fd, resp, resp_len, MSG_DONTWAIT);

[0125] }

[0126] }

[0127] / / Optional: Call pause() every 1000 loop iterations to reduce power consumption

[0128] if ((++cycles&0x3FF) == 0) {

[0129] / / But it still maintains a sub-microsecond response time.

[0130] }

[0131] }

[0132] }

[0133] Based on the hybrid thread processing using the epoll worker thread and the Busy Polling dedicated thread described above, the final performance metrics compared with the traditional solution are shown in Table 1.

[0134] Table 1

[0135]

[0136] Optionally, before obtaining the event parameters for the client, a hybrid thread-based event handling method further includes:

[0137] Processor initialization specifically includes detecting processor topology, isolating processor cores, and binding network card interrupts;

[0138] Create an epoll worker thread and a Busy Polling dedicated thread, which are used together for thread processing;

[0139] Initialize the classifier, which is used for delayed analysis.

[0140] In the embodiment provided in this application, system initialization is achieved by initializing the processor, initializing the classifier, and pre-creating the epoll worker thread and the Busy Polling dedicated thread. This pre-allocates resources, configures the execution environment, and establishes a management framework, providing a stable and efficient foundation for subsequent event processing based on high-concurrency event parameters.

[0141] In an exemplary embodiment provided in this application, processor initialization may further include the following:

[0142] Processor core isolation and interrupt binding: ① isolcpus mechanism: Isolates specified processor cores from the kernel scheduling domain at startup (e.g., isolcpus=2,3); ② Interrupt affinity: Binds the network card receive queue (RSS) interrupt to a non-isolated core to avoid interfering with busy polling threads; ③ Memory topology awareness: Uses numactl (a tool that allows users to control the non-uniform memory access policy of processes in Linux) to bind the memory of busy polling threads to the same NUMA (non-uniform memory access) node.

[0143] User-space protocol stack (optional enhancements): ① For ultra-low latency connections, bypass the kernel TCP stack; ② Use AF_XDP sockets to directly access the network card driver; ③ Custom lightweight reliable transport protocol (similar to QUIC (Quick UDP InternetConnections) but simplified version); ④ Memory pool pre-allocation to eliminate latency caused by memory allocation.

[0144] Adaptive Load Balancer: ① When the number of connections in a single busy polling thread is greater than 100 or the processor core utilization is greater than 90%, it will automatically trigger: ② Distribute new connections to epoll mode; ③ Or start a new busy polling thread (requires more reserved processor cores).

[0145] In this embodiment, the initialization implementation code example is as follows:

[0146] void server_init() {

[0147] / / 1. Detect processor topology

[0148] detect_cpu_topology();

[0149] / / 2. Isolate the processor core (root privileges required)

[0150] / / echo 2,3> / sys / devices / system / cpu / isolated

[0151] isolate_cpus(2, 3);

[0152] / / 3. Network adapter binding interrupted

[0153] bind_irq_to_cpu(interrupt_number, 0); / / Bind to CPU0

[0154] / / 4. Create an epoll thread pool (default 4 threads)

[0155] epoll_pool = create_thread_pool(4, epoll_worker_main);

[0156] / / 5. Create a busy polling thread (bound to an isolated core)

[0157] for (int cpu = 2; cpu<= 3; cpu++) {

[0158] pthread_create(&polling_thread,

[0159] attr = { .cpu_affinity = cpu},

[0160] polling_worker_main);

[0161] }

[0162] / / 6. Initialize the classifier

[0163] classifier_init("vip_ips.txt", / / VIP IP list)

[0164] auto_detect = true);

[0165] }

[0166] An embodiment of this application provides a hybrid thread that applies the aforementioned event handling method based on a hybrid thread. The hybrid thread includes:

[0167] A classifier is used to perform latency analysis based on events and determine the latency type of the events.

[0168] epoll worker threads;

[0169] The Busy Polling dedicated thread, together with the epoll worker thread, is used to perform mixed thread processing on event parameters based on the delay type of multiple events, in order to obtain response parameters for the client.

[0170] The hybrid thread of this embodiment uses a classifier to perform latency analysis on event parameters for the client, obtaining the latency type of each event in the event parameters. Then, it utilizes both epoll worker threads and a dedicated Busy Polling thread to perform hybrid thread processing on the event parameters based on the latency types of multiple events, resulting in response parameters for the client. In this way, hybrid threads can support massive long-lived connections (concurrency exceeding ten thousand) and microsecond-level ultra-low latency request processing within the same client service process, thereby meeting the latency requirements of different events while handling a large number of concurrent tasks.

[0171] This application presents a hybrid thread-based event handling method, providing a hybrid network framework that achieves a hybrid scheduling architecture with zero copy, zero lock contention, and CPU-level isolation within the same server process. Specifically, for ordinary clients: the epoll mechanism is used, supporting over 100,000 connections per thread; for ultra-low latency clients (<1% of connections): a dedicated thread, busy polling, is used, with latency <10μs.

[0172] This application's event handling method based on hybrid threads proposes for the first time a runtime adaptive hybrid scheduling model, breaking through the limitations of traditional single-mode scheduling. Simultaneously, it dynamically switches connection types based on file descriptor migration, eliminating the need to rebuild connections (because a file descriptor is obtained after the initial connection establishment, subsequent connection type switching only utilizes the file descriptor for migration, thus avoiding connection reconstruction). Furthermore, a CPU topology-aware resource isolation mechanism achieves physical-level latency guarantees. Therefore, this application offers technical advantages in cost reduction, elastic scalability, high reliability, and simplified operation and maintenance. Specifically, cost reduction is reflected in: no need to deploy a separate service cluster for ultra-low latency; elastic scalability is reflected in: the number of VIP clients can be dynamically adjusted at runtime; high reliability is reflected in: polling thread crashes do not affect the epoll pool, and vice versa; simplified operation and maintenance is reflected in: unified monitoring, logging, and configuration management.

[0173] Please see Figure 2 , Figure 2 This is a flowchart illustrating the event handling method based on hybrid threads provided by the application in an exemplary embodiment of this application, as shown below. Figure 2 As shown, the application flow of the event handling method based on hybrid threads is as follows:

[0174] Control Plane: Identifies the latency type of each event in the event parameters obtained from the client by connecting the classifier and the CPU topology awareness;

[0175] epoll worker thread pool (default mode): It processes events with a general delay mode through event-driven and dynamic load balancing to obtain the first response parameters, and can complete 99% of the event processing in ordinary clients.

[0176] Busy Polling dedicated thread (low latency mode): Processes events with ultra-low latency mode through CPU binding (isolcpus) and user-space network stack to obtain the second response parameters, and can complete the processing of 1% of the events in VIP clients (clients with ultra-low latency requirements).

[0177] Please see Figure 3 , Figure 3 An exemplary embodiment of this application illustrates an event handling method based on hybrid threads, such as... Figure 3 As shown, this application provides a hybrid thread-based event processing system. Applying the above-described hybrid thread-based event processing method, the hybrid thread-based event processing system 300 includes:

[0178] The acquisition module 301 is used to acquire event parameters for the client, which include multiple events;

[0179] The type determination module 302 is used to perform delay analysis based on the event to obtain the delay type of the event;

[0180] The hybrid thread processing module 303 is used to perform hybrid thread processing on event parameters based on the delay types of multiple events to obtain response parameters for the client. Hybrid thread processing represents thread processing that combines epoll worker threads and BusyPolling dedicated threads.

[0181] The hybrid thread-based event processing method provided in this application performs latency analysis on the event parameters for the client obtained by the acquisition module 301 through the type determination module 302 to obtain the latency type of each event in the event parameters. Then, the hybrid thread processing module performs hybrid thread processing on the event parameters based on the latency types of multiple events, combining epoll worker threads and Busy Polling dedicated threads, to obtain the response parameters for the client. In this way, the hybrid thread can support massive long connections (concurrency of over 10,000) and microsecond-level ultra-low latency request processing in the same client service process, thereby meeting the latency requirements of different events while handling a large number of concurrent tasks.

[0182] Optionally, the event includes the source IP segment, the TCP Option field, and current event statistics; the type determination module 302 is specifically used for:

[0183] Analyze the source IP range and find the first latency pattern that matches the source IP range from the preset IP range;

[0184] The delay information is read from the TCP Option field to obtain the second delay mode;

[0185] Based on current event statistics, a third delay pattern is obtained through delay matching.

[0186] If the first, second, and third delay modes are all normal delay modes, then the delay type of the event is determined to be the default delay mode; otherwise, the delay type is determined to be the ultra-low latency mode.

[0187] Optionally, the type determination module 302 is specifically used for:

[0188] Retrieve historical statistics data from the client;

[0189] By analyzing the patterns in historical statistical data, we can obtain the historical lag pattern.

[0190] Based on historical delay patterns, a third delay pattern is identified that matches the current event statistics.

[0191] Optionally, the hybrid thread processing module 303 is specifically used for:

[0192] For events whose delay type in the event parameters is general delay mode, a first TCP connection is established between the event and the preset epoll worker thread based on the event's file descriptor.

[0193] The corresponding event is transmitted to the epoll worker thread via the first TCP connection for event processing, and the first response parameters are obtained.

[0194] For events with an ultra-low latency mode in the event parameters, a second TCP connection is established between the event and the pre-configured Busy Polling dedicated thread based on the event's file descriptor.

[0195] The corresponding event is transmitted to the Busy Polling dedicated thread via a second TCP connection for event processing, and the second response parameters are obtained.

[0196] Based on the first and second response parameters, response parameters for the client are formed.

[0197] Optionally, the hybrid thread processing module 303 is specifically used for:

[0198] For each event in the event parameters, a third TCP connection is established between the event and the pre-configured epoll worker thread based on the event's file descriptor;

[0199] The event parameters are input into the epoll worker thread through multiple corresponding third TCP connections. The epoll worker thread processes events with a general delay mode and obtains the third response parameters.

[0200] In the epoll worker thread, when there is an event with the ultra-low latency mode, event migration is triggered, and the event with the ultra-low latency mode is migrated to the preset Busy Polling dedicated thread for event processing to obtain the fourth response parameter.

[0201] Based on the third and second response parameters, response parameters for the client are formed.

[0202] Optionally, the hybrid thread-based event handling system 300 also includes an initialization module, which is specifically used for:

[0203] Processor initialization specifically includes detecting processor topology, isolating processor cores, and binding network card interrupts;

[0204] Create an epoll worker thread and a Busy Polling dedicated thread, which are used together for thread processing;

[0205] Initialize the classifier, which is used for delayed analysis.

[0206] It should be noted that the event processing system based on hybrid threads provided in the above embodiments and the event processing method based on hybrid threads provided in the above embodiments belong to the same concept. The specific ways in which each module and unit performs operations have been described in detail in the method embodiments, and will not be repeated here. In practical applications, the event processing system based on hybrid threads provided in the above embodiments can be assigned to different functional modules as needed, that is, the internal structure of the system can be divided into different functional modules to complete all or part of the functions described above, and this is not a limitation here.

[0207] A computing device according to an embodiment of this application includes a memory, a processor, and a program stored in the memory and running on the processor. When the processor executes the program, it implements some or all of the steps of the above-described event handling method based on hybrid threads.

[0208] The computing device can be a computer, and the corresponding program is computer software. The parameters and steps of the computing device described above can be referred to the parameters and steps of the embodiment of the event processing method based on hybrid threads in the above text, and will not be repeated here.

[0209] Figure 4 A schematic diagram of a computer system suitable for implementing the embodiments of this application is shown. It should be noted that... Figure 4 The computer system 400 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0210] like Figure 4 As shown, the computer system 400 includes a Central Processing Unit (CPU) 401, which can perform various appropriate actions and processes, such as executing the methods described in the above embodiments, based on programs stored in Read-Only Memory (ROM) 402 or programs loaded from Storage Unit 408 into Random Access Memory (RAM) 403. The RAM 403 also stores various programs and data required for system operation. The CPU 401, ROM 402, and RAM 403 are interconnected via a bus 404. An Input / Output (I / O) interface 405 is also connected to the bus 404.

[0211] The following components are connected to I / O interface 405: an input section 406 including a keyboard, mouse, etc.; an output section 407 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 408 including a hard disk, etc.; and a communication section 409 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 409 performs communication processing via a network such as the Internet. A drive 410 is also connected to I / O interface 405 as needed. A removable medium 411, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 410 as needed so that computer programs read from it can be installed into storage section 408 as needed.

[0212] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program including a computer program for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 409, and / or installed from removable medium 411. When the computer program is executed by central processing unit (CPU) 401, it performs various functions defined in the system of this application.

[0213] This application provides a computer-readable storage medium storing instructions that, when executed, perform the aforementioned steps of a hybrid thread-based event handling mechanism. The computer-readable storage medium can be either transient or non-transitory.

[0214] The technical solutions of this disclosure can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes one or more instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of this disclosure. The aforementioned computer-readable storage medium can be a non-transitory computer-readable storage medium, including: USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks, and other media capable of storing program code; it can also be a transient computer-readable storage medium.

[0215] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains 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 a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0216] Those skilled in the art will recognize that this application can be implemented as a system, method, or computer program product. Therefore, this disclosure can be implemented in the following forms: it can be entirely hardware, entirely software (including firmware, resident software, microcode, etc.), or a combination of hardware and software, generally referred to herein as a "module" or "system." Furthermore, in some embodiments, this application can also be implemented as a computer program product contained in one or more computer-readable media, which contains computer-readable program code. Computer-readable storage media can be, for example, but not limited to—electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof.

[0217] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0218] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. An event handling method based on hybrid threads, characterized in that, include: Obtain event parameters for the client, the event parameters including multiple events; Based on the event, a delay analysis is performed to determine the delay type of the event; The event parameters are processed using a hybrid thread based on the delay types of multiple events to obtain response parameters for the client. The hybrid thread processing represents a combination of epoll worker threads and Busy Polling dedicated threads.

2. The method according to claim 1, characterized in that, The event includes the source IP segment, the TCP Option field, and current event statistics; the latency analysis based on the event to obtain the latency type of the event includes: The source IP segment is analyzed, and a first latency pattern matching the source IP segment is found from a preset IP range; The delay information is read from the TCP Option field to obtain the second delay mode; Based on the current event statistics, a third delay mode is obtained by performing delay matching. If the first delay mode, the second delay mode, and the third delay mode are all general delay modes, then the delay type of the event is determined to be the default delay mode; otherwise, the delay type is determined to be the ultra-low latency mode.

3. The method according to claim 2, characterized in that, The process of performing delay matching based on the current event statistics to obtain a third delay mode includes: Obtain the historical statistics data of the client; By performing pattern analysis on the historical statistical data, the historical lag pattern was obtained; Based on the historical delay patterns, a third delay pattern is identified that matches the current event statistics.

4. The method according to claim 1, characterized in that, The process of performing mixed-thread processing on the event parameters based on the delay types of multiple events to obtain response parameters for the client includes: For events whose delay type in the event parameters is general delay mode, a first TCP connection is established between the event and a preset epoll worker thread based on the event's file descriptor. The corresponding event is transmitted to the epoll worker thread through the first TCP connection for event processing to obtain the first response parameter. For events whose latency type is ultra-low latency mode in the event parameters, a second TCP connection is established between the event and a pre-set Busy Polling dedicated thread based on the event's file descriptor. The corresponding event is transmitted to the Busy Polling dedicated thread via the second TCP connection for event processing to obtain the second response parameters. Based on the first response parameter and the second response parameter, response parameters for the client are formed.

5. The method according to claim 1, characterized in that, The process of performing mixed-thread processing on the event parameters based on the delay types of multiple events to obtain response parameters for the client includes: For each event in the event parameters, a third TCP connection is established between the event and a preset epoll worker thread based on the file descriptor of the event; The event parameters are input into the epoll worker thread through multiple corresponding third TCP connections. The epoll worker thread processes events with a general delay mode to obtain third response parameters. In the epoll worker thread, when there is an event with an ultra-low latency mode, event migration is triggered, and the event with an ultra-low latency mode is migrated to the preset Busy Polling dedicated thread for event processing to obtain the fourth response parameter. Based on the third response parameter and the second response parameter, response parameters for the client are formed.

6. The method according to any one of claims 1 to 5, characterized in that, Before obtaining the event parameters for the client, the method further includes: Processor initialization specifically includes detecting processor topology, isolating processor cores, and binding network card interrupts; Create an epoll worker thread and a Busy Polling dedicated thread, which are used together for thread processing. Initialize the classifier, which is used for the latency analysis.

7. A hybrid thread, characterized in that, The event handling method based on a hybrid thread as described in any one of claims 1 to 6 is provided, wherein the hybrid thread comprises: A classifier is used to perform delay analysis based on events to determine the delay type of the events; epoll worker threads; The Busy Polling dedicated thread, together with the epoll worker thread, is used to perform mixed thread processing on the event parameters based on the delay types of multiple events, to obtain response parameters for the client.

8. An event processing system based on hybrid threads, characterized in that, The event processing method based on hybrid threads as described in any one of claims 1 to 6 is applied, wherein the event processing system based on hybrid threads comprises: The acquisition module is used to acquire event parameters for the client, the event parameters including multiple events; A type determination module is used to perform delay analysis based on the event to obtain the delay type of the event; The hybrid thread processing module is used to perform hybrid thread processing on the event parameters based on the delay types of multiple events to obtain response parameters for the client. The hybrid thread processing represents thread processing that combines epoll worker threads and BusyPolling dedicated threads.

9. A computing device comprising a memory, a processor, and a program stored in the memory and running on the processor, characterized in that, When the processor executes the program, it implements the steps of a hybrid thread-based event handling method as described in any one of claims 1 to 6.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed on a terminal device, cause the terminal device to perform the steps of a hybrid thread-based event handling method as described in any one of claims 1 to 6.

Images