CN106649301B

CN106649301B - Data query method, device and system

Info

Publication number: CN106649301B
Application number: CN201510712657.5A
Authority: CN
Inventors: 徐凯
Original assignee: Beijing Gridsum Technology Co Ltd
Current assignee: Beijing Gridsum Technology Co Ltd
Priority date: 2015-10-28
Filing date: 2015-10-28
Publication date: 2020-09-11
Anticipated expiration: 2035-10-28
Also published as: CN106649301A

Abstract

The invention discloses a method, a device and a system for data query, relates to the technical field of telecommunication, and aims to solve the problem that a query result does not correspond to a query operation due to time delay. The method of the invention comprises the following steps: generating a non-repeated request mark for a query request to be sent; sending a query request carrying a request mark to a server; receiving a query response returned by the server, wherein the query response carries query data and a request mark carried by a query request corresponding to the query response; judging whether the received request mark is the same as the request mark carried by the last sent query request; if the judgment result is yes, outputting the query data. The invention is mainly applied to the data query process based on the HTTP protocol.

Description

Data query method, device and system

Technical Field

The present invention relates to the field of telecommunication technologies, and in particular, to a method, an apparatus, and a system for querying data.

Background

Data query is the most basic data interaction means in modern internet technology, and is widely used in browser application and database query systems. A typical data query process involves both a client as the query originator and a server as the query responder. The client initiates a query request, adds a query condition (such as a host address to be accessed) to the query request and sends the query condition to the server. The server analyzes the content of the query request, queries data according to the query conditions, and returns the query result (such as webpage data) to the client in a mode of returning query response.

In the existing data query process, the inventor finds that: when the client initiates multiple query requests in a short time, the sequence of the query response returned by the server and the sequence of the query request initiated by the client are not necessarily consistent due to various reasons. Specifically, in one case, when a client sends query requests to the same server through different Hypertext Transfer Protocol (HTTP) connections, the transmission speeds of multiple HTTP connections are different due to the influence of network transmission conditions, and the sequence of the query requests reaching the server and the sequence of the query responses returning to the client are irregular, so that the query requests sent earlier may obtain corresponding query responses later. In another case, the client sends query requests to different servers through multiple HTTP connections. Under the condition that the network transmission conditions are consistent, even if the query requests can reach the service ends according to the sequence sent by the client, the return sequence of the query responses can be disturbed because the load degree and the processing speed of different service ends are different. In summary, no matter what causes the above problems, as long as a delay occurs between sending the query request and receiving the query response, and the client initiates a new query request during the delay, when a response corresponding to a previous request is returned, the client outputs the previous response as a query result of a subsequent request, so that the query result seen by the user does not correspond to the input query condition, thereby affecting the use of the query service by the user.

Disclosure of Invention

The invention provides a data query method, a data query device and a data query system, which can solve the problem that a query result does not correspond to a query operation due to time delay.

To solve the above problem, in one aspect, the present invention provides a method for querying data, where the method includes:

generating a non-repeated request mark for a query request to be sent;

sending a query request carrying a request mark to a server;

receiving a query response returned by the server, wherein the query response carries query data and a request mark carried by a query request corresponding to the query response;

judging whether the received request mark is the same as the request mark carried by the last sent query request;

if the judgment result is yes, outputting the query data.

In another aspect, the present invention further provides a device for querying data, where the device includes:

the generating unit is used for generating non-repeated request marks for the query request to be sent;

the sending unit is used for sending a query request carrying a request mark to the server;

the receiving unit is used for receiving the query response returned by the server, wherein the query response carries query data and a request mark carried by a query request corresponding to the query response;

the judging unit is used for judging whether the received request mark is the same as the request mark carried by the last sent query request;

and the output unit is used for outputting the query data when the judgment result is yes.

In another aspect, the present invention further provides a system for querying data, where the system includes a client and a server;

the client is used for generating a non-repeated request mark for the query request to be sent and sending the query request carrying the request mark to the server;

the server is used for responding to the query request to perform data query, analyzing the query request to obtain a request mark, adding the request mark and query data obtained by data query into a query response corresponding to the query request, and returning the query response to the client;

and the client is also used for receiving the query response returned by the server, judging whether the received request mark is the same as the request mark carried by the query request sent at the last time, and outputting the query data if the judgment result is yes.

The data query method, the device and the system provided by the invention can add a unique request mark in the query request sent to the server, and the server adds the request mark to the query response corresponding to the query request and returns the query response to the client. When receiving the inquiry response, the client compares the request mark in the inquiry response with the request mark in the last sent inquiry request. If the two request marks are the same, the received query response is proved to be the query response corresponding to the last query request, and the client outputs the query result in the query response. Compared with the prior art, the method and the device can enable the client to directly output the query result corresponding to the last query operation executed by the user, thereby ensuring the reality and effectiveness of the latest query operation of the user.

The foregoing description is only an overview of the technical solutions of the present invention, and the embodiments of the present invention are described below in order to make the technical means of the present invention more clearly understood and to make the above and other objects, features, and advantages of the present invention more clearly understandable.

Drawings

Various other advantages and benefits will become apparent to those of ordinary skill in the art upon reading the following detailed description of the preferred embodiments. The drawings are only for purposes of illustrating the preferred embodiments and are not to be construed as limiting the invention. Also, like reference numerals are used to refer to like parts throughout the drawings. In the drawings:

FIG. 1 is a flow chart of a method for querying data according to an embodiment of the present invention;

FIG. 2 is a flow chart of another method for querying data provided by an embodiment of the invention;

FIG. 3 is a block diagram illustrating an apparatus for querying data according to an embodiment of the present invention;

FIG. 4 is a block diagram illustrating an apparatus for querying data according to an embodiment of the present invention;

fig. 5 shows a system block diagram of a data query according to an embodiment of the present invention.

Detailed Description

Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be embodied in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

In order to ensure that a query result output by a client corresponds to a query operation executed by a user, the embodiment of the invention provides a data query method. The core idea of the method is as follows: the query requests and the query responses which correspond to each other are identified in a request mark adding mode, and no matter how many times of query operations are carried out by the user and the sequence of the query responses returned by the server side is, the client side only outputs the query result corresponding to the last query operation, so that the effectiveness of the last query operation of the user is ensured. As shown in fig. 1, the method includes:

101. generating non-repeated request marks for the query request to be sent.

Before each query request is initiated by the client, a request mark is generated for the query request to be sent, and the request mark is not repeatedly generated and used, so that the request mark of each query request is ensured to be unique and effective.

In practical application, a client may temporarily generate a request tag before sending an inquiry request, or may generate a plurality of non-repetitive request tags in advance, and pre-store the request tags in a tag list or a tag queue, and select one request tag from the request tags to be allocated to an inquiry request to be sent when the inquiry request is initiated. The present embodiment does not limit the timing of generating the request flag.

102. And sending a query request carrying the request mark to a server.

The client adds the generated request mark to a preset field of the query request, and sends the query request carrying the request mark to the server. In practical application, the same private protocol can be configured on both sides of the client and the server, and the specific field position of the client for adding the request mark and the specific field position of the server for analyzing the request mark are specified. However, in the case where the field position cannot be specified by rewriting the protocol, the request flag may be transmitted separately from the inquiry request. However, in order to ensure strong correlation between the request tag and the query request, a strict limitation is required to the time interval between sending the request tag and the query request. Ideally, the time interval should be much smaller than the minimum time interval that may exist between two query requests artificially triggered.

It should be noted that the private Protocol described in this embodiment refers to a Protocol type used by a transport layer, and includes but is not limited to a Transmission Control Protocol (TCP) and a User Datagram Protocol (UDP), and this embodiment does not exclude a public Protocol used by an application layer, such as a Hypertext Transfer Protocol (HTTP).

103. And receiving the query response returned by the server.

After receiving the query request, the server analyzes the query condition information from the query request, and analyzes the request mark added by the client from the specified field position. And then searching corresponding query data according to the query condition information, and adding the query data serving as a query result into a query response. Unlike the prior art, the server adds the parsed request tag to the query response, so that the client can subsequently identify the query response.

Similar to step 102, the field location of the server add request tag may also be freely specified by the private protocol. In a simpler implementation, the field positions of the client and the server for adding the request mark can be specified as the same position.

104. And judging whether the received request mark is the same as the request mark carried by the last sent query request.

In order to compare the request marks, the client needs to cache the sent query request according to the initiation timing sequence. When receiving the query response, the client analyzes the query data and the request mark added by the server from the query response, and analyzes the request mark added by the client from the last cached query request. And then comparing the two analyzed request marks respectively.

It should be noted that, in the present embodiment, the client is configured to output the query result corresponding to the last query operation, so that no matter how many query operations the user has performed before, it is not necessary to compare the analyzed request tag with the request tag in the previous request.

105. If the judgment result is yes, outputting the query data.

If the two request marks are the same, the server returns a query response corresponding to the last query request, and the query data in the query response is the query result to be obtained by the last query operation, so that the client outputs the query data back to the user.

If the two request marks are different, the server side returns the query response corresponding to the prior query request. Because the user initiates at least one subsequent query operation after initiating the prior query operation, and the query data corresponding to the prior query operation is fed back to the user at the moment, the client can perform special processing on the query response corresponding to the prior query request. In practical application, the processing mode of saving storage resources is to directly discard the query data in the prior query response. Of course, in some cases where the query service quality is considered, the client may also save the query data in the previous query response for the subsequent election to feed back to the user.

It should be noted that the method provided by this embodiment is applicable to all data query scenarios in real life, and these scenarios include, but are not limited to: requesting web content through a browser, vertical searches through APPs, database queries in private networks, and the like.

The prior art and the method of fig. 1 are illustrated below by a simple example:

suppose that a user sends a query request 1 to a vertical search server to request for querying the price H of a 16-type Audi A4L full-family vehicle model, and the server has a high load at the moment, so that the user does not respond to the query request 1 in time; the user then sends a query request 2 to the server requesting a query for the price L of the 15-money Benz C200 automobile type. After the client sends the query request 2, the server responds to the query request 1, and adds the price H to the query response 1 and returns the price H to the client. In the prior art, the client directly outputs the price H after receiving the query response 1, but at this time, the user has made a second query operation for generating the query request 2, and the expected query result is the price L corresponding to the second query operation, in which case the price H is obviously not good enough to be output.

In the method shown in fig. 1, the client adds a request tag "110" to the transmitted query request 1, and adds a request tag "203" to the transmitted query request 2. When the server responds to the query request 1, the request mark '110' in the query request is added to the query response 1, and the price H is returned to the client. After receiving the query response 1, the client compares the request mark "110" with the request mark "203" in the query request 2 sent later, and finds that the two are different, and the client discards the price H. Thereafter, the server returns a query response 2 carrying the request tag "203" and the price L. The client compares the request mark "203" in the response 2 with the request mark "203" in the query request 2, finds that the two are the same, and outputs the price L, which is the query result expected by the user currently.

As can be seen from the above example: in the prior art, the query result output by the client is staggered with the query operation performed by the user, and the method cannot enable the user to obtain an effective query result from the perspective of query expectation. In contrast, the method shown in fig. 1 sacrifices the output of the previous query result, but can ensure that the last query operation of the user can obtain the corresponding query result, so as to ensure the effectiveness of the partial query operation under the condition that the response delay cannot be avoided.

Further, as a refinement of the method shown in fig. 1, an embodiment of the present invention further provides a method for querying data. As shown in fig. 2, the method includes:

201. generating non-repeated request marks for the query request to be sent.

In this embodiment, the parameter that can be used as the request tag may be a pseudo-random number, an information Digest Algorithm (MD 5) value, or a timestamp. The use of three parameters is described below:

1. pseudo random number

The client side is implanted with a pseudo-random number generation function which is characterized in that the pseudo-random numbers generated each time are not repeated. When data query is performed, the client can monitor the running state of programs such as a browser by one thread. When a query request is generated, the thread intercepts the send action through a hook function and jumps to call a pseudo-random number generation function to generate a pseudo-random number.

In one implementation of the present embodiment, when compiling using the C language, the pseudo random number generator function based on the ansi standard provided by the C language compiler may be directly used. This function consists of two sub-functions, srand (). When a pseudo-random number is generated, an initial value named as a seed value and with the type of unsigned is provided for srand (), and the value range of the initial value is 0-65535. The seed value may be assigned randomly using a fast count register or a shift register as is often the case. And then, calling rand (), and returning a pseudo-random number according to the seed value of the srand (), wherein the pseudo-random number is randomly selected in the value range of 0-32767. When the next pseudo-random number needs to be generated, the rand () is repeatedly called, and a new pseudo-random number is still randomly selected from the value range. Since the rand () theoretically has a mechanism of not repeating selection (that is, pseudo random numbers selected by calling the rand () multiple times all fall within the above range but do not repeat with each other), a plurality of different pseudo random numbers can be generated based on one seed value in this embodiment.

In practice, however, the above-described non-repeating selection mechanism is not a full probability event, i.e., there is a small probability of repeating the selected plurality of pseudo-random numbers (which is also the origin of the "pseudo-random number" name). In particular, as the number of generated pseudo random numbers is increased, the value range of the subsequently selected pseudo random numbers is smaller and smaller, and therefore the probability of repeatedly selecting the pseudo random numbers is higher and higher. In order to prevent the occurrence of repeated pseudo random numbers, in a further development of the embodiment, the seed value can be changed in accordance with a predetermined number of generations. For example, after 1000 pseudo random numbers are generated by one seed value, a new seed value is randomly re-assigned to srand () and the generation of pseudo random numbers by rand () is continued based on the new seed value. The random change of the seed value can further increase the degree of randomization of the rand (), thereby reducing the probability of the pseudo random number repeating.

In practical applications, the preset number of generation times may be set according to the value range of the pseudo random number, for example, the number of generation times may be set to 32768/2-16384, or 32768/4-8192. Of course, the generation times may also be a fixed value, for example, 1000 times in the above example, and the present embodiment does not limit the specific value of the preset generation times.

2. MD5 value

In this embodiment, MD5 operation may be performed on the query condition in the query request, and the obtained MD5 value may be used as the request tag. The calculated MD5 value is not repeated because the query conditions for different query requests are different from each other.

In practical application, for the query request requesting the web page content, MD5 operation may be performed on the Uniform Resource Locator (URL), for example, on the URL, carried in the query request "http://localhost:7777/ user.do？name＝uu&sex＝male"do MD5 operation; the MD5 operation may be performed only on the query string in the URL, for example, "name ═ uu" in the URL&The MD5 operation is performed for sex ═ male ". For a database query request, the MD5 operation may be performed on the query field therein. The present embodiment does not limit the specific object of the MD5 operation.

3. Time stamp

In this embodiment, a timestamp may be generated according to the time generated by the query request, and the timestamp may be used as the request tag. Generally, query requests generated based on user operations are generated at different times, or users generally cannot simultaneously initiate multiple query requests at the same time. The generation time of the query request is unique. In practical applications, the client may request to acquire the current system clock when generating the query request, and use the acquired system time value as the timestamp. In addition, the client may also count through an independent thread after starting, and read the current count value as the relative timestamp to use when generating the query request.

It should be noted that, in an actual application, there may be a case where multiple background query requests are triggered by an application process at the same time, that is, there are concurrent query requests that are not triggered manually. Since the timestamps of the concurrent query requests are the same, they cannot be used as a request marker. In this case, the client may use the timestamp in combination with other information that may reflect the relative uniqueness of the query request as a request tag. Illustratively, the combination of information that can be used as a request tag can be "timestamp + process number/name" or "timestamp + host domain name".

The above describes an implementation where pseudo-random numbers, MD5 values, and timestamps are used as request markers. In practical applications, the three parameters can be used as the request mark alone or in combination with each other.

202. A request tag is added to the query request.

At present, the most widely used application layer protocol for the data query technology is the HTTP protocol, and the HTTP protocol is taken as an example for description in this embodiment.

The HTTP request contains three parts, a request line, a header field (head), and a body field (body). The request line is used for recording information such as request types, access resources, HTTP versions and the like, the header field is used for explaining additional information used by the server, and any data information can be added into the body field. The client may add a request tag to the body field in this embodiment. In addition, since the content in the header field can also be modified appropriately, it is also feasible to add the request tag to the header field in practical applications.

203. And sending a query request carrying the request mark to a server.

204. The sent query request is added to the local stack.

After the query request is sent to the server, the query request needs to be stored locally at the client for subsequent comparison request marking. In this embodiment, the client adds different query requests to the stack in the order of the sending order for storage. The stack has a "first-in-last-out" feature, with the earliest query request sent being stored at the bottom of the stack and the latest query request sent being stored at the top of the stack. By utilizing the characteristic, when the request mark is compared, the client directly reads the content in the stack top, and the query request sent at the last time can be obtained.

205. And receiving the query response returned by the server.

For a single client, the request mark in each query request can be guaranteed not to be repeated through the use of parameters such as pseudo-random numbers, MD5 values and the like. However, the server interacts with a large number of clients, and the process of generating request tags among the clients is independent, so that it cannot be ensured that the request tags in the query requests of different clients are not repeated. In this embodiment, it is not necessary to ensure that request tags generated by different clients are different, and the server does not need to distinguish the request tags of different clients, or even pay attention to specific contents of the request tags, and only needs to add the request tag analyzed from the query request "as is" to the query response corresponding to the query request.

206. And judging whether the received request mark is the same as the request mark carried by the query request stored at the top of the local stack.

The query response return order may be disturbed due to network latency or server load conditions. The client does not need to determine which query request the received query response corresponds to. Therefore, when receiving the query response each time, the client reads the stack top content of the stack once to obtain the last sent query request, and analyzes the corresponding request mark from the query request. The token is then compared to the parsed request token in the query response. If the two are the same, it means that the received query response corresponds to the last sent query request, step 207 is executed to output the query data in the query response; if the two are different, it indicates that the received query response is the query response corresponding to the previous query request, and since the query data corresponding to the last query operation is expected by the user at this time, and it has no meaning to output the query data of the previous query operation, the client executes step 208 to discard the query data in the query response.

207. If the judgment result is yes, outputting the query data.

The output described in this embodiment includes displaying the data information in different forms through different types of peripherals, and in practical applications, the client can output images through a display or output audio through a speaker. For a more common image output mode, the client may display the query data in a browser page, or in an APP window, or in a specific database query interface. The present embodiment does not limit the manner of outputting the query data and the type of the peripheral.

208. If the judgment result is negative, the query data are discarded.

Further, considering that the user sometimes needs to check the query data of some previous query operations, in order to improve the problem of incomplete query result feedback caused by discarding the previous query data, as a replacement of step 208, this embodiment may further cache the query result corresponding to the previous query operation for subsequent election to output and display. Specifically, after the step 206 is executed, if the request tag comparison is different, the client sequentially reads the remaining query requests stored in the stack, and parses the request tag in each query request to compare the request tag with the request tag in the query response. Since the request tag in the query response is generated by the client when sending the query request, the query request containing the request tag can be found in the stack. And when the corresponding query request is found, the client takes the query data in the query response as historical query data, and performs correlation output with the attribute information of the found query request. The attribute information is mainly used for distinguishing query operations by users, and may be but not limited to query conditions in a query request, such as a URL or a query field. And displaying the attribute information and the query data in a list in a specific window/interface so that the user can conveniently view the query result of the past query operation.

In a final implementation of this embodiment, if the alternative of step 208 is not used, then the stack save query request may not be used when step 204 is performed. Because the backtracking of the previous query request is not needed, the client does not need to store all the query requests, and only needs to store the last query request. Therefore, in the implementation manner, the client only needs to open up a small cache space capable of storing one query request. After sending a new query request, the client stores a subsequent query request in the storage space, and replaces an original stored prior query request. Because the client only needs to store one query request at any time, the implementation mode can reduce the occupation degree of the cache, simultaneously can save the complex logic of cleaning the cache, and can greatly optimize the memory use of the client.

Further, as an implementation of the method shown in fig. 1 or fig. 2, another embodiment of the present invention further provides a device for querying data. The present apparatus embodiment corresponds to the foregoing method embodiment, and can implement all the contents in the foregoing method embodiment. For convenience of reading, the present apparatus embodiment only performs a summary description on the contents in the foregoing method embodiments, and details in the method embodiments are not repeated. As shown in fig. 3, the apparatus includes: a generating unit 31, a transmitting unit 32, a receiving unit 33, a judging unit 34, and an output unit 35. Wherein,

a generating unit 31, configured to generate a non-repeating request tag for a query request to be sent;

a sending unit 32, configured to send an inquiry request carrying a request tag to a server;

the receiving unit 33 is configured to receive a query response returned by the server, where the query response carries query data and a request tag carried by a query request corresponding to the query response;

a judging unit 34, configured to judge whether the received request flag is the same as a request flag carried in the last query request sent;

and an output unit 35, configured to output the query data when the determination result is yes.

Further, as shown in fig. 4, the generating unit 31 includes:

a first generation module 311 for generating a pseudo random number by a pseudo random number generation function;

a second generating module 312, configured to perform information summarization algorithm MD5 calculation on the query condition in the query request, and generate an MD5 value;

a third generating module 313, configured to generate a timestamp according to the time generated by the query request.

Further, the first generating module 311 is configured to: and when the request mark is a pseudo-random number, replacing the seed value according to the preset generation times.

Further, as shown in fig. 4, the apparatus further includes:

the adding unit 36 is configured to add the sent query request to the local stack before receiving the query response returned by the server;

the determining unit 34 is configured to determine whether the received request flag is the same as a request flag carried by the query request stored at the top of the local stack.

Further, as shown in fig. 4, the apparatus further includes:

a search unit 37, configured to search, when the determination result is negative, a query request corresponding to the received request tag;

and the output unit 35 is configured to output the query data as historical query data in association with the found attribute information of the query request.

The data query device comprises a processor and a memory, wherein the generating unit 31, the sending unit 32, the receiving unit 33, the judging unit 34, the output unit 35 and the like are stored in the memory as program units, and the processor executes the program units stored in the memory to realize corresponding functions.

The processor comprises a kernel, and the kernel calls the corresponding program unit from the memory. The kernel can be set to be one or more, and the client is ensured to directly output the query result corresponding to the finally initiated query request by adjusting the kernel parameters.

The memory may include volatile memory in a computer readable medium, Random Access Memory (RAM) and/or nonvolatile memory such as Read Only Memory (ROM) or flash memory (flash RAM), and the memory includes at least one memory chip.

The present application further provides a computer program product adapted to perform program code for initializing the following method steps when executed on a data processing device: generating a non-repeated request mark for a query request to be sent; sending a query request carrying a request mark to a server; receiving a query response returned by the server, wherein the query response carries query data and a request mark carried by a query request corresponding to the query response; judging whether the received request mark is the same as the request mark carried by the last sent query request; if the judgment result is yes, outputting the query data.

Further, as an implementation of the method shown in fig. 1 or fig. 2, another embodiment of the present invention further provides a system for querying data. The system embodiment corresponds to the method embodiment, and can realize all the contents in the method embodiment. For convenience of reading, the embodiments of the present system only schematically describe the contents of the foregoing method embodiments, and details of the method embodiments are not described in detail. As shown in fig. 5, the system includes: a client 51 and a server 52, wherein the client 51 comprises the device shown in fig. 3 or fig. 4 or is independent of the device but has a data interaction relationship with the device to realize the full functions of the device. Specifically, the method comprises the following steps:

the client 51 is configured to generate a non-repetitive request tag for a query request to be sent, and send the query request carrying the request tag to the server 52;

the server 52 is configured to perform data query in response to the query request, analyze the query request to obtain a request tag, add the request tag and query data obtained by data query to a query response corresponding to the query request, and return the query response to the client 51;

the client 51 is further configured to receive a query response returned by the server 52, determine whether the received request flag is the same as the request flag carried in the query request sent last time, and if the determination result is yes, output query data.

The device and the system for data query provided by the embodiment of the invention can add a unique request mark in the query request sent to the server, and the server adds the request mark in the query response corresponding to the query request and returns the query response to the client. When receiving the inquiry response, the client compares the request mark in the inquiry response with the request mark in the last sent inquiry request. If the two request marks are the same, the received query response is proved to be the query response corresponding to the last query request, and the client outputs the query result in the query response. Compared with the prior art, the embodiment of the invention can enable the client to directly output the query result corresponding to the last query operation executed by the user, thereby ensuring the reality and effectiveness of the latest query operation of the user.

As will be appreciated by one skilled in the art, embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). The memory is an example of a computer-readable medium.

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

The above are merely examples of the present application and are not intended to limit the present application. Various modifications and changes may occur to those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.

Claims

1. A method of data querying, the method comprising:

generating a non-repeated request mark for a query request to be sent;

sending a query request carrying the request mark to a server;

and if the judgment result is yes, outputting the query data.

2. The method of claim 1, wherein generating non-repeating request tags for query requests to be sent comprises:

generating a pseudo-random number by a pseudo-random number generation function; or,

performing information summarization algorithm MD5 calculation on the query conditions in the query request to generate an MD5 value; or,

and generating a time stamp according to the time generated by the query request.

3. The method of claim 2, wherein if the request flag is a pseudo-random number, the method further comprises:

and replacing the seed value according to the preset generation times.

4. The method according to claim 1, wherein before said receiving the query response returned by the server, the method further comprises:

adding the sent query request into a local stack;

the determining whether the received request flag is the same as the request flag carried by the last query request includes:

and judging whether the received request mark is the same as the request mark carried by the query request stored at the top of the local stack.

5. The method according to any one of claims 1 to 4, wherein if the determination result is negative, the method further comprises:

searching a query request corresponding to the received request mark;

and taking the query data as historical query data, and performing correlation output on the historical query data and the found attribute information of the query request.

6. An apparatus for data query, the apparatus comprising:

a sending unit, configured to send a query request carrying the request tag to a server;

a receiving unit, configured to receive a query response returned by the server, where the query response carries query data and a request tag carried by a query request corresponding to the query response;

7. The apparatus of claim 6, wherein the generating unit comprises:

a first generation module for generating a pseudo random number by a pseudo random number generation function;

the second generation module is used for calculating the information abstract algorithm MD5 of the query conditions in the query request and generating an MD5 value;

and the third generation module is used for generating a time stamp according to the time generated by the query request.

8. The apparatus of claim 6, further comprising:

the joining unit is used for joining the sent query request into a local stack before receiving the query response returned by the server;

and the judging unit is used for judging whether the received request mark is the same as the request mark carried by the query request stored at the top of the local stack.

9. The apparatus of any one of claims 6 to 8, further comprising:

the searching unit is used for searching the query request corresponding to the received request mark when the judging result is negative;

and the output unit is used for performing correlation output on the query data serving as historical query data and the searched attribute information of the query request.

10. The system for data query is characterized by comprising a client and a server;

the client is used for generating a non-repeated request mark for a query request to be sent and sending the query request carrying the request mark to the server;

the server is used for responding to the query request to perform data query, analyzing the query request to obtain the request mark, adding the request mark and query data obtained by data query into a query response corresponding to the query request, and returning the query response to the client;

and the client is also used for receiving the query response returned by the server, judging whether the received request mark is the same as the request mark carried by the last query request sent, and if so, outputting the query data.

11. A storage medium, comprising a stored program, wherein the program, when executed, controls an apparatus in which the storage medium is located to perform the method of querying data according to any one of claims 1 to 5.

12. A processor, characterized in that the processor is configured to run a program, wherein the program when running performs the method of data query of any one of claims 1 to 5.