Alarm data interaction method, system, device, storage medium and program product

Abstract

The application discloses an alarm data interaction method, system, device, storage medium and program product, relates to the technical field of data interaction, and is applied to an alarm data interaction system. The alarm data interaction system comprises a background service end of a data cluster and a UI view service end which is communicatively connected with the background service end based on micro-service technology. The method comprises the following steps: acquiring registration protocol information sent by the UI view service end, wherein the registration protocol information comprises an instance identifier and instance data; determining target protocol data according to the instance identifier and the instance data, and determining target alarm data in the background service end according to the target protocol data, so as to interact the target alarm data to the UI view service end. The application improves the efficiency of alarm data interaction.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data interaction, and particularly relates to an alarm data interaction method, system, device, storage medium and program product. BACKGROUND

[0002] With the continuous development of technology, the application of the alarm flow window in the field of alarm monitoring is also more and more frequent, and therefore users have higher requirements for alarm data interaction.

[0003] At present, when interacting with alarm data, the real-time data pulling, historical data synchronization, alarm details and the like corresponding API interfaces are usually provided by a background service through a micro-service Rest (Resource Representational State Transfer, architecture style of state transition) API (Application Programming Interface, application program interface) interface, and a UI (User Interface, user interface) view service completes corresponding data acquisition / data update by calling the API interface in a timing or on-demand manner. However, this alarm data interaction mode needs to call the API interface in a timing or on-demand manner to complete corresponding data acquisition / data update, thereby causing low efficiency of alarm data interaction. SUMMARY

[0004] The main purpose of the present application is to provide an alarm data interaction method, system, electronic device and readable storage medium, and aims to solve the technical problem of low efficiency of alarm data interaction.

[0005] To achieve the above purpose, the present application provides an alarm data interaction method, which is applied to an alarm data interaction system, the alarm data interaction system comprising a background service end of a data cluster and a UI view service end in communication connection with the background service end based on micro-service technology, and the alarm data interaction method comprising:

[0006] obtaining registration protocol information sent by the UI view service end, wherein the registration protocol information comprises an instance identifier and instance data;

[0007] determining target protocol data according to the instance identifier and the instance data, and determining target alarm data in the background service end according to the target protocol data, so as to interact the target alarm data to the UI view service end.

[0008] To achieve the above object, the application further provides an alarm data interaction system, which comprises a background server of a data cluster, a UI view server and a controller in communication connection with the background server based on micro-service technology, the controller being connected with the background server and the UI view server, and the controller comprising:

[0009] a protocol acquisition module configured to acquire registration protocol information sent by the UI view server, wherein the registration protocol information comprises instance identification and instance data;

[0010] a data interaction module configured to determine target protocol data according to the instance identification and the instance data, and determine target alarm data in the background server according to the target protocol data, so as to interact the target alarm data to the UI view server.

[0011] The application further provides an alarm data interaction device, which comprises at least one processor and a memory in communication connection with the at least one processor, the memory storing instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the steps of the alarm data interaction method as described above.

[0012] The application further provides a storage medium, which stores a program for implementing an alarm data interaction method, and the program for implementing the alarm data interaction method is executed by a processor to perform the steps of the alarm data interaction method as described above.

[0013] The application further provides a program product, which comprises an alarm data interaction program, and the alarm data interaction program is executed by a processor to perform the steps of the alarm data interaction method as described above.

[0014] The alarm data interaction method of the application is applied to an alarm data interaction system, which comprises a background server of a data cluster and a UI view server in communication connection with the background server based on micro-service technology, registration protocol information sent by the UI view server is acquired, wherein the registration protocol information comprises instance identification and instance data; target protocol data is determined according to the instance identification and the instance data, and target alarm data in the background server is determined according to the target protocol data, so as to interact the target alarm data to the UI view server.

[0015] The target protocol data can be determined based on the target protocol data determined by the registration protocol information sent by the UI view server, and the target alarm data can be determined directly to realize the interaction of the target alarm data to the UI view server. Thus, the problem that the corresponding data acquisition / data update can be completed only by calling the API interface in a timely manner or on demand in the prior art is avoided, and the target alarm data for interaction can be determined directly after the target protocol data is determined by the registration protocol information sent by the UI view server, thereby avoiding the phenomenon that the corresponding data acquisition / data update can be completed only by calling the API interface in a timely manner or on demand, so as to improve the efficiency of alarm data interaction. BRIEF DESCRIPTION OF DRAWINGS

[0016] The accompanying drawings, which are incorporated herein and constitute part of the specification, illustrate embodiments consistent with the application and, together with the description, serve to explain the principles of the application.

[0017] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the accompanying drawings needed to be used in the embodiments or prior art description will be briefly introduced. Obviously, those skilled in the art can obtain other drawings according to these drawings without any creative effort.

[0018] Figure 1 A flowchart of an alarm data interaction method provided by the first embodiment of the present application is shown in the figure.

[0019] Figure 2 A flowchart of an alarm data interaction method provided by the first embodiment of the present application is shown in the figure.

[0020] Figure 3 A flowchart of an alarm data interaction method provided by the fifth embodiment of the present application is shown in the figure.

[0021] Figure 4 A structural diagram of an alarm data interaction system provided by the sixth embodiment of the present application is shown in the figure.

[0022] Figure 5 A structural diagram of an electronic device provided by the seventh embodiment of the present application is shown in the figure.

[0023] The object, functional features and advantages of the present application will be further illustrated with reference to the embodiments and the accompanying drawings. DETAILED DESCRIPTION

[0024] In order to make the above objectives, characteristics and advantages of the present application more obvious and easy to understand, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, not all. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative labor fall within the scope of protection of the present application.

[0025] Embodiment one

[0026] Most of the existing water window technical solutions adopt direct micro-service RestAPI interface, and the background service provides real-time data pulling, historical data synchronization, alarm details and corresponding API interfaces. The UI view service completes corresponding data acquisition / data update by calling these API interfaces in a timely manner or on demand. That is, only when the user needs to actively call can data acquisition and update be completed, and multiple calls are required if multiple data are needed, which causes inefficient processing and makes it difficult to meet the high real-time and high concurrency requirements. Moreover, the user needs to actively operate, so the API interface needs to correspond to all alarm data at any time, which lacks effective support for dynamic scalability and fault tolerance of alarm data in interaction. Further to solve the problem of low efficiency of alarm data interaction, the technical solution of the present application is proposed.

[0027] The embodiment of the present application provides an alarm data interaction method. In the first embodiment of the alarm data interaction method of the present application, referring to Figure 1 , the alarm data interaction method is applied to an alarm data interaction system, the alarm data interaction system includes a background service end of a data cluster and a UI view service end in communication connection with the background service end based on micro-service technology, and the alarm data interaction method includes the following steps.

[0028] Step S10, acquiring registration protocol information sent by the UI view service end, wherein the registration protocol information includes instance identification and instance data;

[0029] In the embodiment, the alarm data interaction method is applied to an alarm data interaction system, which at least includes a background server and a UI view server. The background server and the UI view server are communicatively connected based on a micro-service technology. The micro-service technology can be an RPC (Remote Procedure Call Protocol) mode of a dubbo (a distributed service framework), or other micro-service technologies such as a RestAPI. Here, the dubbo is taken as an example. For example, the dubbo server is embedded in the background server to be started, and the UI view server is built-in with a dubbo client to realize the communicatively connection of the background server and the UI view server based on the RPC mode of the dubbo. The background server adopts a cluster, and the UI view server also adopts a cluster mode, such as using a kafka real-time technology for clustering. The background server and the UI view server can use a zookeeper for coordination, or use other modes for coordination, such as using self-managed metadata to store partition and broker metadata, and selecting a broker as a controller, a StateSynchronizer, etc. of the Kafka, and realizing the alarm data interaction method of the application through the controller. The controller can be arranged in the UI view server, or arranged in the background server, or arranged separately, which is not limited herein. In the application, the kafka real-time technology and the RPC micro-service of the dubbo are used in combination, and the coordination is performed by using the zookeeper.

[0030] In an embodiment, the background server dynamically manages the list of UI view servers (new access, exit, etc.) by listening to a specified zookeeper path, and the UI view server writes protocol data to the specified zookeeper path, and manages the list of UI view servers by writing and updating heartbeat information. At the same time, real-time alarm data, historical alarm data, and alarm update data are interacted using kafka, and are requested / reacted by setting a dubbo microservice. After obtaining the registration protocol information sent by the UI view server, the background server interacts based on the registration protocol information, that is, selects alarm information to interact based on the registration protocol information for efficient interaction. The registration protocol information includes an instance identifier and instance data corresponding to the instance identifier, and the instance identifier refers to an identifier corresponding to each instance, wherein each instance can uniquely correspond to an alarm data requirement of an opened UI interface, and the UI interface refers to an interface directly interacting with a user, and the instance data refers to related data of the instance identifier, such as kafka information corresponding to the instance identifier, subscription information corresponding to the instance identifier, and heartbeat information corresponding to the instance identifier. That is, the registration protocol information includes at least one instance identifier and instance data corresponding to the instance identifier, and target protocol data can be obtained based on the instance identifier and the instance data corresponding to the instance identifier, so as to efficiently determine target alarm data in the background server based on the target protocol data, and interact the target alarm data to the UI view server, thereby improving the interaction efficiency of the alarm data between the background server and the UI view server.

[0031] In step S20, target protocol data is determined based on the instance identifier and the instance data, and target alarm data is determined in the background server based on the target protocol data, so as to interact the target alarm data to the UI view server.

[0032] In the embodiment, when there is one instance identifier and its corresponding instance data, the target protocol data is determined based on the instance identifier and the instance data corresponding to the instance identifier (i.e., the target protocol data is determined according to the instance identifier and the instance data); when there are multiple instance identifiers and their respective corresponding instance data, the step of determining the target protocol data based on the instance identifier and the instance data corresponding to the instance identifier is sequentially executed, which can also be executed in multi-thread synchronization, which is not limited herein. Taking one instance identifier and its corresponding instance data as an example, it is directly determined whether the instance identifier exists in the online protocol data. For example, the identifiers of the online protocol data are view2, view3 and view4, and the instance identifier is view1. It is determined that the instance identifier does not exist in the online protocol data. The new online protocol data based on the instance identifier view1 is created as the target protocol data. Conversely, if the instance identifier is view2, it is determined that the instance identifier exists in the online protocol data. The online protocol data with the identifier view1 is updated based on the instance data as the target protocol data. The target protocol data refers to the online protocol data that is updated or created based on the instance identifier and the instance data corresponding to the instance identifier. The online protocol data refers to the data that is currently in the working state and is interacted with the selection alarm data. After the target protocol data is determined, because the target protocol data indicates the alarm data that needs to be interacted at this time, the target alarm data is determined in the background server through the target protocol data, and finally the target alarm data is interacted to the UI view server, thereby completing the efficient alarm data interaction between the UI view server and the background server. The target alarm data refers to the alarm data that needs to be interacted, which can be real-time alarm data, historical alarm data and alarm data updated after user interaction. The target alarm data can be quickly determined in the background server through the target protocol data, without the need for the user to call the API interface to complete the data interaction, thereby improving the efficiency of data interaction.

[0033] As an example, the alarm data interaction method comprises the following steps S10-S20: obtaining registration protocol information sent by the UI view server, wherein the registration protocol information comprises instance identification and instance data; determining target protocol data according to the instance identification and the instance data, and determining target alarm data in the background server according to the target protocol data, so as to interact the target alarm data to the UI view server. The target protocol data is determined according to the registration protocol information sent by the UI view server, and the target alarm data can be directly determined based on the target protocol data, so as to realize the interaction of the target alarm data to the UI view server. Thus, the problem that the corresponding data acquisition / data update can be completed only by calling the API interface in a timely manner or on demand in the prior art is avoided. After the target protocol data is determined according to the registration protocol information sent by the UI view server, the target alarm data for interaction can be directly determined, and the phenomenon that the corresponding data acquisition / data update can be completed only by calling the API interface in a timely manner or on demand is avoided, so as to improve the efficiency of the alarm data interaction.

[0034] Embodiment two

[0035] Further, in another embodiment of the present application, the same or similar contents as the above-mentioned embodiment one can be referred to the above introduction, and will not be described in detail hereinafter. On this basis, the target protocol data comprises a first preset filtering condition, and the step of determining the target alarm data in the background server according to the target protocol data comprises:

[0036] Step S21, determining real-time alarm data in the background server, and detecting whether the real-time alarm data meets the first preset filtering condition;

[0037] Step S22, if the real-time alarm data meets the first preset filtering condition, the real-time alarm data meeting the first preset filtering condition is taken as the target alarm data.

[0038] In the embodiment, the combination of the kafka real-time technology and the RPC microservice of dubbo and the coordination using the zookeeper are used. After the use environment of the kafka real-time technology, the RPC microservice of dubbo and the zookeeper is created, a new instance is created based on the opening of the alarm stream window UI interface and the sending of the UI view service side, and the UI view service side can also update based on the existing instance. The UI view service side is usually multi-instance, and one UI view service side can support 150 UI interface connections at the same time. More than 150, usually multiple UI view service sides are opened, and the UI interface is evenly distributed to different UI view service sides according to the algorithm. The background service side is usually a cluster, and is also a multi-instance to form a unified cluster. The UI view service side interacts with the background service side, and the number of opened UI view service sides can be dynamically adjusted based on the number of opened UI interfaces, so as to save internal resources.

[0039] In an embodiment, the following example illustrates a typical target protocol data, which can be in JSON format or other formats. The target protocol data is as follows:

[0040]

[0041] In the filterIdList in subscribe_info, the filter condition specified by the user when opening an alarm stream window on the UI interface is indicated, such as ** province + wireless network, ** province + city + core network and the like. At this time, the filter condition can be integrated into the filter, and an ID is set based on the filter. For example, ** province + wireless network is saved as a filter named “** wireless network”, and the ID is 987091. The user selects a filter on the UI interface when opening an alarm stream window, and the stream window will appear the alarm data meeting the specified filter condition of the filter. The core content of the above target protocol data includes four parts: one is the basic information (identification) of the UI view service; two is to require the background service side to send real-time alarms / historical (synchronous) alarms to the specified kafka and topic name; three is the subscription condition set of real-time alarms, and the background service side sends the real-time alarms meeting the condition to the specified kafka and real-time alarm topic according to the subscription condition. Four is the heartbeat timestamp heartbeat. At this time, the background service side can flexibly and effectively support the dynamic expansion and contraction of the UI view service side.

[0042] In an embodiment, for the interaction of real-time alarm data, each UI view server registers a target protocol data with "kafkainfo" agreement, including the UI view server specified kafka cluster (bootstrap.servers), real-time alarm topic (real_topic), real-time alarm consumer group (real_group), and also has subscribe_info to specify the filter set required by real-time alarm. Refer to Figure 2 , Figure 2The flowchart of the alarm data interaction method of the present application is shown in the figure. Each instance in the background server (i.e. background server instances 1-3 in the figure, each background server instance includes at least message cluster transceiver, micro-service technology service, and distributed task sending function between each background server instance, at this time if the controller is set in the background server, it will also include the function of open source distributed framework monitoring / operation of the UI view service instance) receives a part of real-time alarm data (also a kafka topic, each instance of the background server is responsible for consuming a part) from the message cluster source data queue. Then when determining the target alarm data (at this time the scene of interacting with real-time alarm data), the attributes of the real-time alarm data in each background server instance are detected, and when the first preset filtering condition in the target protocol data is met, the real-time alarm data (real-time data, not historical data) is taken as the target alarm data and stored in the real_topic (real-time warning queue) under the specified cluster address, otherwise, if the first preset filtering condition in the target protocol data is not met, the new real-time alarm data is continuously obtained for detection, and the meaning of meeting is that there is the same condition as the first preset filtering condition, at this time the condition can be represented by ** province + wireless full network or directly represented by ID, which is not limited here. The first preset filtering condition refers to the power condition selected by the user, and there can be at least one filtering condition, which can be equivalent to using a "filter". For example, if a real-time alarm data meets the two conditions of ** province + wireless full network, and the ID defined by ** province + wireless full network is 987091, then the attribute of the real-time alarm data is added with the ID 987091. Then compare the filterIdList set in subscribe_info in the target protocol data, for example, the identification of the target protocol data is view1, and according to the target protocol data with the identification of view1, it is known that the set in filterIdList has 987091, then the real-time alarm data is sent to the real-time alarm queue (real_topic) of the specified kafka cluster in "kafkainfo" of view1. At this time, the controller will continuously detect and send the real-time alarm data meeting the condition from the message cluster source in the background server to the specified kafka and topic of each UI view service, so as to complete the timely sending of real-time alarm data and improve the data interaction efficiency between the UI view service and the background server.

[0043] Embodiment three

[0044] Further, in another embodiment of the present application, the same or similar content as the above embodiment one can be referred to the above description, and the subsequent will not be described. On this basis, the target protocol data includes a start time point, an end time point, a record threshold and a second preset filter condition, and the step of determining the target alarm data in the background server according to the target protocol data comprises:

[0045] In step S23, the time between the start time point and the end time point is split into a subtask duration based on the preset splitting manner, and the historical alarm data corresponding to the subtask duration in the background server is determined;

[0046] In step S24, based on the subtask duration, it is detected whether the historical alarm data meets the second preset filter condition;

[0047] In the present embodiment, when the historical alarm data is synchronized, that is, at this time the user needs to query the historical data of the selected filter condition in the specified time period. The UI view server is completed together by microservices combined with kafka, and the microservices can be implemented by using dubbo rpc. The UI view server calls the dubbo service interface provided by the background server cluster through the controller, and the interface agreement is as follows:

[0048] responseDTO sync_history_alarms(reqID,filterID,start_time,end_time,max_records)

[0049] Wherein, reqID is the request ID identifier, filterID is the specified filter ID (that is, including the second preset filter condition in the filter), start_time is the start time point, end_time is the end time point, and max_records is the record threshold. Finally, the interface returns a responseDTO object, including return_code (return code) and return_message (return information). If abnormal, return_code is -100, and return_message is error information. After the interface is called, the background server can start a distributed task to perform asynchronous data synchronization, and the controller returns the responseDTO information immediately after executing the interface agreement, and the data is sent asynchronously through kafka.

[0050] In an embodiment, when synchronizing the historical alarm data, first, legality detection is performed on all the historical alarm data, and if no legal parameter is found, an error with a return_code of -100 is returned. The legality detection at least includes determining whether the historical alarm parameter is within a start time point and an end time point, such as within a specified specific region, within a specified specific alarm error. After obtaining all the legal historical alarm data, the time between the start time point and the end time point is split into subtask durations based on a preset splitting manner, and the historical alarm data corresponding to the subtask durations in the background server is determined, that is, the time between the start time point and the end time point is split into subtask durations of the same or different time lengths, and the preset splitting manner refers to a user-defined splitting manner, such as splitting 4 hours into one subtask duration, and then determining the historical alarm data corresponding to each subtask duration in all the legal historical alarm data. At this time, based on the subtask duration, it can be detected whether the historical alarm data meets the second preset filtering condition, and the second preset filtering condition refers to a condition specified in the interface agreement or the target protocol data, which can be the same as or different from the first preset filtering condition, and is not limited herein, that is, simultaneously in multiple threads, it can be determined whether the historical alarm data in each subtask duration meets the second preset filtering condition, or it can be determined in sequence whether the historical alarm data in the subtask duration meets the second preset filtering condition, and the determination manner is not limited herein. For example, the preset splitting manner is to form one subtask duration according to every 4-hour span, and the time sequence is reversed. For example, the start_time is 2023-12-01 10:00, and the end_time is 2023-12-01 18:00, then it is split into two subtask durations, the first subtask duration contains the time points 2023-12-01 14:00-2023-12-01 18:00, and the second subtask duration contains the time points 2023-12-01 10:00-2023-12-01 14:00. It is detected whether the historical alarm data in the first subtask duration meets the filtering condition, and the historical alarm data meeting the filtering condition is taken as the target alarm data. After detecting whether all the historical alarm data in the first subtask duration meets the filtering condition, it is detected whether the historical alarm data in the second subtask duration meets the filtering condition; or the historical alarm data in the first subtask duration and the historical alarm data in the second subtask duration can be simultaneously detected whether they meet the filtering condition.

[0051] In step S25, if the historical alarm data meets the second preset filtering condition, the count value corresponding to the historical alarm data meeting the second preset filtering condition is determined.

[0052] Step S26, if the count value is less than the record threshold, a step of detecting whether the historical alarm data meets the second preset filtering condition based on the subtask duration is performed.

[0053] Step S27, if the count value is greater than or equal to the record threshold, all historical alarm data meeting the second preset filtering condition is determined as target alarm data.

[0054] In the embodiment, when the historical alarm data meets the second preset filtering condition, the count value corresponding to the historical alarm data meeting the second preset filtering condition is determined, that is, the historical alarm data currently meeting the second preset filtering condition is determined as the first, second, or third, and then whether to query new historical alarm data is determined based on the number of historical alarm data meeting the second preset filtering condition. The count value refers to the sorting value of the historical alarm data meeting the second preset filtering condition at this time. When the count value is less than the record threshold (or the historical alarm data does not meet the second preset filtering condition), it is determined that the user demand is not reached, and then the step of detecting whether the historical alarm data meets the second preset filtering condition based on the subtask duration is continuously performed. The record threshold refers to a value defined by the user. When the count value is greater than or equal to the record threshold, all historical alarm data meeting the second preset filtering condition is determined as target alarm data, and then the interaction of the historical alarm data can be efficiently realized.

[0055] In an embodiment, based on the distance of the above two subtask durations, when the historical alarm data meeting the condition is output after the first two subtask durations are executed in sequence, the two are merged and compared with max_records (the record threshold). If the total number of records exceeds max_records, the second subtask duration does not need to be executed, otherwise the second subtask duration is continuously executed. At this time, the result of each received subtask duration execution can be immediately packaged and sent to the sync_topic in the kafka address of the UI view server target protocol data. The format of the interactive package message can be as follows:

[0056] {msg_type:“sync_data”,--synchronization data

[0057] req_id:abc09854,--dubbo microservice call input reqID

[0058] msgs:[{alarm data 1}, {alarm data 2}]--message set

[0059] }

[0060] The UI view server receives messages from a sync topic of the kafka, and transmits data to a specified UI interface according to a reqID to display, which can be executed by a data task cluster in a concurrent manner and the result data is sent in batches. The UI interface can quickly see the first response data, and the subsequent data can be added in real time, thereby reducing the overall interaction time.

[0061] Embodiment Four

[0062] In another embodiment of the present application, the same or similar contents as the above embodiment one can be referred to the above introduction, and the subsequent will not be described. On this basis, the step of determining the target protocol data according to the instance identifier and the instance data comprises:

[0063] In step S201, a first identifier corresponding to each online protocol data is determined, and whether the first identifier is the same as the instance identifier is detected in sequence;

[0064] In step S202, if the first identifier is the same as the instance identifier, the online protocol data corresponding to the instance identifier is updated based on the instance data as the target protocol data;

[0065] In step S203, if the first identifier is not the same as the instance identifier, the target protocol data is constructed based on the instance data.

[0066] In the embodiment, when determining the target protocol data, whether the protocol data newly created is needed or the protocol data needs to be updated is determined based on the instance identifier. At this time, by determining the first identifier corresponding to each online protocol data, that is, the first identifier corresponding to each online protocol data, the first identifier refers to the identifier corresponding to the online protocol data, such as view1. If the first identifiers corresponding to all online protocol data are not the same as the instance identifier at this time, the target protocol data is constructed based on the instance data, that is, the target protocol data is registered on the zookeeper based on the kafka information, the subscription information (real-time topic, historical topic, etc.), the heartbeat information and the like in the instance data as in the embodiment two. Otherwise, when the first identifier corresponding to the online protocol data is the same as the instance identifier, it is determined that the instance data in the online protocol data needs to be updated at this time, and the online protocol data corresponding to the instance identifier is updated based on the instance data as the target protocol data, which means that the online protocol data corresponding to the instance identifier is the online protocol data corresponding to the first identifier which is the same as the instance identifier. The registration and update of the protocol data are realized, and the interaction basis is provided for the subsequent interaction of the alarm data.

[0067] In an embodiment, referring to Figure 2If the instance identifier and the instance data are acquired when there is no online protocol data, and if there are two instance identifiers and instance data, it is determined that the UI view server needs to start two instances, each of which has an instance identifier, such as view1 representing instance 1 and view2 representing instance 2. At this time, instance 1 and instance 2 are registered in the / data_flow_clients directory on the zookeeper, such as view1 after registration creating / data_flow_clients / view1, and view2 after registration creating / data_flow_clients / view2, that is, the UI view service view1 and the UI view service view2 in the figure, and the respective instance data is written into the corresponding directory, such as view1 after registration writing instance data into / data_flow_clients / view1. At least two instances include information cluster (which can be kafka) receiving and microservice (which can be dubbo rpc) technology calling, and the microservice technology calling can realize synchronous calling, alarm details, and associated viewing. The two instances also include open source distributed framework (which can be zookeeper) operation. At this time, if the control is set in the background server, the background server will monitor the UI view service view1 and the UI view service view2, and can know the internal demand change in real time to quickly perform data interaction.

[0068] Further, in an embodiment, after the step of determining the target protocol data according to the instance identifier and the instance data, the method further comprises:

[0069] In step S204, all registered protocol information in a preset time is acquired, and a second identifier in the registered protocol information is determined.

[0070] In step S205, if the second identifier is the same as a target identifier corresponding to the target protocol data, a step of determining target alarm data in the background server according to the target protocol data is performed.

[0071] In step S206, if the second identifier is not the same as the target identifier corresponding to the target protocol data, the target protocol data is deleted.

[0072] In the embodiment, after the target protocol data is determined, in addition to determining the target alarm data in the background server, the state of the target protocol data is also judged to determine whether the target protocol data needs to be deleted. By obtaining all the registered protocol information within a preset time, the second identifier in the registered protocol information is determined, that is, whether there is data for updating the target protocol data within a certain time is determined, which is generally determined by the identifier. The preset time refers to the time set by the user. For example, view1 updates the latest timestamp to the "heartbeat" field of the instance data in the / data_flow_clients / view1 directory every 20 seconds, indicating that it is still alive. It can also be that the filterIdList is updated to the "subscribe_info" field of the protocol data in the / data_flow_clients / view1 directory within 2 hours. At this time, the second identifier in all the registered protocol information within the preset time is the same as the target identifier corresponding to the target protocol data (at least one second identifier is the same), and the target protocol data is updated. At this time, the step of determining the target alarm data in the background server according to the target protocol data is performed. Otherwise, when the second identifier is different from the target identifier corresponding to the target protocol data, it is determined that the instance corresponding to the target protocol data is offline, and the target protocol data is deleted. The effective use of memory is ensured.

[0073] In an embodiment, when the controller sets the background server, the background server listens to the data change of each UI view server instance. For example, view1 updates the "heartbeat" and "subscribe_info" fields in / data_flow_clients / view1, and the background service also updates these information. The background server detects the information in each UI view service in the internal list every certain period of time or in real time. For example, if the "heartbeat" in a certain UI view service view1 is not updated for more than 1 hour, it is determined that the UI view server instance is offline, view1 is deleted from the internal list, and the / data_flow_clients / view1 directory is deleted, so as to ensure the effective use of internal resources of the entire alarm data interaction system.

[0074] Embodiment Five

[0075] In another embodiment of the present application, the same or similar contents as the above-mentioned embodiment one can refer to the above introduction, and will not be described in detail hereinafter. On this basis, refer to Figure 3 , Figure 3 The flowchart of the alarm data interaction method provided by the embodiment five of the present application, the alarm data interaction system further comprises a UI interface in communication connection with the UI view server, and the alarm data interaction method further comprises:

[0076] Step S30: Obtain operation information from the UI interface and generate cluster alarm update data based on the operation information;

[0077] Step S40: Update the real-time alarm data in the target alarm data based on the cluster alarm update data, and display the updated real-time alarm data on the UI interface.

[0078] In this embodiment, the alarm data interaction system also includes a UI interface that communicates with the UI view server, as shown below. Figure 2 When a user manually confirms or adds notes to alarm data on the UI, the message cluster in the work order system sends dispatch information for the alarm data, or directly sends confirmation or notes based on the UI to the alarm update queue of the message cluster. This information is then used as the operation information on the UI. This operation information refers to the manual confirmation or notes added to the alarm data. Since the volume is small and needs to be quickly and promptly displayed on the UI, it can be transmitted via Kafka messages. Therefore, cluster alarm update data needs to be generated based on the operation information. Cluster alarm update data refers to cluster data that meets the requirements for Kafka transmission. (Continue to refer to...) Figure 2 After the UI interface or work order system dispatches an alarm, it is sent to the designated message cluster alarm update queue (alarm_modify). The background data service receives change messages from the message cluster alarm update queue (alarm_modify) in real time and broadcasts them to all UI view servers (sent to the real-time alarm queues registered by all UI view servers). Upon receiving the message, the UI view server immediately updates the alarm fields and notifies the UI interface to update, ensuring the real-time update of alarm data. One format for updating alarm data is as follows:

[0079] {msg_type:“modify_data”,--synchronize data}

[0080] msgs:[{"alarmID":98765412,"remark":"Confirm Processing"},--Message 1

[0081] {"alarmID":98765412,"worksheet":"Order Dispatched"}]--Message 2

[0082] }

[0083] In an embodiment, the UI view server needs to view alarm details, view other information associated with the alarm, etc., which can be achieved by calling the interface of the background service in a dubbo rpc manner in combination with the real-time log stream kafka manner. Details are not described herein. A high-efficiency alarm data interaction system can be formed by combining the dubbo rpc manner with the kafka manner.

[0084] Embodiment six

[0085] The embodiments of the present application also provide an alarm data interaction system, which refers to Figure 4 The alarm data interaction system includes a background server of a data cluster, a UI view server and a controller which are communicatively connected based on micro-service technology, the controller is connected with the background server and the UI view server, and the controller includes:

[0086] A protocol obtaining module A01 is configured to obtain registration protocol information sent by the UI view server, wherein the registration protocol information includes instance identification and instance data.

[0087] A data interaction module A02 is configured to determine target protocol data according to the instance identification and the instance data, determine target alarm data in the background server according to the target protocol data, and interact the target alarm data to the UI view server.

[0088] Optionally, the data interaction module A02 is further configured to:

[0089] determine real-time alarm data in the background server, and detect whether the real-time alarm data meets the first preset filtering condition;

[0090] If the real-time alarm data meets the first preset filtering condition, the real-time alarm data meeting the first preset filtering condition is determined as target alarm data.

[0091] Optionally, the data interaction module A02 is further configured to:

[0092] split the time between the start time point and the end time point into a subtask duration based on a preset splitting manner, and determine historical alarm data corresponding to the subtask duration in the background server;

[0093] detect whether the historical alarm data meets the second preset filtering condition based on the subtask duration;

[0094] If the historical alarm data meets the second preset filtering condition, a count value corresponding to the historical alarm data meeting the second preset filtering condition is determined.

[0095] If the count value is less than the record threshold, the step of detecting whether the historical alarm data satisfies the second preset filtering condition based on the subtask duration is performed.

[0096] If the count value is greater than or equal to the record threshold, all historical alarm data satisfying the second preset filtering condition is determined as target alarm data.

[0097] Optionally, the data interaction module A02 is further configured to:

[0098] determine a first identifier corresponding to each online protocol data, and detect whether the first identifier is same as the instance identifier in sequence;

[0099] If the first identifier is same as the instance identifier, the online protocol data corresponding to the instance identifier is updated based on the instance data as target protocol data;

[0100] If the first identifier is not same as the instance identifier, target protocol data is constructed based on the instance data.

[0101] Optionally, the data interaction module A02 is further configured to:

[0102] acquire all registered protocol information within a preset time, and determine a second identifier in the registered protocol information;

[0103] If the second identifier is same as a target identifier corresponding to the target protocol data, the step of determining target alarm data in the background server based on the target protocol data is performed;

[0104] If the second identifier is not same as the target identifier corresponding to the target protocol data, the target protocol data is deleted.

[0105] Optionally, the controller is further configured to:

[0106] acquire operation information of the UI interface, and generate cluster alarm update data based on the operation information;

[0107] update real-time alarm data in the target alarm data based on the cluster alarm update data, so as to display the real-time alarm data after the update on the UI interface.

[0108] The alarm data interaction system provided by the present application adopts the alarm data interaction method in the above embodiment, and solves the technical problem of low efficiency of alarm data interaction. Compared with the prior art, the alarm data interaction system provided by the present application has the same beneficial effects as the alarm data interaction method provided by the above embodiment, and other technical features in the alarm data interaction system are the same as the features disclosed in the above embodiment method, which will not be repeated here.

[0109] Embodiment seven

[0110] The electronic device provided by the embodiment of the present application comprises at least one processor, and a memory connected with the at least one processor in communication; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the alarm data interaction method in the above embodiment one.

[0111] Reference will now be made to Figure 5 , which shows a structural schematic diagram of an electronic device suitable for implementing the embodiments of the present disclosure. The electronic device in the embodiments of the present disclosure can include but is not limited to mobile terminals such as mobile phones, notebook computers, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablets), PMPs (portable multimedia players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), and the like, and fixed terminals such as digital TVs, desktop computers, and the like. Figure 5 The electronic device shown is only an example, and should not bring any limitation to the functions and use range of the embodiments of the present disclosure.

[0112] As shown in Figure 5 , the electronic device can include a processing system 1001 (such as a central processor, a graphics processor, etc.), which can perform various appropriate actions and processes according to programs stored in a read-only memory (ROM) 1002 or programs loaded from a storage system 1003 to a random access memory (RAM) 1004. In the RAM 1004, various programs and data required for the operation of the electronic device are also stored. The processing system 1001, the ROM 1002, and the RAM 1004 are connected to each other through a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus.

[0113] Generally, the following systems can be connected to the I / O interface 1006: an input system 1007 including, for example, a touch screen, a touch pad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; an output system 1008 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a storage system 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication system 1009. The communication system can allow the electronic device to communicate wirelessly or wiredly with other devices to exchange data. Although the electronic device is shown with various systems, it is understood that not all of the shown systems are required to be implemented or possessed. More or fewer systems can alternatively be implemented or possessed.

[0114] In particular, according to embodiments of the present disclosure, the processes described above with reference to the flowcharts can be implemented as a computer software program. For example, embodiments of the present disclosure include a program product including a computer program carried on a computer readable medium, the computer program containing program code for executing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network through the communication system 1009, or installed from the storage system 1003, or installed from the ROM 1002. When the computer program is executed by the processing system 1001, the above-mentioned functions defined in the methods of the embodiments of the present disclosure are performed.

[0115] The electronic device provided by the present application adopts the alarm data interaction method in the above-mentioned embodiments, and solves the technical problem of low efficiency of alarm data interaction. Compared with the prior art, the electronic device provided by the embodiments of the present application has the same beneficial effects as the alarm data interaction method provided by the above-mentioned embodiments, and other technical features in the electronic device are the same as the features disclosed in the above-mentioned method, which will not be repeated here.

[0116] It should be understood that parts of the present disclosure can be realized by hardware, software, firmware or a combination thereof. In the description of the above-mentioned embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0117] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto, and any person skilled in the art can easily think of changes or replacements within the technical range disclosed by the present application, which should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

[0118] Embodiment eight

[0119] The embodiment provides a storage medium, which can be a computer readable storage medium, and has computer readable program instructions stored thereon, the computer readable program instructions being used for executing the alarm data interaction method in the above embodiment.

[0120] The computer readable storage medium provided by the embodiment of the application may, for example, be a U disk, but is not limited to an electric, magnetic, optical, electromagnetic, infrared, or semiconductor system, system, or device, or any combination of the above. More specific examples of the computer readable storage medium can include, but are not limited to, an electric connection with one or more conductive wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the embodiment, the computer readable storage medium can be any tangible medium containing or storing a program, which can be used by or in combination with an instruction execution system, system, or device. The program code contained on the computer readable storage medium can be transmitted by any suitable medium, including but not limited to an electric wire, an optical cable, an RF (radio frequency), and the like, or any suitable combination of the above.

[0121] The computer readable storage medium described above can be contained in an electronic device, or can exist separately and not be assembled into an electronic device.

[0122] The computer readable storage medium described above carries one or more programs, when the one or more programs are executed by an electronic device, the registration protocol information sent by a UI view server is acquired, wherein the registration protocol information includes an instance identifier and instance data; target protocol data is determined according to the instance identifier and the instance data, and target alarm data is determined in the background server according to the target protocol data, so as to interact the target alarm data to the UI view server.

[0123] Computer program code for carrying out operations of the present disclosure can be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like, and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code can execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider).

[0124] The computer program instructions can also be loaded onto a computer or other programmable information processing apparatus to cause a series of operations to be performed on the computer or other programmable information processing apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable information processing apparatus implement the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0125] The modules involved in the embodiments of the present disclosure can be implemented in the manner of software or hardware. In some cases, the name of the module does not constitute a limitation on the module itself.

[0126] The computer readable storage medium provided by the present application stores computer readable program instructions for executing the alarm data interaction method described above, and solves the technical problem of low efficiency of alarm data interaction. Compared with the prior art, the computer readable storage medium provided by the embodiments of the present application has the same beneficial effects as the alarm data interaction method provided by the above embodiments, and will not be described here.

[0127] Embodiment Nine

[0128] The present application also provides a program product comprising a computer program which, when executed by a processor, implements the steps of the alarm data interaction method described above.

[0129] The program product provided by the present application solves the technical problem of low efficiency of alarm data interaction. Compared with the prior art, the program product provided by the embodiment of the present application has the same beneficial effects as the alarm data interaction method provided by the above-mentioned embodiment, and will not be described here.

[0130] The above is only the preferred embodiment of the present application, and does not limit the patent scope of the present application, and any equivalent structure or equivalent process transformation using the content of the specification and drawings of the present application, or direct or indirect application in other related technical fields, are also included in the patent processing scope of the present application.

Claims

1. An alarm data interaction method, characterized by, The alarm data interaction method is applied to an alarm data interaction system, the alarm data interaction system comprises a background server of a data cluster and a UI view server in communication connection with the background server based on micro-service technology, and the alarm data interaction method comprises the following steps: Obtain the registration protocol information sent by the UI view server, wherein the registration protocol information comprises an instance identifier and instance data; Determine target protocol data according to the instance identifier and the instance data, and determine target alarm data in the background server according to the target protocol data, so as to interact the target alarm data to the UI view server.

2. The method of claim 1, wherein the alert data is transmitted to the mobile device via a short message service (SMS) message. The target protocol data comprises a first preset filtering condition, and the step of determining target alarm data in the background server according to the target protocol data comprises the following steps: Determine real-time alarm data in the background server, and detect whether the real-time alarm data meets the first preset filtering condition; If the real-time alarm data meets the first preset filtering condition, the real-time alarm data meeting the first preset filtering condition is taken as target alarm data.

3. The method of claim 1, wherein the alert data is transmitted to the mobile device via a short message service (SMS) message. The target protocol data comprises a start time point, an end time point, a record threshold and a second preset filtering condition, and the step of determining target alarm data in the background server according to the target protocol data comprises the following steps: Split the time between the start time point and the end time point into a subtask duration based on a preset splitting mode, and determine the historical alarm data corresponding to the subtask duration in the background server; Detect whether the historical alarm data meets the second preset filtering condition based on the subtask duration; If the historical alarm data meets the second preset filtering condition, determine the count value corresponding to the historical alarm data meeting the second preset filtering condition; If the count value is less than the record threshold, execute the step of detecting whether the historical alarm data meets the second preset filtering condition based on the subtask duration; If the count value is greater than or equal to the record threshold, determine all historical alarm data meeting the second preset filtering condition as target alarm data.

4. The method of claim 1, wherein the alert data is transmitted to the mobile device via a short message service (SMS) message. 5 The step of determining target protocol data according to the instance identifier and the instance data comprises the following steps: Determine a first identifier corresponding to each online protocol data, and detect whether the first identifier is the same as the instance identifier in sequence; If the first identifier is the same as the instance identifier, update the online protocol data corresponding to the instance identifier based on the instance data as target protocol data; If the first identifier is not the same as the instance identifier, construct target protocol data based on the instance data.

5. The method of claim 1, wherein the alert data is transmitted to the mobile device via a short message service (SMS) message. After the step of determining target protocol data according to the instance identifier and the instance data, the following steps are performed: ​ Obtain all registration protocol information within a preset time, and determine a second identifier in the registration protocol information; If the second identifier is the same as a target identifier corresponding to the target protocol data, execute the step of determining target alarm data in the background server according to the target protocol data; If the second identifier is not the same as a target identifier corresponding to the target protocol data, the target protocol data is deleted.

6. The method of claim 1 to 5, wherein, The alarm data interaction system further includes a UI interface in communication connection with the UI view server, and the method further includes: obtaining operation information of the UI interface, and generating cluster alarm update data based on the operation information; updating real-time alarm data in the target alarm data based on the cluster alarm update data, so as to display the real-time alarm data after the update on the UI interface.

7. An alarm data exchange system characterized by The alarm data interaction system includes a background server of a data cluster, a UI view server and a controller in communication connection with the background server based on micro-service technology, the controller is connected with the background server and the UI view server, and the controller includes: a protocol acquisition module configured to acquire registration protocol information sent by the UI view server, wherein the registration protocol information includes an instance identifier and instance data; a data interaction module configured to determine target protocol data according to the instance identifier and the instance data, and determine target alarm data in the background server according to the target protocol data, so as to interact the target alarm data to the UI view server.

8. An alarm data interchange apparatus characterized by The alarm data interaction device includes: at least one processor; a memory in communication connection with the at least one processor; The memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the steps of the alarm data interaction method in any one of claims 1 to 6.

9. A storage medium, characterized by The storage medium stores a program for implementing an alarm data interaction method, and the program is executed by a processor to implement the steps of the alarm data interaction method in any one of claims 1 to 6.

10. A program product, characterized by The program product includes an alarm data interaction program, and the alarm data interaction program is executed by a processor to implement the steps of the alarm data interaction method in any one of claims 1 to 6.

Images