Push method, device, cloud platform, medium and product of internet of things data

Abstract

The application provides a kind of Internet of Things data pushing method, device, cloud platform, medium and product.The method comprises: receiving the Internet of Things data to be pushed sent by Internet of Things business system;The Internet of Things data to be pushed includes push address;According to push address, the Internet of Things data to be pushed is divided into different types of resources;According to the identification of each type of resource in cache, each type of resource is forwarded to the corresponding queue;The resources of each type in normal queue and the resources of each type in green queue are respectively pushed concurrently, and the following steps are executed in the process of pushing: whether the resources of each type in normal queue or / and the resources of each type in green queue trigger the preset flow limiting rule is judged;If triggered, the resources of each type in normal queue or / and the resources of each type in green queue are forwarded to the flow limiting queue;The resources of each type in flow limiting queue are pushed.The pushing efficiency and real-time performance of the Internet of Things data to be pushed are improved.

Description

Technical Field

[0001] This application relates to the field of Internet of Things (IoT) technology, and in particular to a method, device, cloud platform, medium, and product for pushing IoT data. Background Technology

[0002] IoT devices access the operator's cellular network via a general-purpose integrated circuit card and transmit application-related IoT data through the cellular network. When IoT devices generate status changes, International Mobile Equipment Identity (IMEI) changes, SIM card location changes, prepaid tariff expiration, session start, session period cumulative usage, and policy and billing rule function unit usage, etc., the push operation of IoT data can be configured on the IoT platform.

[0003] Currently, existing technologies typically write this IoT data to be pushed directly into a message middleware, where the program's consumer module consumes the IoT data one by one and pushes it to the push address.

[0004] However, when faced with a large amount of IoT data to be pushed, the inconsistent push addresses and the different resource conditions of different push addresses may lead to high I / O latency due to overload or performance issues, which can easily reduce the efficiency and real-time performance of IoT data push. Summary of the Invention

[0005] This application provides a method, apparatus, cloud platform, medium, and product for pushing IoT data, in order to improve the efficiency and real-time performance of pushing IoT data.

[0006] In a first aspect, embodiments of this application provide a method for pushing IoT data, comprising: receiving IoT data to be pushed sent by an IoT business system; wherein the IoT data to be pushed includes a push address; dividing the IoT data to be pushed into different types of resources according to the push address; obtaining the identifier corresponding to each type of resource from a cache; forwarding each type of resource to a corresponding queue according to the identifier corresponding to each type of resource; the queues include a normal queue, a green queue, and a rate-limiting queue; using a multi-threaded approach, concurrently pushing each type of resource in the normal queue and each type of resource in the green queue, and performing the following steps during the push process: determining whether each type of resource in the normal queue, or / and each type of resource in the green queue, triggers a preset rate-limiting rule; wherein the preset rate-limiting rule includes a preset rate-limiting duration; if the preset rate-limiting rule is triggered, forwarding each type of resource in the normal queue, or / and each type of resource in the green queue, to the rate-limiting queue; pushing each type of resource in the rate-limiting queue; during the push process, after the preset rate-limiting duration is reached, forwarding each type of resource from the normal queue or / and the green queue to the rate-limiting queue again for push.

[0007] In one possible implementation, the preset rate limiting rules include: statistical duration, minimum number of requests, slow call time, and slow call ratio; correspondingly, determining whether each type of resource in the normal queue, or / and each type of resource in the green queue, triggers the preset rate limiting rules includes: if, within the statistical duration, the proportion of each type of resource in the normal queue whose call time exceeds the slow call time in the minimum number of requests exceeds the slow call ratio, then it is determined that each type of resource in the normal queue has triggered the preset rate limiting rules; or / and if, within the statistical duration, the proportion of each type of resource in the green queue whose call time exceeds the slow call time in the minimum number of requests exceeds the slow call ratio, then it is determined that each type of resource in the green queue has triggered the preset rate limiting rules.

[0008] In one possible implementation, the IoT data to be pushed is divided into different types of resources based on the push address, including: obtaining the main URL of the push address; and dividing the IoT data to be pushed into different types of resources based on the main URL.

[0009] In one possible implementation, resources of each type are forwarded to their corresponding queues based on their identifiers, including: if the identifier for each type of resource is a first identifier, or if the identifier for each type of resource is empty, then the resources of each type are forwarded to the normal queue; if the identifier for each type of resource is a second identifier, then the resources of each type are forwarded to the green queue; if the identifier for each type of resource is a third identifier, then the resources of each type are forwarded to the rate-limiting queue.

[0010] In one possible implementation, after classifying the IoT data to be pushed into different types of resources according to the push address, the method further includes: obtaining the server status of each type of resource based on the push address; setting an identifier for each type of resource based on the server status; and saving each type of resource and its corresponding identifier to a cache.

[0011] In one possible implementation, the queue also includes an abandoned queue; correspondingly, the method further includes discarding resources of various types in the abandoned queue without pushing them.

[0012] Secondly, embodiments of this application provide an IoT data push device, comprising:

[0013] The data receiving module receives IoT data to be pushed from the IoT business system; the IoT data to be pushed includes the push address.

[0014] The segmentation module is used to divide the IoT data to be pushed into different types of resources based on the push address;

[0015] The identifier acquisition module is used to retrieve the identifiers corresponding to various types of resources from the cache;

[0016] The forwarding module is used to forward resources of different types to the corresponding queues based on the identifiers of each type of resource; the queues include the normal queue, the green queue, and the rate-limiting queue.

[0017] The first push module is used to concurrently push various types of resources in the normal queue and various types of resources in the green queue using a multi-threaded approach, and performs the following steps during the push process;

[0018] The push module includes:

[0019] The judgment unit determines whether each type of resource in the normal queue, or / and each type of resource in the green queue, triggers the preset rate limiting rule; wherein the preset rate limiting rule includes the preset rate limiting duration;

[0020] If the forwarding unit triggers the preset rate limiting rule, it will forward all types of resources in the normal queue and / or all types of resources in the green queue to the rate limiting queue.

[0021] The second push module is used to push various types of resources in the rate-limiting queue;

[0022] The third push module is used to forward various types of resources from the normal queue and / or the green queue to the rate-limiting queue during the push process. After the preset rate-limiting time is reached, the resources are forwarded back to the normal queue and / or the green queue for push.

[0023] Thirdly, embodiments of this application provide a cloud platform, including: a memory and a processor;

[0024] The memory stores computer-executed instructions;

[0025] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0026] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0027] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0028] The IoT data push method, apparatus, cloud platform, medium, and product provided in this application improve push efficiency by dividing the IoT data to be pushed into different types of resources according to the push address, and forwarding each type of resource to different queues for push according to the identifier of each type of resource, thereby achieving traffic distribution. Furthermore, according to preset rate limiting rules, during the push process, resources of each type that trigger the preset rate limiting rules in the normal queue and / or the green queue are forwarded to the rate limiting queue, without interfering with the push efficiency of the normal queue and the green queue. In addition, multi-threaded concurrent push ensures the real-time performance of IoT data push. Attached Figure Description

[0029] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0030] Figure 1 A schematic diagram illustrating a scenario for the IoT data push method provided in an embodiment of this application;

[0031] Figure 2 A flowchart illustrating the IoT data push method provided in this application embodiment;

[0032] Figure 3 This is a schematic diagram of the structure of the IoT data push device provided in the embodiments of this application;

[0033] Figure 4 This is a schematic diagram of the structure of the cloud platform provided in an embodiment of this application.

[0034] The accompanying drawings have illustrated specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to specific embodiments. Detailed Implementation

[0035] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0036] Figure 1 This is a schematic diagram illustrating a scenario for the IoT data push method provided in an embodiment of this application, such as... Figure 1 As shown, the cloud platform provided in this embodiment includes a receiving device 101 and a processor 102.

[0037] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the method. In other feasible embodiments of this application, the above architecture may include more or fewer components than illustrated, or combine some components, or split some components, or arrange different components, which can be determined according to the actual application scenario and is not limited here. Figure 1 The components shown can be implemented in hardware, software, or a combination of both.

[0038] In the specific implementation process, the receiving device 101 can be an input / output interface or a communication interface, which can receive IoT data to be pushed by the IoT business system.

[0039] The processor 102 can process the IoT data to be pushed in order to push the IoT data.

[0040] It should be understood that the aforementioned processor can be implemented by reading instructions from memory and executing those instructions, or it can be implemented through chip circuitry.

[0041] IoT devices access the operator's cellular network via a general-purpose integrated circuit card (GPU) and transmit application-related IoT data through the cellular network. When automated rules such as device status changes, IMU changes, SIM card location changes, prepaid data expiration, session initiation, session period cumulative usage, and policy and billing rule function unit usage are triggered, IoT data push operations can be configured on the IoT platform. Currently, existing technologies typically write this IoT data to be pushed directly into a message middleware, where the program's consumer module consumes the IoT data one message at a time and pushes it to the push address. However, when dealing with large volumes of IoT data to be pushed, due to inconsistent push addresses and differences in resource conditions across different push addresses, overload or performance issues may lead to high I / O latency, easily reducing the efficiency and real-time performance of IoT data push.

[0042] To address the aforementioned technical issues, this application proposes the following technical concept: Based on the push address, the IoT data to be pushed is divided into different types of resources, and each type of resource is assigned a different identifier; based on the identifier, each type of resource is forwarded to its corresponding queue for push, achieving distributed push and improving push efficiency. A normal queue, a green queue, and a rate-limiting queue are set up. The various types of resources in the normal and green queues are monitored, and resources that trigger preset rate-limiting rules are forwarded to the rate-limiting queue, without interfering with the push efficiency of the normal and green queues. Furthermore, a multi-threaded approach is used to push the various types of data in the normal and green queues, ensuring the real-time nature of the IoT data push.

[0043] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0044] Figure 2 This is a flowchart illustrating the IoT data push method provided in the embodiments of this application, as shown below. Figure 2 As shown, the method includes:

[0045] S201: Receive IoT data to be pushed from the IoT business system; the IoT data to be pushed includes the push address.

[0046] In this embodiment, the IoT data to be pushed generated by IoT device-triggered events in the IoT business system is encapsulated into a message and written into a unified message queue.

[0047] Optionally, the message format is as follows:

[0048] {

[0049] "pushUrl":"http: / / 163.177.xxx / 12n / Check / simStateChange?type=3&from=9",

[0050] "data":{XXX},

[0051] "timestamp":1678543200,

[0052] }

[0053] Optionally, the triggering event can be a change in the SIM card status.

[0054] S202: Based on the push address, divide the IoT data to be pushed into different types of resources.

[0055] Specifically, obtain the main URL of the push address; based on the main URL, divide the IoT data to be pushed into different types of resources.

[0056] In this embodiment, different push addresses are treated as resources and managed accordingly. For example, the same push address, i.e., the main URL part is the same, but the request parameters are different, are regarded as different types of resources.

[0057] For example, the main URL is http: / / 163.177.XXX / M2m / Check / simStateChange, and the request parameters are type=3&form=9, type=3&form=8, type=3&form=7, and type=3&form=6, which belong to the same type of resource, as follows:

[0058] http: / / 163.177.XXX / M2m / Check / simStateChange?type=3&form=9;

[0059] http: / / 163.177.XXX / M2m / Check / simStateChange?type=3&form=8;

[0060] http: / / 163.177.XXX / M2m / Check / simStateChange?type=3&form=7;

[0061] http: / / 163.177.XXX / M2m / Check / simStateChange?type=3&form=6.

[0062] For example, the following two push addresses belong to different types of resources:

[0063] http: / / 119.29.252.XXX / notify / usage;

[0064] http: / / 120.77.XXX / iot / api / gateway / 20210624418615 / push / card / stop.do.

[0065] S203: Retrieve the identifiers corresponding to each type of resource from the cache.

[0066] In this embodiment, when the cloud platform starts, it reads all resource information from the database, deduplicates and categorizes it according to rules, and then loads it into the cache. The database stores all push addresses and their initial configurations, such as preset rate limiting rules.

[0067] Alternatively, the database can be a relational database.

[0068] In this embodiment, the server status of each type of resource being pushed is obtained according to the push address; an identifier is set for each type of resource according to the server status; and each type of resource and its corresponding identifier are saved to the cache.

[0069] Optionally, the identifier includes a first identifier, a second identifier, and a third identifier. If the server is in a high-performance state, the identifier of each type of resource pushed to the server is set to the second identifier; for each type of resource that is not marked, the identifier is set to the first identifier; the third identifier is generated during the rate limiting monitoring process, as described in step S205.

[0070] Optionally, the identifier also includes a fourth identifier, which is set to the identifier of each type of resource pushed to the server if the server status is abandoned.

[0071] Alternatively, it can be a Redis cache.

[0072] S204: Based on the identifier corresponding to each type of resource, forward each type of resource to the corresponding queue; the queues include the normal queue, the green queue, and the rate-limiting queue.

[0073] In this embodiment, resources of various types are consumed from the message queue, and each type of resource is forwarded to a new queue according to the identifier corresponding to each type of resource.

[0074] Specifically, if the identifier corresponding to each type of resource is the first identifier, or the identifier corresponding to each type of resource is empty, then each type of resource is forwarded to the normal queue; if the identifier corresponding to each type of resource is the second identifier, then each type of resource is forwarded to the green queue; if the identifier corresponding to each type of resource is the third identifier, then each type of resource is forwarded to the rate-limiting queue.

[0075] Optionally, the queue also includes an abandoned queue. If the identifier corresponding to each type of resource is the fourth identifier, then each type of resource is forwarded to the abandoned queue.

[0076] Optionally, the first identifier can be N, the second identifier can be G, the third identifier can be B, and the fourth identifier can be D.

[0077] S205: Using a multi-threaded approach, push resources of various types in the normal queue and resources of various types in the green queue concurrently. The following steps are executed during the push process.

[0078] In this embodiment, a multi-threaded concurrent approach is used to consume various types of resources in the normal queue and the green queue, with different thread resources provided for different queues. For example, more threads are allocated to the green queue, which executes normally for a long time or requires priority push. This improves platform resource utilization while ensuring the real-time nature of message pushes from IoT devices.

[0079] Specifically, step S205 includes S2051~S2052:

[0080] S2051: Determine whether each type of resource in the normal queue, or / and each type of resource in the green queue, triggers the preset rate limiting rule; wherein the preset rate limiting rule includes the preset rate limiting duration.

[0081] In this embodiment, the preset rate limiting rules include: statistical duration, minimum number of requests, slow call time and slow call ratio;

[0082] Specifically, if, within the statistical period, the proportion of each type of resource in the normal queue whose call time exceeds the slow call time in the minimum number of requests exceeds the slow call ratio, then it is determined that the preset rate limiting rules have been triggered for each type of resource in the normal queue; or / and if, within the statistical period, the proportion of each type of resource in the green queue whose call time exceeds the slow call time in the minimum number of requests exceeds the slow call ratio, then it is determined that the preset rate limiting rules have been triggered for each type of resource in the green queue.

[0083] In this embodiment, the rate limiting rules are configured based on the following core parameters:

[0084] Rate limiting duration: The time during which resources are restricted after rate limiting is triggered, in seconds.

[0085] Slow call time: A call that takes longer than the slow call time is considered a slow call, measured in milliseconds.

[0086] Slow call ratio: The percentage of slow calls during the push process, ranging from 0 to 1.

[0087] Minimum number of requests: The minimum number of requests required to count push notifications. If the number of requests is below the minimum, the rate limiting rule will not be triggered.

[0088] Statistical duration: The time window during the statistical push process, in minutes or seconds.

[0089] Example parameter settings:

[0090] Slow call time: 1000 milliseconds

[0091] Slow call ratio: 0.6

[0092] Minimum number of requests: 100

[0093] Duration of statistics: 30 minutes

[0094] Traffic throttling duration: 60 seconds

[0095] For example, the preset rate limiting rule is as follows: within 30 minutes, if the proportion of resources of any type with a call time exceeding 1000 milliseconds in 100 pushes of any type of resource exceeds 0.6, the preset rate limiting rule is triggered. Here, the rate limiting duration indicates that after triggering the preset rate limiting rule, resources of each type in the normal queue and / or the green queue are transferred to the rate limiting queue; resources of each type transferred from the normal queue and / or the green queue to the rate limiting queue are re-forwarded to the normal queue and / or the green queue after the rate limiting duration is reached.

[0096] In this embodiment, slow call information for different types of resources is acquired separately in rate limiting monitoring, without interference between them. For example, when a preset rate limiting rule is triggered for resource type A, rate limiting is only applied to resource type A and does not affect other resources.

[0097] In this embodiment, different preset rate limiting rules correspond to different resource types. For example, the preset rate limiting rules for resource type A are: rate limiting duration 300 seconds, slow call time 1000 milliseconds, slow call ratio 0.6, minimum number of requests 50, and statistical duration 30 minutes. The preset rate limiting rules for resource type B are: rate limiting duration 600 seconds, slow call time 2000 milliseconds, slow call ratio 0.8, minimum number of requests 100, and statistical duration 15 minutes.

[0098] S2052: If the preset rate limiting rule is triggered, all types of resources in the normal queue, and / or all types of resources in the green queue, will be forwarded to the rate limiting queue.

[0099] In this embodiment, the push of each type of resource in the normal queue and each type of resource in the green queue is subject to rate limiting monitoring by preset rate limiting rules, while the push of each type of resource in the rate limiting queue is not subject to rate limiting monitoring by preset rate limiting rules.

[0100] Optionally, the identifier of each type of resource forwarded to the rate limiting queue can be modified to a third identifier.

[0101] S206: Push various types of resources in the rate-limiting queue.

[0102] In this embodiment, resources of all types in the rate-limiting queue are pushed directly without being affected by preset rate-limiting rules, and the push to the green queue and normal queue is not affected.

[0103] S207: During the push process, resources of various types forwarded from the normal queue and / or the green queue to the rate-limiting queue will be re-forwarded to the normal queue and / or the green queue for push after the preset rate-limiting time has been reached.

[0104] In this embodiment, the rate-limiting queue, green queue, and normal queue monitor the status of each type of resource in real time and dynamically adjust the identifiers of each type of resource.

[0105] Specifically, resources of all types in the normal queue and / or the green queue are forwarded to the rate-limiting queue after triggering preset rate-limiting rules. Resources of all types forwarded from the normal queue and / or the green queue to the rate-limiting queue are then re-forwarded to the normal queue and / or the green queue for push after the preset rate-limiting duration has been reached.

[0106] Optionally, the rate limiting duration can be 60 seconds.

[0107] Optionally, the identifiers of various resource types forwarded from the rate-limiting queue to the normal queue are changed to N; the identifiers of various resource types forwarded from the rate-limiting queue to the green queue are changed to G.

[0108] Optionally, the queue may also include a discard queue.

[0109] In this embodiment, all types of resources in the discard queue are discarded and not pushed.

[0110] In summary, based on the push address, the IoT data to be pushed is divided into different types of resources. Based on the identifier of each resource type, they are forwarded to different queues for separate push, achieving distributed push and improving push efficiency. Furthermore, according to preset rate limiting rules, during the push process, resources of each type that trigger the preset rate limiting rules in the normal queue and / or the green queue are forwarded to the rate limiting queue, without interfering with the push efficiency of the normal and green queues. In addition, multi-threaded concurrent push ensures the real-time nature of the IoT data push.

[0111] Based on the above embodiments, this embodiment provides an IoT data push system. The system is deployed on a cloud platform and is based on a microservice architecture, including: a push message production module, a push message consumption module, a queue layering module, a traffic governance component, a database module, and a caching module.

[0112] The push message production module is used to write the IoT data to be pushed generated by the IoT business system into the message queue. The IoT data to be pushed includes the push address.

[0113] The push message consumption module is used to consume IoT data from the message queue;

[0114] The queue layering module divides the IoT data to be pushed into different types of resources based on the push address; retrieves the corresponding identifiers for each type of resource from the cache; and forwards each type of resource to the corresponding queue based on the identifiers. The queues include normal queues, green queues, and rate-limited queues.

[0115] The traffic management component is used to define and monitor rate limiting rules for various types of resources and dynamically adjust the identifiers of various types of resources.

[0116] Optionally, the traffic management component can be Sentinel. Sentinel monitors data such as slow call status, success rate, and call count for various types of resources in real time.

[0117] The database module is used to store all push addresses and their initial configurations, such as rate limiting parameters.

[0118] The caching module is used to store the identifiers of various types of resources and related rate limiting monitoring data.

[0119] In summary, based on the push address, the IoT data to be pushed is divided into different types of resources. Based on the identifier of each resource type, they are forwarded to different queues for separate push, achieving distributed push and improving push efficiency. Furthermore, according to preset rate limiting rules, during the push process, resources of each type that trigger the preset rate limiting rules in the normal queue and / or the green queue are forwarded to the rate limiting queue, without interfering with the push efficiency of the normal and green queues. In addition, multi-threaded concurrent push ensures the real-time nature of the IoT data push.

[0120] Figure 3 This is a schematic diagram of the structure of the IoT data push device provided in the embodiments of this application, as shown below. Figure 3 As shown, the IoT data push device provided in this embodiment includes: a data receiving module 301, a partitioning module 302, an identifier acquisition module 303, a forwarding module 304, a first push module 305, a second push module 306, and a third push module 307. The first push module 305 includes a judgment unit 3051 and a forwarding unit 3052.

[0121] The data receiving module 301 receives IoT data to be pushed from the IoT business system; the IoT data to be pushed includes the push address.

[0122] The segmentation module 302 is used to segment the IoT data to be pushed into different types of resources based on the push address.

[0123] The identifier acquisition module 303 is used to obtain the identifiers corresponding to various types of resources from the cache.

[0124] The forwarding module 304 is used to forward resources of each type to the corresponding queues according to the identifiers of each type of resource; the queues include the normal queue, the green queue and the rate-limiting queue.

[0125] The first push module 305 is used to concurrently push various types of resources in the normal queue and various types of resources in the green queue using a multi-threaded approach, and performs the following steps during the push process.

[0126] The first push module 305 includes:

[0127] Judgment unit 3051 determines whether each type of resource in the normal queue, or / and each type of resource in the green queue, triggers the preset rate limiting rule; wherein the preset rate limiting rule includes the preset rate limiting duration.

[0128] If the preset rate limiting rule is triggered, forwarding unit 3052 will forward all types of resources in the normal queue and / or all types of resources in the green queue to the rate limiting queue.

[0129] The second push module 306 is used to push various types of resources in the rate-limiting queue.

[0130] The third push module 307 is used to forward various types of resources from the normal queue and / or the green queue to the rate-limiting queue during the push process. After the preset rate-limiting time is reached, the resources are forwarded back to the normal queue and / or the green queue for push.

[0131] In one possible implementation, the preset rate limiting rules include: statistical duration, minimum number of requests, slow call time, and slow call ratio; correspondingly, determining whether each type of resource in the normal queue, or / and each type of resource in the green queue, triggers the preset rate limiting rules includes: if, within the statistical duration, the proportion of each type of resource in the normal queue whose call time exceeds the slow call time in the minimum number of requests exceeds the slow call ratio, then it is determined that each type of resource in the normal queue has triggered the preset rate limiting rules; or / and if, within the statistical duration, the proportion of each type of resource in the green queue whose call time exceeds the slow call time in the minimum number of requests exceeds the slow call ratio, then it is determined that each type of resource in the green queue has triggered the preset rate limiting rules.

[0132] In one possible implementation, the segmentation module 302 is specifically used to: obtain the main URL of the push address; and segment the IoT data to be pushed into different types of resources based on the main URL.

[0133] In one possible implementation, the forwarding module 304 is configured to forward each type of resource to the normal queue if the identifier corresponding to each type of resource is the first identifier or the identifier corresponding to each type of resource is empty; forward each type of resource to the green queue if the identifier corresponding to each type of resource is the second identifier; and forward each type of resource to the rate-limiting queue if the identifier corresponding to each type of resource is the third identifier.

[0134] In one possible implementation, the IoT data push device further includes a storage module, which is used to obtain the server status of each type of resource being pushed according to the push address; set an identifier for each type of resource according to the server status; and save each type of resource and its corresponding identifier to a cache.

[0135] In one possible implementation, the queue also includes an abandoned queue; correspondingly, the method further includes discarding resources of various types in the abandoned queue without pushing them.

[0136] The IoT data push device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0137] Figure 4 This is a schematic diagram of the cloud platform provided in an embodiment of this application. Figure 4 As shown, the cloud platform provided in this embodiment includes at least one processor 401 and a memory 402. Optionally, the cloud platform also includes a communication component 403. The processor 401, memory 402, and communication component 403 are connected via a bus 404.

[0138] In a specific implementation, at least one processor 401 executes computer execution instructions stored in memory 402, causing at least one processor 401 to perform the above-described method.

[0139] The specific implementation process of processor 401 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0140] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0141] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0142] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0143] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0144] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0145] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0146] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0147] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0148] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0149] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0150] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0151] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0152] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A push method of Internet of Things data, characterized in that, Applied to a cloud platform, comprising: Receiving the Internet of Things data sent by the Internet of Things service system; wherein the Internet of Things data includes a push address; According to the push address, the Internet of Things data is divided into different types of resources; According to the push address, the server state of each type of resource is obtained; According to the server state, the identification of each type of resource is set; The identification of each type of resource is saved to the cache; According to the identification of each type of resource, the identification of each type of resource is obtained from the cache; According to the identification of each type of resource, the identification of each type of resource is forwarded to the corresponding queue; the queue includes a normal queue, a green queue and a flow limiting queue; In the process of pushing, the following steps are performed: If the proportion of each type of resource in the normal queue that exceeds the slow call time in the minimum request number within a statistical time exceeds the slow call proportion, it is determined that the preset flow limiting rule is triggered for each type of resource in the normal queue; Or / and if the proportion of each type of resource in the green queue that exceeds the slow call time in the minimum request number within the statistical time exceeds the slow call proportion, it is determined that the preset flow limiting rule is triggered for each type of resource in the green queue; different types of resources are separately obtained in flow limiting monitoring, and do not interfere with each other; wherein the preset flow limiting rule includes a preset flow limiting time; If the preset flow limiting rule is triggered, each type of resource in the normal queue and / or each type of resource in the green queue is forwarded to the flow limiting queue; The resources in the flow limiting queue are pushed; In the process of pushing, each type of resource in the normal queue and / or the green queue is forwarded to the flow limiting queue, and after the preset flow limiting time is reached, it is reforwarded to the normal queue and / or the green queue for pushing.

2. The method of claim 1, wherein, According to the push address, the Internet of Things data is divided into different types of resources, comprising: Obtaining the main URL of the push address; According to the main URL, the Internet of Things data is divided into different types of resources.

3. The method of claim 1, wherein, According to the identification of each type of resource, the identification of each type of resource is forwarded to the corresponding queue, comprising: If the identification of each type of resource is a first identification, or the identification of each type of resource is empty, each type of resource is forwarded to the normal queue; If the identification of each type of resource is a second identification, each type of resource is forwarded to the green queue; If the identification of each type of resource is a third identification, each type of resource is forwarded to the flow limiting queue.

4. The method according to any one of claims 1 to 3, characterized in that, The queue also includes a discarded queue; Correspondingly, the method further comprises: Discarding each type of resource in the discarded queue and not pushing.

5. A push device of Internet of Things data, characterized in that, Applied to a cloud platform, comprising: The data receiving module receives the to-be-pushed IoT data sent by the IoT service system; the to-be-pushed IoT data includes a push address; The dividing module divides the to-be-pushed IoT data into different types of resources according to the push address; The server state obtaining module obtains the server state of each type of resource according to the push address; The identification setting module sets an identification for each type of resource according to the server state; The saving module saves each type of resource and the identification corresponding to each type of resource in a cache; The identification obtaining module obtains the identification corresponding to each type of resource from the cache; The forwarding module forwards each type of resource to a corresponding queue according to the identification corresponding to each type of resource; the queue includes a normal queue, a green queue, and a flow limiting queue; The first pushing module concurrently pushes each type of resource in the normal queue and each type of resource in the green queue in a multi-threaded manner; the following steps are performed during the pushing process; The first pushing module includes: The first determining unit determines that each type of resource in the normal queue triggers a preset flow limiting rule if the proportion of each type of resource whose calling time exceeds the slow calling time in the minimum request number within a statistical time length exceeds a slow calling proportion; The second determining unit determines that each type of resource in the green queue triggers a preset flow limiting rule if the proportion of each type of resource whose calling time exceeds the slow calling time in the minimum request number within the statistical time length exceeds the slow calling proportion; different types of resources independently obtain slow calling conditions in flow limiting monitoring and do not interfere with each other; the preset flow limiting rule includes a preset flow limiting time length; The forwarding unit forwards each type of resource in the normal queue and / or each type of resource in the green queue to the flow limiting queue if the preset flow limiting rule is triggered; The second pushing module pushes each type of resource in the flow limiting queue; The third pushing module re-converts each type of resource in the flow limiting queue to the normal queue and / or the green queue for pushing after the preset flow limiting time length is reached.

6. A cloud platform, characterized by, The memory and the processor; The memory stores computer execution instructions; The processor executes the computer execution instructions stored in the memory, so that the processor executes the method of any one of claims 1-4. The computer readable storage medium stores computer execution instructions, and the computer execution instructions are executed by the processor to implement the method of any one of claims 1-4.

7. A computer readable storage medium characterized in that, The computer program is executed by the processor to implement the method of any one of claims 1-4.

8. A computer program product, characterised in that, ​

Images