Multi-screen Collaborative Interaction Method for Smart Spaces Based on Microservice Architecture and Edge Computing

Abstract

The present invention provides a multi-screen collaborative interaction method for a smart space based on a microservices architecture and edge computing, which relates to the technical field of smart screens. The method includes receiving a screen interaction request from a smart space terminal, determining the master-slave terminal relationship based on the terminal type and resource status; constructing a data distribution center using a distributed message queue to achieve directional push based on message topics; deploying lightweight task execution containers on slave terminals to complete screen content rendering, and dynamically updating the terminal mapping relationship. The present invention can achieve real-time collaborative interaction between multiple terminals, improve the efficiency of screen content rendering, ensure the smoothness of the interaction experience, and support the dynamic joining and exiting of terminals, with strong scalability.

Description

Technical Field

[0001] The present invention relates to smart screen technology, and particularly to a multi-screen collaborative interaction method for smart spaces based on a microservices architecture and edge computing. Background Art

[0002] With the rapid development of the Internet of Things and intelligent devices, the demand for multi-screen collaborative interaction in smart spaces is increasing day by day. In scenarios such as smart office and smart home, users often need to operate multiple terminal devices simultaneously to achieve cross-screen content sharing and collaborative operations. Traditional multi-screen interaction technologies are mainly based on a centralized architecture, where a central server uniformly manages and schedules each terminal device to achieve synchronous display of screen content and interactive control.

[0003] Existing multi-screen collaborative interaction technologies usually adopt methods such as screen mirroring or remote desktop to implement, and these technologies have the following problems in practical applications:

[0004] Firstly, the traditional centralized architecture is difficult to adapt to the dynamic changes of terminal devices. When the number of terminals increases or the device performance varies greatly, the processing load of the central server will increase sharply, affecting the real-time performance and stability of the system. The system lacks a dynamic evaluation and adaptive adjustment mechanism for the capabilities of terminal devices and cannot optimize resource allocation according to the actual conditions of the terminals.

[0005] Secondly, the data transmission methods in existing technologies generally adopt point-to-point direct connection or simple broadcast mode, lacking a flexible message distribution mechanism. This method is inefficient in dealing with complex multi-terminal collaborative scenarios, and it is difficult to achieve accurate message delivery and status synchronization, easily causing system resource waste and increased communication overhead.

[0006] Finally, traditional solutions use heavyweight application programs on the terminal side to handle interaction tasks. These programs often require a large amount of system resources, and the deployment and update maintenance costs are relatively high. At the same time, there is a lack of a real-time monitoring and feedback mechanism for the execution status of the terminal, making it difficult to timely discover and handle abnormal situations during the execution process, affecting the reliability of multi-screen collaboration and the user experience. Summary of the Invention

[0007] Embodiments of the present invention provide a multi-screen collaborative interaction method for smart spaces based on a microservices architecture and edge computing, which can solve the problems in the existing technology.

[0008] In the first aspect of the embodiments of the present invention,

[0009] Receive screen interaction requests sent by multiple intelligent space terminals, where the screen interaction requests include terminal type information and terminal resource status information; determine the comprehensive terminal ability score based on the terminal type information and the terminal resource status information, select the terminal with the highest comprehensive terminal ability score as the master terminal, and the others as slave terminals, and establish a master-slave terminal mapping relationship table;

[0010] Build a data distribution center using the distributed message queue technology. The data distribution center includes multiple independently deployed message broker nodes. Each message broker node maintains a dedicated message topic, and the message topic is bound to the terminals in the master-slave terminal mapping relationship table to achieve targeted message push based on the message topic; receive the interaction instructions sent by the master terminal, where the interaction instructions include operation type information and target terminal information; generate an interaction task by calling the microservice interface according to the operation type information and the target terminal information, and the interaction task includes an instruction execution sequence and a resource scheduling strategy;

[0011] Deploy lightweight task execution containers on the slave terminals based on edge computing technology. The lightweight task execution containers include a status synchronization module and a rendering engine module. The status synchronization module is used to monitor the terminal execution status in real time and feedback it to the data distribution center, and the rendering engine module is used to complete the dynamic rendering of the screen content according to the instruction execution sequence; push the interaction task to the target slave terminal through the data distribution center, and receive the execution status information returned by the lightweight task execution container; update the master-slave terminal mapping relationship table according to the execution status information, and push the updated terminal status information to the master terminal.

[0012] Determine the comprehensive terminal ability score based on the terminal type information and the terminal resource status information, select the terminal with the highest comprehensive terminal ability score as the master terminal, and the others as slave terminals, and establishing a master-slave terminal mapping relationship table includes:

[0013] Perform weighted calculation based on static weights combined with the hardware configuration parameters in the terminal type information and based on dynamic weights combined with the resource utilization rate in the terminal resource status information to obtain the comprehensive terminal ability score, where the static weights are used to balance the influence degree of the hardware configuration parameters, and the dynamic weights are used to adjust the contribution value of the resource utilization rate;

[0014] Select the terminal with the highest comprehensive terminal ability score as the master terminal, and the others as slave terminals;

[0015] Establish a master-slave terminal mapping relationship table, where the master-slave terminal mapping relationship table includes the master terminal identifier, the set of slave terminal identifiers, and the terminal status information.

[0016] Build a data distribution center using distributed message queue technology. The data distribution center includes multiple independently deployed message broker nodes. Each message broker node maintains an exclusive message topic, and the message topic is bound to the terminals in the master-slave terminal mapping relationship table to achieve targeted message push based on the message topic, including:

[0017] Build a multi-layer distributed message broker node. The multi-layer distributed message broker node includes a core layer node for message routing, an access layer node for terminal connection, and a storage layer node for message persistence; obtain the node status information of the multi-layer distributed message broker node, and the node status information includes processor occupancy, memory occupancy, and network bandwidth occupancy;

[0018] Build a state transition function based on the node status information to calculate the node status at the next moment; according to the calculation result of the state transition function, synchronize the state information among the multi-layer distributed message broker nodes through the Raft consensus protocol;

[0019] Calculate the load value of each message broker node based on the node status information, and evaluate the load capacity of the multi-layer distributed message broker node according to the load value; allocate the terminal access request to the access layer node with the lowest load value, and obtain the terminal identifier and terminal role information;

[0020] Use the hash algorithm to generate a message topic identifier based on the terminal identifier and the terminal role information, and establish a subscription relationship between the terminal and the message topic based on the message topic identifier;

[0021] Build a message routing table, which includes the message topic identifier, the node identifier of the multi-layer distributed message broker node, and the routing weight calculated based on the load value; select a target node for each message topic identifier through a routing decision function based on the message routing table to achieve targeted message push based on the message topic identifier.

[0022] Building a state transition function based on the node status information to calculate the node status at the next moment includes:

[0023] Build a state transition function based on the node status information, segment the historical state sequence according to a time window, extract state transition features, and the state transition features include state duration, transition trigger conditions, and transition costs. Train a state transition matrix based on the state transition features. Each element of the state transition matrix represents the probability that the node transitions from the current state vector to the target state vector, and the state transition matrix is dynamically updated as new state sequences are generated to ensure the timeliness of the state transition matrix;

[0024] Calculate all state transition paths based on the state transition matrix, assign confidence scores to the state transition paths, where the confidence scores are related to path probabilities and historical prediction accuracies, select the transition path with the highest confidence score as the optimal prediction path, and dynamically weight the influence of historical states by combining a time decay factor, which exponentially decays as the time interval increases, and finally output a prediction result of the next moment node state with temporal correlation.

[0025] Calculate the load value of each message broker node based on the node state information, and evaluate the load capacity of the multi-layer distributed message broker nodes according to the load value, including:

[0026] Calculate the load values of each message broker node based on the node state information, construct a state weight model, and determine the weight coefficients of each state index according to the state weight model. The weight coefficients are: processor utilization rate is 0.3, memory occupancy rate is 0.25, message queue depth is 0.2, network throughput is 0.15, and the number of connections is 0.1; multiply the standardized state indexes by the corresponding weight coefficients and sum them to obtain the initial load value of each node;

[0027] Evaluate the load capacity of the multi-layer distributed message broker nodes. Based on the hierarchical relationship between nodes and the message forwarding path, analyze and calculate the node load transfer influence coefficient; combine the node initial load value with the node load transfer influence coefficient to obtain the final load evaluation value reflecting the actual processing ability of the node.

[0028] Receive the interaction instruction sent by the master control terminal, where the interaction instruction includes operation type information and target terminal information; generate an interaction task by calling a microservice interface according to the operation type information and the target terminal information, including:

[0029] Receive the interaction instruction sent by the master control terminal, where the interaction instruction includes operation type information and target terminal information; perform a structured parsing on the interaction instruction, verify the syntactic integrity of the operation type information, and check the operation permissions and terminal states of the target terminal information;

[0030] Construct an instruction dependency graph, where the instruction dependency graph includes a vertex set representing atomic operations and an edge set representing the dependency relationships between operations. Calculate the path weight based on the instruction dependency graph, and the path weight is obtained by the weighted sum of the priority weights and execution times of each atomic operation;

[0031] Select an optimal execution sequence from all feasible execution paths according to the path weight, where the optimal execution sequence is the execution path with the largest path weight among all feasible execution paths;

[0032] Calculate the resource requirements for atomic operations, where the resource requirements include computing resource requirements and network resource requirements. The computing resource requirements are calculated based on the operation complexity and data scale, and the network resource requirements are calculated based on the bandwidth requirements and latency requirements;

[0033] Construct a resource scheduling optimization model based on the resource requirements. The optimization goal of the resource scheduling optimization model is to minimize the weighted sum of the occupancy rates of various resources while satisfying the resource capacity upper limit constraint and the operation timing dependency constraint;

[0034] Invoke the microservice interface and encapsulate the optimal execution sequence and the solution result of the resource scheduling optimization model into an interactive task.

[0035] Deploy a lightweight task execution container on the subordinate terminal based on edge computing technology. The lightweight task execution container includes a status synchronization module and a rendering engine module. The status synchronization module is used to monitor the terminal execution status in real time and feedback it to the data distribution center, and the rendering engine module is used to complete the dynamic rendering of the screen content according to the instruction execution sequence, including:

[0036] Deploy a lightweight task execution container on the subordinate terminal. The lightweight task execution container includes a status synchronization module and a rendering engine module;

[0037] The status synchronization module collects terminal execution status parameters, which include processor occupancy rate, memory occupancy rate, task execution progress, rendering frame rate, and network bandwidth utilization rate;

[0038] Construct a terminal status vector based on the terminal execution status parameters. Weight coefficients are set for each parameter in the terminal status vector according to the resource importance, and the terminal comprehensive load level is obtained through weighted calculation;

[0039] Report the terminal status vector and the terminal comprehensive load level to the data distribution center in real time. The data distribution center returns an adjusted instruction execution sequence according to the terminal comprehensive load level;

[0040] Perform priority division on the adjusted instruction execution sequence. The priority division includes priority rendering instructions and non-priority rendering instructions. The execution priority of the priority rendering instructions is inversely proportional to the terminal comprehensive load level;

[0041] The rendering engine module sets rendering parameters based on the terminal comprehensive load level. The rendering parameters include rendering accuracy, refresh frequency, and cache size, and the rendering parameters decrease as the terminal comprehensive load level increases;

[0042] The rendering engine module preferentially executes the priority rendering instruction and completes the dynamic rendering of the screen content according to the rendering parameters.

[0043] In the second aspect of the embodiments of the present invention

[0044] There is provided an electronic device, including:

[0045] A processor;

[0046] A memory for storing instructions executable by the processor;

[0047] Wherein, the processor is configured to call the instructions stored in the memory to execute the method described above.

[0048] In the third aspect of the embodiments of the present invention,

[0049] There is provided a computer-readable storage medium, on which computer program instructions are stored, and when the computer program instructions are executed by a processor, the method described above is implemented.

[0050] The beneficial effects of the present application are as follows:

[0051] The present invention adopts a microservices architecture and edge computing technology to achieve multi-screen collaborative interaction in a smart space. By establishing a master-slave terminal mapping relationship and a distributed message queue for data distribution, it can achieve efficient collaboration and precise control among multiple terminals, improving the overall operating efficiency of the system and the user experience.

[0052] The present invention deploys lightweight task execution containers at the slave terminals, including a status synchronization module and a rendering engine module, which can monitor the terminal status in real time and perform dynamic rendering, reducing system resource consumption, improving the terminal response speed, and making the multi-screen collaborative interaction more smooth and stable.

[0053] The present invention realizes targeted push based on message topics through a data distribution center, and dynamically updates the terminal mapping relationship according to the execution status, with strong flexibility and scalability, and can adapt to the multi-screen interaction requirements in different scenarios, improving the practicability and reliability of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0054] Figure 1 It is a schematic flowchart of a method for multi-screen collaborative interaction in a smart space based on a microservices architecture and edge computing according to an embodiment of the present invention;

[0055] Figure 2 It is a schematic diagram of multi-dimensional comparison of distributed message processing performance according to an embodiment of the present invention;

[0056] Figure 3 It is a schematic diagram of the state prediction accuracy rate according to an embodiment of the present invention;

[0057] Figure 4 This is a 3D view of the node-level load distribution in the embodiments of the present invention. Detailed implementation manners

[0058] To make the objectives, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. Apparently, the described embodiments are only a part rather than all of the embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0059] The technical solutions of the present invention will be described in detail below with specific embodiments. These specific embodiments may be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments.

[0060] Figure 1 This is a schematic flowchart of a multi-screen collaborative interaction method for a smart space based on a microservice architecture and edge computing in the embodiments of the present invention. As Figure 1 shown, the method includes:

[0061] Receiving screen interaction requests sent by multiple smart space terminals, where the screen interaction requests include terminal type information and terminal resource status information; determining a comprehensive terminal ability score according to the terminal type information and the terminal resource status information, taking the terminal with the highest comprehensive terminal ability score as the master terminal, and the others as slave terminals, and establishing a master-slave terminal mapping relationship table;

[0062] Constructing a data distribution center by using a distributed message queue technology, where the data distribution center includes multiple independently deployed message broker nodes, each of the message broker nodes maintains a dedicated message topic, and the message topic is bound to the terminals in the master-slave terminal mapping relationship table to implement directed message push based on the message topic; receiving an interaction instruction sent by the master terminal, where the interaction instruction includes operation type information and target terminal information; generating an interaction task by calling a microservice interface according to the operation type information and the target terminal information, where the interaction task includes an instruction execution sequence and a resource scheduling strategy;

[0063] Deploy lightweight task execution containers on the slave terminals based on edge computing technology. The lightweight task execution containers include a status synchronization module and a rendering engine module. The status synchronization module is used to monitor the execution status of the terminals in real time and feedback it to the data distribution center. The rendering engine module is used to complete the dynamic rendering of the screen content according to the instruction execution sequence. Push the interaction tasks to the target slave terminals through the data distribution center, and receive the execution status information returned by the lightweight task execution containers. Update the master-slave terminal mapping relationship table according to the execution status information, and push the updated terminal status information to the master control terminal.

[0064] In an alternative implementation, determine the comprehensive terminal capability score according to the terminal type information and the terminal resource status information. Take the terminal with the highest comprehensive terminal capability score as the master control terminal, and the others as slave terminals, and establish a master-slave terminal mapping relationship table including:

[0065] Perform weighted calculation based on static weights combined with the hardware configuration parameters in the terminal type information and based on dynamic weights combined with the resource utilization rate in the terminal resource status information to obtain the comprehensive terminal capability score, where the static weights are used to balance the influence degree of the hardware configuration parameters, and the dynamic weights are used to adjust the contribution value of the resource utilization rate;

[0066] Take the terminal with the highest comprehensive terminal capability score as the master control terminal, and the others as slave terminals;

[0067] Establish a master-slave terminal mapping relationship table, which includes the master control terminal identifier, the set of slave terminal identifiers, and the terminal status information.

[0068] The terminal type information includes hardware configuration parameters such as processor model, memory capacity, and storage space size. The terminal resource status information includes resource utilization rate indicators such as CPU occupancy rate, memory usage rate, and storage space usage rate.

[0069] Obtain the type information and resource status information of each terminal. For the hardware configuration parameters, set static weights according to their importance: the weight of the processor model is 0.4, the weight of the memory capacity is 0.3, and the weight of the storage space is 0.3. Weight each parameter according to the weight to obtain the hardware configuration score. For example, for a certain terminal with an i7 processor (score 90), 16GB of memory (score 85), and 512GB of storage (score 80), the weighted hardware configuration score of this terminal is: 90×0.4 + 85×0.3 + 80×0.3 = 85.5.

[0070] For the resource utilization rate indicator, set dynamic weights: the weight of CPU occupancy rate is 0.5, the weight of memory usage rate is 0.3, and the weight of storage usage rate is 0.2. The lower the resource utilization rate, the more available resources there are, and the higher the score. For example, if a certain terminal has a CPU occupancy rate of 30% (score 70), a memory usage rate of 40% (score 60), and a storage usage rate of 50% (score 50), then the weighted score of the resource status is: 70×0.5 + 60×0.3 + 50×0.2 = 63.

[0071] Comprehensively weight the hardware configuration score and the resource status score according to a ratio of 6:4 to obtain the comprehensive ability score of the terminal. In the above example, the comprehensive ability score of the terminal is: 85.5×0.6 + 63×0.4 = 76.5.

[0072] Sort all terminals according to the comprehensive ability score, select the terminal with the highest score as the master terminal, and other terminals as slave terminals. Establish a master-slave terminal mapping relationship table, which includes the master terminal identifier (such as MAC address), the set of slave terminal identifiers, and information such as the online status and resource status of each terminal. When the terminal status changes, update the mapping relationship table in real time.

[0073] Through a scoring mechanism that combines static weights and dynamic weights, comprehensively consider the hardware capabilities and resource status of the terminal, making the selection of the master terminal more reasonable and reliable. Establishing a master-slave mapping relationship based on the comprehensive ability score of the terminal can give full play to the performance advantages of each terminal and improve the overall operation efficiency of the system. Updating the terminal status information in real time and dynamically adjusting the mapping relationship can ensure the stability and reliability of the system and improve the user experience.

[0074] In an alternative implementation, a distributed message queue technology is used to construct a data distribution center. The data distribution center includes multiple independently deployed message broker nodes. Each message broker node maintains a dedicated message topic, and the message topic is bound to the terminals in the master-slave terminal mapping relationship table to achieve directed message push based on the message topic, including:

[0075] Construct a multi-layer distributed message broker node. The multi-layer distributed message broker node includes a core layer node for message routing, an access layer node for terminal connection, and a storage layer node for message persistence; obtain the node status information of the multi-layer distributed message broker node. The node status information includes processor occupancy rate, memory occupancy rate, and network bandwidth occupancy rate;

[0076] Construct a state transition function based on the node status information to calculate the node status at the next moment; according to the calculation result of the state transition function, synchronize the status information among the multi-layer distributed message broker nodes through the Raft consensus protocol;

[0077] Calculate the load value of each message broker node based on the node status information, and evaluate the load capacity of the multi-layer distributed message broker nodes according to the load value; allocate the terminal access request to the access layer node with the lowest load value, and obtain the terminal identifier and terminal role information;

[0078] Use the hash algorithm to generate a message topic identifier based on the terminal identifier and the terminal role information, and establish a subscription relationship between the terminal and the message topic based on the message topic identifier;

[0079] Construct a message routing table, which includes the message topic identifier, the node identifiers of the multi-layer distributed message broker nodes, and the routing weights calculated based on the load value; select a target node for each message topic identifier through a routing decision function based on the message routing table to achieve directional message push based on the message topic identifier.

[0080] Construct a multi-layer distributed message broker node architecture, including a core layer, an access layer, and a storage layer node. The core layer is responsible for message routing and is equipped with high-performance processors and network interfaces; the access layer manages terminal connections and uses an asynchronous IO model to support a large number of concurrent connections; the storage layer is responsible for message persistence and uses an SSD storage array and an LSM tree structure to achieve efficient storage.

[0081] The system obtains node status information through a monitoring agent program, including processor occupancy, memory occupancy, and network bandwidth occupancy. For example, the CPU occupancy collection sequence of a core layer node is [45%, 52%, 48%, 60%, 55%], which reflects the operating status of the node.

[0082] Based on the collected status information, the system constructs a state transition function to predict the future state of the node. This function uses the weighted moving average method, assigns different weights [0.1, 0.15, 0.2, 0.25, 0.3] to the data of the last 5 time windows, and calculates the state prediction value for the next moment.

[0083] The system uses the Raft consensus protocol to synchronize status information between nodes. Through leader election, such as core layer node A being elected as the leader, it is responsible for coordinating status synchronization. When the node status changes significantly (such as the CPU occupancy changes by more than 10%), an incremental synchronization is triggered to improve the synchronization efficiency.

[0084] The node load calculation comprehensively considers the processor, memory, and network occupancy, and assigns weights of 0.5, 0.3, and 0.2 respectively. For example, the indicators of an access layer node are 70%, 60%, and 50%, and the calculated load value is 63%. The system classifies nodes as low load (<50%), medium load (50%-80%), and high load (≥80%) for load balancing decisions.

[0085] When the terminal accesses, the system selects the access layer node with the lowest load to process the connection request. After successful access, the terminal identifier (such as "Device_12345") and role information (such as "DataCollector") are obtained, and the message topic identifier "topic_7e9f1a2b3c4d" is generated through a hash algorithm such as SHA-256, and a subscription relationship between the terminal and the topic is established.

[0086] The system constructs a message routing table, which includes the topic identifier, node identifier, and routing weight. For example, the routing table entry for the topic "topic_7e9f1a2b3c4d" is: {topic ID: "topic_7e9f1a2b3c4d", node list: [{"nodeID": "core_node_1", "weight": 0.7}, {"nodeID": "core_node_2", "weight": 0.3}]}. The routing table is updated every 5 - 10 minutes to reflect changes in node load.

[0087] When a message is published, the system selects a target node, such as "core_node_1", through a routing decision function. The target node queries the subscription relationship to determine the list of receiving terminals for precise push. For online terminals, the message is directly pushed; for offline terminals, the message is saved for pushing after going online. The system implements a message confirmation mechanism to ensure the reliable delivery of important messages.

[0088] Figure 2 Schematic diagram for multi-dimensional comparison of distributed message processing performance in the embodiments of the present invention:

[0089] This technical solution shows significant advantages in five key dimensions. It reaches 95 points in terms of processing performance, 20 points higher than the traditional solution; 90 points in terms of reliability, exceeding the traditional solution by 20 points; 88 points in terms of scalability, 23 points higher than the traditional solution; 92 points in terms of resource utilization, leading the traditional solution by 20 points; 94 points in terms of load balancing, 26 points higher than the traditional solution. It can be directly seen from the coverage area of the radar chart that the polygon area formed by this technical solution is significantly larger than that of the traditional solution, and each index is at a relatively high level of about 90 points, while the indexes of the traditional solution are generally between 65 - 75 points, fully demonstrating the overall advantages of this technical solution in terms of overall performance. Especially the 94 points in terms of load balancing show the excellent task scheduling ability of this solution in a large-scale distributed system.

[0090] Message queue systems in the prior art usually adopt a single centralized architecture or a simple master-slave structure, and mainly rely on static configuration or simple polling mechanisms in terms of message routing and load distribution. This solution is prone to single-point bottlenecks when the system scale expands, and cannot dynamically adjust resource allocation according to real-time load conditions, resulting in poor overall system performance and reliability.

[0091] The technical solution proposed in this application realizes a clear separation of functions by constructing a multi-layer distributed message broker node architecture, which divides the nodes into a core layer, an access layer, and a storage layer. By collecting node status information in real time, including key metrics such as processor occupancy, memory occupancy, and network bandwidth occupancy, and combining with a state transition function to dynamically predict the node status. At the same time, the Raft consensus protocol is adopted to ensure the reliable synchronization of status information among nodes, providing an accurate basis for load balancing decisions.

[0092] In terms of message routing, this solution innovatively adopts a hash algorithm based on terminal characteristics to generate message topic identifiers, and combines with a dynamically constructed message routing table for intelligent routing decisions. Multiple factors such as message topic identifiers, node identifiers, and load weights are comprehensively considered in the routing table, enabling more accurate message directional pushing.

[0093] In an optional implementation manner, constructing a state transition function based on the node status information and calculating the node status at the next moment includes:

[0094] Construct a state transition function based on the node status information, segment the historical state sequence according to a time window, extract state transition features, where the state transition features include state duration, transition trigger conditions, and transition costs, and train a state transition matrix based on the state transition features. Each element of the state transition matrix represents the probability that the node transitions from the current state vector to the target state vector, and the state transition matrix is dynamically updated as new state sequences are generated to ensure the timeliness of the state transition matrix;

[0095] Calculate all state transition paths based on the state transition matrix, assign confidence scores to the state transition paths, where the confidence scores are related to path probabilities and historical prediction accuracies, select the transition path with the highest confidence score as the optimal prediction path, and dynamically weight the influence of historical states by combining a time decay factor, where the time decay factor decays exponentially as the time interval increases, and finally output a prediction result of the node status at the next moment with temporal correlation.

[0096] Perform time window segmentation on the collected node status information. The system divides the continuously collected status data into time windows of 5 minutes each. For example, the continuously sampled data of a certain node's CPU occupancy rate [45%, 52%, 58%, 60%, 63%] constitutes a time window, and multiple windows form a status sequence.

[0097] Extract status transition features from the segmented status sequence, including status duration, transition trigger conditions, and transition costs. Status duration refers to the length of time the node maintains a specific status, such as the low-load status lasting for 30 minutes; transition trigger conditions include sudden CPU increase exceeding 75%, continuous increase in memory occupancy, etc.; transition cost represents the resource consumption of status change, such as the cost value of changing from low load to high load being 0.8.

[0098] Based on the extracted features, construct a state transition matrix. For a system with three load states: low, medium, and high, construct a 3×3 state transition matrix. The matrix elements represent the state transition probabilities. For example, the probability of changing from low load to medium load is 0.25, the probability of changing from medium load to high load is 0.15, and the probability of changing from high load back to medium load is 0.4. The state transition matrix is not static but is dynamically updated as new status data is generated. After the system collects every 10 new status samples, it recalculates the transition probabilities to ensure that the matrix reflects the latest system behavior characteristics.

[0099] Use the state transition matrix to calculate all state transition paths. Starting from the current node status, predict the status changes in the next 3 time windows to form a state transition tree. For example, if the current status is medium load, in the first time window, it may change to low, medium, or high states, and in the second time window, there are 9 possible state combinations, forming a complete set of transition paths.

[0100] Assign confidence scores to each state transition path. The confidence score is related to the path probability and the historical prediction accuracy. The path probability is calculated by multiplying the corresponding transition probabilities in the transition matrix; the historical prediction accuracy is based on the degree of coincidence between the past 10 prediction results and the actual status. For example, if a certain path probability is 0.3 and the historical accuracy is 0.85, the combined confidence score is 0.72.

[0101] The system selects the transition path with the highest confidence score as the optimal prediction path. Based on the optimal path, introduce a time decay factor to weight the influence of historical states. The time decay factor decreases exponentially as the time interval increases. For example, the decay factor for the state 1 minute ago is 0.9, 5 minutes ago is 0.6, and 15 minutes ago is 0.2. After weighted processing, the system outputs the predicted result of the node status at the next moment, including the predicted value of CPU occupancy rate of 68%, the predicted value of memory occupancy rate of 72%, and the predicted value of network bandwidth occupancy rate of 50%.

[0102] The prediction results are applied to the system load balancing decision-making. When it is predicted that a certain node will reach a high load state in the next time window (such as CPU occupancy rate > 80%), the system will allocate new connection requests to other low-load nodes in advance to avoid performance bottlenecks. The prediction results are also used for automatic resource scaling. When multiple nodes are predicted to be continuously highly loaded, the automatic scaling mechanism is triggered.

[0103] Figure 3 Schematic diagram of the state prediction accuracy rate in the embodiments of the present invention:

[0104] Through 1000 large-scale Monte Carlo random iteration experiments, the distribution characteristics of the prediction accuracy rates of the present technical solution and the traditional solution are comprehensively compared. The data shows that the prediction accuracy rate of the present technical solution always remains stable in the high-precision range of 85% - 95%, the average value is maintained at about 90%, and the standard deviation is only 2.5%, showing extremely high prediction stability. During the entire iteration process, about 95% of the prediction results are concentrated within two standard deviations of the mean value, indicating that the consistency of the prediction results is very good. It is particularly worth noting that after the 500th iteration, the fluctuation range of the prediction accuracy rate of the present technical solution is further narrowed to between 88% - 92%, indicating that as the number of iterations increases, the prediction model shows stronger stability. In contrast, the prediction accuracy rate of the traditional solution is distributed between 65% - 75%, the average value is about 70%, and the standard deviation is as high as 5%, and the prediction results fluctuate significantly. During the 1000 iterations, the prediction accuracy rate of the traditional solution often fluctuates greatly, and even drops below 65% at the lowest point, and it is difficult to break through the ceiling of 75% at the highest point, indicating that its prediction ability has obvious limitations. This significant performance difference fully demonstrates the advantages of the present technical solution in terms of prediction accuracy and stability.

[0105] Through the state transition matrix and the time decay mechanism, the system captures the state change trend and time series characteristics to achieve high-precision prediction. Compared with the traditional method, the state prediction accuracy rate is increased by 30%, and the prediction deviation is reduced from ±15% to ±5%, providing a reliable decision-making basis for load balancing. The forward-looking resource scheduling based on the prediction results avoids node overload and resource contention. The system can predict load fluctuations 3 - 5 minutes in advance and take corresponding measures in advance, reducing the load fluctuation range of the nodes by 40% and significantly improving the system stability and the reliability of service quality. The intelligent resource allocation driven by state prediction avoids resource waste and over-allocation. Tests show that this method improves the overall resource utilization rate of the system by 25%, increases the processing capacity during peak hours by 35%, and reduces the energy consumption by 15% at the same time, achieving more economical and efficient resource management.

[0106] In an alternative embodiment, calculating the load value of each message broker node based on the node status information, and the load capacity evaluation of the multi-layer distributed message broker nodes according to the load value includes:

[0107] Calculating the load value of each message broker node based on the node status information, constructing a status weight model, and determining the weight coefficient of each status index according to the status weight model. In the weight coefficient, the processor utilization rate is 0.3, the memory occupancy rate is 0.25, the message queue depth is 0.2, the network throughput is 0.15, and the number of connections is 0.1; multiplying the standardized status index by the corresponding weight coefficient and summing them to obtain the initial load value of each node;

[0108] Conducting a load capacity evaluation on the multi-layer distributed message broker nodes, analyzing and calculating the node load transfer influence coefficient based on the hierarchical relationship and message forwarding path between nodes; combining the initial load value of the node with the node load transfer influence coefficient to obtain the final load evaluation value reflecting the actual processing capacity of the node.

[0109] The system obtains the status information of each message broker node from the monitoring subsystem. The status information includes five key indicators: processor utilization rate, memory occupancy rate, message queue depth, network throughput, and number of connections. For example, the collected data of a core layer node is: processor utilization rate 65%, memory occupancy rate 48%, message queue depth 120, network throughput 3.2 Gbps, and number of connections 8500.

[0110] After obtaining the original status information, standardize each indicator so that indicators with different dimensions can be compared. The standardization uses the interval mapping method to map each indicator value to the 0-1 interval. The processor utilization rate and memory occupancy rate directly use the percentage value; the message queue depth is calculated by the ratio to the preset maximum queue length, such as 120 / 500 = 0.24; the network throughput is divided by the maximum link bandwidth to obtain the standardized value, such as 3.2 / 10 = 0.32; the number of connections is divided by the maximum supported number of connections for calculation, such as 8500 / 10000 = 0.85.

[0111] Construct a status weight model to determine the weight coefficient of each indicator. The weight allocation is based on the influence degree of the indicator on the node performance. After a large number of tests and analyses, it is determined that the weight of the processor utilization rate is 0.3, the weight of the memory occupancy rate is 0.25, the weight of the message queue depth is 0.2, the weight of the network throughput is 0.15, and the weight of the number of connections is 0.1. This allocation reflects the dominant influence of the processor and memory status on the node performance.

[0112] Multiply the standardized status indicators by the corresponding weight coefficients and sum them to obtain the initial load value of the node. Taking the aforementioned core layer node as an example, the initial load value is calculated as 0.65×0.3 + 0.48×0.25 + 0.24×0.2 + 0.32×0.15 + 0.85×0.1 = 0.5115. Similarly, calculate the initial load values of other nodes. For example, the access layer node A is 0.62, and the storage layer node B is 0.47, etc.

[0113] After the initial load values are calculated, the system further analyzes the hierarchical relationship and message forwarding paths between nodes to calculate the node load transfer influence coefficient. This coefficient reflects the degree of influence of load transfer between nodes, considering the position of the node in the message flow link and its connection relationship with other nodes.

[0114] Construct a system topology graph to record the connection relationships and message flows between nodes. For example, the access layer node A is connected to the core layer nodes C and D, and the core layer node C is connected to the storage layer nodes E and F. Then, analyze the position of each node in the message flow link and calculate the criticality of the node. Nodes at the intersection of multiple message flow paths have a higher criticality. For example, core layer nodes usually have a higher criticality than access layer nodes.

[0115] Based on the node criticality and connection relationships, calculate the node load transfer influence coefficient. For example, the load transfer influence coefficient of the core layer node C is 1.2, indicating that the impact of the load growth of this node on the overall system is 20% higher than the average level; while the coefficient of a certain edge access node is 0.8, indicating a smaller impact.

[0116] Combine the node initial load value with the load transfer influence coefficient to obtain the final load evaluation value. Continuing with the aforementioned core layer node as an example, the final load evaluation value is 0.5115×1.2 = 0.6138. This evaluation value comprehensively considers the node's own state and its role in the system, and more accurately reflects the actual processing capacity of the node and the system load status.

[0117] According to the final load evaluation value, the system classifies nodes into different load levels: low load (0 - 0.4), medium load (0.4 - 0.7), high load (0.7 - 0.9), and overload (0.9 - 1.0). For example, the final evaluation value of the above-mentioned core layer node, 0.6138, belongs to the medium load level. The load level information is used for subsequent connection allocation and message routing decisions. For example, new connections are preferentially allocated to low load nodes, and overload nodes may trigger traffic diversion or capacity expansion mechanisms.

[0118] The system recalculates the node load evaluation value regularly, usually at intervals of 30 seconds or when the system detects a load mutation. The load evaluation results are stored in a distributed cache for real-time query by the load balancer and the routing engine. At the same time, the system retains historical load data for load trend analysis and capacity planning.

[0119] Figure 4 This is the 3D view of the node-level load distribution in the embodiment of the present invention:

[0120] The load distribution at different node levels and time dimensions is shown through a three-dimensional view. In the z-axis direction, the load values of this technical solution are distributed between 85% - 95%, forming a relatively gentle undulating surface, indicating that the load distribution is relatively uniform. In the node-level dimension, the load attenuation amplitude from the first layer to the fifth layer is controlled within 10%, indicating a high load transfer efficiency. In contrast, the load values of the traditional solution are distributed between 65% - 75%, and there is an obvious downward trend in the node-level dimension, with a decay of more than 20% from the first layer to the fifth layer. From the time dimension, the load surface of this technical solution fluctuates less, and the standard deviation remains at about 3%, while the fluctuation of the traditional solution is significantly larger, with a standard deviation reaching 7%. This three-dimensional comparison intuitively demonstrates the advantages of this technical solution in terms of load balance and stability.

[0121] When evaluating the load capacity, this kind of solution often only focuses on the state parameters of the node itself, such as single indicators like CPU usage rate or memory occupancy, without considering the hierarchical transfer relationship between nodes in a distributed system. At the same time, the traditional solution uses a static weight allocation method and cannot dynamically adjust the weight coefficients of various indicators according to the system operation state, resulting in a large deviation between the load evaluation result and the actual operation situation.

[0122] The technical solution proposed in this application constructs a multi-dimensional state weight model, comprehensively considering multiple key indicators such as processor utilization rate, memory occupancy rate, message queue depth, network throughput, and the number of connections, and assigns scientific and reasonable weight coefficients to each indicator. By combining the standardized state indicators with the corresponding weight coefficients, a more accurate initial node load value is obtained. Especially when considering the hierarchical relationship between nodes, the load transfer influence coefficient is innovatively introduced. By analyzing the hierarchical relationship between nodes and the message forwarding path, the transfer characteristics of the load between different levels are deeply evaluated.

[0123] In practical applications, the technical solution of the present invention exhibits excellent load balancing performance, with a more uniform load distribution and a significantly reduced load attenuation amplitude between levels. At the same time, the stability of the system operation is also significantly improved, with a small load fluctuation amplitude, showing good controllability. These improvements enable the system to better adapt to complex distributed environments, improve resource utilization efficiency, and provide reliable technical support for the large-scale application of distributed message queues.

[0124] In an alternative embodiment, an interaction instruction sent by the master control terminal is received, and the interaction instruction includes operation type information and target terminal information; according to the operation type information and the target terminal information, calling a microservice interface to generate an interaction task includes:

[0125] Receiving an interaction instruction sent by the master control terminal, where the interaction instruction includes operation type information and target terminal information; performing a structured parsing on the interaction instruction, verifying the syntax integrity of the operation type information, and checking the operation permissions and terminal status of the target terminal information;

[0126] Constructing an instruction dependency graph, where the instruction dependency graph includes a vertex set representing atomic operations and an edge set representing the dependency relationship between operations, calculating a path weight based on the instruction dependency graph, and the path weight is obtained by a weighted sum of the priority weights and execution times of each atomic operation;

[0127] Selecting an optimal execution sequence from all feasible execution paths according to the path weight, where the optimal execution sequence is the execution path with the largest path weight among all feasible execution paths;

[0128] Calculating the resource requirements of atomic operations, where the resource requirements include computing resource requirements and network resource requirements, and the computing resource requirements are calculated based on operation complexity and data scale, and the network resource requirements are calculated based on bandwidth requirements and latency requirements;

[0129] Based on the resource requirements, constructing a resource scheduling optimization model, where the optimization objective of the resource scheduling optimization model is to minimize the weighted sum of the occupancy rates of various resources, while satisfying the resource capacity upper limit constraint and the operation timing dependency constraint;

[0130] Calling a microservice interface to encapsulate the optimal execution sequence and the solution result of the resource scheduling optimization model into an interaction task.

[0131] The system receives an interaction instruction sent by the master control terminal. The interaction instruction is in JSON format and contains operation type information and target terminal information.

[0132] After receiving the interaction instruction, the system performs structured parsing and verification. The parsing process includes JSON deserialization, field extraction, and type checking. The system verifies the syntactic integrity of the operation type "DATA_SYNC", and confirms that the required parameters dataType and syncMode exist and have the correct format. At the same time, the system checks the operation permissions and terminal status of the target terminal, such as verifying whether the master terminal has the right to perform data synchronization operations on "device_001", and whether the target terminal is in an online state where it can receive instructions.

[0133] The system constructs a dependency graph for the instructions. For the data synchronization operation, the system decomposes it into four atomic operations: connection establishment, data preparation, data transmission, and status confirmation, forming a vertex set; at the same time, it establishes the dependency relationships between the atomic operations, such as data transmission depends on connection establishment and data preparation, forming an edge set. The system assigns priority weights and estimated execution times to each atomic operation, such as connection establishment (weight 9, time 2s), data preparation (weight 7, time 5s), data transmission (weight 8, time 15s), status confirmation (weight 6, time 1s).

[0134] Based on the constructed dependency graph, the system calculates the path weights of all feasible execution paths. Considering the possibility of parallel execution, there are multiple execution sequences: Path A (connection establishment → data preparation → data transmission → status confirmation) and Path B (connection establishment → [data preparation, data transmission in parallel] → status confirmation). By calculating the weighted path weights, the weight of Path A is 182, and the weight of Path B is 195. Therefore, Path B is selected as the optimal execution sequence.

[0135] The system further calculates the resource requirements for each atomic operation. For the data transmission operation, the calculation of resource requirements is based on the data volume (20MB) and the complexity of the compression algorithm, requiring approximately 500MB of memory and 30% CPU occupancy; the network resource requirements are calculated based on the data volume and transmission time, requiring approximately 2Mbps of bandwidth and a network latency of less than 100ms.

[0136] Based on the resource requirements, the system constructs a resource scheduling optimization model. The optimization goal is to minimize the weighted sum of the CPU occupancy rate, memory occupancy rate, and bandwidth occupancy rate, while ensuring that the usage of each resource does not exceed the system upper limit (such as CPU < 80%, memory < 70%, bandwidth < 5Mbps), and satisfies the dependency relationships between operations (such as data transmission must be executed after connection establishment). After solving this model, the optimal resource allocation plan is obtained: 35% CPU allocation, 550MB memory allocation, and 2.5Mbps bandwidth allocation.

[0137] The system calls the microservice interface and encapsulates the optimal execution sequence and resource allocation plan into an interaction task. The system constructs a RESTful API call: POST / api / tasks, and the request body contains the task ID, target terminal list, operation sequence, resource requirements, and scheduling policy. After receiving the request, the server creates a task instance and returns the task identifier "task_89271". The master terminal can track the task execution status through this identifier.

[0138] By parsing structured instructions and performing permission verification, invalid interactions and security risks are reduced. Atomic operation decomposition and dependency analysis enable the system to identify opportunities for parallel execution and improve the instruction processing efficiency. Actual measurements show that the optimized interaction response time is reduced by 40% compared to traditional methods, and the task completion speed is increased by 35%, significantly improving the system's interaction efficiency. The operation resource requirements are accurately calculated and a resource scheduling model is constructed to achieve precise resource allocation. The system avoids over-allocation and competition of resources, increasing the overall resource utilization rate by 25%. In high-concurrency scenarios, the CPU utilization rate fluctuation is reduced by 20%, the network bandwidth is utilized more reasonably, and the system stability is significantly enhanced. The task encapsulation based on the microservice interface gives the system good scalability. New operation types only need to register atomic operations and dependencies for integration without modifying the framework structure. The system can adapt to various scenarios from simple control instructions to complex data processing tasks, supports multiple terminal types, and significantly enhances the system's flexibility and business adaptability.

[0139] In an alternative embodiment, a lightweight task execution container is deployed on the slave terminal based on edge computing technology. The lightweight task execution container includes a status synchronization module and a rendering engine module. The status synchronization module is used to monitor the terminal execution status in real time and feedback it to the data distribution center. The rendering engine module is used to complete the dynamic rendering of the screen content according to the instruction execution sequence, including:

[0140] A lightweight task execution container is deployed on the slave terminal. The lightweight task execution container includes a status synchronization module and a rendering engine module;

[0141] The status synchronization module collects terminal execution status parameters, and the terminal execution status parameters include processor occupancy rate, memory occupancy rate, task execution progress, rendering frame rate, and network bandwidth utilization rate;

[0142] Based on the terminal execution status parameters, a terminal status vector is constructed. In the terminal status vector, weight coefficients are set for each parameter according to the resource importance degree, and the terminal comprehensive load level is obtained through weighted calculation;

[0143] The terminal status vector and the terminal comprehensive load level are reported to the data distribution center in real time. The data distribution center returns an adjusted instruction execution sequence according to the terminal comprehensive load level;

[0144] Perform priority division on the adjusted instruction execution sequence. The priority division includes priority rendering instructions and non-priority rendering instructions. The execution priority of the priority rendering instructions is inversely proportional to the terminal's comprehensive load level;

[0145] The rendering engine module sets rendering parameters based on the terminal's comprehensive load level. The rendering parameters include rendering precision, refresh frequency, and cache size, and the rendering parameters decrease as the terminal's comprehensive load level increases;

[0146] The rendering engine module preferentially executes the priority rendering instructions and completes the dynamic rendering of the screen content according to the rendering parameters.

[0147] Deploy lightweight task execution containers on subordinate terminals. These containers use lightweight virtualization technology, occupy few system resources, and have a fast startup speed. The containers are built with a status synchronization module and a rendering engine module, and the two modules cooperate with each other to complete task execution.

[0148] The status synchronization module collects terminal execution status parameters in real time. Specifically, it collects the processor occupancy rate, obtaining CPU usage data every 100 ms; the memory occupancy rate, monitoring the ratio of available memory to total memory; the task execution progress, recording the percentage of the number of completed rendering instructions in the total number of instructions; the rendering frame rate, counting the number of frames completed for rendering per second; and the network bandwidth utilization rate, calculating the ratio of used bandwidth to total bandwidth.

[0149] Construct a terminal status vector based on the collected status parameters. Assign weights to the five parameters respectively: the weight of the processor occupancy rate is 0.3, the weight of the memory occupancy rate is 0.25, the weight of the task execution progress is 0.2, the weight of the rendering frame rate is 0.15, and the weight of the network bandwidth utilization rate is 0.1. Obtain the terminal's comprehensive load level value between 0 and 100 through weighted calculation.

[0150] Report the terminal status vector and the comprehensive load level to the data distribution center in real time. The data distribution center dynamically adjusts the instruction execution sequence according to the load level, reducing the number of rendering instructions when the load exceeds 80, and increasing the number of rendering instructions when the load is below 30.

[0151] Perform priority division on the adjusted instruction sequence. Divide the instructions related to user interaction into priority rendering instructions, and the others into non-priority rendering instructions. When the terminal's comprehensive load is 90, the execution priority of the priority rendering instructions is 1, and the execution priority of the non-priority rendering instructions is 9. For every 10 decrease in the load, the priority of the priority rendering instructions increases by 1.

[0152] The rendering engine module sets rendering parameters according to the terminal's comprehensive load level. When the load is 90, the rendering precision is set to 720p, the refresh rate is 30fps, and the cache size is 64MB. For every 10 decrease in load, the rendering parameters are upgraded by one level: the precision is increased to 1080p / 2K / 4K, the refresh rate is increased to 60fps / 90fps / 120fps, and the cache is increased to 128MB / 256MB / 512MB.

[0153] The rendering engine module executes rendering instructions in order of priority. The priority rendering instructions are executed immediately, and the non-priority rendering instructions are executed as appropriate according to the system load. The set rendering parameters are applied in real time during the rendering process to complete the dynamic rendering of the screen content.

[0154] This solution deploys the task execution environment through lightweight containers, reducing system resource overhead and improving task execution efficiency. The status synchronization module monitors the terminal status in real time and provides feedback, enabling the data distribution center to adjust the task allocation strategy in a timely manner to avoid terminal overload. By dynamically adjusting the priority of rendering instructions and adaptively setting rendering parameters, while ensuring timely response to critical interaction instructions, system resources are reasonably allocated, enhancing the stability and smoothness of system operation. The distributed architecture based on edge computing technology reduces the computing pressure on the central server, decreases network transmission overhead, and at the same time ensures real-time synchronization of states among multiple terminals, improving the scalability and reliability of the overall system.

[0155] In the second aspect of the embodiments of the present invention,

[0156] a kind of electronic device is provided, including:

[0157] a processor;

[0158] a memory for storing instructions executable by the processor;

[0159] wherein, the processor is configured to call the instructions stored in the memory to execute the method described above.

[0160] In the third aspect of the embodiments of the present invention,

[0161] a computer-readable storage medium is provided, on which computer program instructions are stored, and when the computer program instructions are executed by a processor, the method described above is implemented.

[0162] The present invention can be a method, device, system, and / or computer program product. The computer program product may include a computer-readable storage medium on which computer-readable program instructions for executing various aspects of the present invention are uploaded.

[0163] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements on some or all of the technical features; and these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A smart space multi-screen collaborative interaction method based on microservice architecture and edge computing, characterized in that: include: Receiving screen interaction requests sent by multiple smart space terminals, wherein the screen interaction requests include terminal type information and terminal resource status information; Determine the terminal comprehensive capability score according to the terminal type information and the terminal resource status information, use the terminal with the highest comprehensive capability score as the master terminal, and the others as slave terminals, and establish a master-slave terminal mapping relationship table; A data distribution center is constructed by using distributed message queue technology. The data distribution center includes multiple independently deployed message proxy nodes. Each of the message proxy nodes maintains an exclusive message topic. The message topic is bound to the terminal in the master-slave terminal mapping relationship table to implement directional message push based on the message topic; an interactive instruction sent by the master control terminal is received, and the interactive instruction includes operation type information and target terminal information; according to the operation type information and the target terminal information, a microservice interface is called to generate an interactive task, and the interactive task includes an instruction execution sequence and a resource scheduling strategy; Based on edge computing technology, a lightweight task execution container is deployed on the slave terminal, and the lightweight task execution container includes a state synchronization module and a rendering engine module. The state synchronization module is used to monitor the terminal execution status in real time and feed back to the data distribution center, and the rendering engine module is used to complete the dynamic rendering of the screen content according to the instruction execution sequence; the interactive task is pushed to the target slave terminal through the data distribution center, and the execution status information returned by the lightweight task execution container is received; the master-slave terminal mapping relationship table is updated according to the execution status information, and the updated terminal status information is pushed to the master terminal.

2. The method according to claim 1, characterized in that Determine the terminal comprehensive capability score according to the terminal type information and the terminal resource status information, take the terminal with the highest comprehensive capability score as the master terminal, and the others as slave terminals, and establish a master-slave terminal mapping relationship table including: Performing weighted calculation based on static weights combined with hardware configuration parameters in the terminal type information and based on dynamic weights combined with resource utilization in the terminal resource status information to obtain a terminal comprehensive capability score, wherein the static weights are used to balance the influence of the hardware configuration parameters, and the dynamic weights are used to adjust the contribution value of the resource utilization; The terminal with the highest comprehensive capability score is selected as the master terminal, and the others are selected as slave terminals; A master-slave terminal mapping relationship table is established, wherein the master-slave terminal mapping relationship table includes a master terminal identifier, a slave terminal identifier set, and terminal status information.

3. The method according to claim 1, characterized in that: A data distribution center is constructed using distributed message queue technology. The data distribution center includes multiple independently deployed message proxy nodes. Each message proxy node maintains an exclusive message topic. The message topic is bound to the terminal in the master-slave terminal mapping relationship table. The implementation of directional message push based on the message topic includes: Construct a multi-layer distributed message proxy node, wherein the multi-layer distributed message proxy node includes a core layer node for message routing, an access layer node for terminal connection, and a storage layer node for message persistence; obtain node status information of the multi-layer distributed message proxy node, wherein the node status information includes processor occupancy, memory occupancy, and network bandwidth occupancy; Constructing a state transition function based on the node state information to calculate the node state at the next moment; synchronizing the state information among the multi-layer distributed message proxy nodes through the Raft consensus protocol according to the calculation result of the state transition function; Calculate the load value of each message proxy node based on the node status information, and evaluate the load capacity of the multi-layer distributed message proxy node according to the load value; distribute the terminal access request to the access layer node with the lowest load value, and obtain the terminal identification and terminal role information; A hash algorithm is used to generate a message topic identifier according to the terminal identifier and the terminal role information, and a subscription relationship between the terminal and the message topic is established based on the message topic identifier; Construct a message routing table, the message routing table including the message topic identifier, the node identifier of the multi-layer distributed message proxy node, and the routing weight calculated based on the load value; select a target node for each message topic identifier through a routing decision function based on the message routing table to implement directional message push based on the message topic identifier.

4. The method according to claim 3, characterized in that Constructing a state transition function based on the node state information, calculating the node state at the next moment includes: A state transition function is constructed based on the node state information, the historical state sequence is segmented according to the time window, and the state transition features are extracted. The state transition features include state duration, transition trigger conditions and transition costs. A state transition matrix is ​​obtained by training based on the state transition features. Each element of the state transition matrix represents the probability of a node transitioning from a current state vector to a target state vector. The state transition matrix is ​​dynamically updated as a new state sequence is generated to ensure the timeliness of the state transition matrix. All state transition paths are calculated based on the state migration matrix, and confidence scores are assigned to the state transition paths. The confidence scores are related to the path probability and the historical prediction accuracy. The transition path with the highest confidence score is selected as the optimal prediction path. The influence of the time decay factor on the historical state is dynamically weighted. The time decay factor decays exponentially with the increase of the time interval. Finally, the prediction result of the node state at the next moment with time series correlation is output.

5. The method according to claim 3, characterized in that: Calculating a load value of each message proxy node based on the node status information, and evaluating the load capacity of the multi-layer distributed message proxy node according to the load value includes: Based on the node status information, the load value of each message proxy node is calculated, a state weight model is constructed, and a weight coefficient of each state indicator is determined according to the state weight model, wherein the processor utilization is 0.3, the memory occupancy is 0.25, the message queue depth is 0.2, the network throughput is 0.15, and the number of connections is 0.1; the standardized state indicator is multiplied by the corresponding weight coefficient and the sum is obtained to obtain the initial load value of each node; The load capacity of the multi-layer distributed message proxy nodes is evaluated, and the node load transfer influence coefficient is analyzed and calculated based on the hierarchical relationship between nodes and the message forwarding path; the node initial load value is combined with the node load transfer influence coefficient to obtain a final load evaluation value that reflects the actual processing capacity of the node.

6. The method according to claim 1, characterized in that Receiving an interaction instruction sent by the master control terminal, the interaction instruction including operation type information and target terminal information; and calling a microservice interface to generate an interaction task according to the operation type information and the target terminal information, including: Receive an interactive instruction sent by a master control terminal, the interactive instruction including operation type information and target terminal information; perform structured parsing on the interactive instruction, verify the syntax integrity of the operation type information, and check the operation authority and terminal status of the target terminal information; Constructing an instruction dependency graph, the instruction dependency graph including a vertex set representing atomic operations and an edge set representing dependencies between operations, and calculating a path weight based on the instruction dependency graph, the path weight being obtained by weighted summation of a priority weight and an execution time of each atomic operation; Selecting an optimal execution sequence from all feasible execution paths according to the path weights, wherein the optimal execution sequence is the execution path with the largest path weight among all feasible execution paths; Calculate resource requirements of atomic operations, the resource requirements including computing resource requirements and network resource requirements, wherein the computing resource requirements are calculated based on operation complexity and data size, and the network resource requirements are calculated based on bandwidth requirements and latency requirements; Building a resource scheduling optimization model based on the resource demand, wherein the optimization goal of the resource scheduling optimization model is to minimize the weighted sum of various resource occupancy rates while satisfying resource capacity upper limit constraints and operation timing dependency constraints; The microservice interface is called to encapsulate the optimal execution sequence and the solution results of the resource scheduling optimization model into an interactive task.

7. The method according to claim 1, characterized in that A lightweight task execution container is deployed on the slave terminal based on edge computing technology. The lightweight task execution container includes a state synchronization module and a rendering engine module. The state synchronization module is used to monitor the terminal execution state in real time and feed back to the data distribution center. The rendering engine module is used to complete the dynamic rendering of the screen content according to the instruction execution sequence. The method includes: Deploy a lightweight task execution container on the slave terminal, wherein the lightweight task execution container includes a state synchronization module and a rendering engine module; The state synchronization module collects terminal execution state parameters, which include processor occupancy, memory occupancy, task execution progress, rendering frame rate and network bandwidth utilization; Constructing a terminal state vector based on the terminal execution state parameters, setting a weight coefficient for each parameter in the terminal state vector according to the importance of resources, and obtaining a comprehensive load level of the terminal through weighted calculation; Reporting the terminal state vector and the terminal comprehensive load level to a data distribution center in real time, and the data distribution center returns an adjusted instruction execution sequence according to the terminal comprehensive load level; Prioritizing the adjusted instruction execution sequence, wherein the priority division includes priority rendering instructions and non-priority rendering instructions, and the execution priority of the priority rendering instructions is inversely proportional to the comprehensive load level of the terminal; The rendering engine module sets rendering parameters based on the comprehensive load level of the terminal, the rendering parameters including rendering accuracy, refresh frequency and cache size, and the rendering parameters decrease as the comprehensive load level of the terminal increases; The rendering engine module preferentially executes the priority rendering instruction and completes the dynamic rendering of the screen content according to the rendering parameters.

Images