A multi-channel hardware environment cloud broadcasting method and system based on multiple types of alerts

Abstract

The application discloses a multi-channel hardware environment cloud broadcasting method and system based on multiple types of warnings, and relates to the technical field of Internet of Things. The multi-channel hardware environment cloud broadcasting method comprises the following steps: constructing an access framework, accessing multiple hardware devices through the access framework, and receiving warning messages triggered by the hardware devices; building a distributed cluster, performing parallel processing and asynchronous processing on the warning messages through the distributed cluster, obtaining a cloud broadcasting task, and performing cloud broadcasting notification according to the cloud broadcasting task; and storing the warning messages through a distributed full-text retrieval engine. The application can simplify the access process of the hardware devices, improve the fluency and compatibility of data interaction, and reduce the response time of the warning messages through the parallel processing and asynchronous processing of the warning messages by the distributed cluster and the storage of the warning messages by the distributed full-text retrieval engine, so that the query of 100 million data can be responded within milliseconds, and the application can be widely used in the technical field of Internet of Things.

Description

TECHNICAL FIELD

[0001] The application relates to the technical field of Internet of Things, in particular to a multi-channel hardware environment cloud broadcasting method and system based on multiple types of warnings. BACKGROUND

[0002] Currently, multiple types of devices access the system according to multiple entry accesses defined by different manufacturers. When the warning message arrives, the set linkage record is triggered to perform cloud broadcasting notification. There are many technical problems in multi-channel multi-entry access. The main technical problems are as follows: multi-channel multi-entry access leads to complex data integration interaction, which is not convenient for data integration and is difficult to manage uniformly; the interoperability between multiple types of devices is lacking, thereby increasing the complexity of use; the management of multi-channel multi-entry access is complex, and the resources and events consumed are increased.

[0003] The second technical problem is: the performance bottleneck exists in message synchronization processing, which leads to response time delay and cannot respond in time; the resource occupation ratio is high, and a large number of messages will increase thread occupation, leading to high consumption of system resources and possibly causing crashes or failures; the complexity of error processing is increased, and the entire processing flow is blocked when an error occurs, leading to the need for a complex retry and recovery mechanism; using a MySQL database for data storage has problems such as performance degradation, increased query events, and reduced system real-time performance; the storage cost is high, and large-scale data storage requires more storage resources, especially for the demand for high availability and fast read-write; data backup and recovery are complex and time-consuming, increasing the difficulty of operation and maintenance, and there are problems such as index maintenance burden, query optimization difficulty, and low transaction processing efficiency. SUMMARY

[0004] To solve the above technical problems, the purpose of the present application is to provide a multi-channel hardware environment cloud broadcasting method and system based on multiple types of warnings, which is efficient and simple in data integration.

[0005] To achieve the above purpose, one aspect of the embodiments of the present application provides a multi-channel hardware environment cloud broadcasting method based on multiple types of warnings, comprising the following steps:

[0006] An access framework is constructed to access multiple hardware devices through the access framework and receive warning messages triggered by each hardware device;

[0007] A distributed cluster is built to perform parallel processing and asynchronous processing on each warning message through the distributed cluster to obtain a cloud broadcasting task, and perform cloud broadcasting notification according to the cloud broadcasting task;

[0008] Each warning message is stored through a distributed full-text retrieval engine.

[0009] In some embodiments, the access framework is constructed, specifically comprising:

[0010] defining an application programming interface to enable multiple hardware devices to be accessed through the same access method;

[0011] An interface document is set, which includes at least a request method, request parameters, and a response format.

[0012] In some embodiments, the building of a distributed cluster is specifically:

[0013] Use Kafka as the message middleware to build the distributed cluster.

[0014] In some embodiments, the parallel and asynchronous processing of each of the alarm messages by the distributed cluster to obtain a cloud broadcast task, and performing cloud broadcast notification according to the cloud broadcast task specifically includes:

[0015] Querying preset linkage records, and performing parallel and asynchronous processing on each of the alarm messages according to the linkage records through the distributed cluster;

[0016] The cloud broadcast task is triggered according to the alarm message after parallel processing and asynchronous processing, and the corresponding alarm message is sent to the user end for cloud broadcast notification according to the cloud broadcast task.

[0017] In some embodiments, the multi-channel hardware environment cloud broadcasting method further includes:

[0018] A current load rate is obtained, and the distributed cluster is expanded according to the current load rate.

[0019] In some embodiments, obtaining the current load rate and expanding the distributed cluster according to the current load rate specifically includes:

[0020] Obtaining the current load rate;

[0021] When the current load rate is greater than a preset load rate threshold, configuring a new server node, and then adding the node information of the server node to the distributed cluster;

[0022] Redistributing the partitions of the distributed cluster.

[0023] In some embodiments, the storing of each of the warning messages by a distributed full-text search engine is specifically as follows:

[0024] Each of the alarm messages is stored through ElasticSearch.

[0025] To achieve the above objectives, another aspect of the present application provides a multi-channel hardware environment cloud broadcast system based on multi-type alerts, including:

[0026] An access framework construction module is used to construct an access framework, access a variety of hardware devices through the access framework, and receive alarm messages triggered by each of the hardware devices;

[0027] A message asynchronous processing module is used to build a distributed cluster, perform parallel and asynchronous processing on each of the alarm messages through the distributed cluster, obtain a cloud broadcast task, and perform cloud broadcast notification according to the cloud broadcast task;

[0028] The data storage module is used to store the alarm message through a distributed full-text search engine.

[0029] To achieve the above-mentioned purpose, another aspect of an embodiment of the present application proposes an electronic device, which includes a memory, a processor, a program stored on the memory and executable on the processor, and a data bus for realizing connection and communication between the processor and the memory. When the program is executed by the processor, the multi-channel hardware environment cloud broadcast method based on multi-type alerts as described above is realized.

[0030] To achieve the above-mentioned purpose, another aspect of an embodiment of the present application proposes a storage medium, which is a computer-readable storage medium for computer-readable storage. The storage medium stores one or more programs, and the one or more programs can be executed by one or more processors to implement the multi-channel hardware environment cloud broadcast method based on multi-type warnings as described above.

[0031] The beneficial effects of the present invention are as follows: the multi-channel hardware environment cloud broadcast method and system based on multi-type alarms of the present invention first constructs an access framework, accesses a variety of hardware devices through the access framework, and receives alarm messages triggered by each hardware device. Then, a distributed cluster is built, and each alarm message is processed in parallel and asynchronously by the distributed cluster to obtain a cloud broadcast task, and then a cloud broadcast notification is performed according to the cloud broadcast task. Finally, each alarm message is stored by a distributed full-text search engine. On the one hand, the present invention allows hardware devices of various channels to access through the access framework by constructing a unified access framework, thereby simplifying the access process of each hardware device, realizing efficient integration of hardware devices from different manufacturers, and improving the fluency and compatibility of data interaction; on the other hand, by constructing a distributed cluster to process each alarm message in parallel and asynchronously, the response time of the alarm message can be reduced; in addition, by storing each alarm message by a distributed full-text search engine, the query performance and response speed of the system can be improved, achieving a millisecond-level response for querying billions of data. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following introduction is made to the drawings required for use in the embodiments of the present invention. It should be understood that the drawings introduced below are only for the convenience of clearly describing some embodiments of the technical solutions of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without any creative work.

[0033] Figure 1 A flowchart of the steps of a multi-channel hardware environment cloud broadcast method based on multi-type warnings provided by an embodiment of the present invention;

[0034] Figure 2 A flowchart of the steps for constructing an access framework provided by an embodiment of the present invention;

[0035] Figure 3 A flowchart of the steps for building a distributed cluster according to an embodiment of the present invention;

[0036] Figure 4 A flowchart of the steps for processing an alarm message provided by an embodiment of the present invention;

[0037] Figure 5 A flowchart of step S113 provided in an embodiment of the present invention;

[0038] Figure 6 A flowchart of step S103 provided in an embodiment of the present invention;

[0039] Figure 7 A schematic diagram of a message processing flow provided by an embodiment of the present invention;

[0040] Figure 8 A flowchart of a multi-channel hardware environment cloud broadcast method based on multi-type alerts provided by an embodiment of the present invention;

[0041] Figure 9 A schematic diagram of the structure of a multi-channel hardware environment cloud broadcast system based on multi-type warnings provided by an embodiment of the present invention;

[0042] Figure 10 A schematic diagram of the hardware structure of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0043] In order to make the purposes, technical solutions and advantages of the present application clearer, the present application will be further described in detail below with reference to the drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and not intended to limit the present application. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with embodiments of the present application, but are only examples of devices and methods consistent with some aspects of the embodiments of the present application as detailed in the appended claims.

[0044] It can be understood that the terms "first", "second" and the like used in the present application can be used herein to describe various concepts, but unless specifically stated, these concepts are not limited by these terms. These terms are only used to distinguish one concept from another. For example, without departing from the scope of the embodiments of the present application, the first information can also be referred to as the second information, and similarly, the second information can also be referred to as the first information. Depending on the context, the word "if" as used herein can be interpreted as "when" or "when" or "in response to determining".

[0045] The terms "at least one", "multiple", "each", "any" and the like used in the present application include one, two or more than two, multiple includes two or more than two, each refers to each of the corresponding multiple, and any refers to any one of the multiple.

[0046] Before the embodiments of the present application are described in detail, first, some nouns and terms involved in the embodiments of the present application are described, and the nouns and terms involved in the embodiments of the present application are applicable to the following explanations.

[0047] 1) Message middleware, a software architecture responsible for delivering messages in distributed systems. It supports asynchronous communication, enabling different systems or services to be decoupled. Common features include message queues, publish-subscribe mechanisms, and message routing. Message middleware improves the reliability, scalability, and flexibility of systems, and is widely used in event-driven architectures, microservices, and real-time data processing scenarios.

[0048] 2) Kafka, an open-source stream processing platform for processing real-time data streams, widely used in data transmission, log collection, and real-time analysis. It uses a publish-subscribe model to organize messages through topics, supporting high throughput and scalability.

[0049] 3) RESTful API (Representational State Transfer API) is an API design approach based on the REST architectural style. Its core concept is to abstract internet resources into a series of entities that can be accessed and manipulated through a unified interface. It offers simplicity, scalability, and ease of maintenance.

[0050] 4) Elasticsearch is an open-source, highly scalable, distributed full-text search engine. It can store and retrieve data in near real time and is highly scalable, capable of scaling to hundreds of servers and processing petabytes of data. In Elasticsearch, data is organized into indexes, each of which can be considered a collection of documents with similar characteristics. These documents are stored in JSON format and contain multiple fields, similar to rows and columns in a relational database. Elasticsearch indexes these documents to support efficient search operations.

[0051] 5) Equipment affiliation refers to transferring the use or management rights of a piece of equipment to another organization or individual. This approach allows for flexibility in resource allocation and optimizes equipment efficiency. This practice is common in industries like manufacturing and transportation, involving equipment sharing or outsourcing management.

[0052] Currently, multi-device access systems use multiple entry points defined by different manufacturers. When an alarm message arrives, it triggers the configured linkage record for cloud broadcast notification. Multi-channel, multi-entry access presents several technical challenges, primarily: multi-channel, multi-entry access complicates data integration and interaction, hindering data integration and unified management; lacks interoperability between multiple device types, increasing complexity; and multi-channel, multi-entry access management is complex, requiring increased resources and events.

[0053] Secondary technical issues include: performance bottlenecks in message synchronization processing, resulting in delayed response time and inability to respond in a timely manner; high resource usage, and excessive number of messages will increase thread usage, leading to increased system resource consumption and possibly crashes or failures; the complexity of error handling increases, and when errors occur, the entire processing flow will be blocked, resulting in the need for complex retry and recovery mechanisms; using MySQL database for data storage will result in performance degradation, increased query events, and reduced system real-time performance; storage costs increase, and large-scale data storage requires more storage resources, especially for high availability and fast reading and writing requirements; data backup and recovery are complex and time-consuming, which increases the difficulty of operation and maintenance work, and there are problems such as index maintenance burden, query optimization difficulty, and low transaction processing efficiency.

[0054] To this end, an embodiment of the present invention proposes a multi-channel hardware environment cloud broadcast method based on multi-type alarms. First, an access framework is constructed, and a variety of hardware devices are accessed through the access framework, and alarm messages triggered by each hardware device are received. Then, a distributed cluster is built, and each alarm message is processed in parallel and asynchronously by the distributed cluster to obtain a cloud broadcast task, and then a cloud broadcast notification is performed according to the cloud broadcast task. Finally, each alarm message is stored through a distributed full-text search engine. On the one hand, the present invention allows hardware devices of various channels to access through the access framework by constructing a unified access framework, thereby simplifying the access process of each hardware device, realizing efficient integration of hardware devices from different manufacturers, and improving the fluency and compatibility of data interaction; on the other hand, by constructing a distributed cluster to process each alarm message in parallel and asynchronously, the response time of the alarm message can be reduced; in addition, by storing each alarm message through a distributed full-text search engine, the system query performance and response speed can be improved, achieving a millisecond-level response for querying billions of data. The multi-channel hardware environment cloud broadcast method can be applied to fields such as disaster warning, smart home monitoring, and industrial Internet of Things, but is not limited to these.

[0055] Reference Figure 1 , Figure 1 A flowchart of a multi-channel hardware environment cloud broadcast method based on multi-type alerts provided in an embodiment of the present invention. The embodiment of the present invention provides a multi-channel hardware environment cloud broadcast method based on multi-type alerts, which includes steps S101 to S103:

[0056] S101. Build an access framework, access various hardware devices through the access framework, and receive alarm messages triggered by each hardware device;

[0057] Specifically, a unified access framework is established based on business needs and technical specifications. This access framework allows hardware devices from different channels and manufacturers to access through a unified application programming interface (API). This simplifies the access process for hardware devices from different channels and manufacturers, thereby enhancing the fluidity and compatibility of data exchange. After the hardware devices are connected, the operating status, performance indicators, and environmental parameters of each hardware device are monitored in real time. When device anomalies or collected data anomalies are detected, corresponding alarm messages are triggered to alert the relevant staff or users.

[0058] It should be noted that the hardware equipment can be sensor equipment, smart home appliances and security monitoring equipment, etc. The sensor equipment can include environmental monitoring sensors for real-time monitoring of environmental parameters and industrial sensors for status monitoring and fault diagnosis of industrial equipment. Environmental monitoring sensors can be temperature sensors, humidity sensors, light sensors, smoke sensors and gas sensors, etc. Industrial sensors can be pressure sensors, flow sensors, vibration sensors and liquid level sensors, etc. Smart home appliances can include smart home devices and smart kitchen devices. Smart home devices can be smart light bulbs, smart sockets and smart door locks, etc. Smart kitchen equipment can be smart refrigerators, smart ovens and smart trash cans, etc. Security monitoring equipment can include security cameras and intrusion monitoring equipment. Intrusion monitoring equipment can be infrared sensors, door and window sensors, etc.

[0059] Reference Figure 2 , Figure 2 A flowchart of steps for constructing an access framework provided in an embodiment of the present invention is provided. As an optional implementation, the step of constructing the access framework can be further divided into the following steps S1011 and S1012:

[0060] S1011. Define an application programming interface to enable multiple hardware devices to access through the same access method;

[0061] S1012. Set an interface document, which at least includes a request method, request parameters, and a response format.

[0062] In some optional embodiments, by defining a standard application programming interface (API) to implement an interface abstraction layer, device manufacturers can simplify the hardware device access process and minimize development effort. The interface abstraction layer is a core component of the unified access framework design. It hides underlying complexity and provides device manufacturers with a simple, intuitive interface, thereby enhancing the fluidity and compatibility of data interaction.

[0063] Specifically, an embodiment of the present invention designs a set of RESTful APIs as standard application programming interfaces (APIs). RESTful APIs are an interface design style based on the HTTP protocol that uses standard HTTP methods (such as GET, POST, PUT, DELETE, etc.) to manipulate resources. Designing RESTful APIs as application programming interfaces allows hardware devices from different channels and different manufacturers to access the system using the same access method, that is, using the same request method, URL structure, and data format, thereby achieving interface standardization. Next, clear interface documentation is provided, detailing each API's functionality, request method, request parameters, and response format. This accelerates developer learning and enables them to quickly understand how to use these APIs for device access and data exchange. Furthermore, over time, the system may need to update or expand its functionality, and device manufacturers may also need to upgrade their devices. Therefore, a RESTful API that supports version management is designed, allowing the system to support both old and new API versions simultaneously to meet the adaptation requirements of different hardware devices and improve system compatibility and stability.

[0064] S102: Build a distributed cluster, process each alarm message in parallel and asynchronously through the distributed cluster, obtain a cloud broadcast task, and perform cloud broadcast notification according to the cloud broadcast task;

[0065] Specifically, traditional synchronous processing often creates performance bottlenecks. This embodiment of the present invention improves system performance by enabling multiple server nodes in a distributed cluster to simultaneously process different alarm messages. It also introduces message queuing technology to asynchronously process received alarm messages, eliminating system bottlenecks waiting for the results of processing a single alarm message. This allows the system to process multiple alarm messages simultaneously, improving the throughput and response speed of cloud broadcasting and enhancing the overall stability and scalability of the system.

[0066] Reference Figure 3 , Figure 3 A flowchart of steps for building a distributed cluster provided in an embodiment of the present invention is provided. As an optional implementation, the step of building a distributed cluster can be further divided into the following steps S1021:

[0067] S1021. Use Kafka as the message middleware to build a distributed cluster.

[0068] In some optional embodiments, the embodiments of the present application use Kafka as a message middleware to realize asynchronous processing. Kafka can process high-throughput messages, thereby ensuring that the system can process a large number of alarm messages at the same time. A distributed cluster is composed of multiple Kafka servers (server nodes), and each server node can store and transmit messages.

[0069] Among them, Kafka adopts a publish-subscribe model, and its core components include a producer, a consumer, a server node, a topic, a partition, a replica, and a ZooKeeper. The producer is responsible for sending messages to the Kafka cluster; the consumer is responsible for pulling messages from the Kafka cluster and processing them; the server node is responsible for storing message data; and the topic represents a type of message. Each topic can be subdivided into multiple partitions; the partition is the basic unit of message storage in Kafka, and each partition is an ordered, immutable sequence of records that can be continuously appended; the replica is responsible for ensuring data reliability and fault tolerance; and the ZooKeeper is responsible for metadata management of the Kafka cluster, controller election, and other operations.

[0070] Specifically, in the embodiments of the present application, according to the processing requirements of the alarm messages, corresponding Kafka topics are created. The number of topics and the number of partitions are set according to data traffic and parallel processing requirements. Kafka producers are configured at the generation end of the alarm messages (i.e., the access framework) to send alarm messages to the corresponding topics in the Kafka cluster. At the same time, Kafka consumers are configured at the processing end of the alarm messages (i.e., the user end) to subscribe to and consume alarm messages from the Kafka cluster, thereby realizing asynchronous processing and high-throughput processing of alarm messages.

[0071] Referring to Figure 4 , Figure 4 A step flowchart of alarm message processing provided by the embodiments of the present application is further provided as an optional implementation, in which each alarm message is processed in parallel and asynchronously by a distributed cluster to obtain a cloud broadcasting task, and cloud broadcasting notification is performed according to the cloud broadcasting task. This step can be further divided into the following steps S1022 and S1023:

[0072] S1022, query a preset linkage record, and process each alarm message in parallel and asynchronously by a distributed cluster according to the linkage record;

[0073] S1023: triggering a cloud broadcast task according to the alarm message after parallel processing and asynchronous processing, and sending the corresponding alarm message to the user end for cloud broadcast notification according to the cloud broadcast task.

[0074] In some optional embodiments, after receiving the alarm message, the pre-set linkage records will be queried. These linkage records define how to perform subsequent processing when a certain type of alarm message is received. After querying the corresponding linkage records, the computing power of the distributed cluster is used to perform parallel and asynchronous processing on the received alarm messages according to these linkage records, and then trigger the corresponding cloud broadcast task based on the alarm messages after parallel and asynchronous processing. The cloud broadcast task is a mechanism for sending notifications to the user end through the cloud, which can quickly and accurately convey the alarm information to the user. According to the specific requirements of the cloud broadcast task, the processed alarm message is encapsulated into a format suitable for transmission and sent to the designated user end through the network. After receiving these alarm messages, the user end will immediately perform a cloud broadcast notification, reminding the user's attention through sound, pop-up windows, vibration, etc., to ensure that the user can obtain important alarm information in a timely manner and take appropriate countermeasures.

[0075] Specifically, when an alarm message arrives, the linkage records to be queried are records of related operations or events automatically triggered by the system or device based on preset rules and policies after receiving the alarm signal. These records contain key information such as the system or device status at the time the alarm was triggered, the operations performed, and the results of the operations. They are valuable references for subsequent analysis, troubleshooting, and system configuration optimization.

[0076] For example, linkage records may include alarm trigger information, linkage operation information, operation result information, and related device status information. Alarm trigger information records key information such as the specific time the alarm was triggered, the trigger source (e.g., device or sensor), the alarm type (e.g., intrusion, fire, etc.), and the alarm level. This information helps understand the context and cause of the alarm. Linkage operation information records the related operations automatically triggered by the system or device after receiving an alarm signal, such as adjusting the camera's field of view, starting recording, and sending notifications. These operations are automatically executed by the system based on preset rules and policies, aiming to respond to and handle alarms in a timely manner. Operation result information records the results of the linkage operation, such as whether the camera's field of view was successfully adjusted, recording was successfully started, or notifications were successfully sent. This information helps evaluate the effectiveness of the linkage operation and the system's response speed. Related device status information records device or system status information related to the alarm and linkage operation, such as the camera's operating status and network connection status. This information helps understand the overall performance and stability of the device or system. By querying and analyzing linkage records, relevant personnel can promptly understand the circumstances of alarm triggering and linkage operations, evaluate system performance and response speed, discover potential problems and vulnerabilities, and take corresponding measures for optimization and improvement.

[0077] As an optional implementation, the multi-channel hardware environment cloud broadcast method further includes the following step S113:

[0078] S113. Obtain the current load rate, and expand the distributed cluster according to the current load rate.

[0079] Specifically, the current load rate is monitored and obtained in real time. When the current load rate is high, the distributed cluster (i.e., Kafka cluster) is expanded to cope with sudden traffic and improve the system's processing capacity and stability.

[0080] Reference Figure 5 , Figure 5 A flowchart of step S113 provided in an embodiment of the present invention, further as an optional implementation, obtains the current load rate, and the step of expanding the distributed cluster according to the current load rate can be further divided into the following steps S1131 to S1133:

[0081] S1131. Obtain the current load rate;

[0082] In some optional embodiments, the load rate data of each server node in the distributed cluster (i.e., Kafka cluster) can be collected in real time through monitoring tools or APIs, including but not limited to performance indicators such as CPU usage, memory occupancy, disk I / O, and network bandwidth, and the current load rate can be obtained by comprehensive judgment.

[0083] S1132: When the current load rate is greater than a preset load rate threshold, configure a new server node, and then add the node information of the server node to the distributed cluster;

[0084] S1133. Reallocate the partitions of the distributed cluster.

[0085] In some optional embodiments, when the current load rate is greater than a pre-set load rate threshold, the distributed cluster (i.e., Kafka cluster) is expanded. First, a new server node (i.e., Broker node) is prepared, and the Kafka service is installed and configured in the server node. Then, the node information of the server node (i.e., Broker node) is added to the administrator (ZooKeeper) so that the distributed cluster (i.e., Kafka cluster) can identify and manage the new node. Then, the partition rebalancing tool or API provided by Kafka is used to reallocate the existing partitions to the new server node (i.e., Broker node). After expanding the distributed cluster (i.e., Kafka cluster), the monitoring tool provided by Kafka can be further used to track the load and performance indicators of the cluster in real time. According to the monitoring results, the configuration of the cluster can be further optimized and adjusted to improve the performance and stability of the system.

[0086] It should be noted that the load rate threshold can be set according to actual conditions such as cluster performance, cluster resource utilization, historical operation data, etc. For example, the load rate threshold can be 80%, 85%, etc.

[0087] S103: Store each alarm message through a distributed full-text search engine.

[0088] Specifically, the embodiments of the present invention use a distributed full-text search engine to replace the traditional MySQL database, improving query performance and response speed. While traditional MySQL database backup and recovery often involve complex scripting and manual operations, the distributed full-text search engine provides a more convenient and automated backup and recovery mechanism. With simple configuration and commands, regular backup and rapid recovery of alarm data can be achieved, significantly reducing operational costs and risks.

[0089] Reference Figure 6 , Figure 6 A flowchart of step S103 provided in an embodiment of the present invention, further as an optional implementation, the step of storing each alarm message by a distributed full-text search engine can be further divided into the following steps S1031:

[0090] S1031. Store each alarm message through ElasticSearch.

[0091] Specifically, taking into account the query performance and response speed, an embodiment of the present invention adopts ElasticSearch for data storage. When the system receives an alarm message, a storage process is triggered immediately. In this process, the alarm message will undergo a series of preprocessing operations, such as formatting the message content to ensure that it meets the index requirements of ElasticSearch, and extracting key information (such as alarm level, occurrence time, trigger source, etc.) for subsequent retrieval and analysis. Then, the preprocessed alarm message will be sent to the ElasticSearch cluster. Using the powerful distributed storage and indexing capabilities of ElasticSearch, these messages will be efficiently stored and a corresponding index structure will be established. When the user needs to query or analyze the alarm message, the query interface provided by ElasticSearch on the front-end interface can be used to quickly locate the relevant alarm information and perform further processing or response as needed.

[0092] ElasticSearch is an open-source search engine built on Lucene. It provides a distributed, multi-tenant full-text search engine with an HTTP web interface and schema-free JSON documents. Designed to handle large volumes of rapidly changing data, Elastic Search is suitable for scenarios requiring complex search queries and real-time analytics. It supports full-text search, structured search, analytics, and combinations of these three, and can scale to hundreds of servers and process petabytes of data.

[0093] Further, if Figure 7 The figure shows a schematic diagram of the message processing flow. Alarm messages triggered by hardware devices flow from the business system to the message center for processing, and then enter the ElasticSearch storage layer, forming an efficient message processing flow. By implementing redundancy and backup of data, data security and availability can be further guaranteed.

[0094] In summary, the processing flow of the multi-channel hardware environment cloud broadcast method based on multi-type warnings in the embodiment of the present invention is as follows: Figure 8 As shown:

[0095] The first step is to design a RESTful API as an access framework. This access framework connects to various hardware devices and receives alarm messages triggered by each hardware device.

[0096] The second step is to introduce Kafka as a message middleware. This message middleware processes each alarm message in parallel and asynchronously, triggering a cloud broadcast task. Based on the cloud broadcast task, the corresponding alarm message is sent to the user end for cloud broadcast notification.

[0097] The third step is to use ElasticSearch for data storage and store the alarm messages in ElasticSearch in real time for backup.

[0098] To better understand the solution of the embodiment of the present invention, the multi-channel hardware environment cloud broadcast method provided by the embodiment of the present invention is described below through specific application examples.

[0099] In smart home security monitoring projects, different types of hardware devices such as smoke sensors, gas sensors, and temperature sensors are deployed in various corners of the home. It is necessary to integrate the environmental data collected by each sensor to enable users to monitor and control in real time. The specific implementation steps are as follows:

[0100] 1) Build a unified access framework: Develop a RESTful API and provide detailed API documentation so that smoke sensors, gas sensors, and temperature sensors can be connected in the same way and receive alarm messages triggered by each sensor.

[0101] 2) Introducing Kafka message middleware: Building a Kafka cluster to implement parallel data and asynchronous processing of alarm messages from various sensors, and configuring consumers to process different types of alarm messages.

[0102] 3) Use ElasticSearch for data storage, store alarm messages in the ElasticSearch storage layer in real time, and use the query interface provided by ElasticSearch on the front-end interface to achieve fast search and visualization for user-friendly access and use.

[0103] After a period of deployment and testing, the project successfully achieved fast and efficient data exchange. Response times for queries of billions of messages have reached milliseconds, significantly simplifying user operations and making device usage intuitive and easy to understand, significantly improving the overall user experience.

[0104] The above describes the multi-channel hardware environment cloud broadcast method based on multiple types of warnings in the embodiment of the present invention. It can be seen that compared with the alarm message cloud broadcast notification method in the prior art, the embodiment of the present invention has the following advantages:

[0105] 1. Design a set of RESTful APIs as standard application programming interfaces (APIs). This allows hardware devices from different channels and manufacturers to access the same method, reducing the need to adapt different systems and services. Developers only need to rely on a unified API, eliminating the need to write separate integration code for each system, thus reducing development and maintenance costs.

[0106] Second, we introduced Kafka as a message middleware. The parallel message processing mechanism combined with the message queue achieves high throughput and can process multiple alarm messages simultaneously, further improving the system's throughput and meeting large-scale data processing needs. Users can add consumers and producers as needed, dynamically expanding the system to accommodate business growth.

[0107] 3. Using ElasticSearch as a storage solution can significantly improve query performance and response speed, achieving millisecond-level response for queries of billions of data.

[0108] Reference Figure 9 The embodiment of the present invention further provides a multi-channel hardware environment cloud broadcast system based on multi-type warnings, including:

[0109] Access framework construction module, used to build an access framework, access multiple hardware devices through the access framework, and receive alarm messages triggered by each hardware device;

[0110] The message asynchronous processing module is used to build a distributed cluster, perform parallel and asynchronous processing on each alarm message through the distributed cluster, obtain cloud broadcast tasks, and perform cloud broadcast notifications based on the cloud broadcast tasks;

[0111] The data storage module is used to store each alarm message through a distributed full-text search engine.

[0112] It can be understood that the contents of the above-mentioned multi-channel hardware environment cloud broadcast method embodiment based on multi-type warnings are all applicable to the present multi-channel hardware environment cloud broadcast system embodiment based on multi-type warnings. The functions specifically implemented by the present multi-channel hardware environment cloud broadcast system embodiment based on multi-type warnings are the same as those of the above-mentioned multi-channel hardware environment cloud broadcast method embodiment based on multi-type warnings, and the beneficial effects achieved are also the same as those achieved by the above-mentioned multi-channel hardware environment cloud broadcast method embodiment based on multi-type warnings.

[0113] An embodiment of the present invention further provides an electronic device comprising: a memory, a processor, a program stored in the memory and executable on the processor, and a data bus for enabling communication between the processor and the memory. When the program is executed by the processor, the aforementioned multi-channel hardware environment cloud broadcast method based on multi-type alerts is implemented. The electronic device can be any intelligent terminal, including a tablet computer and an in-vehicle computer.

[0114] like Figure 10 FIG2 is a schematic diagram of the hardware structure of the electronic device provided by the embodiment of the present invention, referring to FIG2 Figure 10 , an embodiment of the present invention provides an electronic device, including:

[0115] The processor 1001 may be implemented as a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, and is configured to execute relevant programs to implement the technical solutions provided by the embodiments of the present invention.

[0116] The memory 1002 can be implemented in the form of a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 1002 can store an operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 1002 and is called by the processor 1001 to execute the multi-channel hardware environment cloud broadcast method based on multi-type warnings in the embodiments of the present invention.

[0117] Input / output interface 1003, used to implement information input and output;

[0118] Communication interface 1004, used to implement communication interaction between this device and other devices, which can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WiFi, Bluetooth, etc.);

[0119] Bus 1005 , which transmits information between various components of the device (e.g., processor 1001 , memory 1002 , input / output interface 1003 , and communication interface 1004 );

[0120] The processor 1001 , the memory 1002 , the input / output interface 1003 and the communication interface 1004 are connected to each other in communication within the device via the bus 1005 .

[0121] An embodiment of the present invention also provides a storage medium, which is a computer-readable storage medium used for computer-readable storage. The storage medium stores one or more programs, and the one or more programs can be executed by one or more processors to implement the above-mentioned multi-channel hardware environment cloud broadcast method based on multi-type warnings.

[0122] It can be understood that the contents of the above-mentioned multi-channel hardware environment cloud broadcast method embodiment based on multi-type warnings are all applicable to the present storage medium embodiment, and the functions specifically implemented by the present storage medium embodiment are the same as those of the above-mentioned multi-channel hardware environment cloud broadcast method embodiment based on multi-type warnings, and the beneficial effects achieved are also the same as those achieved by the above-mentioned multi-channel hardware environment cloud broadcast method embodiment based on multi-type warnings.

[0123] The memory, as a non-transient computer-readable storage medium, can be used to store non-transient software programs and non-transient computer executable programs. In addition, the memory may include a high-speed random access memory and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some embodiments, the memory may optionally include a memory remotely arranged relative to the processor, and these remote memories may be connected to the processor via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0124] The embodiment of the present invention also discloses a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device can read the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device performs Figure 1 The method shown.

[0125] In some optional embodiments, the function / operation mentioned in the block diagram may not occur in the order mentioned in the operation diagram. For example, depending on the function / operation involved, the two boxes shown in succession can actually be executed substantially simultaneously or the above-mentioned boxes can sometimes be executed in reverse order. In addition, the embodiment presented and described in the flow chart of the present invention is provided in an exemplary manner for the purpose of providing a more comprehensive understanding of the technology. The disclosed method is not limited to the operation and logic flow presented herein. Optional embodiments are contemplated in which the order of the various operations is changed and the sub-operations described as a part of a larger operation are performed independently.

[0126] In addition, although the present invention is described in the context of functional modules, it should be understood that, unless otherwise stated, one or more of the above-mentioned functions and / or features can be integrated into a single physical device and / or software module, or one or more functions and / or features can be implemented in separate physical devices or software modules. It is also understood that a detailed discussion of the actual implementation of each module is not necessary for understanding the present invention. More specifically, given the properties, functions, and internal relationships of the various functional modules in the devices disclosed herein, the actual implementation of the module will be understood within the routine skills of an engineer. Therefore, a person skilled in the art can implement the present invention set forth in the claims using ordinary skills without undue experimentation. It is also understood that the specific concepts disclosed are merely illustrative and are not intended to limit the scope of the present invention, which is determined by the full scope of the appended claims and their equivalents.

[0127] If the above functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the above methods of each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, and other media that can store program code.

[0128] The logic and / or steps represented in the flowcharts or otherwise described herein, for example, can be considered as an ordered list of executable instructions for implementing the logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (e.g., a computer-based system, a system including a processor, or other system that can fetch and execute instructions from an instruction execution system, apparatus, or device). For purposes of this specification, a "computer-readable medium" can be any device that can contain, store, communicate, propagate, or transport a program for use by, or in conjunction with, an instruction execution system, apparatus, or device.

[0129] More specific examples (a non-exhaustive list) of computer-readable media include the following: an electrical connection with one or more wires (electronic devices), a portable computer disk cartridge (magnetic devices), a random access memory (RAM), a read-only memory (ROM), an erasable and programmable read-only memory (EPROM or flash memory), a fiber optic device, and a portable compact disc read-only memory (CDROM). In addition, the computer-readable medium may even be paper or other suitable media on which the program is printed, since the program may be obtained electronically, for example, by optically scanning the paper or other media, followed by editing, deciphering, or processing in another suitable manner as necessary, and then stored in a computer memory.

[0130] It should be understood that various parts of the present invention can be implemented using hardware, software, firmware, or a combination thereof. In the above-described embodiments, multiple steps or methods can be implemented using software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented using hardware, as in another embodiment, any one of the following technologies known in the art or a combination thereof can be used: a discrete logic circuit having a logic gate circuit for implementing a logic function on a data signal, an application-specific integrated circuit having a suitable combination of logic gate circuits, a programmable gate array (PGA), a field programmable gate array (FPGA), etc.

[0131] In the above description of this specification, reference to the terms "one embodiment / example," "another embodiment / example," or "certain embodiments / examples" means that the specific features, structures, materials, or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representation of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.

[0132] While embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions, and variations may be made to the embodiments without departing from the principles and spirit of the invention, and that the scope of the invention is defined by the claims and their equivalents.

[0133] The above is a specific description of the preferred implementation of the present invention, but the present invention is not limited to the embodiments. Those skilled in the art can make various equivalent modifications or substitutions without violating the spirit of the present invention. These equivalent modifications or substitutions are all included in the scope defined by the claims of this application.

Claims

1. A multi-channel hardware environment cloud broadcast method based on multi-type warnings, characterized in that: The following steps are involved: Building an access framework, accessing multiple hardware devices through the access framework, and receiving alarm messages triggered by each of the hardware devices; Building a distributed cluster, performing parallel and asynchronous processing on each of the alarm messages through the distributed cluster to obtain a cloud broadcast task, and performing cloud broadcast notification according to the cloud broadcast task; Storing each of the alarm messages through a distributed full-text search engine; The construction of the access framework specifically includes: defining an application programming interface to enable multiple hardware devices to be accessed through the same access method; Setting an interface document, wherein the interface document includes at least a request method, request parameters, and a response format; The construction of a distributed cluster is specifically as follows: Use Kafka as the message middleware to build the distributed cluster; The distributed cluster is used to perform parallel and asynchronous processing on each of the alarm messages to obtain a cloud broadcast task, and cloud broadcast notification is performed according to the cloud broadcast task, specifically including: Querying preset linkage records, and performing parallel and asynchronous processing on each of the alarm messages according to the linkage records through the distributed cluster; triggering the cloud broadcast task according to the alarm message after parallel processing and asynchronous processing, and sending the corresponding alarm message to the user end for cloud broadcast notification according to the cloud broadcast task; The storing of each of the warning messages by the distributed full-text search engine is specifically as follows: Each of the alarm messages is stored through ElasticSearch.

2. A multi-channel hardware environment cloud broadcast method based on multi-type warnings according to claim 1, characterized in that: The multi-channel hardware environment cloud broadcast method further includes: A current load rate is obtained, and the distributed cluster is expanded according to the current load rate.

3. A multi-channel hardware environment cloud broadcast method based on multi-type warnings according to claim 2, characterized in that: The obtaining of the current load rate and the expansion of the distributed cluster according to the current load rate specifically include: Obtaining the current load rate; When the current load rate is greater than a preset load rate threshold, configuring a new server node, and then adding the node information of the server node to the distributed cluster; Redistributing the partitions of the distributed cluster.

4. A multi-channel hardware environment cloud broadcast system based on multi-type warnings, characterized by: include: An access framework construction module is used to construct an access framework, access a variety of hardware devices through the access framework, and receive alarm messages triggered by each of the hardware devices; A message asynchronous processing module is used to build a distributed cluster, perform parallel and asynchronous processing on each of the alarm messages through the distributed cluster, obtain a cloud broadcast task, and perform cloud broadcast notification according to the cloud broadcast task; A data storage module, used for storing each of the alarm messages through a distributed full-text search engine; The construction of the access framework specifically includes: defining an application programming interface to enable multiple hardware devices to be accessed through the same access method; Setting an interface document, wherein the interface document includes at least a request method, request parameters, and a response format; The construction of a distributed cluster is specifically as follows: Use Kafka as the message middleware to build the distributed cluster; The distributed cluster is used to perform parallel and asynchronous processing on each of the alarm messages to obtain a cloud broadcast task, and cloud broadcast notification is performed according to the cloud broadcast task, specifically including: Querying preset linkage records, and performing parallel and asynchronous processing on each of the alarm messages according to the linkage records through the distributed cluster; triggering the cloud broadcast task according to the alarm message after parallel processing and asynchronous processing, and sending the corresponding alarm message to the user end for cloud broadcast notification according to the cloud broadcast task; The storing of each of the warning messages by the distributed full-text search engine is specifically as follows: Each of the alarm messages is stored through ElasticSearch.

5. An electronic device, characterized in that: The electronic device includes a memory, a processor, a program stored in the memory and executable on the processor, and a data bus for realizing connection and communication between the processor and the memory. When the program is executed by the processor, the steps of the multi-channel hardware environment cloud broadcast method based on multi-type alerts as described in any one of claims 1 to 3 are realized.

6. A storage medium, which is a computer-readable storage medium and is used for computer-readable storage, characterized in that: The storage medium stores one or more programs, and the one or more programs can be executed by one or more processors to implement the steps of the multi-channel hardware environment cloud broadcast method based on multi-type warnings as described in any one of claims 1 to 3.

Images