Internet of Things data pushing method and device, cloud platform, medium and product

Abstract

The invention provides an Internet of Things data pushing method and device, a cloud platform, a medium and a product. The method comprises the following steps: receiving to-be-pushed Internet of Things data sent by an Internet of Things service system; the to-be-pushed Internet of Things data comprises a push address; dividing the to-be-pushed Internet of Things data into different types of resources according to the push address; forwarding the various types of resources to the corresponding queues according to the identifiers of the various types of resources in the cache; concurrent pushing is carried out on various types of resources in the normal queue and various types of resources in the green queue, and the following steps are executed in the pushing process: whether various types of resources in the normal queue or / and various types of resources in the green queue trigger a preset flow limiting rule is judged; if the current limiting queue is triggered, forwarding various types of resources in the normal queue or / and various types of resources in the green queue to the current limiting queue; and pushing the various types of resources in the flow limiting queue. And the pushing efficiency and the real-time performance of the to-be-pushed Internet of Things data are improved.

Description

Technical Field

[0001] The present application relates to the technical field of Internet of Things, and in particular to a method, device, cloud platform, medium and product for pushing Internet of Things data. Background Art

[0002] IoT devices access the operator's cellular network through a universal integrated circuit card and transmit application-related IoT data through the cellular network. When the IoT device generates a state change, an international mobile equipment identity code change, a number card location change, a prepaid tariff expiration, a session start, a session cycle cumulative usage, and a policy and charging rules functional unit usage, etc., the push operation of IoT data can be configured on the IoT platform.

[0003] At present, the existing technology usually writes these IoT data to be pushed directly into the message middleware, and the consumer module of the program consumes the IoT data one by one and pushes them to the push address.

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

[0005] The embodiments of the present application provide a method, device, cloud platform, medium and product for pushing IoT data, so as to achieve the effect of improving the push efficiency and real-time performance of IoT data.

[0006] In a first aspect, an embodiment of the present application provides 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; according to the push address, dividing the IoT data to be pushed into different types of resources; obtaining identifiers corresponding to each type of resource from a cache; forwarding each type of resource to a corresponding queue according to the identifiers corresponding to each type of resource; the queue includes a normal queue, a green queue and a current limiting queue; using a multi-threaded method, each type of resource in the normal queue and each type of resource in the green queue are concurrently pushed, and the following steps are performed 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 current limiting rule; wherein the preset current limiting rule includes a preset current limiting duration; if the preset current 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 current limiting queue; pushing each type of resource in the current limiting queue; during the push process, the normal queue or / and the green queue forwards each type of resource to the current limiting queue, and after the preset current limiting duration is reached, it is forwarded to the normal queue or / and the green queue for pushing again.

[0007] In one possible implementation, the preset flow limiting rules include: statistical duration, minimum number of requests, slow call time and slow call ratio; accordingly, judging whether each type of resource in the normal queue, or / and each type of resource in the green queue triggers the preset flow limiting rules, including: 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 the each type of resource in the normal queue has triggered the preset flow 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 the each type of resource in the green queue has triggered the preset flow limiting rules.

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

[0009] In one possible implementation, each type of resource is forwarded to a corresponding queue according to an identifier corresponding to each type of resource, including: if the identifier corresponding to each type of resource is a first identifier, or the identifier corresponding to each type of resource is empty, then each type of resource is forwarded to a normal queue; if the identifier corresponding to each type of resource is a second identifier, then each type of resource is forwarded to a green queue; if the identifier corresponding to each type of resource is a third identifier, then each type of resource is forwarded to a current limiting queue.

[0010] In a possible implementation, after the IoT data to be pushed is divided into different types of resources according to the push address, it also includes: obtaining the server status of each type of resource being pushed according to the push address; setting an identifier for each type of resource according to the server status; and saving each type of resource and the identifier corresponding to each type of resource in the cache.

[0011] In a possible implementation, the queue further includes a discarded queue; accordingly, the method further includes: discarding various types of resources in the discarded queue and not pushing them.

[0012] In a second aspect, an embodiment of the present application provides a device for pushing IoT data, including:

[0013] A data receiving module receives the IoT data to be pushed sent by the IoT business system; wherein the IoT data to be pushed includes a push address;

[0014] A division module is used to divide the IoT data to be pushed into different types of resources according to the push address;

[0015] The identification acquisition module is used to obtain the identification corresponding to each type of resource from the cache;

[0016] The forwarding module is used to forward each type of resource to the corresponding queue according to the corresponding identifier of each type of resource; the queues include normal queues, green queues and current-limited queues;

[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 in a multi-threaded manner, and execute the following steps during the push process;

[0018] The push module includes:

[0019] A judgment unit, for judging whether various types of resources in the normal queue and / or various types of resources in the green queue trigger preset flow limiting rules; wherein the preset flow limiting rules include preset flow limiting duration;

[0020] The forwarding unit, if a preset current limiting rule is triggered, forwards various types of resources in the normal queue and / or various types of resources in the green queue to the current limiting queue;

[0021] The second push module is used to push various types of resources in the current 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 current limiting queue during the push process, and after reaching a preset current limiting time, forward them to the normal queue and / or the green queue for pushing again.

[0023] In a third aspect, an embodiment of the present application provides a cloud platform, including: a memory, a processor;

[0024] The memory stores computer-executable instructions;

[0025] The processor executes the computer-executable instructions stored in the memory, so that the processor executes the above first aspect and / or various possible implementations of the first aspect.

[0026] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, in which computer-executable instructions are stored. When the computer-executable instructions are executed by a processor, they are used to implement the first aspect above and / or various possible implementations of the first aspect.

[0027] In a fifth aspect, an embodiment of the present application provides a computer program product, including a computer program, which, when executed by a processor, implements the above first aspect and / or various possible implementation methods of the first aspect.

[0028] The push method, device, cloud platform, medium and product of IoT data provided by the embodiment of the present application divide the IoT data to be pushed into different types of resources according to the push address, and forward each type of resource to different queues for push according to the identifier of each type of resource, so as to realize diversion push and improve push efficiency; and according to the preset current limiting rules, during the push process, each type of resource in the normal queue or / and the green queue that triggers the preset current limiting rules is forwarded to the current limiting queue, without interfering with the push efficiency of the normal queue and the green queue. In addition, the multi-threaded method is used for concurrent push, which ensures the real-time push of IoT data. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

[0031] Figure 2 A flow chart of a method for pushing IoT data provided in an embodiment of the present application;

[0032] Figure 3 A schematic diagram of the structure of a device for pushing Internet of Things data provided in an embodiment of the present application;

[0033] Figure 4 A schematic diagram of the structure of the cloud platform provided in an embodiment of the present application.

[0034] The above drawings have shown clear embodiments of the present application, which will be described in more detail later. These drawings and text descriptions are not intended to limit the scope of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0035] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

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

[0037] It is to be understood that the structure illustrated in the embodiment of the present application does not constitute a specific limitation on the method. In other feasible implementations of the present application, the above architecture may include more or fewer components than shown in the figure, or combine certain components, or split certain components, or arrange the components differently, which can be determined according to the actual application scenario and is not limited here. Figure 1 The components shown may be implemented in hardware, software, or a combination of software and hardware.

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

[0039] The processor 102 may process the IoT data to be pushed, so as to push the IoT data to be pushed.

[0040] It should be understood that the above-mentioned processor can be implemented by the processor reading instructions in the memory and executing the instructions, or it can be implemented by a chip circuit.

[0041] IoT devices access the operator's cellular network through a universal integrated circuit card and transmit application-related IoT data through the cellular network. When the IoT device generates a state change, an international mobile equipment identity code change, a number card location change, a prepaid tariff expires, a session starts, the cumulative usage of the session period, and the usage of the policy and billing rules function unit, etc., the push operation of IoT data can be configured on the IoT platform. At present, the existing technology usually writes these IoT data to be pushed directly into the message middleware, and the consumer module of the program consumes the IoT data one by one and pushes it to the push address. However, when faced with a large amount of IoT data to be pushed, due to inconsistent push addresses and different resource conditions of different push addresses, the I / O delay may be high due to overload or performance issues, which can easily lead to reduced push efficiency and real-time performance of IoT data.

[0042] In order to solve the above technical problems, the present application proposes the following technical ideas: according to the push address, the IoT data to be pushed is divided into different types of resources, and different identifiers are assigned to each type of resource; according to the identifier, each type of resource is forwarded to the corresponding queue for pushing, so as to realize diversion push and improve push efficiency. A normal queue, a green queue and a current limiting queue are set up to monitor various types of resources in the normal queue and the green queue, and various types of resources that trigger the preset current limiting rules are forwarded to the current limiting queue without interfering with the push efficiency of the normal queue and the green queue. In addition, a multi-threaded method is adopted to push various types in the normal queue and the green queue, which ensures the real-time push of the IoT data to be pushed.

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

[0044] Figure 2 A flow chart of a method for pushing IoT data provided in an embodiment of the present application is shown in FIG. Figure 2 As shown, the method includes:

[0045] S201: receiving the IoT data to be pushed sent by the IoT business system; wherein the IoT data to be pushed includes a push address.

[0046] In this embodiment, the IoT data to be pushed generated by the IoT device triggering event 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 trigger event may be a change in the state of the SIM card.

[0054] S202: Divide the IoT data to be pushed into different types of resources according to the push address.

[0055] Specifically, the main URL of the push address is obtained; and according to the main URL, the IoT data to be pushed is divided into different types of resources.

[0056] In this embodiment, different push addresses are regarded as resources for classification management. For example, the same push address, that is, the main URL part is the same, but the request parameters are different, which 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, respectively, belonging to the same type of resources, 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: Obtain identifiers corresponding to each type of resource from the cache.

[0066] In this embodiment, when the cloud platform is started, all resource information in the database is read, deduplicated and classified according to the rules, and then loaded into the cache. Among them, the database stores all push addresses and their initial configurations, such as preset current limiting rules.

[0067] Optionally, the database may be a relational database.

[0068] In this embodiment, the server status to which each type of resource is 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 the identifier corresponding to each type of resource are saved in the cache.

[0069] Optionally, the identifier includes a first identifier, a second identifier, and a third identifier. If the server state is a high-performance state, the mark 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 current limiting monitoring process, which is introduced in step S205.

[0070] Optionally, the identifier further includes a fourth identifier. If the server state is an abandoned state, the identifier of each type of resource pushed to the server is set to the fourth identifier.

[0071] Optionally, this could be a Redis cache.

[0072] S204: forwarding each type of resource to a corresponding queue according to an identifier corresponding to each type of resource; the queues include a normal queue, a green queue, and a current-limiting queue.

[0073] In this embodiment, various types of resources are consumed from the message queue, and various types of resources are forwarded to the new queue according to the identifiers corresponding to the various types of resources.

[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, each type of resource is forwarded to the normal queue; if the identifier corresponding to each type of resource is the second identifier, each type of resource is forwarded to the green queue; if the identifier corresponding to each type of resource is the third identifier, each type of resource is forwarded to the current limiting queue.

[0075] Optionally, the queue further includes a discard queue, and if the identifier corresponding to each type of resource is the fourth identifier, each type of resource is forwarded to the discard queue.

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

[0077] S205: Using a multi-threaded approach, each type of resource in the normal queue and each type of resource in the green queue are pushed concurrently, and the following steps are performed during the pushing process.

[0078] In this embodiment, a multi-threaded concurrent mode is adopted to consume various types of resources in the normal queue and various types of resources in the green queue, and different thread resources are provided for different queues. For example, more threads are allocated to the green queue that has been in normal execution for a long time or needs to be pushed first. This improves the utilization rate of platform resources and ensures the real-time nature of message push by IoT devices.

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

[0080] S2051: Determine whether various types of resources in the normal queue and / or various types of resources in the green queue trigger preset flow limiting rules; wherein the preset flow limiting rules include preset flow limiting durations.

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

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

[0083] In this embodiment, the current limiting rules are configured according to the following core parameters:

[0084] Current limiting duration: the time resources are limited after current limiting is triggered, in seconds.

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

[0086] Slow call ratio: The ratio of slow calls in the push statistics process, with a ratio range of 0-1.

[0087] Minimum number of requests: The minimum number of requests for statistical push quantity. If the number of requests is lower than the minimum number, the current limiting rule will not be triggered.

[0088] Statistics duration: The time window during the statistics 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] Statistical duration: 30 minutes

[0094] Current limiting time: 60 seconds

[0095] Exemplarily, the preset flow limiting rule is: within 30 minutes, if the proportion of each type of resource with a call time exceeding 1000 milliseconds in 100 pushes of any type of resource exceeds 0.6, the preset flow limiting rule is triggered. Among them, the flow limiting duration means that each type of resource in the normal queue or / and green queue is transferred to the flow limiting queue after triggering the preset flow limiting rule; each type of resource transferred from the normal queue or / and green queue to the flow limiting queue is forwarded to the normal queue or / and green queue again after reaching the flow limiting duration.

[0096] In this embodiment, different types of resources obtain slow call situations separately in the current limiting monitoring without interfering with each other. For example, when type A resources trigger the preset current limiting rules, only type A resources are current limited without affecting other resources.

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

[0098] S2052: If the preset current limiting rule is triggered, various types of resources in the normal queue and / or various types of resources in the green queue are forwarded to the current limiting queue.

[0099] In this embodiment, the push of various types of resources in the normal queue and various types of resources in the green queue are subject to the flow limiting monitoring of the preset flow limiting rules, and various types of resources in the flow limiting queue are not subject to the flow limiting monitoring of the preset flow limiting rules.

[0100] Optionally, the identifier of each type of resource forwarded to the current limiting queue is modified to a third identifier.

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

[0102] In this embodiment, various types of resources in the current limiting queue are directly pushed, which is not affected by the preset current limiting rules and does not affect the push of the green queue and the normal queue.

[0103] S207: During the push process, the normal queue and / or the green queue forwards the various types of resources to the current limiting queue. After reaching the preset current limiting time, the resources are forwarded to the normal queue and / or the green queue for push again.

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

[0105] Specifically, each type of resource in the normal queue or / and each type of resource in the green queue is forwarded to the flow-limiting queue due to triggering the preset flow-limiting rule. Each type of resource forwarded from the normal queue or / and the green queue to the flow-limiting queue is forwarded to the normal queue or / and the green queue for push again after reaching the preset flow-limiting time.

[0106] Optionally, the current limiting time period may be 60 seconds.

[0107] Optionally, the identifier of each type of resource forwarded from the current limiting queue to the normal queue is modified to N; the identifier of each type of resource forwarded from the current limiting queue to the green queue is modified to G.

[0108] Optionally, the queue also includes a discard queue.

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

[0110] In summary, according to the push address, the IoT data to be pushed is divided into different types of resources, and according to the identifiers of each type of resources, each type of resources is forwarded to different queues for push respectively, so as to realize diversion push and improve push efficiency; and according to the preset current limiting rules, during the push process, the various types of resources in the normal queue or / and the green queue that trigger the preset current limiting rules are forwarded to the current limiting queue, without interfering with the push efficiency of the normal queue and the green queue. In addition, the multi-threaded method is used for concurrent push, which ensures the real-time push of the IoT data to be pushed.

[0111] On the basis of the above embodiments, in this embodiment, a push system for IoT data is provided. 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 management component, a database module and a cache 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, wherein the IoT data to be pushed includes the push address.

[0113] Push message consumption module, used to consume IoT data from the message queue;

[0114] The queue stratification module divides the IoT data to be pushed into different types of resources according to the push address; obtains the identifiers corresponding to each type of resource from the cache; and forwards each type of resource to the corresponding queue according to the identifiers corresponding to each type of resource; the queues include normal queues, green queues, and flow-limited queues.

[0115] Traffic management components are used to define and monitor the flow control rules for various types of resources and dynamically adjust the identification of various types of resources.

[0116] Optionally, the traffic management component can be sentinel. Sentinel monitors data such as slow calls, success rates, and call times of various types of resources in real time.

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

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

[0119] In summary, according to the push address, the IoT data to be pushed is divided into different types of resources, and according to the identifiers of each type of resources, each type of resources is forwarded to different queues for push respectively, so as to realize diversion push and improve push efficiency; and according to the preset current limiting rules, during the push process, the various types of resources in the normal queue or / and the green queue that trigger the preset current limiting rules are forwarded to the current limiting queue, without interfering with the push efficiency of the normal queue and the green queue. In addition, the multi-threaded method is used for concurrent push, which ensures the real-time push of the IoT data to be pushed.

[0120] Figure 3 A schematic diagram of the structure of the device for pushing IoT data provided in the embodiment of the present application is shown in FIG. Figure 3 As shown, the push device of IoT data provided by this embodiment includes: a data receiving module 301, a division module 302, an identification 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 the IoT data to be pushed sent by the IoT service system; wherein the IoT data to be pushed includes a push address.

[0122] The division module 302 is used to divide the IoT data to be pushed into different types of resources according to the push address.

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

[0124] The forwarding module 304 is used to forward 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 current-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 in a multi-threaded manner, and execute the following steps during the push process.

[0126] The first push module 305 includes:

[0127] The judgment unit 3051 judges whether various types of resources in the normal queue and / or various types of resources in the green queue trigger preset flow limiting rules; wherein the preset flow limiting rules include preset flow limiting durations.

[0128] The forwarding unit 3052 forwards various types of resources in the normal queue and / or various types of resources in the green queue to the current limiting queue if the preset current limiting rule is triggered.

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

[0130] The third push module 307 is used to forward various types of resources in the current limiting queue from the normal queue and / or the green queue during the push process, and forward them to the normal queue and / or the green queue for push again after reaching a preset current limiting time.

[0131] In one possible implementation, the preset flow limiting rules include: statistical duration, minimum number of requests, slow call time and slow call ratio; accordingly, judging whether each type of resource in the normal queue, or / and each type of resource in the green queue triggers the preset flow limiting rules, including: 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 the each type of resource in the normal queue has triggered the preset flow 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 the each type of resource in the green queue has triggered the preset flow limiting rules.

[0132] In a possible implementation, the division module 302 is specifically used to: obtain a main URL of the push address; and divide the IoT data to be pushed into different types of resources according to the main URL.

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

[0134] In a possible implementation, the push device for IoT data also includes a storage module, which is used to obtain the server status to which each type of resource is 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 the identifier corresponding to each type of resource in a cache.

[0135] In a possible implementation, the queue further includes a discarded queue; accordingly, the method further includes: discarding various types of resources in the discarded queue and not pushing them.

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

[0137] Figure 4 This is a schematic diagram of the structure of the cloud platform provided in the embodiment of the present 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, the memory 402 and the communication component 403 are connected via a bus 404.

[0138] In a specific implementation process, at least one processor 401 executes the computer-executable instructions stored in the memory 402, so that at least one processor 401 executes the above method.

[0139] The specific implementation process of the processor 401 can be found in the above method embodiment, and its implementation principle and technical effect are similar, so this embodiment 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 (DSP), application-specific integrated circuits (ASIC), etc. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the invention can be directly implemented as a hardware processor, or can be implemented by a combination of hardware and software modules in the processor.

[0141] The memory may include a high-speed memory (Random Access Memory, RAM), and may also include a non-volatile memory (NVM), such as at least one disk storage.

[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. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, the bus in the drawings of this application is not limited to only one bus or one type of bus.

[0143] The present application also provides a computer program product, including a computer program, which implements the above method when executed by a processor.

[0144] The present application also provides a computer-readable storage medium, in which computer-executable instructions are stored. When a processor executes the computer-executable instructions, the above method is implemented.

[0145] The above-mentioned 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 memory, flash memory, magnetic disk or optical disk. The readable storage medium can be any available medium that can be accessed by a general or special-purpose computer.

[0146] An exemplary readable storage medium is coupled to a processor so that the processor can read information from the readable storage medium 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 be located in an application specific integrated circuit (Application Specific Integrated Circuits, referred to as: ASIC). Of course, the processor and the readable storage medium can also exist in the device as discrete components.

[0147] The division of units is only a logical function division, and there may be other divisions in actual implementation, such as 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, device or unit, which can be electrical, mechanical or other forms.

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

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

[0150] If the function is implemented in the form of 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 the present invention, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods of each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, etc. Various media that can store program codes.

[0151] Those skilled in the art can understand that all or part of the steps of implementing the above-mentioned method embodiments can be completed by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, the steps of the above-mentioned method embodiments are executed; and the aforementioned storage medium includes: ROM, RAM, disk or optical disk and other media that can store program codes.

[0152] Finally, it should be noted that those skilled in the art will readily conceive of other embodiments of the present invention after considering the specification and practicing the invention disclosed herein. The present invention is intended to cover any variations, uses or adaptations of the present invention, which follow the general principles of the present invention and include common knowledge or customary technical means in the art not disclosed by the present invention, are not limited to the precise structure described above and shown in the drawings, and may be modified and changed in various ways without departing from the scope thereof. The scope of the present invention is limited only by the appended claims.

Claims

1. A method for pushing Internet of Things data, characterized in that: Applied to cloud platforms, including: Receive the IoT data to be pushed sent by the IoT business system; wherein the IoT data to be pushed includes a push address; According to the push address, the IoT data to be pushed is divided into different types of resources; Get the identifiers corresponding to each type of resource from the cache; According to the identifiers corresponding to the various types of resources, the various types of resources are forwarded to the corresponding queues; the queues include normal queues, green queues and current-limited queues; In a multi-threaded manner, each type of resource in the normal queue and each type of resource in the green queue are pushed concurrently, and the following steps are performed during the pushing process: Determine whether various types of resources in the normal queue and / or various types of resources in the green queue trigger preset current limiting rules; wherein the preset current limiting rules include preset current limiting duration; If the preset current 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 current limiting queue; Pushing various types of resources in the current limiting queue; During the push process, the normal queue and / or the green queue forwards the various types of resources to the current limiting queue, and after reaching the preset current limiting time, they are forwarded to the normal queue and / or the green queue for push again.

2. The method according to claim 1, characterized in that The preset current limiting rules include: statistical duration, minimum number of requests, slow call time and slow call ratio; Accordingly, the determining whether each type of resource in the normal queue and / or each type of resource in the green queue triggers a preset current limiting rule includes: If, for each type of resource in the normal queue, within the statistical duration, the proportion of each type of resource whose call time exceeds the slow call time in the minimum number of requests exceeds the slow call proportion, it is determined that each type of resource in the normal queue has triggered the preset current limiting rule; Or / and if the proportion of each type of resources in the green queue whose call time exceeds the slow call time in the minimum number of requests within the statistical duration exceeds the slow call proportion, it is determined that the various types of resources in the green queue have triggered the preset current limiting rules.

3. The method according to claim 1, characterized in that The method of dividing the IoT data to be pushed into different types of resources according to the push address includes: Get the main URL of the push address; According to the main URL, the IoT data to be pushed is divided into different types of resources.

4. The method according to claim 1, characterized in that: The forwarding of each type of resource to a corresponding queue according to an identifier corresponding to each type of resource includes: If the identifier corresponding to each type of resource is the first identifier, or the identifier corresponding to each type of resource is empty, forwarding each type of resource to a normal queue; If the identifier corresponding to each type of resource is the second identifier, forwarding each type of resource to the green queue; If the identifier corresponding to each type of resource is the third identifier, each type of resource is forwarded to the current limiting queue.

5. The method according to any one of claims 1 to 4, characterized in that: After dividing the IoT data to be pushed into different types of resources according to the push address, the method further includes: According to the push address, obtain the server status of each type of resource being pushed; According to the server status, setting identifiers for the various types of resources; The various types of resources and identifiers corresponding to the various types of resources are saved in a cache.

6. The method according to any one of claims 1 to 4, characterized in that: The queue also includes a discard queue; Accordingly, the method further comprises: All types of resources in the discard queue are discarded and not pushed.

7. A device for pushing Internet of Things data, characterized in that: Applied to cloud platforms, including: A data receiving module receives the IoT data to be pushed sent by the IoT service system; wherein the IoT data to be pushed includes a push address; A division module, used for dividing the IoT data to be pushed into different types of resources according to the push address; The identification acquisition module is used to obtain the identification corresponding to each type of resource from the cache; A forwarding module, used for forwarding each type of resource to a corresponding queue according to an identifier corresponding to each type of resource; the queue includes a normal queue, a green queue and a current-limiting queue; The first push module is used to concurrently push each type of resource in the normal queue and each type of resource in the green queue in a multi-threaded manner, and execute the following steps during the push process; Wherein, the push module includes: A judgment unit, judging whether various types of resources in the normal queue and / or various types of resources in the green queue trigger preset flow limiting rules; wherein the preset flow limiting rules include preset flow limiting duration; A forwarding unit, if the preset current limiting rule is triggered, forwards various types of resources in the normal queue, and / or various types of resources in the green queue to the current limiting queue; A second push module is used to push various types of resources in the current limiting queue; The third push module is used to forward various types of resources in the current limiting queue from the normal queue and / or the green queue during the push process, and after reaching the preset current limiting time, forward them to the normal queue and / or the green queue for pushing again.

8. A cloud platform, characterized in that: include: Memory, processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory, so that the processor performs the method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, which are used to implement the method according to any one of claims 1 to 6 when executed by a processor.

10. A computer program product, characterized in that The invention comprises a computer program, which implements the method according to any one of claims 1 to 6 when being executed by a processor.

Images