A service processing method, electronic equipment and storage medium
By redefining the processing scope of devices based on device information and prioritizing high-priority and high-activity business requests, the problem of critical requests being dropped when nodes fail in the cluster system is solved, thus improving the overall system performance.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- ZHEJIANG UNIVIEW TECH CO LTD
- Filing Date
- 2021-08-06
- Publication Date
- 2026-07-31
AI Technical Summary
In a cluster system, when a node fails, existing technologies cannot effectively allocate and process business requests from critical devices, resulting in poor overall system performance. In particular, when the takeover node has insufficient processing capacity, critical business requests are dropped or fail to be processed.
By obtaining the device information of the device to which the pending business request belongs, the device processing scope of the node is redefined based on the device type priority and activity level. High-priority and high-activity device requests are processed first, while low-priority and low-activity requests are abandoned or the processing is reduced.
It improves the overall performance of the cluster system in the event of node failure, ensures the smooth processing of critical business requests, and enhances the stability and reliability of the system.
Smart Images

Figure CN115914548B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to, but is not limited to, the field of information monitoring, and particularly to a business processing method, electronic device, and storage medium. Background Technology
[0002] With the development of information monitoring needs and business, various business platforms are constantly expanding and becoming increasingly large. Taking video surveillance and management platforms as an example, the number of camera points that the system needs to manage and process data from is increasing, and the requirements for overall business continuity and reliability are also rising. To meet these basic needs, various video management and monitoring systems have adopted cluster solutions, where multiple configurable distributed nodes in the cluster system share the processing tasks of business data from front-end cameras. Using this cluster solution, when individual nodes fail or go down, other nodes can take over their business requests, effectively improving business stability and ensuring overall availability. However, this takeover solution works smoothly when the takeover node has sufficient processing capacity; when the takeover node itself has limited processing capacity and cannot handle the original and takeover business, it will lead to an increased business processing failure rate or the dropping of some business requests.
[0003] Therefore, it is necessary to propose a more reasonable business processing scheme to take over business between nodes in the cluster and achieve the best processing effect at the overall level of the business system. Summary of the Invention
[0004] This disclosure provides a service processing method, electronic device, and storage medium applied in a cluster solution. When each node takes over a new service request, it can determine the new device processing range based on the device information to which the service request belongs. Within its own capabilities, it can selectively process the service request according to the new device processing range, thereby more effectively ensuring the processing of certain service requests. This allows for optimal overall system performance even when the overall system processing capacity is limited.
[0005] On one hand, embodiments of this disclosure provide a business processing method, applied to a business processing node or server, including:
[0006] Receive pending service requests and obtain device information of the device to which the pending service request belongs;
[0007] Based on the device information of the device to which the pending service request belongs and the device information of the devices within the current processing range of the device, a new device processing range is determined; wherein, the device information includes: device type priority and / or device activity;
[0008] The pending service requests are processed according to the new device processing range.
[0009] On the other hand, embodiments of this disclosure also provide an electronic device, including:
[0010] One or more processors;
[0011] Storage device for storing one or more programs.
[0012] When the one or more programs are executed by the one or more processors, the one or more processors implement the business processing method described in any embodiment of this disclosure.
[0013] On the other hand, embodiments of this disclosure also provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the business processing method described in any embodiment of this disclosure.
[0014] The solution of this invention is applied to each service processing node in a cluster system, enabling it to determine the new device processing range based on the device information of the service requests to be taken over, and to prioritize the processing of certain service requests in a targeted manner, so as to achieve the overall optimal performance of the cluster system.
[0015] After reading and understanding the accompanying diagrams and detailed descriptions, the other aspects can be understood. Attached Figure Description
[0016] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the structures shown in these drawings without creative effort.
[0017] Figure 1 This is a flowchart of a business processing method provided in an embodiment of the present invention;
[0018] Figure 2 This is a flowchart illustrating another business processing method provided in an embodiment of the present invention;
[0019] Figure 3 This is a flowchart of another business processing method provided in an embodiment of the present invention.
[0020] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation
[0021] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.
[0022] It should be noted that all directional indications (such as up, down, left, right, front, back, etc.) in the embodiments of the present invention are only used to explain the relative positional relationship and movement of each component in a certain specific posture (as shown in the figure). If the specific posture changes, the directional indication will also change accordingly.
[0023] Furthermore, in this invention, descriptions involving "first," "second," etc., are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this invention, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.
[0024] In this invention, unless otherwise explicitly specified and limited, the terms "connection," "fixed," etc., should be interpreted broadly. For example, "fixed" can mean a fixed connection, a detachable connection, or an integral part; it can mean a mechanical connection or an electrical connection; it can mean a direct connection or an indirect connection through an intermediate medium; it can mean the internal communication of two components or the interaction between two components, unless otherwise explicitly limited. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.
[0025] Furthermore, the technical solutions of the various embodiments of the present invention can be combined with each other, but only if they are feasible for those skilled in the art. If the combination of technical solutions is contradictory or cannot be implemented, it should be considered that such combination of technical solutions does not exist and is not within the scope of protection claimed by the present invention.
[0026] As can be seen, the introduction of cluster solutions improves the overall stability and availability of various business systems. However, in related technical solutions, when available nodes in the cluster take over the business processing tasks of other unavailable nodes, they can only do so within their capabilities. Business requests exceeding their capabilities are discarded or fail to be taken over directly. This discarded business is usually random, which may result in some business requests from critical business locations being abandoned, while some business requests from relatively unimportant locations are processed normally, leading to suboptimal overall system performance. For example, in a video surveillance system, cameras are deployed at numerous locations. Considering the location characteristics or monitoring targets of these locations, some cameras are more critical. When all nodes in the cluster are operating normally, each node is responsible for processing business requests generated by cameras at different locations. Considering the cost of system redundancy, under normal circumstances, the processing load of each node is also high, with little redundancy in processing capacity. When a node in the cluster fails, the business requests generated by the camera locations it was originally responsible for will be taken over by other nodes. These taken-over business data or business processing requests may come from cameras at key locations. If the processing capacity of the taking-over node itself is insufficient to handle its original business processing tasks and the newly taken-over business processing tasks, these taken-over business data or business processing requests from cameras at key locations will also be discarded or fail to be processed. Consequently, the related key monitoring results will also be lost, causing a significant impact on the overall monitoring system.
[0027] The nodes described in the embodiments of this disclosure are also called business processing nodes or business processing servers, and those skilled in the art can understand and clearly understand their meanings.
[0028] This disclosure provides a service processing method that, when taking over service processing requests, can redetermine the service processing scope of each node, and based on the limited processing capabilities of the nodes, can ensure the smooth execution of service processing requests from critical devices in a targeted manner, thereby improving the overall system performance.
[0029] like Figure 1 As shown, this business processing method is applied to a business processing node or server, including:
[0030] Step 101: Receive the pending service request and obtain the device information of the device to which the pending service request belongs;
[0031] Step 102: Determine a new device processing range based on the device information of the device to which the pending service request belongs and the device information of devices within the current processing range of the device; wherein, the device information includes: device type priority and / or device activity.
[0032] Step 103: Process the pending service request according to the new device processing range.
[0033] In some exemplary embodiments, the device may be a physical entity device, a logical device, or a logical node. In this disclosure, the home device of the service request to be processed refers to a service request to be closely associated with that home device, including but not limited to at least one of the following aspects:
[0034] The home device generates the pending service request;
[0035] The pending service request is generated based on the service data generated or acquired by the home device.
[0036] The pending service request is sent via the home device.
[0037] In some exemplary embodiments, step 102, determining a new device processing range based on the device information of the device to which the service request to be processed belongs and the device information of devices within the current processing range of the device itself, includes:
[0038] Step 1021: Sort the devices within the current processing range of the device according to the device type priority and / or device activity in a preset manner, and determine the candidate devices based on the sorting results;
[0039] Step 1022: For each candidate device, perform the following steps: If it is determined that the candidate device meets the deletion criteria, delete the candidate device from its own device processing scope;
[0040] Step 1023: If at least one candidate device meets the deletion condition, add the device to which the pending service request belongs to its own device processing scope to obtain the new device processing scope.
[0041] In some exemplary embodiments, step 1021 includes: sorting devices within its current processing range according to device type priority using a preset method, and determining candidate devices based on the sorting results. The preset method includes ascending or descending order, meaning the service processing node sorts devices within its current processing range in ascending or descending order based on device type priority, and determines one or more candidate devices based on the sorting results.
[0042] Accordingly, step 102, determining candidate devices based on the sorting results, includes: determining the first X or last X devices in the sorting as candidate devices based on the sorting results. For example, sorting in ascending order based on device type priority to determine the first X devices as candidate devices; or sorting in descending order based on device type priority to determine the last X devices as candidate devices; where X is an integer greater than or equal to 1.
[0043] For example, based on device type priority, the business processing node or server sorts the devices within its current processing range in ascending order, that is, sorting them in ascending order using device type priority as the sorting field. It can be seen that the device ranked first is the one with the lowest device type priority among all devices. For example, with a total of 4 devices: Device 1 (low priority), Device 2 (low priority), Device 3 (low priority), and Device 4 (medium priority), after sorting according to step 1021, we get: Device 1, Device 2, Device 3, Device 4. If X = 2, then according to step 1021, 2 candidate devices are determined—Device 1 and Device 2; if X = 1, then 1 candidate device—Device 1—is determined. In some exemplary embodiments, devices with the same device type priority are randomly sorted.
[0044] In some exemplary embodiments, step 1021 includes: sorting devices within its current processing range according to a preset method based on device activity, and determining candidate devices based on the sorting results. The preset method includes ascending or descending order, meaning the service processing node sorts devices within its current processing range in ascending or descending order based on device activity, and determines one or more candidate devices based on the sorting results.
[0045] Accordingly, step 102, determining candidate devices based on the sorting results, includes: determining the first X devices or the last X devices in the sorting as candidate devices based on the sorting results. For example, sorting by device activity in ascending order to determine the first X devices as candidate devices; or sorting by device activity in descending order to determine the last X devices as candidate devices; where X is an integer greater than or equal to 1.
[0046] In some exemplary embodiments, step 1021 includes: sorting devices within its current processing range according to device type priority and device activity, and determining candidate devices based on the sorting results. The preset methods include ascending or descending order, meaning the service processing node sorts devices within its current processing range in ascending or descending order based on device type priority and device activity, and determines one or more candidate devices based on the sorting results.
[0047] For example, devices within the current processing range are sorted in ascending order based on device type priority and device activity. Specifically, device type priority is used as the first sorting field, and device activity is used as the second sorting field. In other words, all devices within the current processing range are first sorted by device type priority in ascending order, and then by device activity in ascending order if device type priorities are the same. As you can see, the device with the lowest device type priority and the lowest device activity is listed first. For example, given 6 devices: Device 1 (low priority, activity level 50), Device 2 (low priority, activity level 100), Device 3 (low priority, activity level 20), Device 4 (medium priority, activity level 100), Device 5 (high priority, activity level 60), and Device 6 (medium priority, activity level 80), after arranging them according to step 1021, we get: Device 3, Device 1, Device 2, Device 6, Device 4, Device 5. For example, if X = 2, then according to step 1021, we determine 2 candidate devices—Device 3 and Device 1; if X = 1, then we determine 1 candidate device—Device 3.
[0048] For example, devices within the current processing range can be sorted in ascending order based on device type priority and device activity. That is, device activity is used as the first sorting field and device type priority is used as the second sorting field. In other words, all devices within the current processing range are first sorted in ascending order by device activity, and then sorted in ascending order by device type priority if the device activity is the same.
[0049] Based on the above examples, those skilled in the art can understand the specific implementation of sorting devices in descending order according to device type priority and device activity within the current processing range of a device, which will not be illustrated here.
[0050] Accordingly, step 102, determining candidate devices based on the sorting results, includes: determining the first X or last X devices in the sorting as candidate devices based on the sorting results. For example, sorting in ascending order based on device type priority and device activity to determine the first X devices as candidate devices; or sorting in descending order based on device type priority and device activity to determine the last X devices as candidate devices; where X is an integer greater than or equal to 1.
[0051] The device type priority representation and activity representation methods described in the embodiments of this disclosure are for illustrative purposes only and are not limited to specific forms. Those skilled in the art can choose different methods. For example, priority can be represented by numbers or letters, or activity can be represented by percentages or level information. X is flexibly set according to the processing capacity of the nodes in the cluster and / or the service volume of devices with high device type priority; it can be pre-configured or dynamically determined.
[0052] In some exemplary embodiments, step 1022 determines that the candidate device meets the deletion criteria, including one of the following:
[0053] If the device type priority of the candidate device is lower than the device type priority of the device to which the pending service request belongs, the candidate device is determined to meet the deletion criteria.
[0054] If the device activity level of the candidate device is lower than the device activity level of the device to which the pending service request belongs, the candidate device is determined to meet the deletion criteria.
[0055] If the device type priority of the candidate device is equal to the device type priority of the device to which the pending service request belongs, and the device activity of the candidate device is less than the device activity of the device to which the pending service request belongs, then the candidate device is determined to meet the deletion condition.
[0056] If the activity level of the candidate device is equal to the activity level of the device to which the pending service request belongs, and the device type priority of the candidate device is lower than the device type priority of the device to which the pending service request belongs, then the candidate device is determined to meet the deletion criteria.
[0057] For example, in step 1021, two candidate devices are identified: device 3 (low priority, activity level 20) and device 1 (low priority, activity level 50). The device information of the device to which the pending business request belongs is device 100 (medium priority, activity level 60). In this case, both devices 3 and 1 meet the deletion criteria and are removed from the device processing scope of the business processing node or the server itself. Device 100 is added to the device processing scope, resulting in a new device processing scope. As another example, in step 1021, two candidate devices are identified: device 3 (low priority, activity level 20) and device 1 (low priority, activity level 50). The device information of the device to which the pending business request belongs is device 100 (low priority, activity level 40). In this case, device 3 meets the deletion criteria, while device 1 does not. Device 3 is removed from its own device processing scope, and device 100 is added to the device processing scope, resulting in a new device processing scope. As yet another example, in step 1021, one candidate device is identified: device 3 (low priority, activity level 20). The device information of the device to which the pending business request belongs is... If device 100 (low priority, activity level 60) is selected, then device 3 meets the deletion criteria and is removed from its own device processing scope. Device 100 is added to the device processing scope, resulting in a new device processing scope. Alternatively, if step 1021 identifies a candidate device, device 3 (low priority, activity level 20), and the device information of the device to which the pending business request belongs is device 100 (low priority, activity level 15), then device 3 does not meet the deletion criteria, no device is removed from its own device processing scope, and device 100 cannot be added to the device processing scope. The device processing scope remains unchanged in this instance.
[0058] It is understandable that in step 1022, candidate devices that meet the deletion criteria are removed from the device processing scope of the service processing node itself. This indicates that the service processing node will no longer process service processing requests from devices outside these scopes (devices removed from the old scope), but will take over service processing requests from higher-priority devices (devices newly added to the scope). When the device to which the service request to be processed belongs has a higher device type priority, or higher activity, or the same device type priority but higher activity, or the same activity but higher device priority, the service processing node will determine to take over the service processing requests from the new device, while abandoning some lower-priority and / or lower-activity service processing requests that it was originally responsible for processing, in order to ensure the optimal overall performance of the service system.
[0059] In some exemplary embodiments, in step 102, the service processing node determines a new device processing range based on the device information of the device to which the service request to be processed belongs and the device information of the devices within its current processing range, including steps 10211-10213:
[0060] Step 10211: Determine the device to be deleted according to one of the following methods:
[0061] One or more devices within the processing range of the current device that have a device type priority lower than the device to which the pending service request belongs are identified as candidate devices; the candidate devices are sorted according to their device type priority in a preset manner, and the devices to be deleted are determined based on the sorting results;
[0062] One or more devices within the processing range of the current device that have a lower device type priority than the device to which the pending service request belongs are identified as candidate devices; the candidate devices are sorted according to a preset method based on their device activity, and devices to be deleted are determined based on the sorting results.
[0063] One or more devices within the processing range of the current device that have a lower device activity level than the device to which the pending service request belongs are identified as candidate devices; the candidate devices are sorted according to their device type priority in a preset manner, and the devices to be deleted are determined based on the sorting results.
[0064] One or more devices within the processing range of the current device that have a lower device activity level than the device to which the pending service request belongs are identified as candidate devices; the candidate devices are sorted according to a preset method based on their device activity level, and devices to be deleted are determined based on the sorting results.
[0065] One or more devices within the processing range of the current device that have a device type priority equal to the device type priority of the device to which the pending service request belongs are identified as candidate devices; the candidate devices are sorted according to a preset method based on their device activity, and devices to be deleted are determined based on the sorting results.
[0066] One or more devices within the processing range of the current device whose device activity is equal to the device activity of the device to which the pending service request belongs are identified as candidate devices; the candidate devices are sorted according to their device type priority in a preset manner, and the devices to be deleted are determined based on the sorting results.
[0067] Step 10212: Remove the device to be deleted from the current device processing scope;
[0068] Step 10213: Add the device to which the pending service request belongs to its own device processing scope to obtain the new device processing scope.
[0069] The preset methods include: ascending order or descending order;
[0070] Determining devices to be deleted based on the sorting results includes: determining the top Z or bottom Z devices to be deleted based on the sorting results.
[0071] In some exemplary embodiments, the device information includes: device type priority, and step 102 includes:
[0072] (i) If the device type priority of the device to which the pending service request belongs is greater than or equal to the first preset priority, determine one or more devices with a device type priority less than the first preset priority in the current device processing range as candidate devices; sort the candidate devices in ascending order of device type priority, delete the top L candidate devices from the device processing range, and add the device to which the pending service request belongs to the device processing range to obtain the new device processing range; L is an integer greater than or equal to 1.
[0073] As can be seen, the candidate devices are arranged in ascending order of device type priority. The top L candidate devices are the L devices with the lowest device type priority from the entire pool of candidates, meaning that the L candidate devices with the lowest device type priority are removed from their processing range. This indicates that the node will no longer process service processing requests from devices outside this range, but will instead take over service processing requests from devices with higher priority. Here, L is flexibly set based on the processing capacity of the nodes in the cluster and / or the service volume of devices with higher device type priority; it can be pre-configured or dynamically calculated. For example, if L is 1, it means that one device is selected at a time to be replaced. It should be noted that when multiple candidate devices have the same device type priority, one or more devices can be randomly selected to be replaced.
[0074] In some exemplary embodiments, the device information includes: device type priority and device activity level, and step 102 includes:
[0075] (ii) If the device type priority of the device to which the pending service request belongs is greater than or equal to the first preset priority, determine one or more devices with a device type priority less than the first preset priority in the current device processing range as candidate devices; sort the candidate devices in ascending order of device activity, delete the top M candidate devices from the device processing range, and add the device to which the pending service request belongs to the device processing range to obtain the new device processing range; M is an integer greater than or equal to 1.
[0076] As can be seen, the candidate devices are sorted in ascending order of device activity. The top M candidate devices are those with the lowest activity levels from the total number of candidate devices. This means the M candidate devices with the lowest activity levels are removed from the node's processing range, indicating that the node will no longer process service requests from devices outside this range, but will instead take over service requests from higher-priority devices. The value of M is flexibly set based on the processing capacity of the nodes in the cluster and / or the workload of higher-priority devices of the device type; it can be pre-configured or dynamically calculated. For example, if M is 1, it means that one device is selected at a time for replacement. It should be noted that when multiple candidate devices have the same activity level, one or more replacement devices can be randomly selected from among them.
[0077] In some exemplary embodiments, the device information includes: device type priority and device activity level, and step 102 includes:
[0078] (iii) If the device type priority of the device to which the pending service request belongs is greater than or equal to the first preset priority, determine one or more devices with a device type priority less than the first preset priority in the current device processing range as candidate devices; sort the candidate devices in ascending order of device type priority and device activity, delete the top P candidate devices from the device processing range, and add the device to which the pending service request belongs to the device processing range to obtain the new device processing range; P is an integer greater than or equal to 1.
[0079] As can be seen, the candidate devices are sorted in ascending order based on device type priority and device activity, specifically with device type priority as the first sorting field and device activity as the second sorting field. All candidate devices are first sorted by device type priority in ascending order, and if device type priorities are the same, they are then sorted by device activity in ascending order. The device ranked first is the candidate device with the lowest device type priority and the lowest device activity. Therefore, those skilled in the art can understand which devices are included in the sorted top P candidate devices. Removing these top P candidate devices from the node's processing scope indicates that the node will no longer process service processing requests from devices outside this scope, but will instead take over service processing requests from devices with higher priority. Here, P is flexibly set and configurable based on the processing capacity of nodes in the cluster and / or the service volume of devices with higher device type priority. For example, P=1 means that one device is selected at a time to be replaced. It should be noted that when multiple candidate devices have the same activity level, one or more devices can be randomly selected to be replaced.
[0080] It should be noted that L, M, and P are each set separately, and they can be the same or different.
[0081] In some exemplary embodiments, the device information includes: device type priority and device activity level, and step 102 includes:
[0082] (iv) If the device type priority of the device to which the pending service request belongs is equal to the second preset priority, determine the device with the lowest device type priority and activity level among the devices in the current device processing range that is equal to the second preset priority. If the activity level of the candidate device is less than that of the device to which the pending service request belongs, delete the candidate device from the device processing range and add the device to which the pending service request belongs to the device processing range to obtain the new device processing range.
[0083] As can be seen, when the device type priority of the pending business request is the same as the device type priority of the devices in the current processing range of the node, the device with the lowest activity level is selected from the current processing range and replaced, so that the business processing requests of the more active device are given priority in the case of the same device type priority.
[0084] It should be noted that the first and second preset priorities mentioned above can be set independently, and their relative importance is not limited. In some exemplary embodiments, where there is no conflict, steps (a) to (iv) above can be combined to implement step 102.
[0085] In some exemplary embodiments, a first preset priority is higher than a second preset priority.
[0086] In some exemplary embodiments, step 102 includes:
[0087] If it is determined that the device to which the pending service request belongs is not within the processing range of the current device, a new processing range is determined based on the device information of the device to which the pending service request belongs and the device information of the devices within the processing range of the current device.
[0088] When a node receives a pending service request, it first determines whether the request belongs to a device that falls within its current processing range. If it does, it means the request did not originate from a newly acquired device, and there is no need to redetermine its processing range. If the request does not, it means the request originated from a newly acquired device, and in this case, the node needs to redetermine its processing range. This ensures that service requests from higher-priority and / or more active devices can be processed by the node, while sacrificing service requests from lower-priority and / or less active devices that originally belonged to the node's processing range. This aims to optimize the performance of the entire cluster system.
[0089] In some exemplary embodiments, the method further includes, before determining the new device processing range:
[0090] Step 1011: Obtain the current load parameters of the node. Determine whether the node is running under high load based on the preset load threshold and the current load parameters. If it is determined to be running under high load, proceed to step 102.
[0091] The preset load parameters include at least one of the following: memory utilization, processor utilization, and I / O throughput. The corresponding preset load thresholds vary depending on the obtained load parameters.
[0092] Those skilled in the art will understand that if a node's current load parameters exceed a preset load threshold, it indicates that the node is currently operating under high load and is unable to take over new device service processing requests without abandoning existing service processing requests from other devices. Specifically, those skilled in the art can obtain the node's load parameters and determine whether it is operating under high load according to relevant solutions; the embodiments disclosed herein do not limit the specific solutions. The obtained load parameters are also not limited to the aspects illustrated above.
[0093] In some exemplary embodiments, the device activity level is a numerical value that characterizes the business activity of a device, dynamically determined based on the number of historical events generated by one or more devices within a defined range in the cluster.
[0094] In some exemplary embodiments, the historical events are historical events of preset active event types. Accordingly, the number of these preset active event types of historical events is also referred to as the corresponding number of active events or the active event base.
[0095] In some exemplary embodiments, one or more devices within a defined range in the cluster are:
[0096] A device in the cluster is a numerical value representing the device's business activity level, dynamically determined based on the number of its own historical events.
[0097] or,
[0098] All devices in the cluster, i.e., a value representing the business activity level of the devices dynamically determined based on the number of historical events of all devices in the cluster;
[0099] or,
[0100] The cluster includes multiple devices (not all devices), including the current device. This value, which represents the business activity level of a device, is dynamically determined based on the number of historical events of multiple devices (not all devices) in the cluster, including the current device.
[0101] In some exemplary embodiments, the device activity level is calculated according to the activity level calculation rules when the calculation trigger conditions are met.
[0102] In some exemplary embodiments, the device activity level is calculated according to activity calculation rules when the calculation trigger condition is met, including:
[0103] When the calculation trigger condition is met, and the device type priority of the device is determined to be greater than or equal to the first preset priority, the device activity is calculated according to the activity calculation rules.
[0104] In some exemplary embodiments, satisfying the computation triggering condition includes at least one of the following:
[0105] The set statistical unit time interval has arrived;
[0106] The set statistical time point has arrived;
[0107] The scheduled event has occurred.
[0108] For example, if the statistical unit time interval is 1 day, it means that activity is calculated (statistically) once a day. Then, if the calculation trigger condition is met every 24 hours, an activity calculation will be triggered. For example, if the statistical unit time interval is 2 hours, it means that activity is calculated (statistically) once every 2 hours. Then, if the calculation trigger condition is met every 2 hours, an activity calculation will be triggered.
[0109] For example, if the set statistical time is 2:00 AM every Sunday, then every Sunday at 2:00 AM, the set statistical time will arrive, triggering an activity calculation. This activity calculation uses a preset unit of time as the calculation time unit to determine the corresponding calculation result.
[0110] For example, specific events include: the cumulative number of new business requests processed by a node reaching a set threshold, such as triggering an activity calculation every time a node completes 10,000 new business requests. Other events include: the addition of a new device to the cluster.
[0111] Those skilled in the art can determine the calculation triggering conditions that need to be triggered for activity calculation based on the business characteristics of each system, and are not limited to the examples above.
[0112] In some exemplary embodiments, the device activity level is calculated according to the activity level calculation rules, including:
[0113] (i) Determine the base number of active events for the device within a unit of time based on the preset active event types; use the base number of active events for the device within a unit of time as the activity level of the device;
[0114] or,
[0115] (ii) Determine the base number of active events for all devices in the cluster within a unit time period based on the preset active event types; determine the base number level of active events for each device based on the distribution of the base number of active events for all devices within a unit time period, and use the base number level of active events as the activity level of each device.
[0116] In some exemplary embodiments, the preset active event types include:
[0117] Preset level alarm events,
[0118] Preset level of illegal events,
[0119] Preset operation.
[0120] The preset alarm events can include one or more types, the preset violation events can include multiple types, and the preset operations can also include one or more types. For example, preset active event type 1 includes: Level 1 alarm events, Level 2 alarm events, violation events of Level 2 or higher, device update operations, and device restart operations. Alternatively, preset active event type 2 includes: alarm events of Level 2 or higher, Level 2 violation events, Level 3 violation events, device update operations, device restart operations, and device parameter adjustment operations.
[0121] As can be seen, these active event types are events that may occur on various devices and are selected to reflect the activity level of the devices. When the business processing application provided in this disclosure is used with different business systems, the appropriate event types can be selected, and are not limited to the content of the examples in this disclosure.
[0122] In some exemplary embodiments, determining the active event base AE (Active Event) of the device within a unit time period based on a preset active event type includes:
[0123] The number of active events that occur within a unit of time is used as the baseline for the number of active events.
[0124] For example, if the unit of time is 1 day and the preset active event type is 1, then the total number of Level 1 alarm events, Level 2 alarm events, Level 2 or higher illegal events, device update operations, and device restart operations that occur on the device within 1 day will be counted. For example, if there are 300 Level 1 alarm events, 50 Level 2 alarm events, 59 Level 2 or higher illegal events, 0 device update operations, and a total of 2 device restart operations within 1 day, then the base number of active events (AE) for the device within 1 day is determined to be 300 + 50 + 59 + 0 + 2 = 411.
[0125] In some exemplary embodiments, determining the active event base AE of the device within a unit time period based on a preset active event type includes:
[0126] The number of active events of each active event type occurring on the device within a unit of time.
[0127] The active event base number is calculated based on the number of active events of each active event type and the weight of the active event type.
[0128] For example, if the unit of time is 1 day and the preset active event type is 1, then the total number of times the device experiences Level 1 alarm events (weight 1), Level 2 alarm events (weight 2), illegal events of Level 2 or higher (weight 1), device update operations (weight 1), and device restart operations (weight 3) within 1 day is counted. For example, if there are 300 Level 1 alarm events, 50 Level 2 alarm events, 59 illegal events of Level 2 or higher, 0 device update operations, and a total of 2 device restart operations within 1 day, then the base number of active events AE for the device within 1 day is determined to be 300*1 + 50*2 + 59*1 + 0*1 + 2*3 = 465.
[0129] As can be seen, devices in the system trigger device activity calculations when the calculation conditions are met. The active event base calculated for different devices at different statistical (calculation) unit times may vary significantly. For example, today the calculated active event base AE for devices in the system may range from a high of 5000 to a low of 4000, while yesterday it ranged from a high of 200 to a low of 10. In this case, using only the active event base of the device itself cannot accurately reflect the differences in activity between devices. Therefore, data aggregation is needed to more accurately reflect the activity of devices within the overall system.
[0130] In some exemplary embodiments, the active event base number of all devices in the cluster within a unit time period is first determined according to a preset active event type; then, the active event base number level of each device is determined according to the distribution of the active event base number of all devices within a unit time period, and the active event base number level is used as the activity level of each device.
[0131] Specifically, based on the distribution of the active event base of all devices within a unit of time, the active event base level of each device is determined, including one of the following:
[0132] (1) Sort the active event base number of all devices in the system in ascending order within a unit time, and use the sorting order as the active event base number level of each device.
[0133] (2) Sort the active event base number of all devices in the system in ascending order within a unit time, divide all sorted devices into Y device intervals with the first device quantity step size, and use the order of the device interval to which each device belongs as its own active event base number level.
[0134] (3) Sort the active event base numbers of all devices in the system in ascending order within a unit time. Divide the active event base numbers of all devices after sorting into Z base number intervals with the first active event base number step size. Each device takes the order of its own active event base number interval as its own active event base number level.
[0135] Taking a video surveillance system as an example, if the system has 200 devices (cameras) and the unit of time is 1 day, then the active event base number of the 200 cameras calculated on that day is: (Camera 1, Camera 2, Camera 3, ..., Camera 200: 100, 320, 398, ..., 10). The active event base number level for each camera can be determined by one of the following:
[0136] (1) Sort the cameras in ascending order of active event base number to get (Camera 3, Camera 2, Camera 1, ..., Camera 200: 398, 320, 100, ..., 10). The order of each camera is used as its own active event base number level, which is (Camera 3, Camera 2, Camera 1, ..., Camera 200: 200, 199, 198, ..., 1).
[0137] (2) Sort the data in ascending order by the number of active events, resulting in (Camera 3, Camera 2, Camera 1, ..., Camera 200: 398, 320, 100, ..., 10). The first step size for the number of devices is 2. Therefore, each pair of cameras forms a device interval, resulting in 100 intervals. These 100 intervals correspond to levels 1 to 100. Each device's active event base level is determined by the order of its assigned device interval, resulting in (Camera 3, Camera 2, Camera 1, ..., Camera 200: ...).
[0138] 100, 100, 99, ... 1).
[0139] (3) Sort the active event base in ascending order to get (Camera 3, Camera 2, Camera 1, Camera 4, ... Camera 200: 398, 320, 102, 100, ... 10). The first active event base step size is 10. Then, with a step size of 10, the active event base of all devices is divided into 40 intervals with corresponding levels from 1 to 40. Each device takes the order of its own active event base interval as its own active event base level, which is (Camera 3, Camera 2, Camera 1, ... Camera 200: 40, 33, 11, 11 ... 2).
[0140] As can be seen, the methods (1), (2), and (3) above use the active event base number of other devices in the system as a reference to determine the active event base number level based on the overall distribution of active event base numbers, and use this level as the device activity level. Based on the above examples, it can be understood that device activity level is used to reflect the activity level of a device in the business system, thereby characterizing the importance of the device. The active event base number level of each device is determined based on the distribution of active event base numbers of all devices within a unit of time, thus reflecting the relative activity level of each device in the system. Those skilled in the art can determine other equivalent or similar solutions based on the above examples, and are not limited to the methods described in this disclosure.
[0141] As can be seen, the device activity level at a certain time or the device activity level at the last statistical moment can be determined based on aspects (i) or (ii) above. For example, if the unit of time is 24 hours, it represents the device activity level of the most recent day, without reflecting historical status. For example, device A had an activity level of 100 (high activity level) for several days before, but today its activity level is 0 (very low activity level). Judging solely from today's activity level, device A would be the least active device, and under the condition of meeting the deletion criteria, device A would be the first device selected for deletion, or, if the business processing belonging to device A is of the same priority, it could not be taken over by other nodes. In reality, device A may only have a temporary activity level of 0 today. Therefore, processing device A based solely on today's activity level is not very reasonable and can be further improved. Therefore, some improvement schemes combine the device's activity level over multiple days to perform a dynamic scoring to obtain the final device activity level.
[0142] In some exemplary embodiments, the step of calculating the device activity level according to the activity level calculation rules further includes:
[0143] (iii) Determine the base number of active events for the device per unit time based on the preset active event types;
[0144] Obtain the cardinality of the N active events of the device in the most recent N unit time periods, where N is an integer greater than 1;
[0145] The device activity level is calculated based on the N active event bases and their corresponding activity weights.
[0146] In some exemplary embodiments, among the activity weights corresponding to the N active event bases, the closer the unit time corresponding to the active event base is to the current activity calculation time, the greater its corresponding activity weight.
[0147] For example, to calculate device activity on January 7th, with N=7, the base number of active events for the most recent 7 days (January 1st to January 7th) is: X1, X2, ..., X7. The activity weights for these 7 days are I1, I2, ..., I7, where I7>I6>I5>I4>I3>I2>I1, indicating that the closer to the current time, the greater the weight. Therefore, the current device activity is calculated as X1*I1+X2*I2+X3*I3+……+X7*I7.
[0148] In some exemplary embodiments, the activity weights corresponding to the N active event bases are determined based on preset time period weight values and the time period to which the unit time corresponding to the active event base belongs.
[0149] It should be noted that the weight values can be determined based on the characteristics of the time period corresponding to the base number of active events. For example, for a video surveillance system, cameras around shopping malls have high pedestrian or vehicular traffic on weekends, so the weight of these devices can be set higher on weekends; cameras around schools have high traffic from Monday to Friday, so the weight of these devices can be set higher from Monday to Friday.
[0150] For example, to calculate the activity level of devices near a shopping mall on January 7th, with N=7, the base number of active events for the most recent 7 days (January 1st to January 7th, corresponding to Monday to Sunday) is: Y1, Y2, ..., Y7. The activity weights for these 7 days are I1, I2, ..., I7, where I7 and I6 are greater than I5, I4, I3, I2, and I1, indicating that the weight of weekend time periods is greater than the weight of Monday to Friday time periods. Therefore, the current device activity level is calculated as Y1*I1 + Y2*I2 + Y3*I3 + ... + Y7*I7.
[0151] (iv) Determine the base number of active events for all devices in the cluster within a unit of time based on the preset active event types; determine the base number level of active events for each device based on the distribution of the base number of active events for all devices within a unit of time.
[0152] Get the cardinality levels of N active events in the device over the most recent N time units, where N is an integer greater than 1;
[0153] The device activity level is calculated based on the N active event base levels and their corresponding activity weights.
[0154] The N active event baseline levels can be determined using the aforementioned method. For example, if the unit time is 24 hours and N is 7, then the seven active event baseline levels for the most recent seven days are obtained. Then, based on these seven active event baseline levels and a preset activity weight, the device activity level is calculated. It can be seen that the device activity level calculated in this way can reflect historical activity to a certain extent, allowing the method-based device activity level to more reasonably reflect the device status and reduce the impact of individual abnormal situations on takeover decisions.
[0155] In some exemplary embodiments, among the activity weights corresponding to the N active event base levels, the closer the unit time corresponding to the active event base level is to the current activity calculation time, the greater its corresponding activity weight.
[0156] For example, to calculate device activity on January 7th, with N=7, the base level of active events for the most recent 7 days (January 1st to January 7th) is: A1, A2, ..., A7. The activity weights for these 7 days are I1, I2, ..., I7, where I7>I6>I5>I4>I3>I2>I1, indicating that the closer to the current time, the greater the weight. Therefore, the current device activity is calculated as A1*I1+A2*I2+A3*I3+……+A7*I7.
[0157] In some exemplary embodiments, the activity weights corresponding to the N active event base levels are determined based on preset time period weight values and the time period to which the unit time corresponding to the active event base level belongs.
[0158] It should be noted that the weight value can be determined based on the characteristics of the time period corresponding to the active event base level. For example, for a video surveillance system, cameras around shopping malls have high pedestrian or vehicular traffic on weekends, so the weight of these devices can be set higher on weekends; cameras around schools have high traffic from Monday to Friday, so the weight of these devices can be set higher from Monday to Friday.
[0159] For example, to calculate the activity level of devices near a shopping mall on January 7th, with N=7, the base level of active events for the most recent 7 days (January 1st to January 7th, corresponding to Monday to Sunday) is: A1, A2, ..., A7. The activity weights for these 7 days are I1, I2, ..., I7, where I7 and I6 are greater than I5, I4, I3, I2, and I1, indicating that the weight of weekend time periods is greater than the weight of Monday to Friday time periods. Therefore, the current device activity level is calculated as A1*I1 + A2*I2 + A3*I3 + ... + A7*I7.
[0160] It should be noted that determining device activity according to schemes (iii) or (iv) can take into account historical data and more accurately reflect device activity. Based on aspects of the embodiments of this disclosure, those skilled in the art can flexibly select weighting schemes according to the characteristics of the application system's business data, and are not limited to the aspects of the above examples. It can be seen that the business processing schemes of the embodiments of this disclosure have multiple optional activity calculation rules and weighting schemes. In a given business system, it is not limited to adopting any specific scheme; at the same time, the device activity calculation of all devices uses the same activity calculation rule, and the weighting schemes involved are consistent. That is, ensuring that the activity of all devices is calculated according to the same rule is sufficient for effective comparability and to achieve the expected technical objectives.
[0161] In some exemplary embodiments, step 103, processing the pending service request according to the new device processing range, includes:
[0162] Based on the new device processing range determined in step 102, if the device to which the pending service request belongs is within the new device processing range, the node processes the pending service request; if the device to which the pending service request belongs is not within the new device processing range, the node does not continue to process the pending service request.
[0163] It is understandable that when the device to which a pending service request belongs is not added to the new device processing scope, it indicates that the current node has not found a replacement device for the device to which the newly received pending service request belongs. If the priority of the device to which the pending service request belongs is not higher than the devices originally handled by the current node, and the current node's processing capacity is insufficient to receive and process all of them, the current node cannot smoothly take over the new task from the device to which it belongs. Therefore, if the current node determines that the device to which the pending service request belongs is not within the new device processing scope, it will not process the pending service request.
[0164] In some exemplary embodiments, the method further includes:
[0165] Step 104: If, based on the new device processing range, the device to which the pending service request belongs is not within the new device processing range, the pending service request is forwarded to other available nodes in the cluster.
[0166] As can be seen, when the current node cannot successfully take over the service processing request from the "new" device, it can forward the pending service request to other available nodes. The other available nodes then determine the corresponding service processing procedure according to steps 101-103 above.
[0167] According to the business processing scheme provided in the embodiments of this disclosure, when an unpredictable anomaly occurs in the cluster system of the business system, the available nodes in the cluster can selectively take over the business of the faulty node. This can prioritize the business processing of devices with higher device type priority and / or higher device activity, and ensure that the relevant business data of critical devices is not lost as much as possible, thereby improving the availability and performance of the overall business system.
[0168] This disclosure provides a business processing method. Taking a video surveillance system as an example, the cluster system includes multiple distributed nodes that share the processing of business data generated by cameras at multiple locations. The overall business processing method is as follows: Figure 2 As shown.
[0169] In this system, camera device type priorities are divided into two levels: A and B. Level A cameras indicate that they have the highest device type priority and are the first preset priority. Level A cameras do not require activity calculation. Level B cameras indicate that they have a relatively low device priority and require activity calculation. Each camera in the video surveillance system has its device type priority set according to its deployment characteristics.
[0170] Step 1 - Adding Camera Points:
[0171] Add camera locations to the system and set the device type priority for each camera. Cameras set to level A are also called Class A locations, and cameras set to level B are also called Class B locations.
[0172] Step 2 - Activity Calculation:
[0173] 2.1 Setting Activity Calculation Trigger Conditions: In this embodiment of the video surveillance system, the calculation trigger condition is that, using a 24-hour unit of time, every 24 hours, at 2:00 AM, each Class B camera in the system is triggered to perform device activity calculations. The video surveillance system includes 200 Class B cameras.
[0174] 2.2 Set active event types, including:
[0175] R1, the number of alarms of "important" level or above reported by this camera today;
[0176] R2, the number of operations performed by the user on this camera today; including software upgrades, camera parameter adjustments, etc.
[0177] ...
[0178] RN, the number of violations reported by this camera today.
[0179] 2.3 Daily statistics of active events for each camera (AE)
[0180] Based on the above-mentioned preset active event types, the daily active event base number for 200 Class B cameras is calculated at 2:00 AM each day as follows: Camera 1-320, Camera 2-100, Camera 3-398, Camera 4-12, Camera 5-88, ... Camera 200-10;
[0181] 2.4 Calculate the base number of daily active events for each camera
[0182] Based on the distribution of active event base numbers for all cameras in the daily statistics, the active event base number level for each camera on that day is determined, including:
[0183] The 200 Class B cameras are sorted in ascending order by their active event base number, resulting in the following order: Camera 200-10, Camera 4-12, ..., Camera 5-88, Camera 2-100, Camera 1-320, Camera 3-398. These 200 cameras are then divided into 100 intervals. Using a step size of 2 cameras, the sorted cameras are further divided into 100 intervals, with 2 cameras per interval. The order in which each camera belongs to an interval serves as its active event base number level: Camera 200-1, Camera 4-1, ..., Camera 5-99, Camera 2-99, Camera 1-100, Camera 3-100.
[0184] 2.5 Calculate the daily device activity of each camera
[0185] Option 1: Calculate the device activity level Q for each camera based on the 7-day activity event baseline and corresponding weighting ratio, including:
[0186] Q = Today's activity event base level (A7) * weight (I17) + Yesterday's activity event base level (A6) * weight (I16) + ... + 7 days ago activity event base level * weight (I11);
[0187] Among them, the more recent the time, the higher the weight. Today's weight is I17, which is the highest, and 7 days ago's weight is I11, which is the lowest.
[0188] Option 2: The device activity level Q for each camera will be calculated based on the 7-day activity event baseline and corresponding weighting ratio, including:
[0189] Q = Today's activity event base level (A7) * Saturday weight (I27) + Yesterday's activity event base level (A6) * Friday weight (I26) + ... + 7 days ago's activity event base level * Sunday weight (I21);
[0190] Today is Saturday, and 7 days ago was Sunday. The weights for these two days, I27 and I21, are higher than those for other days.
[0191] The business processing method provided in this disclosure is applied to nodes in a cluster, such as... Figure 2 As shown, it includes:
[0192] Step 3 - Takeover of other camera business:
[0193] If it is determined that the pending business request belongs to a Class A camera, the lowest-activity Class B camera is removed from the processing range of the device itself, and the business processing task of the camera to which the pending business request belongs is taken over.
[0194] If it is determined that the pending service request belongs to a Class B camera, the activity level of the belonging camera is compared with the minimum activity level among Class B cameras within the processing range of the device. If the activity level is higher than the minimum activity level among its own Class B cameras, the camera with the minimum activity level among its own Class B cameras is removed, and the device takes over the service processing task of the camera to which the pending service request belongs. If the activity level is less than or equal to the minimum activity level, the device does not take over the service processing task of the camera to which the pending service request belongs.
[0195] In some exemplary embodiments, the service processing node or server performs step 3 as follows: Figure 3 As shown, it includes:
[0196] Step 301: Receive pending service requests;
[0197] Step 302: Determine if the device is currently running under high load; if so, proceed to step 303.
[0198] Step 303: Determine whether the camera to which the service request to be processed belongs is within the processing range of the device itself. If it is not within the processing range of the device itself, proceed to step 304.
[0199] Step 304: Determine the new device processing range based on the device information (camera information) of the camera to which the pending service request belongs and the device information (camera information) of the devices within the current processing range of the device itself;
[0200] Step 305: Process the pending service request according to the new device processing range.
[0201] Step 304 includes:
[0202] When the pending business request belongs to a Class A camera, select the Class B camera with the lowest device activity from the current processing range of the device.
[0203] Remove the selected Class B camera from its own processing range, and add the camera to which the pending business request belongs to its own processing range to determine the new processing range.
[0204] Accordingly, step 305 includes: the node taking over the pending request and performing the corresponding business processing.
[0205] When the pending business request belongs to a Class B camera, select the Class B camera with the lowest device activity from the current processing range of the device.
[0206] The device activity of the selected Class B camera is compared with the device activity of the camera to which the pending service request belongs. When the device activity of the camera to which the pending service request belongs is greater than that of the selected Class B camera, the selected Class B camera is removed from its own device processing range, and the camera to which the pending service request belongs is added to its own device processing range to determine a new device processing range. Accordingly, step 305 includes: the node takes over the pending request and performs the corresponding service processing.
[0207] When the device activity level of the camera to which the pending service request belongs is less than or equal to the device activity level of the selected Class B camera, the current device processing range of the node is not changed; accordingly, step 305 includes: the node does not take over the pending request and does not perform the corresponding service processing.
[0208] As can be seen, the solution provided in this disclosure is applied to a video surveillance (management) system implemented with a cluster solution. When an unpredictable anomaly occurs in the video surveillance (management) cluster, priority can be given to ensuring the services of camera points with high activity (such as points that frequently report alarms or where illegal events frequently occur), thus minimizing the loss of critical video, alarm, and image data and improving the overall availability of monitoring. When a node in the cluster fails, other nodes selectively take over services based on camera point location, prioritizing services according to camera device type and / or device activity, ensuring that service data at critical points is processed first, reducing the loss or processing failure of critical service data, and optimizing the overall performance of the system when the overall redundancy of the video surveillance (management) system is limited.
[0209] This disclosure also provides an electronic device, including:
[0210] One or more processors;
[0211] Storage device for storing one or more programs.
[0212] When the one or more programs are executed by the one or more processors, the one or more processors implement the business processing method as described in any of the above embodiments.
[0213] This disclosure also provides a computer-readable storage medium having a computer program stored thereon, the program being implemented by a processor using the business processing method described in any of the above embodiments.
[0214] Those skilled in the art will understand that, when processing data recorded by other applications using cluster solutions, sampling the data processing scheme provided in the embodiments of this disclosure can ensure that each node in the cluster can relatively consistently cache and process data from a defined partition. This avoids conflicts in data caching and processing by multiple nodes in the cluster, and also avoids excessive data caching by each node due to random allocation of processing nodes, significantly improving the processing performance and stability of the cluster system. The vehicle passage record aggregation scheme described in the embodiments of this disclosure is used to illustrate relevant details and does not limit the scope of application of the embodiments of this disclosure.
[0215] It will be understood by those skilled in the art that all or some of the steps, systems, or apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all components may be implemented as software executed by a processor, such as a digital signal processor or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software may be distributed on a computer-readable medium, which may include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and can be accessed by a computer. Furthermore, it is well known to those skilled in the art that communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.
[0216] The above description is only a preferred embodiment of the present invention and does not limit the patent scope of the present invention. All equivalent structural transformations made under the concept of the present invention using the contents of the present invention specification and drawings, or direct / indirect applications in other related technical fields, are included within the patent protection scope of the present invention.
Claims
1. A business processing method, characterized in that, Applied to business processing nodes or servers, the method includes: Receive pending service requests and obtain device information of the device to which the pending service request belongs; Based on the device information of the device to which the pending service request belongs and the device information of the devices within the current processing range of the current device, a new device processing range is determined; wherein, the device information includes: device type priority and / or device activity; The pending service requests are processed according to the new device processing range; The step of determining a new device processing range based on the device information of the device to which the pending service request belongs and the device information of devices within its current processing range includes: Based on device type priority and / or device activity, determine at least one candidate device from the devices within the current processing range of the device itself; If the candidate device is determined to meet the deletion conditions, the candidate device is deleted from its own device processing scope, and the device to which the pending service request belongs is added to its own device processing scope to obtain the new device processing scope. The determination that the candidate device meets the deletion criteria includes one of the following: If the device type priority of the candidate device is lower than the device type priority of the device to which the pending service request belongs, the candidate device is determined to meet the deletion criteria. If the device activity level of the candidate device is lower than the device activity level of the device to which the pending service request belongs, the candidate device is determined to meet the deletion criteria. If the device type priority of the candidate device is equal to the device type priority of the device to which the pending service request belongs, and the device activity of the candidate device is less than the device activity of the device to which the pending service request belongs, then the candidate device is determined to meet the deletion condition. If the activity level of the candidate device is equal to the activity level of the device to which the pending service request belongs, and the device type priority of the candidate device is lower than the device type priority of the device to which the pending service request belongs, then the candidate device is determined to meet the deletion criteria.
2. The method as described in claim 1, characterized in that, The device activity level is a numerical value that characterizes the business activity of a device, determined based on the number of historical events generated by one or more devices within a defined range in the cluster.
3. The method as described in claim 1, characterized in that, The step of determining at least one candidate device from the devices within its current processing range based on device type priority and / or device activity includes: Based on device type priority and / or device activity, the devices within the current processing range of the device are sorted according to a preset method, and at least one candidate device is determined based on the sorting result.
4. The method according to any one of claims 1-3, characterized in that, The step of determining a new device processing range based on the device information of the device to which the pending service request belongs and the device information of devices within its current processing range includes: If it is determined that the device to which the pending service request belongs is not within the processing range of the current device, a new processing range is determined based on the device information of the device to which the pending service request belongs and the device information of the devices within the processing range of the current device.
5. The method as described in claim 1 or 2, characterized in that, The device activity level is calculated according to the activity level calculation rules when the calculation trigger conditions are met. The device activity level is calculated according to the activity level calculation rules, including: Based on preset active event types, determine the base number of active events for the device within a unit of time; use the base number of active events for the device within a unit of time as the device activity level. or, Based on the preset active event types, determine the active event base number of all devices in the cluster within a unit of time; based on the distribution of the active event base number of all devices within a unit of time, determine the active event base number level of each device, and use the active event base number level as the device activity level of each device.
6. The method as described in claim 1 or 2, characterized in that, The device activity level is calculated according to the activity level calculation rules when the calculation trigger conditions are met. The device activity level is calculated according to the activity level calculation rules, including: Determine the base number of active events for the device per unit time based on the preset active event types; Obtain the cardinality of the N active events of the device in the most recent N unit time periods, where N is an integer greater than 1; The device activity level is calculated based on the N active event bases and their corresponding activity weights; or, Based on the preset active event types, determine the active event base number of all devices in the cluster within a unit of time; based on the distribution of the active event base number of all devices within a unit of time, determine the active event base number level of each device. Obtain the cardinality levels of the N most recent N active events within the device's time frame, where N is an integer greater than 1; The device activity level is calculated based on the N active event base levels and their corresponding activity weights.
7. The method as described in claim 6, characterized in that, Among the activity weights corresponding to the N active event bases, the closer the unit time corresponding to the active event base is to the current activity calculation time, the greater its corresponding activity weight; or, The activity weights corresponding to the N active event bases are determined based on the preset time period weight values and the time period to which the unit time corresponding to the active event base belongs; or, Among the activity weights corresponding to the N active event base levels, the closer the unit time corresponding to the active event base level is to the current activity calculation time, the greater its corresponding activity weight. or, The activity weights corresponding to the N active event base levels are determined based on the preset time period weight values and the time period to which the unit time corresponding to the active event base level belongs.
8. An electronic device, characterized in that, include: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the business processing method as described in any one of claims 1-7.
9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the business processing method as described in any one of claims 1-7.