Load sharing method and device for multicast service data processing

Abstract

The invention discloses a load sharing method and device for multicast service data processing, the method and device are applied to a hot standby multicast system, the hot standby multicast system comprises a service processing unit, a switch and a client, the switch is connected with each piece of end equipment and the client in the service processing unit, and the method comprises the following steps: obtaining the working state and the equipment type of the end equipment, when it is determined that the end device fails based on the working state, replacing the failed end device with a target end device in the other end devices to work, determining the number of the failed end devices, adjusting the working mode of the target end device according to the device type and number of the failed end devices, and enabling the end devices to realize load sharing and hot backup strategies. According to the technical scheme, special load sharing equipment does not need to be additionally customized, the cost can be effectively reduced, operation is carried out in a unit mode, when any end equipment breaks down, other equipment can continue to process services, packet loss is avoided in the fault switching process, and the stability and reliability of equipment operation are improved.

Description

Technical Field

[0001] The present application relates to the technical field of network service processing, and in particular to a load sharing method and device for multicast service data processing. Background Art

[0002] The typical LAN internal terminal multicast service processing process is as follows: Figure 2 As shown, the client sends a multicast data stream to be processed, which is forwarded to the end device through the switch. The end device processes the multicast data and sends it back to the client.

[0003] If the multicast data rate exceeds the performance limit of the end device, packet loss will occur. To avoid service processing failure caused by packet loss, load balancing technology needs to be introduced.

[0004] Link aggregation and proprietary load balancing devices are commonly used within local area networks to load balance multicast data. Link aggregation is typically achieved by configuring switches, but the devices involved in service processing must be connected between two switches, making it unsuitable for end devices. Proprietary load balancing devices require custom development, resulting in high costs and a poor cost-effectiveness. Summary of the Invention

[0005] In view of the above problems, the present application provides a load sharing method and device for multicast service data processing, which realizes load sharing through multiple terminal devices without the need for additional customized proprietary load sharing equipment, thereby effectively reducing costs.

[0006] In a first aspect, an embodiment of the present application provides a load sharing method for multicast service data processing, which is applied to a hot standby multicast system. The hot standby multicast system includes a service processing unit, a switch, and a client. The switch is respectively connected to each end device in the service processing unit and the client. The method includes:

[0007] Obtaining the working status and device type of the terminal device;

[0008] When it is determined based on the working status that the terminal device is faulty, replacing the faulty terminal device with a target terminal device among the remaining terminal devices to perform work;

[0009] determining the number of said end devices that are faulty;

[0010] The working mode of the target end device is adjusted according to the device type and number of the failed end devices.

[0011] In some embodiments, the service processing group includes a first end device, a second end device, and a third end device, the first end device and the second end device store odd-numbered messages and even-numbered messages, respectively, and the third end device processes all messages, wherein the first end device or the second end device operates in a HALF mode, and the third end device operates in a CACHE mode, and adjusting the operating mode of the target end device according to the device type and number of the failed end devices includes:

[0012] When the device type of the failed end device is the first end device or the second end device, and there is only one failed end device, adjusting the third end device from the CACHE mode to the HALF mode;

[0013] When the device type of the failed end device is the first end device or the second end device, and there are multiple failed end devices, the third end device is adjusted from the CACHE mode to the FULL mode.

[0014] In some embodiments, a method for load sharing multicast service data processing further includes:

[0015] Initialize the terminal device as a faulty machine and build a heartbeat multicast transceiver socket;

[0016] Setting a delayed heartbeat period to determine whether the terminal device is a faulty device based on the heartbeat period;

[0017] When it is determined that the terminal device is not a faulty device, a heartbeat packet is filled in the terminal device to set the working mode of the terminal device, wherein the working mode includes: HALF mode, FULL mode, CACHE mode and STOP mode.

[0018] In some embodiments, a method for load sharing multicast service data processing further includes:

[0019] Get the current time;

[0020] Based on the time difference between the current time and the last time a heartbeat packet was received during a preset time period;

[0021] Acquire the online status of the first end device, the second end device and the third end device respectively based on the heartbeat packet time difference;

[0022] The working mode is switched based on the online status.

[0023] In some embodiments, a method for load sharing multicast service data processing further includes:

[0024] Obtain a heartbeat packet protocol, wherein the heartbeat packet protocol includes: the end device number, the current role, the working mode, the device status, the sequence number of the currently processed packet, and the number of packets processed in the heartbeat cycle;

[0025] A service message cache mode is determined based on the heartbeat packet protocol.

[0026] In some embodiments, when the end device is determined to be faulty based on the working status, replacing the faulty end device with a target end device among the remaining end devices to perform work includes:

[0027] When it is determined based on the working status that the first-end device or the second-end device is faulty, the third-end device is used to replace the faulty first-end device or the second-end device to perform work.

[0028] In a second aspect, an embodiment of the present application provides a load sharing device for multicast service data processing, which is applied to a hot standby multicast system. The hot standby multicast system includes a service processing unit, a switch, and a client. The switch is respectively connected to each end device and the client in the service processing unit, including:

[0029] An acquisition module, configured to acquire the working status and device type of the terminal device;

[0030] a replacement module, configured to, when determining based on the working status that the end device is faulty, replace the faulty end device with a target end device among the remaining end devices to perform work;

[0031] A determination module, configured to determine the number of the faulty end devices;

[0032] An adjustment module is used to adjust the working mode of the target end device according to the device type and number of the failed end devices.

[0033] In a third aspect, an embodiment of the present application provides an electronic device comprising a memory and a processor, wherein the memory stores program code that can be run on the processor, and when the program code is executed by the processor, the load sharing method for multicast service data processing as described in any implementation method of the first aspect is implemented.

[0034] In a fourth aspect, an embodiment of the present application provides a computer storage medium storing one or more programs, which can be executed by an electronic device as described in the third aspect to implement a load sharing method for multicast service data processing as described in any implementation method of the first aspect.

[0035] The embodiment of the present application provides a load sharing method and device for multicast service data processing, which is applied to a hot standby multicast system. The hot standby multicast system includes a service processing unit, a switch and a client. The switch is respectively connected to each terminal device and the client in the service processing unit, obtains the working status and device type of the terminal device, and when it is determined based on the working status that the terminal device fails, the target terminal device among the remaining terminal devices replaces the failed terminal device to work, determines the number of failed terminal devices, and adjusts the working mode of the target terminal device according to the device type and number of the failed terminal devices. The terminal devices implement load sharing and hot standby strategies without the need for additional customized dedicated load sharing equipment, which can effectively reduce costs. It operates in a unit mode. When any one of the terminal devices fails, the remaining devices can continue to process the service. No packet loss occurs during the failover process, thereby improving the stability and reliability of the device operation.

[0036] It should be understood that the content described in this section is not intended to identify the key or important features of the embodiments of the present application, nor is it intended to limit the scope of the present application. Other features of the present application will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] Hereinafter, the present application will be described in more detail based on embodiments with reference to the accompanying drawings.

[0038] Figure 1 A schematic diagram of a load sharing method for multicast service data processing proposed in one embodiment of the present application is shown;

[0039] Figure 2 A schematic diagram of a multicast service processing of an end device in an exemplary prior art proposed in an embodiment of the present application is shown;

[0040] Figure 3 A schematic diagram of an exemplary three-machine hot standby multicast processing proposed in one embodiment of the present application is shown;

[0041] Figure 4 A schematic diagram showing a connection relationship between modules for performing load balancing and hot standby according to an embodiment of the present application is shown;

[0042] Figure 5 An exemplary heartbeat protocol packet sending module processing flow proposed in one embodiment of the present application is shown;

[0043] Figure 6 An exemplary D machine state transition diagram proposed in an embodiment of the present application is shown;

[0044] Figure 7 A schematic diagram of an exemplary heartbeat packet protocol proposed in an embodiment of the present application is shown;

[0045] Figure 8 The following is a flowchart of an exemplary heartbeat receiving and processing module proposed in one embodiment of the present application;

[0046] Figure 9 An exemplary heartbeat reception timeout processing flow chart proposed in one embodiment of the present application is shown;

[0047] Figure 10 An exemplary state transition diagram of machine A proposed in one embodiment of the present application is shown;

[0048] Figure 11 An exemplary state transition diagram of machine B proposed in one embodiment of the present application is shown;

[0049] Figure 12 An exemplary C machine state transition diagram proposed in an embodiment of the present application is shown;

[0050] Figure 13 An exemplary heartbeat receiving protocol parsing flow chart of machine A proposed in one embodiment of the present application is shown;

[0051] Figure 14 An exemplary B-machine heartbeat receiving protocol parsing flow chart proposed in one embodiment of the present application is shown;

[0052] Figure 15 An exemplary C-machine heartbeat receiving protocol parsing flow chart proposed in one embodiment of the present application is shown;

[0053] Figure 16 A schematic diagram of an exemplary service message storage and processing module processing flow proposed in one embodiment of the present application is shown;

[0054] Figure 17 An exemplary service processing flow chart of machine A proposed in one embodiment of the present application is shown;

[0055] Figure 18 An exemplary B-machine service processing flow chart proposed in one embodiment of the present application is shown;

[0056] Figure 19 An exemplary C-machine service processing flow proposed in one embodiment of the present application is shown;

[0057] Figure 20 A structural block diagram of a load sharing device for processing multicast service data proposed in one embodiment of the present application is shown;

[0058] Figure 21 A structural block diagram of an electronic device for executing a load sharing method for multicast service data processing according to an embodiment of the present application is shown;

[0059] Figure 22 A computer-readable storage medium proposed in an embodiment of the present application for storing or carrying a load sharing method for multicast service data processing according to an embodiment of the present application is shown. DETAILED DESCRIPTION

[0060] In order to make the objectives, technical solutions and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with examples and drawings. The exemplary embodiments of the present invention and their descriptions are only used to explain the present invention and are not intended to limit the present invention.

[0061] Currently, link aggregation and dedicated load balancing devices are commonly used within local area networks to load balance multicast data. Link aggregation is typically achieved by configuring switches, but the devices involved in service processing must be connected between two switches, making it unsuitable for end devices. Dedicated load balancing devices require custom development, which is costly and not cost-effective.

[0062] In response to the above technical problems, when there is a demand for high-speed multicast service processing within the local area network, in order to avoid packet loss caused by insufficient processing performance of the end device, the applicant proposes a load sharing method for multicast service data processing. By obtaining the working status and device type of the end device, when the end device failure is determined based on the working status, the target end device among the remaining end devices is replaced with the failed end device to work, the number of failed end devices is determined, and the working mode of the target end device is adjusted according to the device type and number of the failed end devices, and load sharing and hot backup strategies are implemented for the end devices. No additional customized dedicated load sharing equipment is required, which can effectively reduce costs. The unit operation is adopted, and the number of devices is increased in exchange for overall performance improvement. When any one of the devices fails, the remaining devices can continue to process the service, and there is no packet loss during the failover process, which improves the stability and reliability of the device operation. This method can also be used in situations where performance requirements are not high but stability and reliability requirements are high. When two devices in the unit fail, the remaining device can still work normally and ensure that there is no packet loss during the failover process. The load sharing method for multicast service data processing will be described in detail in subsequent embodiments.

[0063] The following describes the application scenarios of the load sharing method for multicast service data processing provided in the embodiment of the present application:

[0064] See also Figure 1 , Figure 1 This is a flow chart of a load sharing method for multicast service data processing provided in an embodiment of the present application. In this embodiment, the load sharing method for multicast service data processing can be applied to the following situations: Figure 3 The hot standby multicast system shown in Figure 4The execution load sharing and hot backup corresponding modules shown in Figure 20 The load sharing device 300 for processing multicast service data is shown in FIG. Figure 21 In the electronic device 200 shown, the electronic device may include one or more electronic devices, and information can be transmitted between the multiple electronic devices via wireless and / or wired means. The multiple electronic devices can collaborate to complete the load sharing method for multicast service data processing. For example, the electronic devices may include computers, mobile terminals, tablets, etc., which are not limited in this application. A load sharing method for multicast service data processing in this application is applied to a hot standby multicast system. The hot standby multicast system includes a service processing unit, a switch, and a client. The switch is respectively connected to each end device and the client in the service processing unit.

[0065] Among them, multiple terminal devices can be set in the business processing group. This application takes three terminal devices as an example for explanation, among which the client, switch and terminal devices in the business processing group transmit data to be processed multicast data stream and processed multicast data stream according to the connection instructions.

[0066] The following is for Figure 1 The process shown is described in detail. The load sharing method for multicast service data processing may include S110 to S140.

[0067] S110: Acquire the working status and device type of the terminal device.

[0068] S120: When it is determined based on the working status that the end device is faulty, a target end device among the remaining end devices is used to replace the faulty end device to perform work.

[0069] S130: Determine the number of faulty end devices.

[0070] S140: Adjust the working mode of the target end device according to the device type and number of the faulty end devices.

[0071] In some embodiments, the service processing unit includes a first end device, a second end device, and a third end device. The first end device and the second end device store odd-numbered messages and even-numbered messages, respectively, and the third end device processes all messages. The first end device or the second end device operates in a HALF mode, and the third end device operates in a CACHE mode. S140 includes S141 to S142, wherein:

[0072] S141: When the device type of the faulty end device is the first end device or the second end device, and there is only one faulty end device, adjust the third end device from the CACHE mode to the HALF mode.

[0073] S142: When the device type of the faulty end device is the first end device or the second end device, and there are multiple faulty end devices, adjust the third end device from the CACHE mode to the FULL mode.

[0074] In some embodiments, the method includes: when it is determined based on the working status that the first-end device or the second-end device is faulty, replacing the faulty first-end device or the second-end device with a third-end device to perform the work.

[0075] In this embodiment, Figure 3 The diagram below illustrates an exemplary three-device hot standby multicast processing scenario, using three stacked devices as an example. These devices collectively process multicast service data. If any one device fails, the remaining two devices can continue to share the workload. This method relies on load balancing and hot standby strategies implemented within each device. Load balancing effectively reduces the traffic volume per device, while hot standby ensures packet loss-free failover.

[0076] Each device in the group has four roles: A, B, C (backup role) and D (faulty device). A or B has two modes: full processing (hereinafter referred to as "FULL mode") and half processing ("HALF mode"). C is fixed in cache mode ("CACHE mode"), and D is fixed in stop processing mode ("STOP mode").

[0077] Among them, when the business processing group runs in "three-machine hot standby" mode, machine A and machine B are both in HALF mode, machine A processes messages with odd packet numbers (and stores messages with even packet numbers at the same time), machine B processes messages with even packet numbers (and stores messages with odd packet numbers at the same time), and machine C is in CACHE mode, storing all messages but not processing business.

[0078] When machine A or B fails, the heartbeat receiving and processing module intervenes and machine C takes over the failed machine at any time, continuing to work in the new role (A or B) and HALF mode, and giving priority to processing the data not processed by the original failed machine to ensure that no packets are lost during the role and mode switching process.

[0079] If both A and B fail at the same time, the heartbeat receiving and processing module takes over, and C processes all business data in the new role A and FULL mode. If the business rate exceeds the processing limit of a single device at this time, a backup machine must be added in time.

[0080] In some embodiments, a method for load sharing multicast service data processing further includes:

[0081] Initialize the end device as a faulty machine and build a heartbeat multicast sending and receiving socket;

[0082] Set the delayed heartbeat period to determine whether the end device is a faulty device based on the heartbeat period;

[0083] When it is determined that the end device is not a faulty device, the opposite end device fills a heartbeat packet to set the working mode of the end device, where the working modes include: HALF mode, FULL mode, CACHE mode and STOP mode.

[0084] In the embodiments of this application, see Figure 4 ,Among them, the load sharing and hot backup implementation mechanism mainly includes three ,modules: the heartbeat protocol group packet sending module, the heartbeat receiving and ,processing module, and the service message caching and processing module.

[0085] When deploying the unit, there is no need to specify the role and mode of the device. After startup, each device is initialized as D machine, and periodically sends its own status through the "heartbeat protocol group packet sending module". The "heartbeat receiving and processing module" completes the role and mode arbitration, and the "business message cache and processing module" completes the storage and processing of business data according to the role and mode.

[0086] In the above embodiment, the processing flow chart of the heartbeat protocol group packet sending module is shown in Figure 5 As shown, the specific steps in the figure are as S11 to S16:

[0087] S11: The local machine is initialized as machine D and a heartbeat multicast receiving and sending socket is established.

[0088] Specifically, the heartbeat multicast address 228.99.99.1 and port 10000 are used as the destination address and destination port. The receiver receives and processes the heartbeat packets sent by the other two devices by listening to the multicast address and port. The device itself does not receive the heartbeat packets sent by itself.

[0089] S12: Delay one heartbeat cycle T (T=1 second in particular). If the local state is normal, enter S14, otherwise enter S13.

[0090] S13: If it is the D machine, return to S12, otherwise the local machine switches to the D machine and then returns to S12.

[0091] S14: If it is not machine D, go to the next step. Otherwise, this machine switches to machine C and then goes to the next step. The state of machine D is transferred as follows. Figure 6 An exemplary D machine state transition diagram is shown.

[0092] S15: Follow Figure 7The heartbeat packet protocol diagram shown is filled with heartbeat packets, where the device number (hereinafter referred to as "devId") is unique for each device; the current role (hereinafter referred to as "role") includes A, B, C, and D; the working mode (hereinafter referred to as "mode") includes HALF, FULL, CACHE, and STOP; the device status (hereinafter referred to as "status") is divided into normal and abnormal; the currently processed packet sequence number (hereinafter referred to as "packId"), the business message contains a packet sequence number, and the packet sequence number is self-incrementing; the number of packets processed within the heartbeat cycle (hereinafter referred to as "dealNum") represents the number of packets processed by this machine within the heartbeat cycle T (especially T = 1 second).

[0093] S16: Send a heartbeat packet, clear dealNum, and return to S12.

[0094] In some embodiments, a method for load sharing multicast service data processing further includes:

[0095] Get the current time;

[0096] Based on the time difference between the current time and the time when the heartbeat packet was received during the last preset time period;

[0097] Obtaining the online status of the first end device, the second end device, and the third end device respectively based on the heartbeat packet time difference;

[0098] Switch the working mode based on the online status.

[0099] In the embodiments of this application, see Figure 8 An exemplary heartbeat receiving and processing module processing flow chart is shown, wherein the specific steps include S21 to S22.

[0100] S21: Receive heartbeat packet. If the reception times out, go to S22, otherwise go to S23.

[0101] S22: Heartbeat reception timeout processing process Figure 9 As shown, the execution steps include S221 to S224, wherein:

[0102] S221: Get the current time, calculate the time difference between the current time and the last time the heartbeat packet of the character was received, if the difference is greater than two heartbeat cycles 2T (especially T = 1 second), it is considered that the character has been offline, otherwise it is online, so as to obtain the online status of the ABC machine respectively.

[0103] If the machine is A, it goes to step S222, and its status transition is as follows: Figure 10 shown.

[0104] If the machine is machine B, then the process goes to step S223, and the state transition is as follows: Figure 11 shown.

[0105] If the machine is C, then go to step S224, and its state transition is as follows: Figure 12 As shown, otherwise return to S21.

[0106] S222 includes S2221 to S2224, among which:

[0107] S2221: If both machine A and machine B are online, this machine switches to machine C and returns to S21; otherwise, it enters S2222.

[0108] S2222: If machine A is online and machine B is offline, this machine switches to machine C, and then switches to machine B in the next round, and returns to S21. Otherwise, go to step S2223.

[0109] S2223: If machine A is offline and machine B is online, and the machine is not in HALF mode, set the machine to HALF mode and return to S21; otherwise, return to S21. If the condition that machine A is offline and machine B is online is not met, proceed to step S2224.

[0110] S2224: If both A and B are offline and C is online, return to S21. Otherwise, if the local machine is not in FULL mode, switch to FULL mode and return to S21. If the local machine is in FULL mode, return directly to S21.

[0111] S223 includes S2231 to S2234, among which:

[0112] S2231: If both machine A and machine B are online, this machine switches to machine C and returns to S21; otherwise, it goes to step S2232.

[0113] S2232: If A is offline and B is online, this machine switches to machine C, and then switches to machine A in the next round, and returns to S21, otherwise enter step S2233.

[0114] S2233: If A is online and B is offline, and the local machine is not in HALF mode, set the local machine to HALF mode and return to S21; otherwise, return to S21. If the condition that A is online and B is offline is not met, proceed to step S2234.

[0115] S2234: If both A and B are offline and C is online, return to S21. Otherwise, if the local machine is not in FULL mode, switch to FULL mode and return to S21. If the local machine is in FULL mode, return directly to S21.

[0116] S224 includes S2241 to S2244, among which:

[0117] S2241: If both machine A and machine B are not online, this machine switches to machine A's FULL mode and returns to S21; otherwise, it goes to step S2242.

[0118] S2242: If machine A is offline and machine B is online, this machine switches to machine A's HALF mode and returns to S21; otherwise, it enters S2242.

[0119] S2243: If machine A is online and machine B is offline, this machine switches to machine B's HALF mode and returns to S21; otherwise, it returns directly to S21.

[0120] S23: According to Figure 7 Parse the heartbeat packet and obtain the values ​​of all fields, including devId, role, mode, status, packId, and dealNum.

[0121] S24: If the local machine is machine A, go to S25; if the local machine is machine B, go to S26; if the local machine is machine C, go to S27; otherwise, return to S22.

[0122] S25: The heartbeat receiving protocol parsing process of machine A is as follows: Figure 13 As shown, it includes S251 to S254.

[0123] S251: If it is a heartbeat packet sent by machine C, go to step 252; if it is a heartbeat packet sent by machine B, go to step 253; if it is a heartbeat packet sent by machine A, go to step 254; otherwise, return to S22.

[0124] S252: If the status of machine C is normal, store the time when the heartbeat packet of machine C was last received, and return to S22; otherwise, clear the time when the heartbeat packet of machine C was last received, and return to S22.

[0125] S253 includes S2531 to S2532.

[0126] S2531: If the status of machine B is normal, store the time when the heartbeat packet of machine B was last received. Otherwise, clear the time when the heartbeat packet of machine B was last received, and then proceed to the next step.

[0127] S2532: If the dealNum parsed from the heartbeat packet is not greater than 0, return to S22; otherwise, delete the data from the beginning to the packId in the B cache and return to S22.

[0128] S254 includes S2541 to S2544:

[0129] S2541: If the status of machine A is normal, store the time when the heartbeat packet of machine A was last received; otherwise, clear the time when the heartbeat packet of machine A was last received, and then proceed to the next step.

[0130] S2542: If the mode of the other end is the same as that of the local end, proceed to step S2543; otherwise, proceed to step S2544.

[0131] S2543: If the other end's devId is smaller than the local device's, the local device switches to device C and returns to S22; otherwise, the local device returns directly to S22.

[0132] S2544: If the machine is in FULL mode, return to S22; otherwise, the machine switches to C mode and returns to S22.

[0133] S26: The heartbeat receiving protocol parsing process of machine B is as follows: Figure 14 shown.

[0134] S26 includes S261 to S264.

[0135] S261: If it is a heartbeat packet sent by machine C, go to step S262; if it is a heartbeat packet sent by machine A, go to step S263; if it is a heartbeat packet sent by machine B, go to step S264; otherwise, return to S22.

[0136] S262: If the status of machine C is normal, store the time when the heartbeat packet of machine C was last received, and return to S22; otherwise, clear the time when the heartbeat packet of machine C was last received, and return to S22.

[0137] S263 includes S2631 and S2632: If machine A is in a normal state, store the time of the last heartbeat packet received from machine A. Otherwise, clear the time of the last heartbeat packet received from machine A and proceed to the next step. If the dealNum parsed from the heartbeat packet is not greater than 0, return to S22. Otherwise, delete the data from the beginning to the packId in A's cache and return to S22.

[0138] S264 includes S2641 to S2642:

[0139] S2641: If the status of machine B is normal, store the time when the heartbeat packet of machine B was last received. Otherwise, clear the time when the heartbeat packet of machine B was last received, and then proceed to the next step.

[0140] S2642: If the mode of the other end is the same as that of the local end, proceed to step S2643; otherwise, proceed to step S2644.

[0141] S2643: If the peer end's devId is smaller than the local end's, the local end switches to machine C and returns to S22; otherwise, the local end directly returns to S22.

[0142] S2644: If the machine is in FULL mode, return to S22; otherwise, the machine switches to C mode and returns to S22.

[0143] S27: The heartbeat receiving protocol parsing process of machine C is as follows: Figure 15 shown.

[0144] S27 includes S271 to S274, among which:

[0145] S271: If it is a heartbeat packet sent by machine A, go to step S272; if it is a heartbeat packet sent by machine B, go to step S273; if it is a heartbeat packet sent by machine C, go to step S273; otherwise return to S22.

[0146] S272 includes S2721 to S2722, among which:

[0147] S2721: If the status of machine A is normal, store the time when the heartbeat packet of machine A was last received; otherwise, clear the time when the heartbeat packet of machine A was last received, and then proceed to the next step.

[0148] S2722: If the dealNum parsed from the heartbeat packet is not greater than 0, return to S22; otherwise, delete the data from the beginning to the packId in the A cache and return to S22.

[0149] S273 includes S2731 to S2732, among which:

[0150] S2731: If the status of machine B is normal, store the time when the heartbeat packet of machine B was last received; otherwise, clear the time when the heartbeat packet of machine B was last received, and then proceed to the next step.

[0151] S2732: If the dealNum parsed from the heartbeat packet is not greater than 0, return to S22; otherwise, delete the data from the beginning to the packId in the B cache and return to S22.

[0152] S274 includes S2741 to S2742, among which:

[0153] S2741: If the status of machine C is normal, store the time when the heartbeat packet of machine C was last received; otherwise, clear the time when the heartbeat packet of machine C was last received, and then proceed to the next step.

[0154] S2742: If the other end's devId is smaller than the local device's, the local device switches to device C and returns to S22; otherwise, the local device returns directly to S22.

[0155] In some embodiments, a method for load sharing multicast service data processing further includes:

[0156] Get the heartbeat packet protocol, where the heartbeat packet protocol includes: end device number, current role, working mode, device status, currently processed packet sequence number and the number of packets processed in the heartbeat cycle;

[0157] The service message cache mode is determined based on the heartbeat packet protocol.

[0158] In the embodiment of the present application, a service message cache and processing module is constructed to determine the message cache mode, and its processing flow is as follows: Figure 16 As shown, the specific steps include S31 to S35, wherein:

[0159] S31: Get the service package. If the local machine is machine A, go to S32. If the local machine is machine B, go to S33. If the local machine is machine C, go to S34. Otherwise, return to S31.

[0160] S32, the business processing flow of machine A is as follows Figure 17 As shown, it may include S321 to S323.

[0161] S321: If the machine is in HALF processing mode, go to step S322, otherwise go to step S322.

[0162] S322 includes S3221 to S3222, among which:

[0163] S3221: If the machine has just switched to HALF mode, the data in the A cache is processed, dealNum is added with the corresponding number of processed packets, and then the next step is entered; otherwise, the next step is entered directly.

[0164] S3222: If the sequence number of the data packet to be processed is an even number, store it in the B cache and return to S31, otherwise go to S3233 in step S323.

[0165] S323 includes S3231 to S3232, among which:

[0166] S3231: If the machine has just switched from HALF mode to FULL mode, the data in the B cache is processed, dealNum is added with the corresponding number of processed packets, and then the next step is entered; otherwise, the next step is entered directly.

[0167] S3232: If the machine has just switched from CACHE to FULL mode, the data in the AB cache is processed, dealNum is added with the corresponding number of processed packets, and then the next step is entered; otherwise, the next step is entered directly.

[0168] S3233: Process the business package, increment dealNum by 1, and proceed to S35.

[0169] S33, the business processing flow of machine B is as follows Figure 18 As shown, S33 includes S331 to S333, wherein:

[0170] S331: If the machine is in HALF processing mode, go to step b, otherwise go to step c.

[0171] S332 includes S3321 to S3322, among which:

[0172] S3321: If the machine has just switched to HALF mode, the data in the B cache is processed, dealNum is added with the corresponding number of processed packets, and then the next step is entered; otherwise, the next step is entered directly.

[0173] S3322: If the sequence number of the data packet to be processed is an odd number, store it in the A cache and return to S31, otherwise go to step S3333 in step S333.

[0174] S333 includes S3331 to S3333, among which:

[0175] S3331: If the machine has just switched from HALF mode to FULL mode, the data in the A cache is processed, dealNum is added with the corresponding number of processed packets, and then the next step is entered; otherwise, the next step is entered directly.

[0176] S3332: If the machine has just switched from CACHE to FULL mode, the data in the cache of machine A and machine B is processed, dealNum is added with the corresponding number of processed packets, and then the next step is entered; otherwise, the next step is entered directly.

[0177] S3333: Process the business package, increment dealNum by 1, and proceed to S35.

[0178] S34: Machine C's business processing flow is as follows Figure 19 As shown, if the sequence number of the data packet to be processed is an odd number, it is stored in cache A, otherwise it is stored in cache B, and the process returns to S31.

[0179] S35: Record the current processed packet number packId, and return to S31.

[0180] In some embodiments, when the third-end device is adjusted from the CACHE mode to the FULL mode, it is determined whether the currently operating service rate exceeds the data processing limit of the third-end device;

[0181] When the service rate exceeds the data processing limit of the third-end device, a backup device is added for the third-end device.

[0182] In summary, in the embodiment of the present application, load sharing and hot backup strategies are implemented without the need for additional customized proprietary load sharing equipment, which can effectively reduce costs. It operates in a unit manner, increasing the number of devices in exchange for improved overall performance. When any one of the devices fails, the remaining two devices can continue to process business, and there is no packet loss during the failover process, which improves the stability and reliability of the equipment operation. When two devices in the unit fail, the remaining device can still work normally, and it is guaranteed that there is no packet loss during the failover process.

[0183] See also Figure 20 , Figure 20 This is a structural block diagram of a load sharing device for multicast service data processing provided by the present application, which is applied to a hot standby multicast system. The hot standby multicast system includes a service processing unit, a switch, and a client. The switch is respectively connected to each end device in the service processing unit and the client. A load sharing device 300 for multicast service data processing includes: an acquisition module 310, a replacement module 320, a confirmation module 330, and an adjustment module 340, wherein:

[0184] The acquisition module 310 is used to acquire the working status and device type of the terminal device.

[0185] The replacement module 320 is configured to, when determining based on the working status that an end device is faulty, replace the faulty end device with a target end device among the remaining end devices to perform work.

[0186] The confirmation module 330 is used to determine the number of faulty end devices.

[0187] The adjustment module 340 is configured to adjust the operating mode of the target end device according to the device type and number of the failed end devices.

[0188] The device embodiment in this application may also include other modules, which specifically correspond to part of the content of the above method.

[0189] It should be noted that the device embodiments in this application correspond to the aforementioned method embodiments. The specific principles in the device embodiments can be found in the contents of the aforementioned method embodiments and will not be repeated here.

[0190] In several embodiments provided in this embodiment, the coupling between modules may be electrical, mechanical or other forms of coupling.

[0191] In addition, the functional modules in various embodiments of the present invention may be integrated into a single processing module, or each module may exist physically separately, or two or more modules may be integrated into a single module. The aforementioned integrated modules may be implemented in the form of hardware or software functional modules.

[0192] See also Figure 21 , Figure 21 This is a structural block diagram of an electronic device 200 provided in an embodiment of the present application that can execute the load sharing method for multicast service data processing. The electronic device 200 can be a smart phone, tablet computer, computer, portable computer or other device.

[0193] The electronic device 200 further includes a processor 202 and a memory 204 . The memory 204 stores a program that can execute the contents of the aforementioned embodiments, and the processor 202 can execute the program stored in the memory 204 .

[0194] The processor 202 may include one or more cores for processing data and a message matrix unit. The processor 202 utilizes various interfaces and circuits to connect various components within the electronic device 200. It executes instructions, programs, code sets, or instruction sets stored in the memory 204, and accesses data stored in the memory 204 to perform various functions and process data within the electronic device 200. Optionally, the processor 202 may be implemented using at least one of the following hardware forms: a digital signal processing (DSP), a field-programmable gate array (FPGA), or a programmable logic array (PLA). The processor 202 may integrate one or a combination of a central processing unit (CPU), a graphics processing unit (GPU), and a modem (decoder). The CPU primarily processes the operating system, user interface, and application programs; the GPU is responsible for rendering and drawing display content; and the modem handles wireless communications. It is understood that the modem (decoder) may not be integrated into the processor and may be implemented separately via a communications chip.

[0195] The memory 204 may include a random access memory (RAM) or a read-only memory (ROM). The memory 204 may be used to store instructions, programs, codes, code sets, or instruction sets. The memory 204 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for implementing at least one function (e.g., instructions for a user to obtain a random number), instructions for implementing the various method embodiments described below, and the like. The data storage area may also store data (e.g., random numbers) created by the terminal during use.

[0196] The electronic device 200 may also include a network module and a screen. The network module is used to receive and transmit electromagnetic waves, realize the mutual conversion between electromagnetic waves and electrical signals, and thus communicate with a communication network or other devices, such as communicating with an audio playback device. The network module may include various existing circuit components for performing these functions, such as an antenna, a radio frequency transceiver, a digital signal processor, an encryption / decryption chip, a user identity module (SIM) card, a memory, etc. The network module can communicate with various networks such as the Internet, an intranet, a wireless network, or communicate with other devices via a wireless network. The above-mentioned wireless network may include a cellular telephone network, a wireless local area network, or a metropolitan area network. The screen can display interface content and perform data interaction.

[0197] Please refer to Figure 22 , Figure 22 The computer-readable storage medium 400 stores program code 410, which can be called by a processor to execute the method described in the above method embodiment.

[0198] Computer-readable storage medium 400 may be an electronic memory such as flash memory, EEPROM (Electrically Erasable Programmable Read-Only Memory), EPROM, hard disk, or ROM. Alternatively, the computer-readable storage medium includes a non-transitory computer-readable storage medium. Computer-readable storage medium 400 has storage space for program code 410 for executing any of the method steps in the above method. These program codes 410 can be read from or written to one or more computer program products. Program code 410 can be compressed, for example, in a suitable form.

[0199] The present application also provides a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the load sharing method for multicast service data processing described in the various optional implementations described above.

[0200] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A load sharing method for multicast service data processing, characterized in that: Applied to a hot standby multicast system, the hot standby multicast system includes a service processing unit, a switch, and a client, the switch is respectively connected to each terminal device in the service processing unit and the client, the method includes: Obtaining the working status and device type of the terminal device; When it is determined based on the working status that the terminal device is faulty, replacing the faulty terminal device with a target terminal device among the remaining terminal devices to perform work; determining the number of said end devices that are faulty; The working mode of the target end device is adjusted according to the device type and number of the failed end devices.

2. A load sharing method for multicast service data processing according to claim 1, characterized in that: The service processing unit includes a first end device, a second end device, and a third end device, wherein the first end device and the second end device store odd-numbered messages and even-numbered messages respectively, and the third end device processes all messages, wherein the first end device or the second end device operates in a HALF mode, and the third end device operates in a CACHE mode, and adjusting the operating mode of the target end device according to the device type and number of the failed end devices includes: When the device type of the failed end device is the first end device or the second end device, and there is only one failed end device, adjusting the third end device from the CACHE mode to the HALF mode; When the device type of the failed end device is the first end device or the second end device, and there are multiple failed end devices, the third end device is adjusted from the CACHE mode to the FULL mode.

3. The load sharing method for multicast service data processing according to claim 1, characterized in that: The method further comprises: Initialize the terminal device as a faulty machine and build a heartbeat multicast transceiver socket; Setting a delayed heartbeat period to determine whether the terminal device is a faulty device based on the heartbeat period; When it is determined that the terminal device is not a faulty device, a heartbeat packet is filled in the terminal device to set the working mode of the terminal device, wherein the working mode includes: HALF mode, FULL mode, CACHE mode and STOP mode.

4. The load sharing method for multicast service data processing according to claim 2, characterized in that: The method further comprises: Get the current time; Based on the time difference between the current time and the last time a heartbeat packet was received during a preset time period; Acquire the online status of the first end device, the second end device and the third end device respectively based on the heartbeat packet time difference; The working mode is switched based on the online status.

5. The load sharing method for multicast service data processing according to claim 1, characterized in that: The method further comprises: Obtain a heartbeat packet protocol, wherein the heartbeat packet protocol includes: the end device number, the current role, the working mode, the device status, the sequence number of the currently processed packet, and the number of packets processed in the heartbeat cycle; A service message cache mode is determined based on the heartbeat packet protocol.

6. A load sharing method for multicast service data processing according to claim 2, characterized in that: When it is determined based on the working state that the terminal device fails, replacing the failed terminal device with a target terminal device among the remaining terminal devices to perform work includes: When it is determined based on the working status that the first-end device or the second-end device is faulty, the third-end device is used to replace the faulty first-end device or the second-end device to perform work.

7. A load sharing method for multicast service data processing according to claim 2, characterized in that: The method further comprises: When the third-end device is adjusted from the CACHE mode to the FULL mode, determining whether the currently operating service rate exceeds the data processing limit of the third-end device; When the service rate exceeds the data processing limit of the third-end device, a backup device is added for the third-end device.

8. A load sharing device for multicast service data processing, characterized in that: Applied to a hot standby multicast system, the hot standby multicast system includes a service processing unit, a switch, and a client, the switch is respectively connected to each terminal device in the service processing unit and the client, the device includes: An acquisition module, configured to acquire the working status and device type of the terminal device; a replacement module, configured to, when determining based on the working status that the end device is faulty, replace the faulty end device with a target end device among the remaining end devices to perform work; A determination module, configured to determine the number of the faulty end devices; An adjustment module is used to adjust the working mode of the target end device according to the device type and number of the failed end devices.

9. An electronic device, characterized in that: The electronic device includes a memory and a processor, the memory stores program code that can be run on the processor, and when the program code is executed by the processor, a load sharing method for multicast service data processing according to any one of claims 1 to 7 is implemented.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores program codes, and the program codes can be called by one or more processors to execute a load sharing method for multicast service data processing according to any one of claims 1 to 7.

Images