A message pushing method and system of an internet of things

Abstract

The application relates to the technical field of data processing, in particular to a message pushing method and system of an Internet of Things, which comprises the following steps: obtaining a device message to be pushed; performing batch aggregation processing on the device message to obtain a processed message; performing Webhook pushing on the processed message based on a double-layer thread pool architecture; determining a pushing failure number based on a URL corresponding to the Webhook pushing; if the pushing failure number reaches a preset number threshold, performing fuse breaking on an operation corresponding to the Webhook pushing, generating and outputting fuse breaking information; and under the condition that the fuse breaking information meets a preset time condition, continuing to perform Webhook pushing on the processed message. In this way, the failure number is monitored in real time based on the URL dimension, the health state of a downstream service is intelligently judged, a fuse breaking strategy is automatically triggered, the overall availability is guaranteed, and the safety of message pushing is improved.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and more specifically to a message push method and system for the Internet of Things (IoT) within the field of data processing technology. Background Technology

[0002] In data-driven modern application architectures, webhooks serve as a crucial mechanism for real-time communication between services, bearing the heavy responsibility of efficiently, reliably, and securely pushing events or data to downstream systems. However, with the growth of business scale, especially in scenarios such as the Internet of Things (IoT) with massive numbers of devices and frequent event triggers, traditional webhook implementations can easily lead to excessive pressure on downstream services or even crashes. When a single push fails, the retry mechanism is inefficient and prone to causing repeated pressure. Furthermore, the lack of robust exception handling mechanisms and simple single-key authentication makes them vulnerable to cracking, and the absence of a request legitimacy verification mechanism makes it difficult to identify malicious requests. These security risks are particularly prominent in the open and interconnected IoT environment. Summary of the Invention

[0003] The purpose of this invention is to provide a message push method and system for the Internet of Things (IoT), and the specific technical solution adopted is as follows:

[0004] In a first aspect, embodiments of the present invention provide a message push method for the Internet of Things (IoT), the method comprising:

[0005] Retrieve device messages to be pushed;

[0006] The device messages are batch aggregated to obtain processed messages;

[0007] Based on a two-layer thread pool architecture, the processed messages are pushed via Webhook.

[0008] Based on the URL corresponding to the Webhook push, determine the number of push failures;

[0009] If the number of failed pushes reaches a preset threshold, a circuit breaker message is generated and output.

[0010] If the circuit breaker information meets the preset time condition, the processed message will continue to be pushed via Webhook.

[0011] Secondly, embodiments of the present invention provide an Internet of Things (IoT) message push system, the system comprising:

[0012] The acquisition module is used to acquire device messages to be pushed.

[0013] The aggregation module is used to perform batch aggregation processing on the device messages to obtain processed messages;

[0014] The first push module is used to push the processed messages via Webhook based on a two-layer thread pool architecture.

[0015] The determination module is used to determine the number of push failures based on the URL corresponding to the Webhook push;

[0016] The generation module is used to trigger a circuit breaker for the operation corresponding to the Webhook push if the number of push failures reaches a preset threshold, and to generate and output circuit breaker information.

[0017] The second push module is used to continue pushing the processed message via Webhook when the circuit breaker information meets the preset time conditions.

[0018] Thirdly, a computer program product is provided, comprising: computer program code, which, when run on a computer, causes the computer to perform the method described in the first aspect.

[0019] Fourthly, a computer-readable storage medium is provided that stores computer program code, which, when executed on a computer, causes the computer to perform the method described in the first aspect.

[0020] This invention offers the following advantages: After acquiring the device messages to be pushed, the device messages are batch aggregated to prevent excessive data volume in the processed messages and avoid large single push volumes. Then, a two-layer thread pool architecture is used to push the processed messages via Webhook, ensuring rapid consumption and handling of sudden traffic surges. The number of push failures is determined based on the URL corresponding to the Webhook push. If the number of push failures reaches a preset threshold, the operation corresponding to the Webhook push is circuit-broken, generating and outputting circuit-broken information. Thus, circuit-broken detection is performed using the Uniform Resource Locator (URL) as a dimension. When the number of pushes reaches the preset threshold, a circuit-broken operation is triggered, stopping Webhook pushes and outputting circuit-broken information. Finally, if the circuit-broken information meets a preset time condition, Webhook pushes of the processed messages continue. In this way, by monitoring the number of failures in real time based on the URL dimension, intelligently judging the health status of downstream services, and automatically triggering the circuit breaker strategy, push notifications are proactively paused when downstream services are abnormal, thus avoiding invalid requests. Moreover, by judging whether the circuit breaker information meets the preset time conditions, a timed self-recovery mechanism is implemented, which can restore normal service without manual intervention, effectively preventing downstream service overload and system avalanche effect, ensuring overall availability, and thus improving the security of message push. Attached Figure Description

[0021] To more clearly illustrate the technical solutions and advantages in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 This is a schematic diagram illustrating the implementation process of a message push method for the Internet of Things provided in an embodiment of the present invention;

[0023] Figure 2 This is a schematic diagram illustrating another implementation process of a message push method for the Internet of Things provided in an embodiment of the present invention;

[0024] Figure 3 This is a schematic diagram illustrating another implementation process of a message push method for the Internet of Things provided in this embodiment of the invention;

[0025] Figure 4 This is a schematic diagram illustrating another implementation process of a message push method for the Internet of Things provided in an embodiment of the present invention;

[0026] Figure 5 This is a schematic diagram illustrating another implementation process of a message push method for the Internet of Things provided in an embodiment of the present invention;

[0027] Figure 6 This is a schematic diagram illustrating another implementation process of a message push method for the Internet of Things provided in this embodiment of the invention;

[0028] Figure 7 This is a schematic diagram of the composition structure of an Internet of Things (IoT) message push system provided in an embodiment of the present invention;

[0029] Figure 8 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0030] To further illustrate the technical means and effects adopted by the present invention to achieve its intended purpose, the following, in conjunction with the accompanying drawings and preferred embodiments, details the specific implementation, structure, features, and effects of an IoT message push method proposed according to the present invention. In the following description, different "one embodiment" or "another embodiment" do not necessarily refer to the same embodiment. Furthermore, specific features, structures, or characteristics in one or more embodiments can be combined from any suitable form.

[0031] In the description of the embodiments of the present invention, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of the present invention, "multiple" means two or more.

[0032] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0033] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.

[0034] In related technologies, Webhook push typically involves pushing data one at a time, which is inefficient, wastes network resources, and puts heavy pressure on the target service. In high-frequency event scenarios, a single push can generate a large number of concurrent requests to downstream services in a short period of time, easily leading to excessive pressure or even crashes of downstream services. When a single push fails, the retry mechanism is inefficient and can easily cause repeated pressure. In scenarios with large amounts of device data and frequent events, there is a need for efficient and low-latency pushing of a large number of Webhook events to downstream systems.

[0035] When downstream Webhook services are unavailable (e.g., downtime, network failure), continuous retries will result in a large number of invalid requests, wasting bandwidth and computing resources. This could exhaust the system's own threads, queues, databases, and other resources, ultimately affecting the stability of the entire system. Continuous pushes can also cause excessive pressure or even crashes on downstream services when they are unstable or unavailable. Therefore, pushes should be automatically paused when downstream services experience anomalies to protect both the system and downstream services, and should automatically resume after a certain period.

[0036] Webhook implementations typically lack robust security mechanisms, facing risks such as data breaches, request forgery, and replay attacks. Simple single-key authentication is easily cracked, and the lack of request legitimacy verification mechanisms makes it difficult to identify malicious requests, especially in open and interconnected IoT environments where security vulnerabilities are particularly prominent. Furthermore, Secure Socket Layer (SSL) policies are inflexible and cannot adapt to diverse deployment environments, lax access control leads to unauthorized data access, and the lack of comprehensive auditing and tracing capabilities makes troubleshooting extremely difficult. In today's world where data security and compliance are increasingly important, a secure transmission and authentication solution is urgently needed.

[0037] Based on this, embodiments of the present invention provide a message push method for the Internet of Things (IoT). The specific scheme of the message push method for the IoT provided by the present invention will be described in detail below with reference to the accompanying drawings. Please refer to... Figure 1 The diagram illustrates a flowchart of an IoT message push method according to an embodiment of the present invention, the method comprising:

[0038] 101. Retrieve device messages to be pushed.

[0039] Here, the device message to be pushed can be any type of message from an IoT device. For example, a message pushed via an IoT-based webhook.

[0040] 102. Perform batch aggregation processing on the device messages to obtain processed messages.

[0041] Here, processed messages are obtained by using a multi-level message batch aggregation mechanism on device messages.

[0042] In some possible implementations, step 102 above can be achieved through the following process:

[0043] First, the Kafka partition of the device messages is determined. Then, based on the Kafka partition of the device messages, batch aggregation processing is performed on the device messages to obtain processed messages. For example, the device messages are specified in the Kafka partition through a device SN modulo operation to ensure that messages from the same device (i.e., messages from the same device) are processed by the same consumer, guaranteeing order. Next, message event aggregation is automatically implemented through batch message listening, using a dual triggering strategy (1000 milliseconds (ms) time window or 200 messages) to consume messages in batches.

[0044] In some possible implementations, after partitioning the device messages using Kafka, a mapping relationship between the device to which the device message belongs and the application is established in each Kafka partition; then, based on the mapping relationship, the device messages are grouped according to the application dimension to obtain multiple groups of device messages; and the multiple groups of device messages are then sharded multiple times to obtain the processed message.

[0045] Here, after device messages are consumed by the message center, they are handed over to the business layer for further grouping and Webhook push. First, the relationship between devices and applications is queried to establish a mapping between devices and applications. For example, assuming the user has pre-created applications and devices (each guaranteed unique by a unique application identifier (ID) and a unique device ID), the system binds applications to devices (a one-to-many relationship between applications and devices) and stores the binding relationship in a relational database (MySQL). Under this premise, the system queries the database for the application data bound to the devices based on a batch of device identifiers (IDs). The specific mapping is constructed using a Map data structure in a programming language (Java), where the key is the device ID and the value is a list of application IDs. Then, device messages are grouped by application dimension, and large batches of events under an application are further sharded according to configured thresholds to avoid excessively large data volumes in a single push. For example, when a large number of device messages need to be pushed, the system first performs initial sharding at the application level. According to a predefined batch size, for instance, ten applications are grouped into a processing unit. The ten applications within a group use a thread pool to push Webhook data in parallel; this is the first application-level sharding. Secondary sharding involves further sharding the batch of Webhook data pushed by each application to prevent excessively large data packets from affecting the push process. Based on the preset size, Webhook messages from each application are sharded in batches of 50, meaning each application's message body contains a maximum of 50 messages per batch.

[0046] 103. Based on a two-layer thread pool architecture, Webhook push is performed on processed messages.

[0047] Here, a two-layer thread pool architecture is used, including a message consumption thread pool and a message push thread pool. The message consumption thread pool is dedicated to event listening and initial processing, and its zero queue capacity ensures fast consumption. The message push thread pool is dedicated to concurrently pushing Hypertext Transfer Protocol (HTTP) requests, and its large queue capacity can handle sudden traffic surges.

[0048] In some possible implementations, step 103 above can be achieved by... Figure 2 The illustrated process involves three steps: first, event collection and partitioning (events pushed via Webhook); second, batch event listening; third, event grouping; fourth, application-level concurrent processing; and finally, application-wide batching and sharding, along with batch pushes, to ensure downstream systems receive the data. The specific implementation process can be described as follows: Figure 3As shown: First, the device reports data (i.e., obtains device messages). Second, a message partitioning strategy is used to partition the device messages. This strategy includes: inputting device messages into a Kafka message queue and partitioning them using the device's serial number (SN) modulo to ensure message order; message consumers use a dual-trigger strategy (e.g., a 1000ms time window or 200 messages) to batch process consumed messages. Next, multi-level batch aggregation is performed on the batch-processed messages. For example, a consumer thread pool is used to manage queue capacity, the relationship between devices and applications is queried, a mapping relationship between devices and applications is established, and device messages are grouped by application ID. Then, application partitioning is implemented using 10-shards, and application-level sharding is performed in parallel. The parallel-processed data is processed asynchronously, followed by secondary sharding of in-application events, including: large queue capacity of the Webhook push pool, in-application event aggregation, event partitioning, and event-level sharding. Finally, the Webhook push processing logic is triggered. In the above process, device events are pushed to the message center buffer based on the message queue, and partitioned using the device's SN code modulo to ensure event order. Next, the message center consumer listens for and aggregates events according to time windows or quantity thresholds to form batch event sets. After grouping the event sets by application dimension, they are serialized into JSON arrays and pushed in batches through concurrent processing and batch sharding strategies. Combined with asynchronous fault tolerance mechanisms (such as asynchronous programming tools (CompletableFuture) for non-blocking requests and failure retries), throughput efficiency is significantly improved and HTTP connection overhead is reduced.

[0049] 104. Based on the URL corresponding to the Webhook push, determine the number of push failures.

[0050] Here, the number of failed pushes is counted based on the URL corresponding to the Webhook push. When the number of failed pushes reaches a preset threshold, a circuit breaker operation is automatically executed to stop the Webhook push.

[0051] In some possible implementations, upon detecting a failed URL request, a check setting operation in a preset database is determined; and based on the number of times the URL request failed, the number of push failures is obtained by recording the number of times the check device operation failed.

[0052] Here, when the system detects a failed URL request, it records the number of failed pushes using a check setting (SETNX) with an expiration time provided by the database (Redis). When the number of failed pushes reaches a threshold, a circuit breaker is triggered.

[0053] 105. If the number of failed pushes reaches a preset threshold, the operation corresponding to the Webhook push is circuit-broken, and circuit-broken information is generated and output.

[0054] Here, if the number of failed pushes reaches a preset threshold, a circuit breaker is triggered to stop Webhook pushes. Circuit breaker information is generated by recording the start time of the circuit breaker operation.

[0055] In some possible implementations, step 105 above can be achieved through the following process:

[0056] First, if the number of failed push notifications reaches the preset threshold, a circuit breaker operation is triggered.

[0057] Here, the preset number of times threshold can be a custom threshold. After detecting a failed URL request, it is determined whether the number of failed pushes has reached the preset number of times threshold. If the preset number of times threshold has been reached, then a circuit breaker operation is triggered to stop Webhook push.

[0058] Secondly, in response to the circuit breaker operation, the Webhook push for the processed messages is stopped within a preset time period.

[0059] Here, the preset duration can be a custom duration. It checks whether the time elapsed from the start of the circuit breaker operation to the current time is less than the preset duration. If it is less, the Webhook push for the processed message is stopped. In some possible implementations, after triggering the circuit breaker, the URL is recorded as having been circuit-breakered, i.e., the URL is recorded as having been circuit-breakered using Redis's `SETNX` method, with the key value being a unique key derived from the URL. The next time a Webhook push is triggered, the key value is retrieved from Redis based on the URL. If it exists, it indicates that the circuit breaker has been triggered. The push continues until the key value expires (i.e., the Webhook is pushed again).

[0060] Finally, based on the preset duration and the start time of the circuit breaker operation, the circuit breaker information is generated and output.

[0061] Here, the preset duration and the start time of the circuit breaker operation are combined to generate a key value, which is then used as the circuit breaker information and output.

[0062] In the above process, the dimension of circuit breaker isolation is URL, and the isolation is the Webhook push operation. When the circuit breaker is triggered, the system stops sending pushes to the Webhook to reduce invalid resource requests. After the circuit breaker is triggered, the push of Webhook messages to the URL will be stopped within a specified time, and a circuit breaker message notification will be triggered, that is, the circuit breaker information will be output.

[0063] 106. If the circuit breaker information meets the preset time condition, continue to push the processed message via Webhook.

[0064] Here, by determining whether the circuit breaker information has expired, it is determined whether the circuit breaker information meets the preset time conditions. If the circuit breaker information has expired, it is determined that the circuit breaker information meets the preset conditions, and in response to the push command, the Webhook push of the processed messages continues. If the circuit breaker information has not expired, it is determined that the circuit breaker information does not meet the preset conditions, and in response to the triggered push command, the push of the processed messages continues to be stopped.

[0065] In some possible implementations, the MQTT status is pushed immediately after the Webhook push to avoid blocking the main process. This can be achieved through the following process:

[0066] MQTT topics are configured with unique user and application identifiers to ensure message isolation. MQTT status is pushed immediately after a Webhook push, allowing the frontend to update the UI in real time and send MQTT messages asynchronously without blocking the main workflow. The frontend subscribes to MQTT messages to obtain the real-time status of Webhook messages. Upon receiving a push notification, it promptly refreshes to obtain the latest Webhook message push record, thus achieving real-time MQTT notifications.

[0067] In some possible implementations, firstly, the circuit breaker duration between the start time of the circuit breaker operation corresponding to the circuit breaker information and the current time is determined; here, the circuit breaker duration can be recorded using a key value. Secondly, if the circuit breaker duration reaches the preset duration, it is determined that the circuit breaker information meets the preset time condition; here, it is determined whether the circuit breaker duration represented by the key value has timed out, i.e., whether the preset duration has been reached, thereby determining whether the circuit breaker information meets the preset time condition. Finally, when a Webhook push trigger operation is detected, Webhook push continues for the processed message. Here, if the circuit breaker duration reaches the preset duration, it means that the circuit breaker duration represented by the key value has timed out, so Webhook push can continue for the processed message in response to the Webhook push trigger operation.

[0068] In some possible implementations, the retry interval for Webhook pushes can be dynamically set to facilitate timely and uncluttered push retries. This can be achieved through the following process:

[0069] First, obtain the retry interval for the Webhook push;

[0070] The retry interval increases exponentially with the number of retries. An exponential backoff algorithm is used, with the retry interval starting at 2000ms and increasing by 2 times each time to avoid retry storms.

[0071] Secondly, when the time of the Webhook push reaches the retry duration interval corresponding to the current retry count, it is determined whether the current retry count has reached the preset retry count threshold, and whether the circuit breaker information corresponding to the Webhook push meets the preset time conditions.

[0072] Here, in response to the triggered Webhook push operation, it is determined whether the Webhook push time has reached the corresponding retry interval. If the retry interval has been reached, it is further determined whether the current retry count has reached the preset retry count threshold, and whether the circuit breaker information corresponding to the Webhook push has timed out.

[0073] Finally, if the current number of retries has not reached the preset retry threshold, and the circuit breaker information corresponding to the Webhook push meets the preset time condition, the Webhook push will be performed again.

[0074] Here, if the current number of retries has not reached the preset retry threshold, and the circuit breaker information corresponding to the Webhook push has expired, then the Webhook push will be retried.

[0075] In some possible implementations, Webhook push relies on HTTP / HTTPS requests. However, network requests are subject to fluctuations, which can lead to instability. Setting a retry interval is mainly to minimize the impact of uncontrollable downstream factors such as network fluctuations. Specifically, this is achieved through the @Retryable annotation provided by the Spring framework, which allows specifying exceptions, the number of retries, and the backoff strategy.

[0076] exist Figure 3 After triggering the Webhook push processing logic based on this, the above-mentioned automatic circuit breaker process can be... Figure 4 The process shown is implemented as follows:

[0077] First, obtain the Webhook push processing logic; second, query the application's Webhook configuration to obtain the configuration; third, determine if the URL is in a circuit breaker state (i.e., determine whether the current state is under circuit breaker based on the URL, for example, whether the circuit breaker duration represented by the key value in the circuit breaker information has expired); fourth, if yes (i.e., the circuit breaker duration has not expired and the current state is under circuit breaker), skip the Webhook push; if no (i.e., the circuit breaker duration has expired and the current state is not under circuit breaker), attempt the Webhook push. Afterwards, construct a signed request and transmit it over the network to a third-party receiving system (i.e., ... Figure 6The process involves several steps: First, the third-party receiving system returns a status code to determine if the circuit breaker condition is triggered, specifically whether the number of URL failures is greater than or equal to a threshold. If the number of URL failures is greater than or equal to the threshold, the automatic circuit breaker recovery mechanism is activated. The circuit breaker status is set (including: Redis key: url; expiration time: reset Timeout), and a circuit breaker Webhook notification is sent (i.e., circuit breaker information is generated and output), and the push record is saved. Then, the Redis key automatically expires (after reset Timeout seconds, the Redis key automatically expires, meaning the circuit breaker information has expired), the circuit breaker status is automatically cleared, and the service is restored. In this way, the number of push failures is counted in real time based on the URL dimension. When the threshold is reached, the circuit breaker is automatically triggered, pausing pushes to isolate the fault. The circuit breaker status interception mechanism actively skips invalid requests, and combined with a timed recovery strategy and retry annotations, automatically handles momentary faults. All failure records are persistently stored and logged to ensure push reliability and anomaly traceability, avoiding resource exhaustion and cascading failures.

[0078] If the number of URL failures is less than a threshold, determine whether a retry is necessary. If a retry is required, an exponential backoff algorithm is used, with retry intervals starting at 2000ms and increasing by double each time, to intelligently retry and save the push record. If no retries are needed, the push record is saved directly. Figure 4 As shown, push records can be stored in a push history database (which includes: URL / content / status / time). In the implementation of front-end display and monitoring, the front-end application first enables history recording and queries the push status, and simultaneously publishes MQTT messages via a defined MQTT topic (e.g., sending MQTT messages by user / application ID). Second, it queries the push history API, performs a paginated query in the push history database, obtains the query results (i.e., MQTT messages), and publishes the MQTT messages. Thus, after a user enables the Webhook history recording switch, they can view the message content, request time, and message push status (e.g., whether the push was successful) pushed to a specified Webhook address, page by page.

[0079] In some possible implementations, real-time MQTT notifications can be sent after a Webhook push. Figure 5The process is as follows: First, an event is generated (an event that triggers a Webhook push); second, the Webhook configuration is retrieved; third, it is determined whether there is permission to check event subscriptions; if not, the event is discarded; if it is, a security header is constructed, and a secure signature is generated by generating a timestamp and a random number; then, an HTTP request is constructed using a key-based hash-based Message Authentication Code (HMAC) algorithm, and an identity identifier and signature are added to determine the SSL authentication mode; if it is standard authentication, HTTPS secure transmission is performed through a standard SSL client; if it is bypassed authentication, HTTPS secure transmission is performed through a non-authentication SSL client; finally, the request and response are recorded, and MQTT status is synchronized. In this way, the frontend can obtain the real-time status of Webhook messages by subscribing to MQTT messages, and can promptly refresh and obtain the latest Webhook message push records after receiving a push. Thus, it innovatively combines timestamps, random numbers, and HMAC algorithms to generate one-time signatures, preventing replay attacks; it supports dual-channel strategies, including standard and bypass SSL verification, to flexibly adapt to different deployment environments; it achieves fine-grained event-level subscription permission control to ensure data is pushed on demand; and it establishes a complete security audit chain and MQTT real-time status synchronization mechanism to improve monitoring capabilities.

[0080] In this embodiment of the invention, the acquired device messages are batch aggregated to prevent the amount of processed message data from becoming too large, thus avoiding excessive data in a single push. Then, a two-layer thread pool architecture is used to push the processed messages via Webhook, ensuring rapid consumption and handling of sudden traffic surges. The number of push failures is determined based on the URL corresponding to the Webhook push. If the number of push failures reaches a preset threshold, a circuit breaker is applied to the operation corresponding to the Webhook push, generating and outputting circuit breaker information. Thus, circuit breaker detection is performed at the URL level; when the number of push failures reaches the preset threshold, a circuit breaker operation is triggered, Webhook push is stopped, and circuit breaker information is output. Finally, if the circuit breaker information meets a preset time condition, Webhook push of the processed messages continues. In this way, by monitoring the number of failures in real time based on the URL dimension, intelligently judging the health status of downstream services, and automatically triggering the circuit breaker strategy, push notifications are proactively paused when downstream services are abnormal, thus avoiding invalid requests. Moreover, by judging whether the circuit breaker information meets the preset time conditions, a timed self-recovery mechanism is implemented, which can restore normal service without manual intervention, effectively preventing downstream service overload and system avalanche effect, ensuring overall availability, and thus improving the security of message push.

[0081] In some embodiments, Webhook push can be configured before it is performed, which can be achieved through the following process:

[0082] First, obtain the original configuration information corresponding to the Webhook push; for example, create the Webhook configuration through the API interface, which includes the following key information: application ID (unique identifier of the associated application), Webhook UUID (Universally Unique IDentifier) ​​(for example, a unique identifier automatically generated by the system), key (security key used for signature verification), and callback URL (target address for receiving pushes).

[0083] Secondly, the URL, circuit breaker information, and message status corresponding to the Webhook push are associated with the original configuration information to obtain the associated configuration information.

[0084] Here, after fully recording the URL, content, result status, and other complete information of the push, the URL, circuit breaker information, and message status corresponding to the Webhook push are bound to the original configuration information to obtain the associated configuration information.

[0085] Finally, the Webhook push is tracked based on the associated configuration information.

[0086] Here, the Webhook ID is linked to the original configuration, which facilitates problem tracking, makes it easier to distinguish between success and failure status, and supports subsequent analysis and replay.

[0087] In the above process, Webhook configuration creation and reception are prerequisites for Webhook push. If you need to push device messages to the target Webhook, you need to configure the URL address corresponding to the target Webhook on the platform and set up the Webhook message receiving end downstream.

[0088] In some possible implementations, a secure, tamper-proof verification mechanism for Webhook is achieved by generating a one-time signature using the timestamp, random number, and HMAC algorithm of the Webhook push. This can be implemented through the following process:

[0089] First, a one-time signature is generated based on the timestamp, random number, and HMAC algorithm of the Webhook push.

[0090] Here, the third-party system needs to implement a standard receiving interface to receive a batch event array in JSON format, verify the UUID, timestamp, random number and signature in the request header, and implement efficient processing logic for push messages.

[0091] Secondly, based on the one-time signature, an identity identifier and independent key for the Webhook push are generated. Finally, based on the identity identifier and independent key, the processed message is pushed via Webhook.

[0092] Here, basic authentication is achieved through UUID identity identification and independent key management; one-time signatures are generated using timestamps, random numbers, and HMAC algorithms to effectively prevent replay attacks; and flexible SSL verification strategies ensure both data security and system compatibility. Figure 6 As shown, in Figure 3 Based on this, after triggering the Webhook push processing logic, the process begins by initiating a Webhook push, constructing a signed request header via HTTP POST. This header construction includes: security header construction (generating a timestamp, a random number, and a security signature); constructing the HTTP request using the HMAC algorithm, adding an identity identifier and signature; determining the SSL verification mode; if standard verification is used, an HTTPS request is sent via a standard SSL client; if verification is bypassed, an HTTPS request is sent via a non-verified SSL client. The HTTPS request is then transmitted over the network to a third-party receiving system. In the third-party receiving system, the request header (including UUID / timestamp / random number / signature) is verified via a standard receiving interface, the signature is verified, and the JSON data is parsed. Then, batch events are processed and status codes are returned to determine the HTTP response status; finally, the request result is received and the request response is recorded. Thus, the above process achieves secure and tamper-proof verification of Webhook, implements basic authentication through UUID identity identification and independent key management; generates one-time signatures using timestamps, random numbers, and HMAC algorithms to effectively prevent replay attacks; combines flexible SSL verification strategies to ensure data security while taking into account system compatibility; and persists all request records to form a complete security audit chain.

[0093] In some embodiments, the system can also provide a test interface to verify the validity of the configuration: provide the Webhook UUID and the test URL; the system attempts to send a test message to the specified Webhook URL to verify the validity of the URL; thus, if the user configures a Webhook on the platform but there is no device that will immediately trigger the Webhook push event, a Webhook test message can be triggered to verify whether the sending process is successful.

[0094] In this embodiment of the invention, after obtaining the device messages to be pushed, the device messages are batch aggregated to ensure that the amount of processed messages is not too large, thus avoiding excessive data in a single push. Then, a two-layer thread pool architecture is used to push the processed messages via Webhook to ensure rapid consumption and handle sudden traffic surges. The number of push failures is determined based on the URL corresponding to the Webhook push. If the number of push failures reaches a preset threshold, a circuit breaker is applied to the operation corresponding to the Webhook push, generating and outputting circuit breaker information. Thus, circuit breaker detection is performed at the URL level; when the number of push failures reaches the preset threshold, a circuit breaker operation is triggered, Webhook push is stopped, and circuit breaker information is output. Finally, if the circuit breaker information meets a preset time condition, Webhook push of the processed messages continues. In this way, by monitoring the number of failures in real time based on the URL dimension, intelligently judging the health status of downstream services, and automatically triggering the circuit breaker strategy, push notifications are proactively paused when downstream services are abnormal, thus avoiding invalid requests. Moreover, by judging whether the circuit breaker information meets the preset time conditions, a timed self-recovery mechanism is implemented, which can restore normal service without manual intervention, effectively preventing downstream service overload and system avalanche effect, ensuring overall availability, and thus improving the security of message push.

[0095] This invention provides an Internet of Things (IoT) message push system. Please refer to [link / reference]. Figure 7 This diagram illustrates the structural composition of an Internet of Things (IoT) message push system according to an embodiment of the present invention. The system 700 includes:

[0096] The acquisition module 701 is used to acquire device messages to be pushed.

[0097] Aggregation module 702 is used to perform batch aggregation processing on the device messages to obtain processed messages;

[0098] The first push module 703 is used to push the processed message via Webhook based on a two-layer thread pool architecture.

[0099] The determination module 704 is used to determine the number of push failures based on the URL corresponding to the Webhook push;

[0100] The generation module 705 is used to trigger a circuit breaker for the operation corresponding to the Webhook push if the number of push failures reaches a preset threshold, and to generate and output circuit breaker information.

[0101] The second push module 706 is used to continue pushing the processed message via Webhook when the circuit breaker information meets the preset time condition.

[0102] In some possible implementations, the aggregation module 702 is further configured to determine the Kafka partition of the device message; and based on the Kafka partition of the device message, to perform batch aggregation processing on the device message to obtain processed messages.

[0103] In some possible implementations, the aggregation module 702 is further configured to establish a mapping relationship between the device to which the device message belongs and the application in each Kafka partition of the message device; based on the mapping relationship, group the device messages according to the application dimension to obtain multiple groups of device messages; and perform multiple sharding processes on the multiple groups of device messages to obtain the processed message.

[0104] In some possible implementations, the determining module 704 is further configured to, upon detecting a failed URL request, determine a check setting operation in a preset database; and obtain the number of push failures based on the number of times the URL request failed according to the check device operation record.

[0105] In some possible implementations, the generation module 705 is further configured to trigger a circuit breaker operation if the number of push failures reaches the preset threshold; in response to the circuit breaker operation, stop initiating Webhook pushes to the processed messages for a preset duration; and generate and output the circuit breaker information based on the preset duration and the start time of the circuit breaker operation.

[0106] In some possible implementations, the second push module 706 is further configured to determine the circuit breaker duration between the start time of the circuit breaker operation corresponding to the circuit breaker information and the current time; if the circuit breaker duration reaches the preset duration, it is determined that the circuit breaker information meets the preset time condition, and when the trigger operation of Webhook push is detected, the processed message continues to be pushed via Webhook.

[0107] In some possible implementations, the second push module 706 is further configured to obtain the retry interval of the Webhook push; wherein the retry interval increases exponentially with the number of retries; when the time of the Webhook push reaches the retry interval corresponding to the current number of retries, it is determined whether the current number of retries has reached a preset retry threshold, and whether the circuit breaker information corresponding to the Webhook push meets a preset time condition; if the current number of retries has not reached the preset retry threshold, and the circuit breaker information corresponding to the Webhook push meets the preset time condition, the Webhook push is re-performed.

[0108] In some possible implementations, the second push module 706 is further configured to obtain the original configuration information corresponding to the Webhook push; associate the URL, circuit breaker information and message status corresponding to the Webhook push with the original configuration information to obtain associated configuration information; and track the Webhook push based on the associated configuration information.

[0109] In some possible implementations, the second push module 706 is further configured to generate a one-time signature based on the timestamp of the Webhook push and a preset random number; generate an identity identifier and independent key for the Webhook push based on the one-time signature; and push the processed message via Webhook based on the identity identifier and independent key.

[0110] Optionally, the transmission medium can be a wired link (e.g., but not limited to, coaxial cable, optical fiber, and Digital Subscriber Line (DSL)) or a wireless link (e.g., but not limited to, Wireless Internet Access (WIFI), Bluetooth, and mobile device networks). It should be noted that the system provided in the above embodiments is only an example illustrating the division of the functional modules described above. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the computer device can be divided into different functional modules to complete all or part of the functions described above. Furthermore, the method embodiments provided in the above embodiments belong to the same concept, and their specific implementation processes are detailed in the method embodiments, and will not be repeated here.

[0111] Figure 8 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present invention. For example, as shown... Figure 8 As shown, the computer device 800 includes: a memory 801, a processor 802, and a computer program 803 stored in the memory 801 and running on the processor 802, wherein when the processor 802 executes the computer program 803, the computer device can execute any of the IoT message push methods described above.

[0112] Furthermore, this embodiment of the invention also protects a system that may include a memory and a processor. The memory stores executable program code, and the processor is used to call and execute the executable program code to perform a message push method for the Internet of Things provided by this embodiment. This embodiment can divide the system into functional modules based on the above method example. For example, each module can correspond to a specific function, or two or more functions can be integrated into a single processing module. The integrated module can be implemented in hardware. It should be noted that the module division in this embodiment is illustrative and only represents a logical functional division; other division methods may exist in actual implementation. It should also be noted that all relevant content of each step involved in the above method embodiment can be referenced to the functional description of the corresponding functional module, and will not be repeated here.

[0113] It should be understood that the system provided in this embodiment is used to execute the above-described IoT message push method, and therefore can achieve the same effect as the above-described implementation method. When using integrated units, the system may include a processing module and a storage module. When the system is applied to a device, the processing module can be used to control and manage the device's actions. The storage module can be used to support the device in executing mutual program code, etc. The processing module may be a processor or a controller, which can implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this invention. The processor may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of Digital Signal Processing (DSP) and a microprocessor, etc., and the storage module may be a memory.

[0114] Furthermore, the system provided in the embodiments of the present invention may specifically be a chip, component, or module. The chip may include a connected processor and a memory. The memory stores instructions, and when the processor calls and executes the instructions, the chip can execute the IoT message push method provided in the above embodiments. This embodiment also provides a computer-readable storage medium storing computer program code. When the computer program code is run on a computer, the computer executes the aforementioned method steps to implement the IoT message push method provided in the above embodiments.

[0115] This embodiment also provides a computer program product. When the computer program product is run on a computer, it causes the computer to perform the aforementioned related steps to realize the IoT message push method provided in the above embodiment. The system, computer-readable storage medium, computer program product, or chip provided in this embodiment are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they achieve can be referred to in the beneficial effects of the corresponding methods provided above, and will not be repeated here. Through the description of the above embodiments, those skilled in the art can understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the system can be divided into different functional modules to complete all or part of the functions described above. In the embodiments provided by this invention, it should be understood that the disclosed system and method can be implemented in other ways. For example, the system embodiments described above are merely illustrative. For example, the division of modules or units is merely a logical functional division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interface, system or unit, and can be electrical, mechanical or other forms.

[0116] It should be noted that the order of the above embodiments of the present invention is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. The processes depicted in the accompanying drawings do not necessarily require a specific or sequential order to achieve the desired results. In some embodiments, multiple task processing and parallel processing are possible or may be advantageous. The various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. The above content is only a specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be covered within the protection scope of the present invention.

Claims

1. A message push method for the Internet of Things, characterized in that, The message push method for the Internet of Things includes: Get the device messages to be pushed; The device messages are batch aggregated to obtain processed messages; Based on a two-layer thread pool architecture, Webhook push is performed on the processed messages; wherein, the two-layer thread pool architecture includes a message consumption thread pool and a message push thread pool, the message consumption thread pool is used for event listening and preliminary processing; the message push thread pool is used for concurrently pushing HTTP requests. Based on the URL corresponding to the Webhook push, determine the number of push failures; If the number of failed pushes reaches a preset threshold, the operation corresponding to the Webhook push is circuit-broken, and circuit-broken information is generated and output. If the circuit breaker information meets the preset time condition, the processed message will continue to be pushed via Webhook.

2. The message push method for the Internet of Things according to claim 1, characterized in that, The step of batch aggregating the device messages to obtain processed messages includes: Determine the Kafka partition of the device message; Based on the Kafka partition of the device message, the device message is batch aggregated to obtain the processed message.

3. The message push method for the Internet of Things according to claim 2, characterized in that, The Kafka partition based on the device messages performs batch aggregation processing on the device messages to obtain processed messages, including: In each Kafka partition of the messaging device, establish a mapping relationship between the device to which the device message belongs and the application. Based on the mapping relationship, the device messages are grouped according to the dimension of the application to obtain multiple groups of device messages; The multiple sets of device messages are processed into fragments multiple times to obtain the processed messages.

4. The message push method for the Internet of Things according to claim 1, characterized in that, The step of determining the number of failed pushes based on the URL corresponding to the Webhook includes: If a URL request fails, determine the check settings in the preset database. The number of failed push notifications is obtained by recording the number of times the URL request failed based on the aforementioned check settings operation.

5. The message push method for the Internet of Things according to claim 1, characterized in that, If the number of failed pushes reaches a preset threshold, the operation corresponding to the Webhook push is circuit-broken, and circuit-broken information is generated and output, including: If the number of failed push notifications reaches the preset threshold, a circuit breaker operation will be triggered. In response to the circuit breaker operation, the Webhook push for the processed message is stopped within a preset time period; Based on the preset duration and the start time of the circuit breaker operation, the circuit breaker information is generated and output.

6. The message push method for the Internet of Things according to claim 1, characterized in that, The step of continuing to push Webhook messages to the processed messages when the circuit breaker information meets a preset time condition includes: Determine the duration of the circuit breaker operation between the start time and the current time corresponding to the circuit breaker information; If the circuit breaker duration reaches the preset duration, it is determined that the circuit breaker information meets the preset time condition, and when a Webhook push trigger operation is detected, the processed message continues to be pushed via Webhook.

7. The message push method for the Internet of Things according to claim 1, characterized in that, The method further includes: Obtain the retry interval for the Webhook push; wherein the retry interval increases exponentially with the number of retries; When the time of the Webhook push reaches the retry duration interval corresponding to the current retry count, it is determined whether the current retry count has reached the preset retry count threshold, and whether the circuit breaker information corresponding to the Webhook push meets the preset time condition. If the current number of retries has not reached the preset retry threshold, and the circuit breaker information corresponding to the Webhook push meets the preset time condition, the Webhook push will be re-attempted.

8. The message push method for the Internet of Things according to claim 1, characterized in that, The method further includes: Obtain the original configuration information corresponding to the Webhook push; The URL, circuit breaker information, and message status corresponding to the Webhook push are associated with the original configuration information to obtain the associated configuration information; Based on the associated configuration information, the Webhook push is tracked.

9. A message push method for the Internet of Things according to claim 1, characterized in that, The method further includes: A one-time signature is generated based on the timestamp of the Webhook push and a preset random number; Based on the one-time signature, the identity identifier and independent key for the Webhook push are generated; Based on the identity identifier and independent key, the processed message is pushed via Webhook.

10. A message push system for the Internet of Things, characterized in that, The system includes: The acquisition module is used to acquire device messages to be pushed. The aggregation module is used to perform batch aggregation processing on the device messages to obtain processed messages; The first push module is used to push the processed messages via Webhook based on a two-layer thread pool architecture; wherein the two-layer thread pool architecture includes a message consumption thread pool and a message push thread pool, the message consumption thread pool is used for event listening and preliminary processing; the message push thread pool is used for concurrently pushing HTTP requests. The determination module is used to determine the number of push failures based on the URL corresponding to the Webhook push; The generation module is used to trigger a circuit breaker for the operation corresponding to the Webhook push if the number of push failures reaches a preset threshold, and to generate and output circuit breaker information. The second push module is used to continue pushing the processed message via Webhook when the circuit breaker information meets the preset time conditions.

Images