CN114979174B

CN114979174B - Method for processing HTTP blocking waiting step-by-step service data

Info

Publication number: CN114979174B
Application number: CN202210399869.2A
Authority: CN
Inventors: 杨培海; 邓宏
Original assignee: Sichuan Hongmei Intelligent Technology Co Ltd
Current assignee: Sichuan Hongmei Intelligent Technology Co Ltd
Priority date: 2022-04-15
Filing date: 2022-04-15
Publication date: 2023-07-21
Anticipated expiration: 2042-04-15
Also published as: CN114979174A

Abstract

The invention discloses a method for processing HTTP blocking waiting step-by-step service data, which is characterized in that a self-circulation mode structural design is utilized, and a blocked HTTP request mode is searched, so that the method can enable a synchronous HTTP request to acquire other asynchronous system data in time, especially when a service cluster is deployed, the asynchronous system data can be received by different services in the cluster.

Description

Method for processing HTTP blocking waiting step-by-step service data

Technical Field

The invention relates to the field of data communication between cloud servers, in particular to a method for processing HTTP blocking waiting step-by-step service data.

Background

At present, whether the system is an internet of things or other application environments, a large amount of data exchange exists, and due to different characteristics of the system, different modes of data exchange can be caused, and the most common mode is an asynchronous mode and a synchronous mode.

At present, the invention discloses a data synchronization method, a server, a mobile terminal and a data synchronization system, wherein the publication number is CN 201180001477.6. From the perspective of a server, the data synchronization method can comprise the steps of receiving a data synchronization request sent by a request synchronization terminal, determining a matched synchronization identifier of the request synchronization terminal synchronization identifier according to a corresponding relation between preset synchronization identifiers, and determining a communication identifier of a terminal to be synchronized corresponding to the matched synchronization identifier according to the corresponding relation between the synchronization identifier and the communication identifier; and sending a data synchronization notification to the terminal to be synchronized according to the communication identifier, wherein the notification carries the synchronization data. In the invention, the matched synchronization identification is arranged in the mobile terminal, and under the condition of synchronization requirement, the terminal to be synchronized is determined by the server according to the synchronization identification, and then the synchronization processing information is sent to the terminal to be synchronized, so that the data synchronization between the mobile terminals is realized.

The publication number CN201310012928.7 provides a data synchronization method and a data synchronization device for a terminal device and a synchronization server. The data synchronization method for the synchronization server comprises the following steps: maintaining a TCP/IP long connection between the synchronization server and at least one cloud server; maintaining data synchronization between the synchronization server and the at least one cloud server by using the TCP/IP long connection; receiving a synchronization request from a terminal device; and carrying out data synchronization between the terminal equipment and the synchronization server. The data synchronization method for the terminal equipment comprises the following steps: transmitting a data synchronization request to a synchronization server through a first file system interface deployed on the terminal equipment, wherein the data synchronization request is used for indicating to perform data synchronization between the terminal equipment and the synchronization server, and the synchronization server and at least one cloud server keep TCP/IP long connection; and carrying out data synchronization between the terminal equipment and the synchronization server through the first file system interface.

The existing methods are all methods for synchronizing data in the system, and are not used for realizing data synchronization among different business logics of different systems, and are not used for realizing the requirement that one HTTP request needs to asynchronously wait for data of other third-party systems.

Disclosure of Invention

To overcome the disadvantages and shortcomings of the prior art, the present invention provides a method of handling HTTP blocking wait for step-by-step service data.

The technical scheme adopted by the invention is that the method comprises the following steps:

step S1: synchronizing data of the third party system A in a mode of blocking HTTP, so that the third party system A is in a waiting state;

step S2: creating a Map set of a single instance, collecting HTTP requests, and finding out corresponding HTTP requests by cloud service;

step S3: after receiving the reply of the third party equipment B, the cloud service finds out a corresponding HTTP request by utilizing the implementation of the step S2 and releases the blocking state of HTTP;

step S4: when the corresponding HTTP request cannot be found, writing the reply of the third party equipment B into Redis;

step S5: when the cloud service receives the HTTP request, a self-circulation thread is activated, data in Redis is checked according to circulation logic of the self-circulation thread, and the blocked HTTP request in the service is activated to unlock;

step S6: and (3) synchronously acquiring asynchronous data of the third party system by using the HTTP under the condition that the cluster is completed through the blocking of the HTTP and the circulation of the thread by utilizing the steps S1, S2, S3, S4 and S5.

The invention provides a method for processing HTTP blocking waiting step-by-step service data, which is characterized in that the invention has 2 innovation points, namely, a self-circulation mode structure design is adopted, and the other is a mode for searching blocked HTTP request mode, so that the invention can enable a synchronous HTTP request to acquire other asynchronous system data in time, especially when a service cluster is deployed, the data of the asynchronous system can be received by different services in the cluster.

Drawings

FIG. 1 is a flow chart of the overall method steps of the present invention;

FIG. 2 is a diagram of FIG. 1 according to an embodiment of the present invention;

fig. 3 is the embodiment of fig. 2.

Detailed Description

It should be noted that, without conflict, the embodiments and features of the embodiments in the present application may be combined with each other, and the present application will be further described in detail with reference to the drawings and the specific embodiments.

As shown in fig. 1, a method of processing HTTP blocking wait-for-step service data,

the method comprises the following steps:

Embodiment one:

demand: the mobile phone controls the intelligent air conditioner through the HTTP request, and the mobile phone needs to synchronously obtain the execution result of the executed air conditioner.

The solution is as follows: the mobile phone requests the cloud IOT system through HTTP, the IOT system sends the command to the equipment through MQTT protocol, the air conditioner receives the control command, after executing, the execution result is sent to the IOT system through the MQTT protocol, and the IOT system returns the result to the mobile phone to tell the execution result of the air conditioner of the mobile phone.

The mobile phone is the third party system A in the following content, the IOT system is HTTP blocking service, and the air conditioner is the third party system B.

Embodiment two:

demand: in the package service, the user speaks into the air conditioner: after the washing machine is started, the air conditioner needs to wait for the execution of the washing machine, and after the execution result is returned, the result is broadcasted to a user in a voice mode. Why the air conditioner needs to wait for the execution result of the washing machine, instead of immediately replying to the user: good results are obtained because the washing machine may have different recovery results when performing the opening operation, such as already on, in washing, etc. It is necessary to block the request of the air conditioner, let the air conditioner wait until the washing machine correctly returns the result.

The solution is as follows: the air conditioner requests the semantic platform through HTTP, the semantic platform firstly blocks the HTTP request and then requests the cloud IOT system, the IOT system transmits a command of the washing machine to the washing machine equipment through an MQTT protocol, the washing machine receives the control command, after executing, the washing machine transmits an execution result to the IOT system through the MQTT protocol, the IOT system returns the result to the semantic platform, the semantic platform activates the blocked HTTP request, and the HTTP returns the result to tell the execution result of the washing machine of the air conditioner.

The above air conditioner is the third party system A in the following content, the semantic platform is HTTP blocking service, and the IOT system and the air conditioner are the third party system B.

When the third party system A requests the service of the third party by means of HTTP, the key value pair set of the shared Map of a single instance is used in the service of the third party system A, and the mark of the request is stored as a key, for example: and the sn of the device stores the thread ID of the current request as a value.

Then logic of self service is carried out, and finally the third party system B is notified asynchronously, such as: and sending a device command to the air conditioner. And simultaneously, blocking the thread and waiting for a reply result of the third party system B so as to meet the synchronous requirement of the third party system A.

The third party system A waits for receiving the message of the third party system B, and after receiving the message of the third party system B, the third party system A searches for a corresponding thread in the key value pair of the shared Map of a single instance by marking sn, and the two cases are now divided into two cases:

1. if the thread is found, the corresponding blocking state is released, and the acquired data are returned to the third party system A together after the blocking state is released; corresponding to the single service deployment mode of fig. 2 as follows.

2. If the thread is not found, indicating that the corresponding HTTP request is not in the service, and writing the data into a Redis memory database; corresponding to the service cluster deployment mode of fig. 3 as follows.

Only the data results in the second case above need be processed at this time. The process comprises the following steps: when a service receives an HTTP request of a third party system A, the service triggers a dead loop, the loop searches whether data exists in Redis at regular intervals, the interval time of the loop is determined by the emergency degree of the HTTP request, if the data exists in the Redis, the service searches whether a corresponding thread exists in the service, if the data exists in the Redis, the blocking state of the corresponding thread is released, the data in the Redis is directly returned to the third party system A, and if the data in the Redis is not detected, the loop is continued until the key value pair of the shared Map of the service single instance has no data in the set. Thus, the problem of acquiring different service data during cluster deployment is solved.

As shown in fig. 2, by way of example two above, the user is presented to the air conditioner: turning on the washing machine, the flow of the single service of fig. 2 is described:

the user turns on the washing machine for the air conditioner, the air conditioner serves as a third party platform A to initiate HTTP call, and the cloud end receives HTTP requests.

The cloud end blocks the HTTP request, and does not return a result, so that the air conditioner is in a waiting state.

The cloud executes logic of the cloud to find the washing machine, and asynchronously sends opening operation to the washing machine, and at the moment, the washing machine is the third party system B.

After the washing machine executes the opening operation, the result is returned to the cloud, and the data returned to the cloud can only be consistent with the HTTP sending service due to single service deployment, namely, the single service is a sender of a command for opening the washing machine and a replying person for receiving the washing machine.

After receiving the reply of the washing machine, the cloud end searches for the HTTP request which is blocked in the service

The blocked HTTP request can be found certainly, then the return data of the washing machine is filled in the HTTP request, the blocking state of the HTTP is opened, and the result of the washing machine is returned to the waiting air conditioner.

The air conditioner plays the result of the washing machine execution.

As shown in fig. 3, by way of example two above, the user is presented to the air conditioner: turning on the washing machine illustrates the flow of the cluster service of fig. 2:

After the washing machine executes the opening operation, the result is returned to the cloud, and because the result is the deployment of the cluster service, the data returned to the cloud may be consistent with the HTTP sending service, or may be above other deployed services, that is, the service sending the washing machine command may not receive the command replied by the washing machine, and the service without the command sent can receive the command of the washing machine.

If found, directly removing HTTP blocking as single service version, returning result

If not, the result is written to Redis.

At the above step, another set of logic is added, namely when the service receives the HTTP request, a thread which is self-circulated every 200ms according to the emergency degree of the demand is activated, the thread checks whether the local machine has the blocked HTTP request, and if not, the thread is circulated to enter a blocking state; if the blocked HTTP request exists, inquiring whether data exists in the Redis, checking whether the data exists in the blocked HTTP request corresponding to the service when the data exists, if so, returning an HTTP result, and if not, continuing to circulate. Until there is no blocked HTTP request.

The returned HTTP is also broadcasted, and the air conditioner plays the result executed by the washing machine.

As shown in fig. 2 and fig. 3, the biggest difference between the cluster and the single service deployment is that the cluster deployment can support greater concurrency, and when HTTP requests become larger with the request amount, the single service cannot be supported continuously, and at this time, the single service needs to be supported by the cluster deployment service. However, in this patent, some of the data is sent and received asynchronously, which causes a problem that the reply result of the data sent by the HTTP-hold-up service a in the cluster may be received by the HTTP-hold-up service B in the cluster, so that the HTTP-hold-up service a can never receive the data that it wants to obtain.

In the description of the present invention, it should be noted that, unless explicitly specified and limited otherwise, the terms "disposed," "mounted," "connected," and "fixed" are to be construed broadly, and may be, for example, fixedly connected, detachably connected, or integrally connected; can be mechanically or electrically connected; can be directly connected or indirectly connected through an intermediate medium, and can be communication between two elements. The specific meaning of the above terms in the present invention can be understood by those of ordinary skill in the art in a specific case.

Although embodiments of the present invention have been shown and described, it will be understood by those skilled in the art that various equivalent changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined in the appended claims and their equivalents.

Claims

1. A method for processing HTTP blocking wait for step-by-step service data, comprising the steps of:

step S1: the cloud service receives an HTTP request of the third party system A, the HTTP request requests the third party device B to execute a task, and the HTTP request is blocked, so that the third party system A is in a waiting state;

step S2: the cloud service asynchronously informs the third party equipment B and creates a Map set of a single instance;

step S3: after receiving the execution result of the third party equipment B, the cloud service searches whether a corresponding blocked HTTP request exists or not by utilizing the Map set in the step S2, and if the corresponding HTTP request is found, the blocking state of the HTTP is released, and the step S6 is entered;

step S4: if the corresponding HTTP request cannot be found, writing the reply of the third-party equipment B into Redis;

step S6: and the cloud service returns an execution result of the third party equipment B to the third party system A, and the third party system A plays the execution result.