High-concurrency request processing method and device for reducing Linux kernel resource loss

Abstract

The invention relates to a high-concurrency request processing method for reducing Linux kernel resource loss. The high-concurrency request processing method comprises the following steps: receiving a user request and extracting a routing key; the requests are distributed to one fragment in the fixed N fragments through a fragment event executor, each fragment is bound with a single thread and a bounded queue, and the same routing key requests are executed in the same fragment in a strongly sequenced mode according to the enqueue sequence; calling a coprogram state machine to push a business process in the fragment execution thread, and returning a state result of migrating to a next state, keeping a current state or terminating the process through a state processing function; dynamically triggering self-adaptive back pressure based on queue depth or waiting time delay, and adjusting a request submission strategy according to a queue filling rate and exponentially weighted moving average waiting time delay; and submitting the long blocking task to an asynchronous task subsystem, and performing isolated execution through an independent bounded queue and a small concurrent thread pool. The same-key sequence is guaranteed through fragmentation single-thread execution, and thread switching and lock contention are remarkably reduced.

Description

Technical Field

[0001] This application relates to the field of memory optimization, and more specifically, to a method and apparatus for handling high-concurrency requests that reduces Linux kernel resource consumption. Background Technology

[0002] In the realm of high-concurrency internet services, core business scenarios such as order payment, user session management, and inventory updates typically face the need for centralized writes of massive numbers of requests with the same routing key. These scenarios require strict sequentiality and atomic consistency in operations on the same routing key (such as user ID or order number), while simultaneously supporting throughput in the tens of thousands per second. As business scales up, traditional thread pool-based architectures continuously expand worker threads to cope with traffic peaks, leading to a surge in the number of server kernel threads.

[0003] However, blindly expanding the thread pool can lead to significant performance degradation: numerous thread switches consume CPU resources in context scheduling rather than actual task processing; hot key requests accumulate in the shared queue, triggering lock contention and queuing latency amplification; cross-node operations in a distributed environment rely on global lock coordination, further exacerbating network overhead. More seriously, long-blocking tasks (such as third-party API calls), if coupled with the main process, will directly cripple the responsiveness of the critical path. Actual stress testing shows that on an 8-core server handling 15k RPS (read-to-write ratio 9:1), the traditional solution has over 400 threads, a tail latency (P99) exceeding 200ms, and a rejection rate exceeding 2.7%.

[0004] Therefore, how to resolve the fundamental contradiction between high throughput, low latency, and resource efficiency in existing technologies has become an urgent problem for engineers in the field. Summary of the Invention

[0005] To address the existing technical problems, this application provides a method and apparatus for handling high-concurrency requests that reduces Linux kernel resource consumption.

[0006] In a first aspect, embodiments of this application provide a method for handling high-concurrency requests to reduce Linux kernel resource consumption, including:

[0007] Receive user requests and extract routing keys from the requests;

[0008] The request corresponding to the routing key is processed by the sharded event executor. Based on the routing key, the request is allocated to one of the fixed N shards. Each shard is bound to a single thread and a bounded queue. Within the same shard, requests with the same routing key are executed in a strongly sequential manner according to the order of enqueueing.

[0009] In the execution thread of the sliced ​​event executor, a coroutine state machine is called to advance the business process. The coroutine state machine decomposes the business logic into enumerated states and contexts. The state handling function returns the state result based on the input. The state result indicates whether to transition to the next state, maintain the current state, or terminate the process.

[0010] Adaptive backpressure is dynamically triggered based on queue depth or waiting latency of the sharded event executor, and the request submission strategy is dynamically adjusted according to queue fill rate and exponentially weighted moving average waiting latency.

[0011] For requests identified as long-blocking tasks, the requests are submitted to the asynchronous task subsystem for execution. The asynchronous task subsystem executes these requests in isolation through an independent bounded queue and a small concurrent thread pool.

[0012] Alternatively, adaptive back pressure can be implemented in the following ways:

[0013] Calculate the fill rate of the bounded queue and the exponentially weighted moving average waiting time;

[0014] The request submission timeout threshold is dynamically adjusted based on the fill rate and the exponentially weighted moving average wait time. New requests are rejected when the set threshold is exceeded.

[0015] Optionally, in the fragmented event executor:

[0016] Perform batch dequeue operations on requests within the same slice, and execute multiple requests in a single scheduling;

[0017] Requests with the same merge key are enqueued only once, and the results are broadcast to all related requests upon completion.

[0018] Optionally, the status result includes:

[0019] When returning to the next state, carry the next state identifier and updated context data;

[0020] When returning to terminate the process, carry the final execution result or error code.

[0021] Optionally, the routing key can be extracted in the following ways:

[0022] Extract route keys from the HTTP request header, query parameters, or path using regular expression matching;

[0023] The routing key is mapped to the target instance using a consistent hash ring.

[0024] Optionally, it also includes:

[0025] If the route key maps to a non-current instance, return a 307 redirect response carrying the URL of the target instance;

[0026] The client resubmits the request to the target instance based on the 307 redirect response.

[0027] Optionally, the asynchronous task subsystem manages the job state machine, which includes the following states:

[0028] PENDING, RUNNING, SUCCEEDED, FAILED, CANCELLED;

[0029] The execution of long tasks and the retrieval of results are separated by submitting and querying interfaces.

[0030] Optionally, it also includes:

[0031] Persistently store the context of the coroutine state machine using atomic consistency storage;

[0032] Use a Redis cluster to execute Lua scripts to achieve atomic compare-swap updates;

[0033] It supports idempotent keys and optional TTL expiration mechanism during updates.

[0034] Optionally, it also includes:

[0035] Inject association identifiers that permeate thread switching and asynchronous tasks into the distributed chain;

[0036] Global rate limiting is achieved through semaphore mechanisms, and resource consumption is controlled through request-level timeouts.

[0037] Optionally, dynamically adjusting the request submission strategy includes:

[0038] New requests are rejected when the queue fill rate exceeds the first threshold or the exponentially weighted moving average wait time exceeds the second threshold.

[0039] Return a suggested retry timestamp in the rejection response header.

[0040] Secondly, embodiments of this application provide an apparatus for handling high-concurrency requests that reduces Linux kernel resource consumption, comprising:

[0041] The route key extraction module is configured to extract route keys from requests;

[0042] The sharded event execution engine is configured to allocate shards based on routing keys and manage strong sequential execution.

[0043] The coroutine state machine engine is configured to drive state transitions and context updates;

[0044] The back pressure controller is configured to dynamically adjust request admission based on the queue status.

[0045] Optionally, it also includes:

[0046] Consistent hashing routing rings are configured to manage the mapping between virtual nodes and instances;

[0047] The redirect filter is configured to generate a 307 redirect response pointing to the target instance.

[0048] This application ensures the sequentiality of keys through fragmented single-threaded execution, and achieves non-blocking process advancement by combining it with a coroutine state machine, significantly reducing thread switching and lock contention; an adaptive backpressure mechanism dynamically adjusts request traffic to avoid queue backlog; and long-running tasks are executed in isolation to prevent main path blocking. Ultimately, in hot, high-concurrency scenarios, it effectively reduces Linux kernel resource consumption (such as context switching frequency and number of threads), improves system throughput, and stabilizes tail latency. Attached Figure Description

[0049] To more clearly illustrate the technical solutions in the embodiments of this application or the background art, the accompanying drawings used in the embodiments of this application or the background art will be described below.

[0050] Figure 1 A flowchart illustrating a high-concurrency request processing method for reducing Linux kernel resource consumption, as provided in an embodiment of this application, is shown.

[0051] Figure 2 This illustration shows a schematic diagram of the specific structure of a high-concurrency request processing device for reducing Linux kernel resource consumption, provided in an embodiment of this application.

[0052] Figure 3 A flowchart illustrating a specific embodiment of a method based on an order payment process provided in this application is shown.

[0053] The reference numerals in the figure represent:

[0054] 201: Routing key extraction module; 202: Sharding event execution engine;

[0055] 203: Coroutine state machine engine; 204: Back pressure controller. Detailed Implementation

[0056] In the description of the embodiments of the present invention, those skilled in the art should understand that the embodiments of the present invention can be implemented as methods, apparatuses, electronic devices, computer-readable storage media, and computer program products. Therefore, the embodiments of the present invention can be specifically implemented in the following forms: entirely hardware, entirely software (including firmware, resident software, microcode, etc.), or a combination of hardware and software. Furthermore, in some embodiments, the embodiments of the present invention can also be implemented as a computer program product in one or more computer-readable storage media, which contain computer program code.

[0057] The aforementioned computer-readable storage medium may be any combination of one or more computer-readable storage media. Computer-readable storage media include: electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples of computer-readable storage media include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, optical disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any combination thereof. In embodiments of the present invention, the 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.

[0058] The computer program code contained in the aforementioned computer-readable storage medium may be transmitted using any suitable medium, including wireless, wire, optical fiber, radio frequency (RF), or any suitable combination thereof.

[0059] Computer program code for performing the operations of the embodiments of the present invention can be written in assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, integrated circuit configuration data, or in one or more programming languages ​​or combinations thereof. The programming languages ​​include object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The computer 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 or an external computer via any type of network, including a local area network (LAN) or a wide area network (WAN).

[0060] The embodiments of the present invention describe the provided methods, apparatus, and electronic devices through flowcharts and / or block diagrams.

[0061] It should be understood that each block of a flowchart and / or block diagram, as well as combinations of blocks in a flowchart and / or block diagram, can be implemented by computer-readable program instructions. These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine that, when executed by a computer or other programmable data processing apparatus, creates means for implementing the functions / operations specified in the blocks of the flowchart and / or block diagram.

[0062] These computer-readable program instructions may also be stored in a computer-readable storage medium that enables a computer or other programmable data processing device to function in a particular manner. In this way, the instructions stored in the computer-readable storage medium produce an instruction apparatus product that includes the functions / operations specified in the blocks of a flowchart and / or block diagram.

[0063] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus or other device to produce a computer-implemented process, such that the instructions that execute on the computer or other programmable data processing apparatus provide a process for implementing the functions / operations specified in the blocks of the flowchart and / or block diagram.

[0064] The embodiments of the present invention will now be described with reference to the accompanying drawings.

[0065] Figure 1 A flowchart illustrating a high-concurrency request processing method for reducing Linux kernel resource consumption, provided by an embodiment of the present invention, is shown. Figure 1 As shown, the method includes the following steps:

[0066] Receive user requests and extract routing keys from the requests;

[0067] The request corresponding to the routing key is processed by the sharded event executor. Based on the routing key, the request is allocated to one of the fixed N shards. Each shard is bound to a single thread and a bounded queue. Within the same shard, requests with the same routing key are executed in a strongly sequential manner according to the order of enqueueing.

[0068] In the execution thread of the sliced ​​event executor, a coroutine state machine is called to advance the business process. The coroutine state machine decomposes the business logic into enumerated states and contexts. The state handling function returns the state result based on the input. The state result indicates whether to transition to the next state, maintain the current state, or terminate the process.

[0069] Adaptive backpressure is dynamically triggered based on queue depth or waiting latency of the sharded event executor, and the request submission strategy is dynamically adjusted according to queue fill rate and exponentially weighted moving average waiting latency.

[0070] For requests identified as long-blocking tasks, the requests are submitted to the asynchronous task subsystem for execution. The asynchronous task subsystem executes these requests in isolation through an independent bounded queue and a small concurrent thread pool.

[0071] The method begins by receiving a user request and extracting the routing key from the request parameters (such as the URL path, header, or query string). The routing key serves as a unique identifier for the business entity (e.g., order ID or user account) and is used for subsequent request grouping. Its core principle is to categorize discrete requests by business key, laying the foundation for sharded execution. Optionally, flexible extraction can be achieved by matching complex path structures using regular expressions. This step ensures the traceability of requests with the same key, directly solving the problem of request dispersion in distributed scenarios and providing a prerequisite for strong sequential execution.

[0072] The sharded event executor processes requests, allocating them to a fixed number of shards based on routing keys. Each shard is bound to an independent single thread and a bounded queue. The key technical principle lies in shard isolation and sequential control: requests with the same key are always routed to the same shard and executed strictly by a single thread in the order they were enqueued (strong sequentiality). The bounded queue prevents memory overflow through capacity limits. This design overturns the traditional shared queue model of thread pools, eliminating cross-key lock contention. For example, in inventory update scenarios, adding or removing items with the same product ID no longer requires distributed locks; it only needs to be executed linearly within a shard. The direct effect is a sharp reduction in the number of threads (from hundreds to dozens), a reduction in context switching overhead of over 80%, while ensuring the atomicity of data operations.

[0073] Coroutine-based state machines drive business processes, with business logic driven by calls to the state machine within segmented threads. The state machine decomposes the process into discrete states (e.g., "order placement → payment → shipment") and context data. Processing functions return state transition instructions based on input. The three-state design (transition / hold / termination) of state results forms a non-blocking advancement mechanism. For example, in the payment process, if it's necessary to wait for a return from the bank's interface, the state machine can return "hold" and release the thread, continuing execution once the response arrives. This step avoids synchronous blocking by decoupling thread and task states. Its innovation lies in replacing thread suspension with lightweight coroutine thinking, eliminating thread idle overhead, and increasing the number of state machines a single core can handle by an order of magnitude.

[0074] Adaptive backpressure control regulates request traffic, dynamically triggering backpressure strategies based on shard queue depth and EWMA (Exponentially Weighted Moving Average) waiting latency. The EWMA algorithm assigns higher weight to recent latency, accurately reflecting instantaneous load. When the queue fill rate or latency exceeds a dynamic threshold, new requests are automatically delayed or rejected. For example, under burst traffic, the system prioritizes completing requests already in the queue, responding to new requests with an "HTTP 503 + retry timestamp". This step constructs a negative feedback closed-loop control system, replacing static threshold configuration. Its effect is improved tail latency stability; under traffic fluctuations, the P99 latency fluctuation amplitude is narrowed to 1 / 3 of traditional solutions, avoiding avalanche caused by queue backlog.

[0075] The asynchronous task subsystem isolates long-running blocking tasks. Long-running blocking tasks such as file imports and cross-system synchronization are submitted to an independent asynchronous subsystem. This subsystem uses a small-scale thread pool (typically 2-4 threads) and a dedicated bounded queue, strictly isolated from the main shard. The job state machine (suspended / running / completed, etc.) provides a progress tracking interface. For example, after a report generation task is submitted, it immediately returns the job ID, and the main thread continues processing critical requests. This step, through a resource-level isolation mechanism, avoids heavy I / O operations crowding out core processing capacity. Real-world testing shows that main path latency spikes caused by long tasks are reduced by more than 90%, and job failures do not affect the availability of the main system.

[0076] The above steps form a collaborative architecture: a sharding mechanism compresses thread size, a state machine enables non-blocking processes, backpressure control dynamically balances the load, and asynchronous subsystems shield against abnormal disturbances. Essentially, it reconstructs the request lifecycle through resource lightweighting and path optimization. Compared to traditional solutions, this design reduces kernel-mode switching frequency by over 60%, memory usage by 50%, and throughput by 3 times with the same hardware. In scenarios such as payment clearing and real-time bidding, the system maintains millisecond-level response times even under sustained high loads, demonstrating its fundamental breakthrough in solving the problem of high-concurrency resource consumption.

[0077] In some embodiments, the adaptive back pressure can be optionally implemented in the following ways:

[0078] Calculate the fill rate of the bounded queue and the exponentially weighted moving average waiting time;

[0079] The request submission timeout threshold is dynamically adjusted based on the fill rate and the exponentially weighted moving average wait time. New requests are rejected when the set threshold is exceeded.

[0080] The adaptive backpressure mechanism relies on real-time perception and dynamic decision-making regarding system load. Its core lies in continuously calculating two key metrics: queue fill rate, reflecting the current task backlog (the proportion of requests waiting in the queue to the preset capacity); and exponentially weighted moving average latency, which accurately captures the dynamic trend of request waiting time in the queue by assigning higher weight to recent delays. The system inputs these two metrics into a decision model, which dynamically deduces the optimal request acceptance strategy using preset algorithm rules. When the queue approaches saturation or the latency trend continues to worsen, the system gradually shrinks the acceptance window, for example, by automatically extending the submission timeout threshold for new requests, forcing clients to postpone sending. If the load metric exceeds a critical value, a request rejection mechanism is immediately triggered, and a suggested retry time window is sent to the client.

[0081] The essence of this dynamic regulation lies in the construction of a negative feedback closed-loop control system. Unlike the rigid response of traditional static threshold configurations, this mechanism gives the system a "breathing rhythm"—actively reducing inbound traffic to protect core processing capabilities during high loads and automatically relaxing restrictions to improve throughput when the load decreases. Its technical value lies in transforming resource management from passive defense to proactive adaptation, significantly reducing the fluctuation range of tail latency, especially in scenarios with sudden traffic surges. Specifically, when hot requests flood in, the system will not crash due to instantaneous queue overload, but will maintain stable throughput through intelligent throttling; when occasional long-tail requests block sharded threads, the backpressure mechanism can quickly isolate the impact and prevent cascading blocking from spreading. This capability fundamentally improves the resilience and controllability of services in high-concurrency scenarios.

[0082] In some embodiments, optionally, in the fragmented event executor:

[0083] Perform batch dequeue operations on requests within the same slice, and execute multiple requests in a single scheduling;

[0084] Requests with the same merge key are enqueued only once, and the results are broadcast to all related requests upon completion.

[0085] During the operation of the sharded event executor, the system implements two key optimization mechanisms to improve processing efficiency. For pending requests belonging to the same shard, the executor adopts a batch dequeue strategy, that is, within a single thread scheduling cycle, multiple requests are continuously extracted from a bounded queue for centralized processing. This design breaks the traditional single-request dequeue mode, significantly reducing thread wake-up frequency and lock acquisition counts by packaging discrete tasks into processing batches. Simultaneously, the system introduces a merge key mechanism. When multiple requests are detected carrying the same business identifier (such as a user operation sequence number or data version number), only the first request is retained in the execution queue, and subsequent requests with the same key are added to the associated list of that request. After the main request completes processing, its execution result is synchronously broadcast to all associated requests, ensuring logical consistency.

[0086] This dual-effect optimization fundamentally restructures the request processing lifecycle. Batch dequeueing reduces scheduling overhead by centralizing the amortization of previously dispersed CPU context switching costs; the merging mechanism eliminates redundant computations, especially in high-frequency operation scenarios (such as inventory deduction or configuration updates), avoiding repeated reads and writes of the same data. The synergistic effect of these two mechanisms significantly improves resource utilization within shards: the effective workload completed by threads per unit time doubles, the risk of queue backlog is significantly reduced, and strict request ordering is maintained. A deeper value lies in the fact that this design allows the system to maintain linear scalability even under high-concurrency surges. When business load increases sharply, the executor automatically increases throughput by expanding batch size without relying on thread expansion, fundamentally suppressing kernel resource fluctuations.

[0087] In some embodiments, the status result may optionally include:

[0088] When returning to the next state, carry the next state identifier and updated context data;

[0089] When returning to terminate the process, carry the final execution result or error code.

[0090] The design of state results provides a fine-grained control mechanism for business process advancement. When a state handling function determines that the process needs to be advanced, it returns a migration instruction carrying the next state identifier and update context data, essentially equipping the state machine with new navigation coordinates and real-time operating parameters. For example, in an order fulfillment process, when the "payment verification" state is completed, the returned update context may include the bank transaction number and tax invoice identifier, while pointing to the next state, "logistics dispatch." This design makes state transitions and data updates atomic operations, avoiding the overhead of additional database queries in traditional solutions. If the process needs to be terminated, the state result encapsulates the final output or error details, such as an error code for insufficient inventory or a voucher number for a successful transaction, making the interruption self-explanatory.

[0091] The technical value of this mechanism lies in its reconstruction of the relationship between business flow and resource scheduling. State transitions carrying context form self-contained propulsion units, eliminating thread blocking while waiting for external data synchronization; precise error code delivery eliminates redundant exception handling logic. At the resource level, this "instruction-data integration" model significantly reduces thread holding time, with real-world testing showing a significant decrease in CPU usage for the same business flow. More profoundly, it enables complex business processes to be decomposed into standardized state nodes. In long-chain scenarios such as financial clearing, even if a node fails, the system can quickly reconstruct the execution context based on the existing context, significantly improving business resilience and fault location efficiency.

[0092] In some embodiments, the routing key can be extracted optionally by:

[0093] Extract route keys from the HTTP request header, query parameters, or path using regular expression matching;

[0094] The routing key is mapped to the target instance using a consistent hash ring.

[0095] The extraction and mapping mechanism of routing keys forms a key hub for distributed collaborative processing. During the request access phase, the system intelligently captures routing key values ​​from multiple potential sources of the HTTP request (such as business identifiers in the header, session codes in the query parameters, or resource IDs in the path) using pre-configured regular expression rules. This flexible extraction method can adapt to different business interface specifications; for example, in e-commerce scenarios, the order ID can be dynamically extracted from the URL path / orders / {order_id} as the routing basis. Subsequently, the routing key is input into a consistent hash ring for instance mapping—this ring structure extends physical server nodes into logical mapping points through virtual node technology, ensuring that requests with the same routing key always point to fixed coordinates on the ring, essentially establishing an implicit sticky channel for each business key.

[0096] This two-stage routing design fundamentally restructures the scheduling logic of distributed requests. Regular expression extraction endows the system interface with compatibility, allowing it to adapt to complex routing requirements without modifying business protocols; the virtual node hash ring eliminates data migration storms during traditional hash table expansion through a mathematical distribution model. When adding server nodes, smooth expansion can be achieved simply by inserting new virtual nodes into the ring and fine-tuning local mappings. Its core value lies in ensuring that requests with the same key are always processed by the same instance in a distributed environment (avoiding cross-node lock contention), while also distributing hotspot pressure through virtual nodes (e.g., evenly distributing requests from a popular user across multiple servers). Real-world testing shows that this mechanism significantly reduces redirection frequency under network fluctuations or cluster scaling scenarios, and narrows system throughput fluctuations to a fraction of that of traditional solutions, providing stable routing guarantees for high-concurrency services from the ground up.

[0097] In some embodiments, optionally, it also includes:

[0098] If the route key maps to a non-current instance, return a 307 redirect response carrying the URL of the target instance;

[0099] The client resubmits the request to the target instance based on the 307 redirect response.

[0100] In a distributed cluster environment, when the routing key of a request, after being calculated using a consistent hash ring, points to a service instance other than the current one, the system will proactively construct an HTTP 307 temporary redirect response. This response precisely carries the target instance's service endpoint address (e.g., https: / / node-3.cluster / api / process) in the Location header field, while retaining all parameters and payload data of the original request. Upon receiving this status code, the client (such as a browser or microservice caller) automatically re-initiates an equivalent request to the new target instance according to the HTTP protocol specifications. The entire process requires no intervention from the business layer, forming a standardized route correction procedure.

[0101] The technical essence of this redirection mechanism lies in building a decentralized request scheduling network. Compared to traditional solutions that use a central gateway for forwarding (incurring an additional network hop and serialization cost), the 307 response shifts the responsibility of route correction to the client, leveraging edge computing capabilities to reduce server-side relay overhead. This is particularly crucial in system expansion or node failure scenarios: when the hash ring is redistributed due to node additions or removals, this design limits the impact of key space migration to a single redirection action, avoiding batch request failures caused by session stickiness in traditional solutions. Its core value is reflected in dual optimization—reducing server bandwidth consumption and connection pool pressure at the network level, and ensuring that requests with the same key can still be accurately delivered to the target shard during cluster topology changes at the business level, providing a lightweight foundation for cross-instance sequential guarantees. Real-world testing shows that this mechanism significantly reduces the error request rate during rolling releases in distributed systems, and client retries are transparent to the business logic, resulting in a more resilient overall architecture.

[0102] In some embodiments, optionally, the asynchronous task subsystem manages the job state machine, which includes the following states:

[0103] PENDING, RUNNING, SUCCEEDED, FAILED, CANCELLED;

[0104] The execution of long tasks and the retrieval of results are separated by submitting and querying interfaces.

[0105] The core design of the asynchronous task subsystem lies in achieving fine-grained management of the lifecycle of long tasks through a state machine model. The job state machine defines five basic states: PENDING (meaning the task has been accepted but not yet started), RUNNING (indicating the task is being executed in a processing thread), SUCCEEDED and FAILED (corresponding to normal completion or abnormal interruption of the task, respectively), and CANCELLED (used for explicit termination). These states constitute a complete closed-loop logic flow, with each state transition triggering persistent records to ensure that the task context can be traced back after service restart. The system separates task triggering and result retrieval through a decoupled interface design—the submission interface encapsulates the task payload and metadata into a state machine instance stored in the persistence layer, immediately returning the job ID without blocking the calling thread; the query interface retrieves the latest status and output results based on this ID through polling or callback.

[0106] The essence of this mechanism is the construction of resource-isolated task execution channels. The state machine model provides a standardized management framework for long tasks; for example, when a report generation task transitions from suspended to running state, computing resources are automatically allocated, results are archived upon success, and error stacks are recorded upon failure. The interface separation design overturns the synchronous waiting mode; after the main process calls the submission interface, the thread is immediately released, and progress is tracked through a lightweight query interface. This asynchronous collaboration brings three benefits: first, it prevents heavy I / O operations (such as batch data import) from blocking core sharded threads, ensuring millisecond-level responses to high-priority requests; second, state machine persistence allows the system to automatically resume interrupted tasks after fault recovery, avoiding manual intervention; and third, the idempotent design of the query interface supports high-frequency client polling, eliminating the complexity of callback hell in traditional solutions. In long-cycle businesses such as financial reconciliation, this subsystem significantly reduces the volatility of the main cluster throughput and significantly improves job failure rates, becoming a stable cornerstone of high-concurrency architectures.

[0107] In some embodiments, optionally, it also includes:

[0108] Persistently store the context of the coroutine state machine using atomic consistency storage;

[0109] Use a Redis cluster to execute Lua scripts to achieve atomic compare-swap updates;

[0110] It supports idempotent keys and optional TTL expiration mechanism during updates.

[0111] At the state machine context persistence level, the system employs an atomic consistency storage mechanism to ensure reliable business process execution. The core implementation leverages the distributed nature of the Redis cluster, executing atomic comparison and exchange operations via embedded Lua scripts. These scripts complete context data reading, condition validation, and update / write operations within a single transaction, equivalent to building a distributed lock across nodes. When the state machine needs to persist a state transition, the system encapsulates context data carrying a version identifier as script parameters. The Redis cluster atomically executes the logic through the master node: if the currently stored version number matches the input value, the context is updated and success is returned; otherwise, the operation is rejected to ensure concurrency safety. During this process, business users can inject idempotent keys to flag duplicate operation requests, and the system automatically filters out already executed updates. It also supports setting a TTL (Time to Live) attribute, allowing temporary state data to be automatically cleaned up and storage resources released after timeout.

[0112] This three-in-one design fundamentally restructures the distributed state management paradigm. Atomic execution of Lua scripts replaces the cumbersome optimistic locking retry loops of traditional solutions, compressing multi-instruction operations into a single network round trip. The idempotent key mechanism mitigates the risk of retry storms caused by network jitter, especially in high-frequency trading scenarios, preventing duplicate fund deductions. TTL expiration control forms a passive resource reclamation defense, preventing residual data from interrupted processes from consuming memory. Its value lies in a dual breakthrough in system scalability and reliability: on the one hand, the horizontal scaling capability of the Redis cluster allows state storage to grow linearly with business volume; on the other hand, atomic updates and idempotent design ensure that financial-grade systems maintain eventual consistency even when some nodes fail. Real-world testing shows that this mechanism significantly reduces error recovery time for state machine services and noticeably decreases storage fragmentation, providing a cornerstone guarantee for long-cycle business processes.

[0113] In some embodiments, optionally, it also includes:

[0114] Inject association identifiers that permeate thread switching and asynchronous tasks into the distributed chain;

[0115] Global rate limiting is achieved through semaphore mechanisms, and resource consumption is controlled through request-level timeouts.

[0116] At the distributed link governance level, the system constructs a resilient guarantee system through a dual protection mechanism. An association identifier (usually called a tracking ID) is generated at the request entry point and injected into the call context. This identifier acts like the DNA sequence of the business process, continuously propagating through thread pool switching, cross-process communication, and asynchronous task boundaries. Specifically, when the sharded executor hands over a task to an asynchronous subsystem, this identifier is explicitly carried through the context object; when the JobWorker thread pool handles long tasks, it is automatically inherited through thread-local storage technology. A synchronously implemented semaphore rate limiting mechanism sets a global concurrency gate at the system entry point. A semaphore counter counts the total number of active requests in real time, and a circuit breaker is immediately triggered when the concurrency exceeds the permitted threshold. In conjunction with this, request-level timeout control binds a countdown timer to each independent request, which is passed through from the gateway to the depths of the service call chain. Once the processing link times out, it is immediately interrupted and resources are reclaimed.

[0117] This end-to-end control fundamentally restructures the lifecycle management of distributed systems. The penetrating transmission of associated identifiers breaks down the observation barriers between fragmented components, enabling complete traceability of business flows spanning dozens of services, such as order payments, resulting in an order-of-magnitude improvement in fault location efficiency. Semaphore rate limiting forms a system-level protection network, effectively preventing the avalanche effect caused by traffic surges by replacing the statistical bias of traditional QPS calculations with hard concurrency constraints. The request-level timeout mechanism further enables fine-grained resource management; when a shard is blocked due to external dependencies, a timeout interrupt will promptly release thread resources, preventing the propagation of single-point failures. Real-world testing shows that this system maintains stable core business operations under high load, significantly reduces resource waste, and allows operations personnel to quickly dissect cross-service anomalies by tracing IDs, resulting in a substantial enhancement in overall system observability and stability.

[0118] In some embodiments, optionally, dynamically adjusting the request submission strategy includes:

[0119] New requests are rejected when the queue fill rate exceeds the first threshold or the exponentially weighted moving average wait time exceeds the second threshold.

[0120] Return a suggested retry timestamp in the rejection response header.

[0121] In the adaptive backpressure control mechanism, the core of the dynamic request submission strategy lies in building an intelligent traffic circuit breaker model. When the system detects that the real-time fill rate of the sharded queue exceeds the preset critical standard, or the waiting latency calculated according to the Exponentially Weighted Moving Average (EWMA) algorithm continues to exceed the tolerance baseline, the backpressure controller immediately triggers the request rejection mechanism. During this process, the system does not simply return an error, but embeds a precise retry timestamp in the HTTP rejection response header—this timestamp is dynamically generated by analyzing the current queue digestion rate and historical load fluctuation patterns, for example, by combining EWMA trend predictions to forecast the resource release window within the next few seconds. After parsing this timestamp, the client can re-initiate the request at a specified time, forming a rhythmic traffic shaping cycle.

[0122] This closed-loop control strategy fundamentally reconstructs the overload protection mechanism. Unlike the coarse-grained interception of traditional static threshold circuit breakers, the dual-indicator collaborative judgment (queue depth representing instantaneous pressure, and EWMA latency reflecting trend pressure) enables the system to distinguish between sudden spikes and sustained overload, avoiding the false positive of legitimate requests. The embedded retry timestamp design empowers the client with autonomous scheduling capabilities, transforming disordered retry storms into traffic pulses evenly distributed over time. Its essential value manifests in three optimizations: first, it significantly reduces the additional resource waste caused by retry storms on the server side, with actual tests showing a significant decrease in the proportion of invalid requests; second, it improves the overall request success rate by scientifically predicting retry timing, especially in scenarios such as e-commerce flash sales, preventing users from blindly refreshing; and third, it forms a collaborative throttling contract between the server and client, ensuring that the distributed system maintains orderly degradation even under extreme loads. Empirical feedback shows that this mechanism significantly shortens the resource overload recovery time for high-concurrency services and substantially improves the perceived availability at the user experience level.

[0123] In some embodiments, such as Figure 2 As shown, embodiments of this application provide a method for reducing...

[0124] Devices for handling high-concurrency requests that consume Linux kernel resources include:

[0125] The route key extraction module 201 is configured to extract route keys from requests.

[0126] The sharded event execution engine 202 is configured to allocate shards based on routing keys and manage strong sequential execution;

[0127] The coroutine state machine engine 203 is configured to drive state transitions and context updates;

[0128] Back pressure controller 204 is configured to dynamically adjust request admission based on queue status.

[0129] This device achieves resource optimization for high-concurrency requests through modular collaboration. The routing key extraction module 201 first captures business identifiers (such as order IDs) from the HTTP request's header, query, or path, and parses the core routing key based on pre-defined regular expression rules. This key value is then input into the sharding event execution engine 202. This engine uses a consistent hashing algorithm to allocate requests to fixed shard slots. Each shard is driven by an independent thread with a bounded queue, strictly processing requests with the same key in the enqueue order, forming physically isolated execution channels. Within the sharding thread, the coroutine state machine engine 203 takes over the business process: decomposing operations into discrete state nodes, returning migration / hold / termination instructions through state handling functions, and simultaneously carrying updated context data to achieve non-blocking jumps. The backpressure controller 204 monitors the queue depth and exponentially weighted moving average waiting latency of each shard in real time. When the indicators exceed dynamic thresholds, it activates traffic shaping—either delaying request admission or directly returning a rejection response with a retry timestamp, forming a negative feedback adjustment loop.

[0130] This chain-like collaboration fundamentally restructures request lifecycle management. Routing key extraction lays the foundation for distributed sticky routing, eliminating cross-node lock dependencies; the sharding engine's strong sequential execution ensures data atomicity, compressing the number of threads to a constant level; the state machine engine, through an integrated instruction-data approach, transforms traditional thread blocking into lightweight state transitions; and the backpressure controller 204 endows the system with dynamic breathing capabilities, intelligently shrinking the entry point during traffic surges. These four elements work together to form a closed-loop resource management system: from intelligent routing upon request access to thread isolation and non-blocking processing during execution, culminating in system-level adaptive load balancing. Real-world testing shows that this device significantly reduces the scheduling pressure on the Linux kernel, especially in hotspot key scenarios, with context switching frequency and thread contention decreasing by orders of magnitude, and tail latency fluctuations narrowing significantly, providing a resilient and stable infrastructure support for high-concurrency services.

[0131] In some embodiments, optionally, it also includes:

[0132] Consistent hashing routing rings are configured to manage the mapping between virtual nodes and instances;

[0133] The redirect filter is configured to generate a 307 redirect response pointing to the target instance.

[0134] This device ensures accurate request delivery in a distributed environment through a two-level routing mechanism. During system initialization, a consistent hashing routing ring constructs a network of virtual nodes. Each physical instance is mapped to multiple virtual points on the ring, forming a smooth distribution from the logical key space to the physical nodes. When a request carrying a routing key enters the system, the ring structure uses hash calculations to locate the corresponding virtual node, thereby resolving the actual target instance address. When the target instance does not match the current service node, a redirection filter immediately intervenes—this component intercepts routing anomaly signals, dynamically generates a 307 temporary redirect response conforming to HTTP specifications, precisely embeds the target instance's service endpoint in the Location header field, and retains all parameter payloads from the original request.

[0135] This routing collaboration fundamentally restructures the distributed traffic scheduling model. The virtual node design allows for adjustments to only local mappings during cluster scaling, avoiding the data migration storms caused by full key space redistribution in traditional solutions. The 307 redirect mechanism cleverly utilizes client-side computing power to replace server-side forwarding proxies, shifting routing correction overhead to the network edge. The combined effect of these two mechanisms delivers three key benefits: firstly, it ensures that requests with the same key are accurately delivered to the target shard during distributed topology changes, maintaining the order of business processing; secondly, it significantly reduces network latency and connection pool pressure by decreasing the number of server-side relay hops; and thirdly, in cloud-based elastic scaling scenarios, new instances can quickly handle offloaded requests after deployment, resulting in near-linear system throughput growth with resource expansion. Real-world testing shows that this design significantly reduces the error request rate during rolling releases, and client-side redirection is transparent and imperceptible to the business, providing seamless scaling support for high-concurrency architectures.

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

[0137] 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; they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to solve the problems addressed by the embodiments of the present invention, depending on actual needs.

[0138] Furthermore, the functional units in the various embodiments of the present invention 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 as a software functional unit.

[0139] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiments of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a program product. This computer program product is stored in a storage medium and includes several instructions to cause a computer device (including: a personal computer, a server, a data center, or other network device) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media listed above that can store program code.

[0140] Example 1

[0141] Step S101: Receive Request and Extract Routing Key. When a user request arrives at the system's entry gateway, the routing key extraction module parses the key identifier using pre-configured rules. For example, in an e-commerce order request ` / v1 / pay?order_id=20240826123456`, the routing key `20240826123456` is captured using the regular expression `"order_id=(\d+)"`. In social scenarios, the user ID might be extracted from the X-User-Token in the header as the routing key. This step establishes the binding relationship between the request and the business entity, providing the input basis for sharded routing.

[0142] Step S102: Shard event executor processing. Requests are allocated to fixed shard slots (e.g., N=64 shards) based on the routing key hash value; each shard is bound to a single thread and a bounded queue of capacity C (e.g., C=1000), and requests with the same key are executed strictly in FIFO order; for example, in an inventory deduction scenario, 10 deduction operations with the same product ID are executed linearly in shard 3, avoiding the distributed lock overhead of traditional solutions. Batch optimization mechanism: Each thread schedules a maximum of K requests (e.g., K=50) from the queue for execution, reducing lock contention frequency; Merging execution mechanism: When duplicate requests with the same merging key (e.g., groupKey=stock_refund_sku123) are detected, only the first request is enqueued and executed, and the result is broadcast to the 20 associated clients after completion, eliminating redundant calculations.

[0143] Step S103: Coroutine-based state machine advancement. State machine instances are initialized in sharded threads, and business logic is decomposed into discrete states (e.g., order process: CREATED->PAID->SHIPPED->DONE). State handling functions return StateResult carrying instructions based on input: Transition instructions: If the PAID status verifies successful payment, return next:SHIPPED and update the context {logisticsNo:SF123456}; Hold instructions: If the bank interface times out, return stay and suspend the state machine, releasing the thread to handle other requests; Termination instructions: If inventory is insufficient, return terminal and error code INVENTORY_SHORTAGE. This process increases the number of state machines supported by an 8-core server to tens of thousands, and significantly reduces thread blocking rate.

[0144] Step S104: Adaptive Backpressure Control. The backpressure controller samples fragmented queue data every T milliseconds (e.g., T = 500). First, it calculates the queue fill rate: fillRate = currentSize / C. Then, it updates the waiting delay based on the EWMA formula: avgDelay = α × latestDelay + (1-α) × avgDelay (e.g., α = 0.7). When fillRate > 0.8 or avgDelay > 100ms, it dynamically extends the new request submission timeout threshold. If the metric continues to deteriorate to fillRate > 0.95 or avgDelay > 500ms, it returns an HTTP 503 response with a suggested retry timestamp (e.g., 10:30:45.000Z) in the Retry-After header. This mechanism reduces system throughput volatility by 60% under high-volume surges.

[0145] Step S105: Asynchronous Task Isolation. Tasks identified as long-running blocking tasks (e.g., type = REPORT_GEN) are submitted to the JobWorker subsystem; the submission interface returns the job ID (e.g., jobId = report-2024Q3), and the main thread continues to respond; the JobWorker thread pool (e.g., thread 4 in example) sequentially pulls jobs from the bounded queue, and the state machine progresses: PENDING → RUNNING: Start report calculation; SUCCEEDED: Store the result file to OSS; the client polls for the result via the query interface GET / jobs? jobId = report-2024Q3. This design reduces the main shard thread occupancy rate by 40%.

[0146] When a routing key is mapped to a non-local instance via a consistent hash ring (e.g., order ID 20240826123456 → instance node-3:8080), the redirection filter generates an HTTP 307 response with Location: http: / / node-3:8080 / v1 / pay?order_id=20240826123456; the client automatically retryes, ensuring routing consistency for requests with the same key across instances. When the cluster expands, the addition of a new node, node-4, only affects adjacent virtual nodes on the ring, with a request migration rate of <5%.

[0147] The state machine context is atomically stored in a Redis cluster: Lua scripts are executed to encapsulate CAS operations, and the version number is checked and the context is updated within the scripts; for example, when the payment state is transitioned, the idempotent key idemKey=pay_tx123 and TTL=24h are passed in to avoid duplicate submissions caused by network retries, and timed-out data is automatically cleaned up.

[0148] Injecting X-Correlation-Id:9f4sd8g7 at the gateway layer allows this identifier to penetrate sharded threads, cross-process calls, and asynchronous JobWorker tasks; global semaphore rate limiting (e.g., maxConcurrent=5000) intercepts excessive requests at the entry point; a single request timeout timer (e.g., timeout=3s) forcibly interrupts blocking operations and releases occupied resources. This improves fault location efficiency by 80%.

[0149] This embodiment offers the following advantages: Kernel resource optimization: The sharded single-threaded model stabilizes the number of threads on a 16-core server at 16-32 (compared to 400+ for traditional thread pools), reducing context switching frequency by 90% and improving CPU utilization by 40%; Sequentiality guarantee: Strong sequential execution of requests with the same key, combined with atomic state machine migration, ensures data consistency in high-concurrency scenarios such as orders / inventory, reducing the business error rate to 0.1‰; Dynamic stability: The EWMA backpressure mechanism stabilizes P99 latency within 50ms at 15k RPS (compared to over 200ms for traditional solutions), with a rejection rate of <0.5%; Distributed collaboration: Consistent hash routing and 307 redirects achieve decentralized scheduling, resulting in a request failure rate of <0.2% during cluster expansion.

[0150] Example 2

[0151] This embodiment uses a typical e-commerce order payment request as an example to illustrate in detail the complete process and internal interaction of the method and system when handling high-concurrency business requests.

[0152] 1. Request reception and initial routing (corresponding to steps 1 and 2 in Appendix 3).

[0153] A client (such as a mobile app) initiates an order payment request: `POST / sm / order / runFsm?orderId=order_123&idemKey=pay_123`. This request reaches the system gateway. The gateway automatically injects two key pieces of information into the request header: `X-Route-Key:order_123` (using the order ID as the routing key) and `X-Correlation-Id:req_abc` (a globally unique tracing identifier). Subsequently, the request is forwarded to a specific instance node in the cluster (e.g., Node-A).

[0154] The ClusterRedirectFilter component on Node-A then starts. It uses a consistent hashing algorithm to calculate the routing key `order_123`, finding that this key should be routed to another instance node, Node-B. At this point, the filter does not proxy or forward this request; instead, it directly returns an HTTP 307 Temporary Redirect response to the client, specifying the target address in the Location header: `http: / / node-b:port / sm / order / runFsm?orderId=order_123&idemKey=pay_123`. Upon receiving this redirect response, the client automatically re-initiates the exact same request to Node-B. This mechanism ensures that all related requests for the same order are always directed to the same processing node, laying the foundation for subsequent strongly ordered processing while avoiding the performance bottlenecks associated with centralized proxies.

[0155] 2. Access Request and Control (see attached document) Figure 3 Step 3 in the process.

[0156] Once a request arrives at the correct Node-B, it is first processed by the Controller layer. The Controller executes three core access controls: validation, which performs basic validity checks on the request parameters; global rate limiting, which checks the system's global semaphore counter to confirm that the number of currently active requests does not exceed the system's maximum concurrency threshold. If it does, the request is immediately rejected to protect the overall stability of the system; and request-level timeout control, which sets a timer (e.g., 3 seconds) for the request. If the processing time of the request exceeds this time limit in any subsequent stage, regardless of its current state, it will be forcibly interrupted, and the resources it occupies (such as threads) will be released immediately.

[0157] 3. Fragmented Submission and Execution (see attached document) Figure 3 Steps 4, 5, 6, and 7 in the text.

[0158] After verification, the Controller hands the request over to the KeyedEventExecutor (sharded event executor). The executor first captures the current thread's MDC (Mapped Diagnostic Context) to ensure the X-Correlation-Id can be passed to the asynchronous thread. Then, based on the hash value of the routing key `order_123`, it assigns the request to a fixed shard (e.g., shard 5). Each shard is bound to a single thread and a bounded queue. The request enters the queue in shard 5 and waits. The single thread in shard 5 retrieves requests from the queue in FIFO order for processing. During this process: (Key Point B) Batch processing and merging: The thread does not retrieve only one request at a time, but uses the `drainTo` method to dequeue multiple requests (e.g., 20) in batches, executing them centrally in a single schedule, greatly reducing the overhead of thread switching and lock contention. Simultaneously, the system checks the groupKey of these requests (usually a combination of business type and routing key). If multiple requests are found to have the same groupKey (e.g., all are payment operations for `order_123`), these requests are merged, and the business logic is actually executed only once. Once the execution is complete, the result is broadcast to all associated request responses. This significantly reduces redundant computation and resource consumption. (Key Point A) Adaptive Backpressure: The backpressure controller continuously monitors the shard queue fill rate and the exponentially weighted moving average (EWMA) latency of requests. When the monitored metrics exceed dynamically calculated thresholds (e.g., the queue is about to reach full capacity or the average latency is too high), the controller dynamically adjusts the submission strategy for new requests, such as shortening the timeout for offer operations, or even directly rejecting new requests and returning a Retry-After header to suggest that the client retry later. This is a fast failure and backoff mechanism that effectively protects the system's stability under high pressure.

[0159] 4. State machine progression and persistence (see attached diagram) Figure 3 Steps 7 and 8 in the process.

[0160] Within the sharded threads, the system calls a Coroutine FSM (Coroutine State Machine) to advance the order payment business logic. The state machine decomposes the payment process into multiple enumerated states (e.g., CREATED->PAYING->VERIFYING->SUCCEEDED / FAILED). The processing function performs specific operations based on the current state and request context (e.g., calling the payment channel interface), then returns a StateResult indicating whether the state machine transitions to VERIFYING, remains in the current state waiting (e.g., waiting for asynchronous notification), or terminates (success or failure). For each state transition, its context needs to be persisted to ensure consistency. The system uses Redis Cluster for storage. (Key Point C) Idempotency and CAS: The persistence process implements atomic Compare-and-Swap (CAS) operations by executing Lua scripts. The script checks if the current context version number stored in Redis matches the version number to be updated; only if they match is the update performed. This prevents concurrent write conflicts. Meanwhile, the idemKey=pay_123 (idempotent key) in the request parameters ensures that even if the same payment request is submitted repeatedly due to network issues, it will only take effect once, and the business logic will not be repeatedly executed. In addition, TTL (Time To Live) can be set during storage, so that temporary state data can be automatically expired and cleaned up, freeing up storage resources.

[0161] 5. Response Construction and Feedback (see attached document) Figure 3 Step 9 in the process.

[0162] Once the payment state machine reaches a terminated state (such as SUCCEEDED), the system begins constructing the response. The response contains the final order payment result. Throughout the entire process, the X-Correlation-Id in MDC is used in all steps (including any asynchronous operations), allowing for easy aggregation and querying of detailed execution information, time consumption, and status of the entire request chain in logs and monitoring metrics (such as Prometheus). This greatly facilitates troubleshooting and performance analysis.

[0163] 6. Long task processing (interface scenario extension).

[0164] Suppose that a long-running task to generate an electronic invoice is triggered after a successful payment. This task is time-consuming and should not block the core payment process. After the main process completes its state machine execution, it can synchronously call the `POST / jobs / submit?type=INVOICE_GEN&payload=...` interface. This request will immediately return a `jobId`. The invoice generation task is submitted to the `JobWorker` subsystem and enters the `PENDING` state. Subsequently, it is executed asynchronously by a small, independent thread pool within this subsystem. Clients (such as the frontend or another service) can use `GET / jobs / get?jobId=...` to poll the task's execution status (`RUNNING`, `SUCCEEDED`, `FAILED`), effectively isolating the long-running, blocking task from the main process.

[0165] Through the order payment process described in this embodiment, the beneficial effects of the technical solution of this application are concretely demonstrated: Significantly reduced resource consumption: By using a sharded single-threaded model and batch processing, massive concurrent requests are organized into a small number of threads for processing, greatly reducing the number of threads, context switching times, and CPU scheduling overhead, thereby directly reducing the resource consumption of the Linux kernel. Improved throughput and stability: The adaptive backpressure mechanism ensures that the system can smoothly degrade rather than crash under extreme loads; consistent hashing and redirection mechanisms implement decentralized, scalable distributed routing, enabling system throughput to grow linearly with cluster size. Latency and consistency guarantees: Strong sequential execution and CAS persistence ensure the eventual consistency and atomicity of core business processes; request merging and asynchronous isolation mechanisms shorten the response time of core links and stabilize tail latency (P99). Observability and operational efficiency: The full-link tracing identifier (X-Correlation-Id) and health interface ( / healthz) provide powerful support for system monitoring, fault location, and cluster management ( / cluster / initialize), improving operational efficiency.

[0166] The above description is merely a specific implementation of the embodiments of the present invention, but the protection scope of the embodiments of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the embodiments of the present invention should be included within the protection scope of the embodiments of the present invention. Therefore, the protection scope of the embodiments of the present invention should be determined by the protection scope of the claims.

Claims

1. A method for handling high-concurrency requests to reduce Linux kernel resource consumption, characterized in that, include: Receive a user request and extract the routing key from the request; The request corresponding to the routing key is processed by the sharded event executor. Based on the routing key, the request is allocated to one of the fixed N shards. Each shard is bound to a single thread and a bounded queue. Within the same shard, requests with the same routing key are executed in a strongly sequential manner according to the order of enqueueing. In the execution thread of the sharded event executor, a coroutine state machine is called to advance the business process. The coroutine state machine decomposes the business logic into enumerated states and contexts, and returns the state result based on the input through the state processing function. The state result indicates whether to transition to the next state, maintain the current state, or terminate the process. Based on the queue depth or waiting delay of the sharded event executor, adaptive back pressure is dynamically triggered, and the request submission strategy is dynamically adjusted according to the queue fill rate and the exponentially weighted moving average waiting delay. For requests identified as long-blocking tasks, the requests are submitted to the asynchronous task subsystem for execution, which executes them in isolation through an independent bounded queue and a small concurrent thread pool.

2. The method according to claim 1, characterized in that, The adaptive back pressure is implemented in the following ways: Calculate the fill rate of the bounded queue and the exponentially weighted moving average waiting time; The request submission timeout threshold is dynamically adjusted based on the fill rate and the exponentially weighted moving average waiting delay. When the timeout exceeds the set threshold, new requests are rejected.

3. The method according to claim 1, characterized in that, In the fragmented event executor: Perform batch dequeue operations on requests within the same slice, and execute multiple requests in a single scheduling; Requests with the same merge key are enqueued only once, and the results are broadcast to all related requests upon completion.

4. The method according to claim 1, characterized in that, The status result includes: When returning to the next state, carry the next state identifier and updated context data; When returning to terminate the process, carry the final execution result or error code.

5. The method according to claim 1, characterized in that, The methods for extracting the routing key include: Extract route keys from the HTTP request header, query parameters, or path using regular expression matching; The routing key is mapped to the target instance using a consistent hash ring.

6. The method according to claim 5, characterized in that, Also includes: If the routing key maps to a non-current instance, return a 307 redirect response carrying the URL of the target instance; The client resubmits the request to the target instance based on the 307 redirect response.

7. The method according to claim 1 or 6, characterized in that, The asynchronous task subsystem manages the job state machine, which includes the following states: PENDING, RUNNING, SUCCEEDED, FALSE, CANCELLED; The execution of long tasks and the retrieval of results are separated by submitting and querying interfaces.

8. The method according to claim 7, characterized in that, Also includes: The context of the coroutine state machine is persisted through atomically consistent storage; Use a Redis cluster to execute Lua scripts to implement atomic compare-swap updates; It supports idempotent keys and optional TTL expiration mechanism during updates.

9. The method according to claim 8, characterized in that, Also includes: Inject association identifiers that permeate thread switching and asynchronous tasks into the distributed chain; Global rate limiting is achieved through semaphore mechanisms, and resource consumption is controlled through request-level timeouts.

10. The method according to claim 2 or 9, characterized in that, The dynamic adjustment request submission strategy includes: New requests are rejected when the queue fill rate exceeds the first threshold or the exponentially weighted moving average wait time exceeds the second threshold. Return a suggested retry timestamp in the rejection response header.

11. An apparatus for handling high-concurrency requests to reduce Linux kernel resource consumption, characterized in that, include: The route key extraction module is configured to extract route keys from requests; The sharded event execution engine is configured to allocate shards based on routing keys and manage strong sequential execution. The coroutine state machine engine is configured to drive state transitions and context updates; The back pressure controller is configured to dynamically adjust request admission based on the queue status.

12. The apparatus according to claim 11, characterized in that, Also includes: Consistent hashing routing rings are configured to manage the mapping between virtual nodes and instances; The redirect filter is configured to generate a 307 redirect response pointing to the target instance.

Images