Lightweight process pool scheduling system and method based on bidirectional circulating message queue communication

Abstract

This invention provides a lightweight process pool scheduling system and method based on bidirectional circular message queue communication, comprising: a parent process module: implementing request caching and request distribution functions, and delivering business message bodies to the bidirectional circular message queue module; a bidirectional circular message queue module: including a child message queue, a parent message queue, and a lightweight message carrier; a child process pool module: monitoring the bidirectional circular message queue module in real time, processing child processes to parse business message bodies, implementing specific processing of business message data, and finally storing it in the database; and a process state machine module: obtaining state switching message bodies from the bidirectional circular message queue module, and responsible for unified recycling and cleanup. This invention solves the resource exhaustion problem caused by the extensive management of system resources and slow inter-service communication in high-concurrency monolithic systems, achieving full utilization of system resources, thereby supporting adaptive processing of high-concurrency traffic at all times.

Description

Technical Field

[0001] This invention relates to the field of process scheduling technology, and more specifically, to a lightweight process pool scheduling system and method based on bidirectional circular message queue communication. Background Technology

[0002] High-concurrency monolithic systems suffer from pain points such as inefficient management of multi-process resources and difficulty in fast communication between multiple services. This requires addressing these pain points while eliminating deep dependencies on large, comprehensive, or even complex and bloated components.

[0003] Patent document CN109240812A (application number: CN201810920122.0) discloses a process optimization scheduling method based on dynamic monitoring, relating to the field of process scheduling technology. This invention includes a process monitor that monitors the process status in a process pool (ProcessPool) and simultaneously monitors the process status in a waiting process queue (Seq-wait); a process scheduler schedules ready processes from the ProcessPool and wake-up processes (ProcessAwake) from the waiting process queue (Seq-wait) to a ready process queue (Seq-ready); the process scheduler schedules ready processes from the ready process queue (Seq-ready) to the processor according to a process scheduling algorithm; and the processor executes the ready processes. However, this invention does not utilize bidirectional circular message queue communication for process pool scheduling. Summary of the Invention

[0004] To address the shortcomings of existing technologies, the purpose of this invention is to provide a lightweight process pool scheduling system and method based on bidirectional circular message queue communication.

[0005] A lightweight process pool scheduling system based on bidirectional circular message queue communication provided by the present invention includes:

[0006] Parent process module: Implements request caching and request dispatch functions, and delivers the business message body to the bidirectional circular message queue module;

[0007] The bidirectional circular message queue module includes a child message queue, a parent message queue, and a lightweight message carrier;

[0008] Subprocess pool module: Real-time monitoring of bidirectional circular message queue module, processing subprocesses to parse business message bodies, realizing specific processing of business message data and final storage into the database;

[0009] Process state machine module: It obtains state transition message bodies from the bidirectional circular message queue module and is responsible for unified recycling and cleanup.

[0010] Preferably, in the parent process module:

[0011] The parent process module obtains message data from both external and internal sources: externally, it obtains business message data from upstream related systems, and caches business requests and message data to achieve request caching; it analyzes business message data in real time, extracts it into lightweight message carriers, forms business message bodies, and delivers these message bodies to the bidirectional circular message queue module to achieve request distribution; internally, the parent process module obtains feedback from the process state machine module regarding whether the child process pool module has idle resources.

[0012] Preferably, in the bidirectional circular message queue module:

[0013] The bidirectional circular message queue module is built on the Linux kernel IPC mechanism and is designed for kernel programming, including:

[0014] The child message queue consists of a unidirectional dedicated queue from the parent process module to the child process pool module, which realizes the enqueueing, caching, and dequeueing of business message bodies; it obtains lightweight message carriers from the parent process module and waits for the child process pool module to process them.

[0015] The parent message queue consists of a unidirectional dedicated queue from the child process pool module to the parent process module. It implements the enqueueing, caching, and dequeueing of state switching message bodies, obtains lightweight message carriers from the child process pool module, and waits for the process state machine module to process them.

[0016] A lightweight message carrier, which includes message type, message processing result, socket location, and file handle.

[0017] Preferably, in the subprocess pool module:

[0018] The subprocess pool module includes:

[0019] The persistent process pool consists of several persistent processes that exist after the application starts and continue to exist even without external requests. It obtains lightweight message carriers from the bidirectional circular message queue module, parses out the message type, socket location and socket descriptor, performs specific processing of business message data and finally puts it into the database, encapsulates the specific processing results, forms lightweight message carriers, and delivers them to the bidirectional circular message queue module.

[0020] The dynamic process pool consists of several dynamic processes. Dynamic processes are created or recycled according to the request load. The dynamic process pool ranges from the minimum to the maximum number. The bidirectional circular message queue module receives lightweight message carriers, parses them to obtain message type, socket location and socket descriptor, realizes specific processing of business message data and final storage, encapsulates the specific processing results to form lightweight message carriers, and delivers them to the bidirectional circular message queue module.

[0021] Preferably, in the process state machine module:

[0022] It consists of five states and a cycle of transitions, including idle, working, suspended, ready, and reclaimed states, which will transition into each other under preset conditions;

[0023] When a process starts, all processes are in an idle state. The child process that first obtains the message body to be sent from the bidirectional circular message queue module enters the working state. If an abnormal scenario occurs in the data center, the child process in the working state enters the suspended state. After the abnormal scenario is resolved, the child process in the suspended state enters the ready state. The child process in the ready state checks whether the current SMS is within the SMS validity time window. If it is, it resumes the working state to continue the current SMS task; otherwise, it discards the current SMS task and enters the idle state. When the total number of processes exceeds the minimum number of processes, the child process in the idle state for more than a preset time enters the recycling state.

[0024] The process state machine obtains the state transition message body from the bidirectional circular message queue module, and obtains information including the subprocess ID that specifically processes business message data and the updated subprocess status. The process state machine is responsible for unified recycling. If a working subprocess has been in the recycling state for more than a preset number of minutes, the process state machine will set it to the recycling state and will automatically enter the unified cleanup process. The process state machine is responsible for unified cleanup. When the total number of processes is greater than the minimum number of processes, the process state machine will shut down the subprocesses that are in the recycling state for more than a preset number of minutes.

[0025] According to the present invention, a lightweight process pool scheduling method based on bidirectional circular message queue module communication is provided, which employs the aforementioned lightweight process pool scheduling system based on bidirectional circular message queue module communication to perform the following:

[0026] Step S1: The parent process module caches SMS sending requests and delivers the business message body to the bidirectional circular message queue module;

[0027] Step S2: Idle processes in the subprocess pool module listen to the bidirectional circular message queue module in real time, process the subprocess to parse the business message body, and perform corresponding processing to complete the SMS entry into the database;

[0028] Step S3: When the processing subprocess is in the working state, a state transition message body is generated and delivered to the bidirectional circular message queue module. After the process state machine module obtains the message, it marks the processing subprocess as the working state and triggers the process state machine module to update itself.

[0029] Step S4: After the processing subprocess completes the SMS entry into the database, it enters the idle state and forms a state transition message body which is delivered to the bidirectional circular queue. After the process state machine module obtains the message, it marks the processing subprocess as being in the idle state and triggers the process state machine module to update itself.

[0030] Preferably, in step S1:

[0031] When a text message sending request enters the parent process module, the parent process module first caches the text message sending request. At the same time, the parent process module queries the process state machine module to find out that there are idle child processes in the child process pool module. Then, it encapsulates the cache location of the text message sending request and the text message type into a lightweight message body to form a business message body. The parent process module then delivers this business message body to the bidirectional circular message queue module.

[0032] Preferably, in step S2:

[0033] The idle process in the subprocess pool module listens to the bidirectional circular message queue module in real time. The first idle subprocess retrieves the business message body from the bidirectional circular message queue module and obtains the processing right to handle this SMS sending request. The processing subprocess parses the business message body, learns the cache location and SMS type of the SMS sending request, establishes an input stream from the cache location to read information including the complete SMS content and SMS type, performs corresponding processing according to the SMS type, and finally completes the SMS storage.

[0034] Preferably, in step S3:

[0035] When a subprocess is in the working state, it encapsulates the notification of entering the working state into a lightweight message body, forming a state transition message body. The subprocess then posts this state transition message body to the bidirectional circular message queue module. The process state machine module retrieves the state transition message body from the bidirectional circular message queue module, parses it to determine that the subprocess has entered the working state from the idle state, and marks the subprocess as being in the working state. Simultaneously, the process state machine module triggers its own update.

[0036] Preferably, in step S4:

[0037] After the processing subprocess completes the SMS entry into the database, it re-enters the idle state and encapsulates the idle state entry notification into a lightweight message body, forming a state transition message body. The processing subprocess delivers this state transition message body to the bidirectional circular message queue module. The process state machine module obtains the state transition message body from the bidirectional circular message queue module, parses it to know that the processing subprocess has entered the idle state from the working state, and marks the processing subprocess as being in the idle state, while simultaneously triggering the process state machine module to update itself.

[0038] Compared with the prior art, the present invention has the following beneficial effects:

[0039] 1. This invention is suitable for scenarios with high concurrency and continuous peak traffic across multiple time periods. It boasts excellent performance, elegant and simple design, and makes full use of operating system hardware resources. It also reduces the vulnerability risks associated with open-source framework components.

[0040] 2. This invention solves the problem of resource exhaustion caused by extensive management of system resources and slow inter-service communication in high-concurrency monolithic systems, and realizes full utilization of system resources, thereby supporting adaptive processing of high-concurrency traffic at all times. Attached Figure Description

[0041] Other features, objects, and advantages of the present invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0042] Figure 1 This is a diagram illustrating the overall workflow.

[0043] Figure 2 This is a flowchart of the process state machine. Detailed Implementation

[0044] The present invention will now be described in detail with reference to specific embodiments. These embodiments will help those skilled in the art to further understand the present invention, but do not limit the invention in any way. It should be noted that those skilled in the art can make several changes and improvements without departing from the concept of the present invention. These all fall within the protection scope of the present invention.

[0045] Example 1;

[0046] This invention proposes a lightweight unified scheduling scheme for process pools based on bidirectional circular message queue communication. The invention consists of a parent process, a child process pool, a process state machine, and a lightweight bidirectional circular message queue. The parent process centrally and efficiently manages resources, the child process pool quickly processes feedback, the process state machine ensures adaptive state switching, and the lightweight bidirectional circular message queue guarantees simple and fast communication.

[0047] A lightweight process pool scheduling method based on bidirectional circular message queue module communication is provided by the present invention, such as... Figures 1-2 As shown, it includes:

[0048] Step S1: The parent process module caches SMS sending requests and delivers the business message body to the bidirectional circular message queue module;

[0049] Specifically, in step S1:

[0050] When a text message sending request enters the parent process module, the parent process module first caches the text message sending request. At the same time, the parent process module queries the process state machine module to find out that there are idle child processes in the child process pool module. Then, it encapsulates the cache location of the text message sending request and the text message type into a lightweight message body to form a business message body. The parent process module then delivers this business message body to the bidirectional circular message queue module.

[0051] Step S2: Idle processes in the subprocess pool module listen to the bidirectional circular message queue module in real time, process the subprocess to parse the business message body, and perform corresponding processing to complete the SMS entry into the database;

[0052] Specifically, in step S2:

[0053] The idle process in the subprocess pool module listens to the bidirectional circular message queue module in real time. The first idle subprocess retrieves the business message body from the bidirectional circular message queue module and obtains the processing right to handle this SMS sending request. The processing subprocess parses the business message body, learns the cache location and SMS type of the SMS sending request, establishes an input stream from the cache location to read information including the complete SMS content and SMS type, performs corresponding processing according to the SMS type, and finally completes the SMS storage.

[0054] Step S3: When the processing subprocess is in the working state, a state transition message body is generated and delivered to the bidirectional circular message queue module. After the process state machine module obtains the message, it marks the processing subprocess as the working state and triggers the process state machine module to update itself.

[0055] Specifically, in step S3:

[0056] When a subprocess is in the working state, it encapsulates the notification of entering the working state into a lightweight message body, forming a state transition message body. The subprocess then posts this state transition message body to the bidirectional circular message queue module. The process state machine module retrieves the state transition message body from the bidirectional circular message queue module, parses it to determine that the subprocess has entered the working state from the idle state, and marks the subprocess as being in the working state. Simultaneously, the process state machine module triggers its own update.

[0057] Step S4: After the processing subprocess completes the SMS entry into the database, it enters the idle state and forms a state transition message body which is delivered to the bidirectional circular queue. After the process state machine module obtains the message, it marks the processing subprocess as being in the idle state and triggers the process state machine module to update itself.

[0058] Specifically, in step S4:

[0059] After the processing subprocess completes the SMS entry into the database, it re-enters the idle state and encapsulates the idle state entry notification into a lightweight message body, forming a state transition message body. The processing subprocess delivers this state transition message body to the bidirectional circular message queue module. The process state machine module obtains the state transition message body from the bidirectional circular message queue module, parses it to know that the processing subprocess has entered the idle state from the working state, and marks the processing subprocess as being in the idle state, while simultaneously triggering the process state machine module to update itself.

[0060] Example 2:

[0061] Example 2 is a preferred embodiment of Example 1, and is used to illustrate the present invention in more detail.

[0062] The present invention also provides a lightweight process pool scheduling system based on bidirectional circular message queue communication. The lightweight process pool scheduling system based on bidirectional circular message queue communication can be implemented by executing the process steps of the lightweight process pool scheduling method based on bidirectional circular message queue communication. That is, those skilled in the art can understand the lightweight process pool scheduling method based on bidirectional circular message queue communication as a preferred embodiment of the lightweight process pool scheduling system based on bidirectional circular message queue communication.

[0063] A lightweight process pool scheduling system based on bidirectional circular message queue communication provided by the present invention includes:

[0064] Parent process module: Implements request caching and request dispatch functions, and delivers the business message body to the bidirectional circular message queue module;

[0065] Specifically, in the parent process module:

[0066] The parent process module obtains message data from both external and internal sources: externally, it obtains business message data from upstream related systems, and caches business requests and message data to achieve request caching; it analyzes business message data in real time, extracts it into lightweight message carriers, forms business message bodies, and delivers these message bodies to the bidirectional circular message queue module to achieve request distribution; internally, the parent process module obtains feedback from the process state machine module regarding whether the child process pool module has idle resources.

[0067] The bidirectional circular message queue module includes a child message queue, a parent message queue, and a lightweight message carrier;

[0068] Specifically, in the bidirectional circular message queue module:

[0069] The bidirectional circular message queue module is built on the Linux kernel IPC mechanism and is designed for kernel programming, including:

[0070] The child message queue consists of a unidirectional dedicated queue from the parent process module to the child process pool module, which realizes the enqueueing, caching, and dequeueing of business message bodies; it obtains lightweight message carriers from the parent process module and waits for the child process pool module to process them.

[0071] The parent message queue consists of a unidirectional dedicated queue from the child process pool module to the parent process module. It implements the enqueueing, caching, and dequeueing of state switching message bodies, obtains lightweight message carriers from the child process pool module, and waits for the process state machine module to process them.

[0072] A lightweight message carrier, which includes message type, message processing result, socket location, and file handle.

[0073] Subprocess pool module: Real-time monitoring of bidirectional circular message queue module, processing subprocesses to parse business message bodies, realizing specific processing of business message data and final storage into the database;

[0074] Specifically, in the subprocess pool module:

[0075] The subprocess pool module includes:

[0076] The persistent process pool consists of several persistent processes that exist after the application starts and continue to exist even without external requests. It obtains lightweight message carriers from the bidirectional circular message queue module, parses out the message type, socket location and socket descriptor, performs specific processing of business message data and finally puts it into the database, encapsulates the specific processing results, forms lightweight message carriers, and delivers them to the bidirectional circular message queue module.

[0077] The dynamic process pool consists of several dynamic processes. Dynamic processes are created or recycled according to the request load. The dynamic process pool ranges from the minimum to the maximum number. The bidirectional circular message queue module receives lightweight message carriers, parses them to obtain message type, socket location and socket descriptor, realizes specific processing of business message data and final storage, encapsulates the specific processing results to form lightweight message carriers, and delivers them to the bidirectional circular message queue module.

[0078] Process state machine module: It obtains state transition message bodies from the bidirectional circular message queue module and is responsible for unified recycling and cleanup.

[0079] Specifically, in the process state machine module:

[0080] It consists of five states and a cycle of transitions, including idle, working, suspended, ready, and reclaimed states, which will transition into each other under preset conditions;

[0081] When a process starts, all processes are in an idle state. The child process that first obtains the message body to be sent from the bidirectional circular message queue module enters the working state. If an abnormal scenario occurs in the data center, the child process in the working state enters the suspended state. After the abnormal scenario is resolved, the child process in the suspended state enters the ready state. The child process in the ready state checks whether the current SMS is within the SMS validity time window. If it is, it resumes the working state to continue the current SMS task; otherwise, it discards the current SMS task and enters the idle state. When the total number of processes exceeds the minimum number of processes, the child process in the idle state for more than a preset time enters the recycling state.

[0082] The process state machine obtains the state transition message body from the bidirectional circular message queue module, and obtains information including the subprocess ID that specifically processes business message data and the updated subprocess status. The process state machine is responsible for unified recycling. If a working subprocess has been in the recycling state for more than a preset number of minutes, the process state machine will set it to the recycling state and will automatically enter the unified cleanup process. The process state machine is responsible for unified cleanup. When the total number of processes is greater than the minimum number of processes, the process state machine will shut down the subprocesses that are in the recycling state for more than a preset number of minutes.

[0083] Example 3:

[0084] Example 3 is a preferred example of Example 1, and is used to illustrate the present invention in more detail.

[0085] This innovative solution is currently being used in the SMS service system of a joint-stock bank. The overall workflow is as follows: Figure 1 As shown.

[0086] When a text message sending request enters the parent process, the parent process first caches the text message sending request. At the same time, the parent process queries the process state machine to find that there are idle child processes in the child process pool. Then, it encapsulates the cache location of the text message sending request and the text message type into a lightweight message body to form a business message body. Next, the parent process delivers this business message body to a doubly circular message queue.

[0087] Idle processes in the child process pool monitor the doubly circular queue in real time. The first idle child process to retrieve the business message body from the doubly circular message queue obtains the processing right to handle this SMS sending request. The processing child process parses the business message body, learns the cache location and SMS type of the SMS sending request, establishes an input stream from the cache location to read the complete SMS content, SMS type and other information, performs corresponding processing according to the SMS type, and finally completes the SMS storage.

[0088] When a subprocess is in the working state, it encapsulates the notification of entering the working state into a lightweight message body, forming a state transition message body. The subprocess then posts this state transition message body to a doubly linked circular message queue. The process state machine retrieves the state transition message body from the doubly linked circular message queue, parses it to determine that the subprocess has entered the working state from the idle state, and officially marks the subprocess as being in the working state, simultaneously triggering a self-update of the process state machine.

[0089] After the processing subprocess completes the SMS data entry, it re-enters the idle state. It encapsulates the idle state entry notification into a lightweight message body, forming a state transition message body, which it then posts to a doubly linked circular queue. The process state machine retrieves the state transition message body from the doubly linked circular queue, parses it to determine that the processing subprocess has transitioned from the working state to the idle state, and officially marks the processing subprocess as being in the idle state, simultaneously triggering a self-update of the process state machine. The process state machine workflow is as follows: Figure 2 As shown.

[0090] This innovation comprises four modules, namely:

[0091] Module 1: Parent Process. The parent process implements request caching and request distribution. The parent process obtains message data from both external and internal sources: externally, it obtains business message data from upstream related systems; the parent process caches business requests and message data to achieve request caching. It analyzes business message data in real time, extracts it into lightweight message carriers, forms a business message body, and delivers this message body to a bidirectional circular message queue to achieve request distribution; internally, the parent process obtains feedback from the process state machine regarding the availability of idle resources in the child process pool.

[0092] Module 2: Doubly Rotating Message Queue. This message queue is built on the Linux kernel IPC mechanism and is designed for kernel programming. Module 2 includes the following modules:

[0093] Module 2.1: Child-to-Child Message Queue. Consists of a unidirectional dedicated queue from the parent process to the child process pool, enabling the enqueueing, caching, and dequeueing of business message bodies. Lightweight message carriers are retrieved from the parent process and await processing by the child process pool.

[0094] Module 2.2: Parent Message Queue. Consists of a unidirectional dedicated queue from the child process pool to the parent process, implementing the enqueueing, buffering, and dequeueing of state transition message bodies. Lightweight message carriers are obtained from the child process pool and await processing by the process state machine.

[0095] Module 2.3: Lightweight Message Carrier. The message carrier contains only small amounts of short information such as message type, message processing result, socket location, and file handle, making the message concise.

[0096] Module 3: Subprocess Pool. Module 3 includes the following modules:

[0097] Module 3.1: Resident Process Pool. Composed of several resident processes, it persists after application startup and remains active even without external requests. It retrieves lightweight message carriers from a doubly circular message queue, parses them to obtain message type, socket location, and socket descriptor. It then handles the specific processing of business message data and its final storage in the database. Finally, it encapsulates the processing results into lightweight message carriers and delivers them to the doubly circular message queue.

[0098] Module 3.2: Dynamic Process Pool. Composed of several dynamic processes, which are created or recycled based on request load. The dynamic process pool ranges from a minimum to a maximum number. A bidirectional circular message queue receives lightweight message carriers, parses them to obtain the message type, socket location, and socket descriptor. It then performs specific processing of business message data and finally stores it in the database. The processing results are encapsulated into lightweight message carriers and delivered to the bidirectional circular message queue.

[0099] Module 4: Process State Machine. Consists of five states and cyclical transitions. There are idle, working, suspended, ready, and reclaimed states, which transition between each other under certain conditions. When a process starts, all processes are in the idle state. The child process that first retrieves the message body from the doubly circular message queue enters the working state. If a sudden anomaly occurs in the data center, such as database HA drift, the child process in the working state enters the suspended state. After the anomaly is resolved, the child process in the suspended state enters the ready state. The child process in the ready state checks if the current SMS message is within the valid time window; if so, it resumes the working state to continue the current SMS task; otherwise, it discards the current SMS task and enters the idle state. When the total number of processes exceeds the minimum number of processes, processes in the idle state for more than one minute enter the reclaimed state.

[0100] The process state machine retrieves state transition message bodies from a doubly looping message queue, obtaining information such as the child process ID for processing specific business message data and the updated child process status. The process state machine is responsible for unified cleanup; child processes that have been in a working state for more than 30 minutes will be set to a cleanup state and will be automatically cleaned up subsequently. The process state machine is also responsible for unified cleanup; when the total number of processes exceeds the minimum number of processes, the process state machine will shut down child processes that have been in a cleanup state for more than one minute.

[0101] Those skilled in the art will understand that, in addition to implementing the system, apparatus, and their modules provided by this invention in purely computer-readable program code, the same program can be implemented in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, the system, apparatus, and their modules provided by this invention can be considered a hardware component, and the modules included therein for implementing various programs can also be considered structures within the hardware component; alternatively, modules for implementing various functions can be considered both software programs implementing the method and structures within the hardware component.

[0102] Specific embodiments of the present invention have been described above. It should be understood that the present invention is not limited to the specific embodiments described above, and those skilled in the art can make various changes or modifications within the scope of the claims, which do not affect the essence of the present invention. Unless otherwise specified, the embodiments and features described in this application can be arbitrarily combined with each other.

Claims

1. A lightweight process pool scheduling system based on bidirectional circular message queue communication, characterized in that, include: Parent process module: Implements request caching and request dispatch functions, and delivers the business message body to the bidirectional circular message queue module; The bidirectional circular message queue module includes a child message queue, a parent message queue, and a lightweight message carrier; Subprocess pool module: Real-time monitoring of bidirectional circular message queue module, processing subprocesses to parse business message bodies, realizing specific processing of business message data and final storage into the database; Process state machine module: obtains state transition message bodies from the bidirectional circular message queue module and is responsible for unified recycling and cleanup; In the bidirectional circular message queue module: The bidirectional circular message queue module is built on the Linux kernel IPC mechanism and is designed for kernel programming, including: The child message queue consists of a unidirectional dedicated queue from the parent process module to the child process pool module, which realizes the enqueueing, caching, and dequeueing of business message bodies; it obtains lightweight message carriers from the parent process module and waits for the child process pool module to process them. The parent message queue consists of a unidirectional dedicated queue from the child process pool module to the parent process module. It implements the enqueueing, caching, and dequeueing of state switching message bodies, obtains lightweight message carriers from the child process pool module, and waits for the process state machine module to process them. Lightweight message carrier, which includes message type, message processing result, socket location and file handle; In the subprocess pool module: The subprocess pool module includes: The persistent process pool consists of several persistent processes that exist after the application starts and continue to exist even without external requests. It obtains lightweight message carriers from the bidirectional circular message queue module, parses out the message type, socket location and socket descriptor, performs specific processing of business message data and finally puts it into the database, encapsulates the specific processing results, forms lightweight message carriers, and delivers them to the bidirectional circular message queue module. The dynamic process pool consists of several dynamic processes. Dynamic processes are created or recycled according to the request load. The dynamic process pool ranges from the minimum to the maximum number. The bidirectional circular message queue module receives lightweight message carriers, parses them to obtain message type, socket location and socket descriptor, realizes specific processing of business message data and final storage, encapsulates the specific processing results to form lightweight message carriers, and delivers them to the bidirectional circular message queue module.

2. The lightweight process pool scheduling system based on bidirectional circular message queue communication according to claim 1, characterized in that, In the parent process module: The parent process module obtains message data from both external and internal sources: externally, it obtains business message data from upstream related systems, and caches business requests and message data to achieve request caching; it analyzes business message data in real time, extracts it into lightweight message carriers, forms business message bodies, and delivers these message bodies to the bidirectional circular message queue module to achieve request distribution; internally, the parent process module obtains feedback from the process state machine module regarding whether the child process pool module has idle resources.

3. The lightweight process pool scheduling system based on bidirectional circular message queue communication according to claim 1, characterized in that, In the process state machine module: It consists of five states and a cycle of transitions, including idle, working, suspended, ready, and reclaimed states, which will transition into each other under preset conditions; When a process starts, all processes are in an idle state. The child process that first obtains the message body to be sent from the bidirectional circular message queue module enters the working state. When an abnormal scenario occurs in the data center, the child process in the working state enters the suspended state. After the abnormal scenario is resolved, the child process in the suspended state enters the ready state. The child process in the ready state checks whether the current SMS is within the SMS validity time window. If it is, it resumes the working state to continue the current SMS task. Otherwise, discard the current SMS task and enter the idle state; When the total number of processes exceeds the minimum number of processes, if the process is in an idle state for more than a preset time, it will enter the recycling state. The process state machine obtains the state transition message body from the bidirectional circular message queue module, and obtains information including the subprocess ID that specifically processes business message data and the updated subprocess status. The process state machine is responsible for unified recycling. If a working subprocess has been in the recycling state for more than a preset number of minutes, the process state machine will set it to the recycling state and will automatically enter the unified cleanup process. The process state machine is responsible for unified cleanup. When the total number of processes is greater than the minimum number of processes, the process state machine will shut down the subprocesses that are in the recycling state for more than a preset number of minutes.

4. A lightweight process pool scheduling method based on bidirectional circular message queue module communication, characterized in that, The lightweight process pool scheduling system based on bidirectional circular message queue communication as described in claim 1 is used to perform the following: Step S1: The parent process module caches SMS sending requests and delivers the business message body to the bidirectional circular message queue module; Step S2: Idle processes in the subprocess pool module listen to the bidirectional circular message queue module in real time, process the subprocess to parse the business message body, and perform corresponding processing to complete the SMS entry into the database; Step S3: When the processing subprocess is in the working state, a state transition message body is generated and delivered to the bidirectional circular message queue module. After the process state machine module obtains the message, it marks the processing subprocess as the working state and triggers the process state machine module to update itself. Step S4: After the processing subprocess completes the SMS entry into the database, it enters the idle state and forms a state transition message body which is delivered to the bidirectional circular queue. After the process state machine module obtains the message, it marks the processing subprocess as being in the idle state and triggers the process state machine module to update itself. In step S2: The idle process in the subprocess pool module listens to the bidirectional circular message queue module in real time. The first idle subprocess retrieves the business message body from the bidirectional circular message queue module and obtains the processing right to handle this SMS sending request. The processing subprocess parses the business message body, learns the cache location and SMS type of the SMS sending request, establishes an input stream from the cache location to read information including the complete SMS content and SMS type, performs corresponding processing according to the SMS type, and finally completes the SMS storage. In step S3: When a subprocess is in the working state, it encapsulates the notification of entering the working state into a lightweight message body, forming a state transition message body. The subprocess then posts this state transition message body to the bidirectional circular message queue module. The process state machine module retrieves the state transition message body from the bidirectional circular message queue module, parses it to determine that the subprocess has entered the working state from the idle state, and marks the subprocess as being in the working state. Simultaneously, the process state machine module triggers its own update.

5. The lightweight process pool scheduling method based on bidirectional circular message queue module communication according to claim 4, characterized in that, In step S1: When a text message sending request enters the parent process module, the parent process module first caches the text message sending request. At the same time, the parent process module queries the process state machine module to find out that there are idle child processes in the child process pool module. Then, it encapsulates the cache location of the text message sending request and the text message type into a lightweight message body to form a business message body. The parent process module then delivers this business message body to the bidirectional circular message queue module.

6. The lightweight process pool scheduling method based on bidirectional circular message queue module communication according to claim 4, characterized in that, In step S4: After the processing subprocess finishes storing the SMS messages, it re-enters the idle state and encapsulates the idle state notification into a lightweight message body, forming a state transition message body. The processing subprocess then delivers this state transition message body to the bidirectional circular message queue module. The process state machine module obtains the state transition message body from the bidirectional circular message queue module, parses it to know that the processing subprocess has entered the idle state from the working state, and the process state machine module marks the processing subprocess as being in the idle state, and at the same time triggers the process state machine module to update itself.

Images