Message request processing method, system, device and readable storage medium
By prioritizing message requests based on their type and business process stage within the set-top box and adding them to a multi-priority queue, the problem of repeated set-top box restarts during peak hours is resolved, achieving orderly processing and traffic mitigation.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- YOUDI NETWORK CO LTD
- Filing Date
- 2022-10-18
- Publication Date
- 2026-07-21
AI Technical Summary
During the set-top box startup process, at peak times, the set-top box may repeatedly restart due to untimely processing of message requests, causing prolonged server congestion.
By determining the type of message request and the stage of the business process, the message request is added to the corresponding multi-priority message queue according to the priority of different stages, and the message request is executed in the order of processing priority.
It enables the orderly processing of set-top box message requests, alleviating traffic pressure during peak periods and preventing repeated restarts of the set-top box.
Smart Images
Figure CN115767188B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of set-top box communication, and in particular to a message request processing method, a message request processing system, a message request processing device, and a computer-readable storage medium. Background Technology
[0002] With rapid societal development and technological advancements, set-top boxes are becoming increasingly prevalent. A set-top box is a device that connects a television set to an external signal source. It converts compressed digital signals into television content and displays it on the television screen. Signals can come from cable TV, satellite dishes, broadband networks, and terrestrial broadcasts. In addition to the images and sound provided by analog television, set-top boxes can also receive digital content.
[0003] In related technologies, powering on a set-top box requires four message requests; only when all four steps are successful can the box be used normally. Since a single operator serves tens of millions of users, during peak hours, to prevent instantaneous traffic surges from overwhelming the server, operators typically use queuing algorithms to process the four message requests in a session sequentially.
[0004] However, in traditional queuing algorithms, message requests are first-in, first-out. This can lead to a failure to boot up successfully because the last message request in the four steps cannot enter the queue or is too late in the queue. This can result in a large number of users repeatedly restarting their set-top boxes, causing server congestion for extended periods. Summary of the Invention
[0005] This application provides a message request processing method, a message request processing system, a message request processing device, and a computer-readable storage medium, which solves the technical problem in related technologies where set-top boxes repeatedly restart due to untimely message request processing during peak periods. It achieves the technical effect of ensuring orderly processing of set-top box message requests and alleviating traffic pressure during peak periods.
[0006] This application provides a message request processing method, which includes:
[0007] Upon receiving a message request, determine the message type of the message request;
[0008] Based on the message type, determine the business process corresponding to the message request;
[0009] Depending on the business stage of the business process, the message request is added to the corresponding message queue, wherein the message request in the later business stage is added to the message queue with higher processing priority.
[0010] The message requests in the message queue are executed in order of processing priority based on the message queue.
[0011] Optionally, the step of adding the message request to the corresponding message queue according to the different business stages of the business process includes:
[0012] If the business phase is the initial business phase, the priority of the message request is determined based on a preset queuing algorithm;
[0013] The message request is added to the corresponding message queue based on the priority.
[0014] Optionally, the step of adding the message request to the corresponding message queue according to the different business stages of the business process further includes:
[0015] If the business stage is not the initial business stage, determine the preceding business process corresponding to the business process;
[0016] Determine the target priority of the preceding business processes;
[0017] The priority corresponding to the message request is determined based on the target priority;
[0018] The message request is added to the corresponding message queue based on the priority.
[0019] Optionally, the step of adding the message request to the corresponding message queue based on the priority includes:
[0020] The message request is sent to the add queue interface. When the add queue interface receives the message request, it determines the queue identifier corresponding to the priority.
[0021] Add the message request to the message queue corresponding to the queue identifier.
[0022] Optionally, the step of adding the message request to the message queue corresponding to the queue identifier includes:
[0023] Determine the load value of the message queue corresponding to the queue identifier;
[0024] If the load value is greater than the load threshold, a target message queue with a lower processing priority than the message queue is determined, and the message request is added to the target message queue.
[0025] Otherwise, add the message request to the message queue.
[0026] Optionally, the step of executing the message requests in the message queue according to the processing priority of the message queue includes:
[0027] The processing order of the message queue is determined based on the processing priority;
[0028] Determine the first message queue corresponding to the processing order, wherein the first message queue is the message queue with the highest processing priority;
[0029] Starting from the first message queue, traverse all the message queues according to the processing order;
[0030] If the message request does not exist in the current message queue, then determine whether the message request exists in the subsequent message queue corresponding to the current message queue;
[0031] If the message request exists in the current message queue, determine the pending requests in the message request;
[0032] Process the pending message request.
[0033] Optionally, the step of determining the pending requests in the message request if the current message queue contains the message request includes:
[0034] Obtain the time information corresponding to the message request, wherein the time information is the moment when the message request was added to the message queue;
[0035] Based on the time information, the earliest message request added to the current message queue is identified as the pending request.
[0036] Furthermore, this application also proposes a message request processing system, which includes: a receiving thread, which, upon receiving a message request, adds the message request to a corresponding message queue according to the business stage of the business process corresponding to the message request; a multi-priority message queue, which includes multiple message queues, each with a different processing priority; and a processing thread, which determines the processing order of the message queues according to the processing priority, and traverses all message queues starting from the first message queue according to the processing order; after processing the message requests in the message queues with higher processing priorities, the message queues with lower processing priorities are then processed.
[0037] Furthermore, this application also proposes a message request processing device, which includes a memory, a processor, and a message request processing program stored in the memory and executable on the processor. When the processor executes the message request processing program, it implements the steps of the message request processing method described above.
[0038] Furthermore, this application also proposes a computer-readable storage medium storing a message request handler, which, when executed by a processor, implements the steps of the message request processing method described above.
[0039] One or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages:
[0040] 1. By determining the message type of the received message request, identifying the corresponding business process based on the message type, and adding the message request to the corresponding message queue according to the different stages of the business process, where messages from later business stages are added to message queues with higher processing priority, and processing the message requests in the message queues according to processing priority, the technical problem of set-top boxes repeatedly restarting due to untimely processing of message requests during peak periods in related technologies is effectively solved. This achieves the technical effect of ensuring orderly processing of set-top box message requests and alleviating traffic pressure during peak periods.
[0041] 2. By employing a pre-defined queuing algorithm to determine the priority of message requests when the business phase is the initial business phase, and by using the priority of the preceding business process as the target priority when the business phase is not the initial business phase, and then determining the priority of the message request based on the target priority, and adding the message request to the corresponding message queue according to the priority, this method effectively solves the technical problem of repeated set-top box restarts due to untimely message request processing during peak periods in related technologies. This achieves the technical effect of ensuring orderly processing of set-top box message requests and alleviating traffic pressure during peak periods. Attached Figure Description
[0042] Figure 1 This is a flowchart illustrating an embodiment of the message request processing method of this application;
[0043] Figure 2 This is a flowchart illustrating Embodiment 2 of the message request processing method of this application;
[0044] Figure 3 This is a flowchart illustrating Embodiment 3 of the message request processing method of this application;
[0045] Figure 4This is a schematic diagram of the hardware structure involved in the embodiment of the message request processing device of this application. Detailed Implementation
[0046] In related technologies, a single power-on process involves four steps: a, b, c, and d. Only after all four steps are successful can the television playback screen be displayed. When a large number of users restart their set-top boxes, causing significant peak system load, delays in processing a single step often result in the need to restart the login process, leading to a snowballing backlog of message requests. The main technical solution adopted in this application is: determining the message type of the received message request; determining the corresponding business process based on the message type; and adding the message request to the corresponding message queue according to the stage of the business process. Messages at later stages are added to message queues with higher processing priority, and the message requests in the message queues are processed according to their processing priority. This achieves the technical effect of ensuring orderly processing of set-top box message requests and alleviating traffic pressure during peak periods.
[0047] To better understand the above technical solutions, exemplary embodiments of this application will be described in more detail below with reference to the accompanying drawings. Although exemplary embodiments of this application are shown in the drawings, it should be understood that this application can be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of this application and to fully convey the scope of this application to those skilled in the art.
[0048] Example 1
[0049] Embodiment 1 of this application discloses a message request processing method, which is described below. Figure 1 The message request processing method includes:
[0050] Step S10: Upon receiving a message request, determine the message type of the message request;
[0051] In this embodiment, the set-top box sends a corresponding message request for each of the four power-on steps. When the receiving thread receives a message request, it determines the message type corresponding to the message request. The receiving thread can determine the corresponding business process, i.e., the power-on steps, based on the message type. The message type is an attribute of the message request, determined according to the power-on steps corresponding to the message request.
[0052] Step S20: Based on the message type, determine the business process corresponding to the message request;
[0053] In this embodiment, when the receiving thread receives a message request, it determines the corresponding business process based on the message type. The business process corresponds to one of the four steps a, b, c, and d during startup.
[0054] As an optional implementation, when the receiving thread receives a message request, it determines the MsgType (Message Type) corresponding to the message request; and determines the business process corresponding to the message request based on the MsgType.
[0055] Step S30: According to the different business stages of the business process, the message request is added to the corresponding message queue, wherein the message request in the later business stage is added to the message queue with higher processing priority.
[0056] In this embodiment, the message queue is a sub-queue of a multi-priority queue, which includes multiple sub-queues. The priority refers to the processing priority; that is, the higher the priority of a sub-queue, the earlier the processing thread processes the message requests in that sub-queue. The business phase corresponds to the four steps of the startup process.
[0057] As an optional implementation, the receiving thread determines the priority of the message request based on the business stage of the business process, then determines the sub-queue in the corresponding multi-priority queue based on the priority, and adds the message request to the sub-queue.
[0058] For example, the receiving thread first determines the priority i based on the MsgType (message type) of the message request, and passes i to the AddJobToQueue interface; the AddJobToQueue interface determines the parameter i and puts the message into the sub-queue with priority i.
[0059] Step S40: Execute the message requests in the message queue according to the processing priority order of the message queue.
[0060] In this embodiment, the processing thread processes the corresponding message queue according to the processing priority, which corresponds to the priority of the message request.
[0061] As an optional implementation, the processing thread processes the sub-queue with priority 1 first, according to processing priority. The sub-queue with priority 1 stores message requests with priority 1. After processing all message requests in the sub-queue with priority 1, the thread processes the sub-queue with priority 2.
[0062] For example, the processing thread calls the FetchJobFromQueue interface, prioritizing the processing of high-priority queues. Only after all messages in a high-priority queue have been processed will the lower-priority queues be processed. That is, messages in Queue1 are processed first; if Queue1 has no messages, messages in Queue2 are processed; if Queue2 has no messages, messages in Queue3 are processed; if all preceding queues have no messages, messages in QueueN are processed, and so on, until all queues have been traversed.
[0063] The technical solutions described in the embodiments of this application have at least the following technical effects or advantages:
[0064] By determining the message type of the received message request, identifying the corresponding business process based on the message type, and adding the message request to the corresponding message queue according to the different stages of the business process (with messages from later business stages added to message queues with higher processing priority), the technical problem of set-top boxes repeatedly restarting due to untimely message request processing during peak periods is effectively solved in related technologies. This achieves the technical effect of ensuring orderly processing of set-top box message requests and alleviating traffic pressure during peak periods.
[0065] Example 2
[0066] Based on Embodiment 1, Embodiment 2 of this application proposes a message request processing method, wherein step S30 includes:
[0067] S210, if the business stage is not the initial business stage, determine the preceding business process corresponding to the business process;
[0068] S220, determine the target priority of the preceding business process;
[0069] S230, determine the priority corresponding to the message request based on the target priority;
[0070] S240, the message request is added to the corresponding message queue based on the priority.
[0071] In this embodiment, the initial service stage is step a of the power-on process, which is the first step in powering on the set-top box. The preceding service process is the power-on step preceding the current service process. The target priority is the priority of the preceding service process.
[0072] As an optional implementation, after the receiving thread determines the business process corresponding to the message request, it determines the business stage corresponding to the business process. If the business stage is not step a of the startup process, it determines the preceding business process of the business process; according to the priority of the preceding business process, it determines the priority of the business process; then, according to the priority, it determines the corresponding sub-queue and adds the message request to the sub-queue.
[0073] For example, the receiving thread determines step c of the business process corresponding to the message request to be started; determines step b of the business stage corresponding to the preceding business process to be started; determines that the current sub-queue of the preceding business process is Queue3, that is, the sub-queue with a priority of 3, determines that the target priority of the preceding business process is 3, and determines that the priority of the business process is 2 based on the target priority, so the message request is added to Queue2.
[0074] Optionally, step S30 may further include:
[0075] S250, if the business stage is the initial business stage, the priority corresponding to the message request is determined based on a preset queuing algorithm;
[0076] S260, the message request is added to the corresponding message queue based on the priority.
[0077] In this embodiment, the initial service stage is step a of the power-on process, at which point the message request has the lowest priority.
[0078] As an optional implementation, after receiving a message request, the receiving thread determines that the message request is a request sent when the set-top box is powered on and step a is executed, that is, the service stage is the initial service stage; based on a preset algorithm, the priority of the message request is determined to be 4 or 5; and the message request is added to Queue4 or Queue5.
[0079] Optionally, step S240 or step S260 includes:
[0080] Step S270: The message request is sent to the add queue interface. When the add queue interface receives the message request, it determines the queue identifier corresponding to the priority.
[0081] Step S280: Add the message request to the message queue corresponding to the queue identifier.
[0082] In this embodiment, the interface for adding a queue is the AddJobToQueue interface, and the queue identifier corresponds to the priority.
[0083] As an optional implementation, after determining the priority of the message request, the receiving thread determines the message queue that matches the priority; sends the message request and priority to the AddJobToQueue interface; after receiving the message request, the AddJobToQueue interface determines the corresponding queue identifier according to the priority; and adds the message request to the sub-queue that matches the queue identifier.
[0084] Optionally, step S280 includes:
[0085] Step S281: Determine the load value of the message queue corresponding to the queue identifier;
[0086] Step S282: If the load value is greater than the load threshold, determine a target message queue with a lower processing priority than the message queue, and add the message request to the target message queue.
[0087] Step S283: Otherwise, add the message request to the message queue.
[0088] In this embodiment, the load value refers to the load status of the message queue, that is, there is a limit to the number of message requests a message queue can hold. This limit can be set proactively according to demand or dynamically according to an algorithm. The load threshold is a warning value for the message queue to accommodate a certain number of message requests.
[0089] As an optional implementation, after determining the sub-queue that matches the queue identifier, the AddJobToQueue interface determines the load status of the sub-queue; if the load status of the sub-queue is greater than the load threshold, the queue identifier is updated to a lower priority, and the sub-queue to be added is re-determined; if the load value is less than or equal to the load threshold, the message request is added to the sub-queue that matches the queue identifier.
[0090] For example, the AddJobToQueue interface determines that the queue identifier is 4, and determines that the sub-queue matching the queue identifier is Queue4; it determines the load value of the sub-queue. If the load value is greater than the load threshold of 85%, it determines that the new queue identifier is 5, and determines that the sub-queue matching the queue identifier before and after the update is Queue5; it continues to determine the load value of Queue5. If the load value of Queue5 is still greater than the load threshold of 80%, it determines that the new queue identifier is 6; if the load value of Queue5 is less than or equal to the load threshold of 80%, then the message queue is added to Queue5.
[0091] As an alternative implementation, the load threshold for each sub-queue is dynamically changed and can be adjusted according to the current number of message requests to ensure that the server's computing load is at its highest efficiency.
[0092] The technical solutions described in the embodiments of this application have at least the following technical effects or advantages:
[0093] By employing a pre-defined queuing algorithm to determine the priority of message requests when the business phase is the initial business phase, and by using the priority of the preceding business process as a target priority when the business phase is not the initial business phase, and then determining the priority of the message request based on the target priority, and adding the message request to the corresponding message queue according to the priority, this approach effectively solves the technical problem of repeated set-top box restarts due to untimely message request processing during peak periods in related technologies. This achieves the technical effect of ensuring orderly processing of set-top box message requests and alleviating traffic pressure during peak periods.
[0094] Example 3
[0095] Based on Embodiment 1, Embodiment 3 of this application discloses a message request processing method, wherein step S40 includes:
[0096] Step S310: Determine the processing order of the message queue based on the processing priority;
[0097] Step S320: Determine the first message queue corresponding to the processing order, wherein the first message queue is the message queue with the highest processing priority;
[0098] Step S330: Starting from the first message queue, traverse all the message queues according to the processing order;
[0099] Step S340: If the message request does not exist in the current message queue, then determine whether the message request exists in the subsequent message queue corresponding to the message queue.
[0100] Step S350: If the message request exists in the current message queue, determine the pending request in the message request;
[0101] Step S360: Process the pending message request.
[0102] In this embodiment, the processing order refers to the order in which the processing thread traverses the sub-queues when executing message requests. The first message queue is the sub-queue with the highest processing priority, namely Queue1. When the processing thread executes a message request, it traverses all sub-queues starting from Queue1. If a message request in Queue1 has been completed, it queries Queue2; this continues until all message requests in all message queues have been processed. The subsequent message queues are sub-queues with lower priority than the currently executing sub-queue.
[0103] As an optional implementation, the processing thread determines the processing order of all message queues based on processing priority, and determines the first message queue to be processed, i.e., Queue1, according to the processing order. Starting from the first message queue, all message queues are traversed according to the processing order. If a message request exists in the currently queried message queue, the message request is executed. If the message request does not exist in the message queue, the subsequent message queue with a lower priority than the current message queue is queried until the message request exists in the currently queried message queue, and the message request is executed.
[0104] Optionally, step S360 includes:
[0105] Step S361: Obtain the time information corresponding to the message request, wherein the time information is the time when the message request was added to the message queue;
[0106] Step S362: Based on the time information, determine the earliest message request added to the current message queue as the pending request.
[0107] In this embodiment, the time information is the moment when the message request is added to the message queue, and serves as an attribute of the corresponding message request.
[0108] As an optional implementation, when the processing thread queries the message queue, there is usually more than one message request in the current message queue. The processing thread processes the earliest message request added to the current message queue in a first-in-first-out order based on the message request's time information.
[0109] As another optional implementation, priority is reflected in the processing order of sub-queues. For message requests in the same sub-queue, the processing thread executes them in a first-in-first-out order.
[0110] For example, the processing thread queries Queue4 and the query results show that there is message request b corresponding to step b and message request a corresponding to step a in the sub-queue. At this time, message request a was added to Queue4 earlier than message request b. So, although message request b has a higher priority than message request a, message request a was added to the sub-queue earlier, so the processing thread processes message request a first.
[0111] The technical solutions described in the embodiments of this application have at least the following technical effects or advantages:
[0112] By employing a process that determines the processing order of message queues based on processing priority, the first message queue to be processed is identified. Starting from the first message queue, all message queues are traversed according to the processing order. If the message request is not present in the current message queue, the corresponding subsequent message queue is queried. If the message request exists in the current message queue, the pending requests within that message request are identified. For message requests within the same message queue, the message request with earlier time information is processed first, following the first-in, first-out (FIFO) principle. Therefore, this approach effectively solves the technical problem in related technologies where untimely message request processing during peak hours leads to repeated set-top box restarts, thereby ensuring orderly processing of set-top box message requests and alleviating traffic pressure during peak periods.
[0113] This application also proposes a message request processing device, referring to... Figure 4 , Figure 4 This is a schematic diagram of the message request processing device structure of the hardware operating environment involved in the embodiments of this application.
[0114] like Figure 4 As shown, the message request processing device may include: a processor 1001, such as a central processing unit (CPU), a communication bus 1002, a user interface 1003, a network interface 1004, and a memory 1005. The communication bus 1002 is used to enable communication between these components. The user interface 1003 may include a display screen or an input unit such as a keyboard; optionally, the user interface 1003 may also include a standard wired interface or a wireless interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 1005 may be a high-speed random access memory (RAM) or a stable non-volatile memory (NVM), such as a disk drive. The memory 1005 may also optionally be a storage device independent of the aforementioned processor 1001.
[0115] Those skilled in the art will understand that Figure 4 The structure shown does not constitute a limitation on the message request processing device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.
[0116] Optionally, the memory 1005 is electrically connected to the processor 1001. The processor 1001 can be used to control the operation of the memory 1005 and can also read data in the memory 1005 to implement message request processing.
[0117] Optionally, such as Figure 4 As shown, the memory 1005, which serves as a storage medium, may include an operating system, a data storage module, a network communication module, a user interface module, and a message request handler.
[0118] Optionally, in Figure 4 In the message request processing device shown, the network interface 1004 is mainly used for data communication with other devices; the user interface 1003 is mainly used for data interaction with users; the processor 1001 and memory 1005 in the message request processing device of this application can be set in the message request processing device.
[0119] like Figure 4 As shown, the message request processing device calls the message request processing program stored in the memory 1005 through the processor 1001, and executes the relevant steps of the message request processing method provided in this application embodiment:
[0120] Upon receiving a message request, determine the message type of the message request;
[0121] Based on the message type, determine the business process corresponding to the message request;
[0122] Depending on the business stage of the business process, the message request is added to the corresponding message queue, wherein the message request in the later business stage is added to the message queue with higher processing priority.
[0123] The message requests in the message queue are executed in order of processing priority based on the message queue.
[0124] Optionally, the processor 1001 may call the message request handler stored in the memory 1005 and further perform the following operations:
[0125] If the business stage is not the initial business stage, determine the preceding business process corresponding to the business process;
[0126] Determine the target priority of the preceding business processes;
[0127] The priority corresponding to the message request is determined based on the target priority;
[0128] The message request is added to the corresponding message queue based on the priority.
[0129] Optionally, the processor 1001 may call the message request handler stored in the memory 1005 and further perform the following operations:
[0130] If the business phase is the initial business phase, the priority of the message request is determined based on a preset queuing algorithm;
[0131] The message request is added to the corresponding message queue based on the priority.
[0132] Optionally, the processor 1001 may call the message request handler stored in the memory 1005 and further perform the following operations:
[0133] The message request is sent to the add queue interface. When the add queue interface receives the message request, it determines the queue identifier corresponding to the priority.
[0134] Add the message request to the message queue corresponding to the queue identifier.
[0135] Optionally, the processor 1001 may call the message request handler stored in the memory 1005 and further perform the following operations:
[0136] Determine the load value of the message queue corresponding to the queue identifier;
[0137] If the load value is greater than the load threshold, a target message queue with a lower processing priority than the message queue is determined, and the message request is added to the target message queue.
[0138] Otherwise, add the message request to the message queue.
[0139] Optionally, the processor 1001 may call the message request handler stored in the memory 1005 and further perform the following operations:
[0140] The processing order of the message queue is determined based on the processing priority;
[0141] Determine the first message queue corresponding to the processing order, wherein the first message queue is the message queue with the highest processing priority;
[0142] Starting from the first message queue, traverse all the message queues according to the processing order;
[0143] If the message request does not exist in the current message queue, then determine whether the message request exists in the subsequent message queue corresponding to the current message queue;
[0144] If the message request exists in the current message queue, determine the pending requests in the message request;
[0145] Process the pending message request.
[0146] Optionally, the processor 1001 may call the message request handler stored in the memory 1005 and further perform the following operations:
[0147] Obtain the time information corresponding to the message request, wherein the time information is the moment when the message request was added to the message queue;
[0148] Based on the time information, the earliest message request added to the current message queue is identified as the pending request.
[0149] Furthermore, this application also proposes a message request processing system, which includes: a receiving thread, which, upon receiving a message request, adds the message request to a corresponding message queue according to the business stage of the business process corresponding to the message request; a multi-priority message queue, which includes multiple message queues, each with a different processing priority; and a processing thread, which determines the processing order of the message queues according to the processing priority, and traverses all message queues starting from the first message queue according to the processing order; after processing the message requests in the message queues with higher processing priorities, the message queues with lower processing priorities are then processed.
[0150] Furthermore, embodiments of this application also propose a computer-readable storage medium storing a message request handler, which, when executed by a processor, implements the relevant steps of any embodiment of the message request processing method described above.
[0151] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0152] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0153] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0154] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0155] It should be noted that any reference signs placed between parentheses in the claims should not be construed as limiting the claims. The word "comprising" does not exclude the presence of components or steps not listed in the claims. The word "a" or "an" preceding a component does not exclude the presence of a plurality of such components. This application can be implemented by means of hardware comprising several different components and by means of a suitably programmed computer. In a unit claim enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names.
[0156] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.
[0157] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.
Claims
1. A message request processing method, characterized in that, The message request processing method is applied to a message request processing system and includes: Upon receiving a message request, the message type of the message request is determined. In the four steps of powering on the set-top box, a corresponding message request is sent for each step. Based on the message type, the business process corresponding to the message request is determined. The business process corresponds to one of the four steps a, b, c, and d during startup, and the business stage is the corresponding four steps of startup. Based on the different business stages of the business process, the message requests are added to the corresponding message queues. Message requests from later business stages are added to message queues with higher processing priority. The step of adding the message requests to the corresponding message queues based on the different business stages of the business process includes: if the business stage is the initial business stage, determining the priority of the message request based on a preset queuing algorithm; if the business stage is not the initial business stage, determining the preceding business process corresponding to the business process, determining the target priority of the preceding business process, determining the priority of the message request based on the target priority; and adding the message request to the corresponding message queue based on the priority. The message requests in the message queues are executed in order of their processing priority. Specifically, the processing order of the message queues is determined based on the processing priority, and the highest-priority first message queue is identified. Starting from the first message queue, all message queues are traversed according to the processing order. Message requests in lower-priority message queues are processed only after all message requests in higher-priority message queues have been processed. If a message request exists in the currently traversed message queue, it is processed in a first-in, first-out (FIFO) order based on the time the message request was added to the queue.
2. The message request processing method as described in claim 1, characterized in that, The step of adding the message request to the corresponding message queue based on the priority includes: The message request is sent to the add queue interface. When the add queue interface receives the message request, it determines the queue identifier corresponding to the priority. Add the message request to the message queue corresponding to the queue identifier.
3. The message request processing method as described in claim 2, characterized in that, The step of adding the message request to the message queue corresponding to the queue identifier includes: Determine the load value of the message queue corresponding to the queue identifier; If the load value is greater than the load threshold, a target message queue with a lower processing priority than the message queue is determined, and the message request is added to the target message queue. Otherwise, add the message request to the message queue.
4. The message request processing method as described in claim 1, characterized in that, After the step of traversing all the message queues in the processing order starting from the first message queue, the process includes: If the message request does not exist in the current message queue, then it is determined whether the message request exists in the subsequent message queue corresponding to the current message queue.
5. A message request processing system, characterized in that, The message request processing system includes: A receiving thread, upon receiving a message request, determines the message type of the message request. In this case, the set-top box sends a corresponding message request for each of the four power-on steps. Based on the message type, the receiving thread determines the corresponding business process for the message request. The business process corresponds to one of the four power-on steps (a, b, c, d), and the business stage corresponds to the four power-on steps. Depending on the business stage of the business process, the receiving thread adds the message request to the corresponding message queue. Message requests in later business stages are added to message queues with higher processing priority. The step of adding the message request to the corresponding message queue based on the business stage includes: if the business stage is the initial business stage, determining the priority of the message request based on a preset queuing algorithm; if the business stage is not the initial business stage, determining the preceding business process corresponding to the business process, determining the target priority of the preceding business process, and determining the priority of the message request based on the target priority; and adding the message request to the corresponding message queue based on the priority. A multi-priority message queue, comprising multiple message queues, each with a different processing priority; A processing thread determines the processing order of the message queues based on the processing priority, and traverses all the message queues starting from the first message queue according to the processing order; after the message requests in the message queues with higher processing priority are processed, the message queues with lower processing priority are then processed.
6. A message request processing device, characterized in that, The device includes a memory, a processor, and a message request handler stored in the memory and executable on the processor, wherein the processor, when executing the message request handler, implements the steps of the message request processing method as described in any one of claims 1 to 4.
7. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a message request handler, which, when executed by a processor, implements the steps of the message request processing method as described in any one of claims 1 to 4.