CN112115149A

CN112115149A - Method and device for providing data

Info

Publication number: CN112115149A
Application number: CN201910536132.9A
Authority: CN
Inventors: 李珂
Original assignee: Beijing Jingdong Century Trading Co Ltd; Beijing Jingdong Shangke Information Technology Co Ltd
Current assignee: Beijing Jingdong Century Trading Co Ltd; Beijing Jingdong Shangke Information Technology Co Ltd
Priority date: 2019-06-20
Filing date: 2019-06-20
Publication date: 2020-12-22

Abstract

The invention discloses a method and a device for providing data, and relates to the technical field of computers. One embodiment of the method comprises: periodically probing the server cluster; after receiving a data request of a front end, judging whether a server which is detected last time is normal or not, if so, sending the data request to the server to acquire data; if the current period is abnormal, judging whether an undetected server exists in the current period, if so, sending a data request to an undetected target server, and acquiring data from the target server under the current normal condition of the target server; otherwise, acquiring data from the standby data; the acquired data is provided to the front end. The implementation mode can automatically search for the normal server, reduces manual operation, reduces front-end and back-end coupling, reduces the dependence of front-end development on the server, and improves the front-end development efficiency.

Description

Method and device for providing data

Technical Field

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

Background

With the richness of Web (internet) application functions, in the current internet software development mode, the division of labor of each software developer is more and more clear, and a typical division of labor mode mainly comprises the following steps: server-side development (i.e., back-end development) and client-side development (i.e., front-end development). The working mode enables the front-end and back-end coupling degree to be high, the front-end development depends on the stability of the server seriously, in the development process, when the server is down or the back-end development releases the server for a long time, the working process of the front-end development can be influenced by different degrees, and meanwhile, the communication cost of the front-end development and the back-end development is high, so that the development efficiency is reduced.

The existing scheme mainly comprises the step of manually switching a request server or manually creating a JSON (JS object notation) file to generate MOCK data (simulation background data) so as to ensure data required by front-end development. The manual switching request server cannot ensure that the switched server can provide normal service, and uncertainty exists; and the synchronization is required to be ensured when the JSON file is manually created to generate test data, namely the JSON file is required to be updated immediately when the JSON file is required to be synchronized with a data structure returned by the server. In addition, the manual switching request server and the manual JSON file creation have the defects of frequent operation and low efficiency.

In the process of implementing the invention, the inventor finds that at least the following problems exist in the prior art:

the front-end and back-end coupling degree is high, the front-end development seriously depends on the stability of a server, the uncertainty is large, the manual operation is frequent, and the front-end development efficiency is low.

Disclosure of Invention

In view of this, embodiments of the present invention provide a method and an apparatus for providing data, which can automatically find a server capable of normal service when the server is down or the backend development is released for a long time, reduce manual operations, and provide reliable backup data, so that the front-end and backend coupling is reduced, thereby reducing the dependence of the front-end development on the server, not affecting the work process of the front-end development, and the backup data can be automatically updated, which gets rid of the inefficient mode of manually creating JSON file MOCK data, and improves the front-end development efficiency.

To achieve the above object, according to an aspect of an embodiment of the present invention, there is provided a method of providing data.

A method of providing data, comprising: periodically probing the server cluster; after receiving a data request of a front end, judging whether a server which is detected last time is normal, wherein: if the server detected last time is normal, sending the data request to the server to acquire data corresponding to a request rule of the data request, wherein the request rule is a set of request parameters; if the server detected last time is abnormal, judging whether an undetected server exists in the current period, if so, sending the data request to an undetected target server, and acquiring data corresponding to the request rule of the data request from the target server under the condition that the target server is normal currently; otherwise, acquiring data corresponding to the request rule of the data request from standby data, wherein the standby data is acquired from a normal server and stored in a database; providing the acquired data to the front end.

Optionally, the method further comprises: and in the case that the server detected last time is abnormal and no undetected server exists in the current period, or in the case that the target server is abnormal currently, adding the request rule of the data request to a queue to be requested so as to request data corresponding to the request rule of the data request subsequently when a normal server exists in the server cluster.

Optionally, when there is a normal server in the server cluster subsequently, according to the sequence of the number of times of requests corresponding to each request rule in the queue to be requested from the maximum to the minimum, data corresponding to each request rule is requested from the normal server in sequence.

Optionally, the method further comprises: intercepting data corresponding to the request rule of the data request acquired from the server or the target server which is detected last time, and updating the data corresponding to the request rule of the data request in the standby data according to the intercepted data; and, after subsequently requesting data corresponding to the request rule of the data request when there is a normal server in the server cluster, the method further includes: and updating data corresponding to the request rule of the data request in the standby data according to the requested data.

Optionally, the step of updating data corresponding to the request rule of the data request in the backup data includes: judging whether a request rule of the data request exists in the database; if yes, comparing whether the data corresponding to the request rule of the data request in the returned data and the standby data are consistent or not, and if yes, not executing updating; if the two are not consistent, updating data corresponding to the request rule of the data request in the standby data into a union of the two, wherein the returned data is the requested data or the intercepted data; and if the data does not exist, storing the return data into the database to serve as the data corresponding to the request rule of the data request in the standby data.

Optionally, detecting whether a normal server exists in the server cluster through an interface detection service, wherein the interface detection service is built through node.

According to another aspect of the embodiments of the present invention, there is provided an apparatus for providing data.

An apparatus for providing data, comprising: the server detection module is used for periodically detecting the server cluster; the data acquisition module is used for judging whether the server which is detected last time is normal after receiving the data request of the front end, wherein: if the server detected last time is normal, sending the data request to the server to acquire data corresponding to a request rule of the data request, wherein the request rule is a set of request parameters; if the server detected last time is abnormal, judging whether an undetected server exists in the current period, if so, sending the data request to an undetected target server, and acquiring data corresponding to the request rule of the data request from the target server under the condition that the target server is normal currently; otherwise, acquiring data corresponding to the request rule of the data request from standby data, wherein the standby data is acquired from a normal server and stored in a database; and the data providing module is used for providing the acquired data to the front end.

Optionally, the data obtaining module is further configured to: and in the case that the server detected last time is abnormal and no undetected server exists in the current period, or in the case that the target server is abnormal currently, adding the request rule of the data request to a queue to be requested so as to request data corresponding to the request rule of the data request subsequently when a normal server exists in the server cluster.

Optionally, the data obtaining module is further configured to, when there is a normal server in the server cluster subsequently, sequentially request the normal server for data corresponding to each request rule according to a sequence of a number of request times corresponding to each request rule in the queue to be requested, which is from a large number to a small number.

Optionally, the method further comprises: the data acquisition module is used for acquiring data corresponding to a request rule of the data request from the server which is detected last time or the target server; the data updating module is used for updating data corresponding to the request rule of the data request in the standby data according to the intercepted data, or updating the data corresponding to the request rule of the data request in the standby data according to the requested data after requesting the data corresponding to the request rule of the data request when a normal server exists in a server cluster in the follow-up process.

Optionally, the data update module is further configured to: judging whether a request rule of the data request exists in the database; if yes, comparing whether the data corresponding to the request rule of the data request in the returned data and the standby data are consistent or not, and if yes, not executing updating; if the two are not consistent, updating data corresponding to the request rule of the data request in the standby data into a union of the two, wherein the returned data is the requested data or the intercepted data; and if the data does not exist, storing the return data into the database to serve as the data corresponding to the request rule of the data request in the standby data.

Optionally, the server detection module detects whether a normal server exists in the server cluster through an interface detection service, where the interface detection service is built by node.

According to yet another aspect of an embodiment of the present invention, an electronic device is provided.

An electronic device, comprising: one or more processors; a memory for storing one or more programs which, when executed by the one or more processors, cause the one or more processors to implement the method of providing data of the present invention.

According to yet another aspect of an embodiment of the present invention, a computer-readable medium is provided.

A computer-readable medium, on which a computer program is stored which, when being executed by a processor, carries out the method of providing data of the invention.

One embodiment of the above invention has the following advantages or benefits: periodically probing the server cluster; after receiving a data request of a front end, judging whether a server which is detected last time is normal, wherein: if the server detected last time is normal, sending a data request to the server to acquire data corresponding to a request rule of the data request, wherein the request rule is a set of request parameters; if the server detected last time is abnormal, judging whether an undetected server exists in the current period, if so, sending the data request to an undetected target server, and acquiring data corresponding to the request rule of the data request from the target server under the condition that the target server is normal currently; otherwise, acquiring data corresponding to the request rule of the data request from the standby data, wherein the standby data is acquired from the normal server and stored in the database; the acquired data is provided to the front end. The method has the advantages that when the server is down or the back-end development is released for a long time, the server capable of normally serving is automatically searched, manual operation is reduced, reliable standby data can be provided, front-end and back-end coupling is reduced, dependence of the front-end development on the server is reduced, the working process of the front-end development is not affected, the standby data can be automatically updated, the low-efficiency mode of manually creating JSON file MOCK data is avoided, and the front-end development efficiency is improved.

Further effects of the above-mentioned non-conventional alternatives will be described below in connection with the embodiments.

Drawings

The drawings are included to provide a better understanding of the invention and are not to be construed as unduly limiting the invention. Wherein:

FIG. 1 is a schematic main flow diagram of a method of providing data according to an embodiment of the invention;

FIG. 2 is a schematic diagram of system interaction, according to one embodiment of the present invention;

FIG. 3 is an interface probe service workflow diagram according to one embodiment of the invention;

FIG. 4 is a flow diagram of IndexDB bibliography service work flow, according to one embodiment of the invention;

FIG. 5 is a schematic diagram of the main blocks of an apparatus for providing data according to an embodiment of the present invention;

FIG. 6 is an exemplary system architecture diagram in which embodiments of the present invention may be employed;

fig. 7 is a schematic block diagram of a computer system suitable for use in implementing a terminal device or server of an embodiment of the invention.

Detailed Description

Exemplary embodiments of the present invention are described below with reference to the accompanying drawings, in which various details of embodiments of the invention are included to assist understanding, and which are to be considered as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the invention. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.

As will be appreciated by one skilled in the art, embodiments of the present invention may be embodied as a system, apparatus, device, method, or computer program product. Accordingly, the present disclosure may be embodied in the form of: entirely hardware, entirely software (including firmware, resident software, micro-code, etc.), or a combination of hardware and software.

Fig. 1 is a schematic main flow diagram of a method of providing data according to an embodiment of the present invention.

As shown in fig. 1, the main process of the method for providing data according to the embodiment of the present invention includes S101 to S105.

S101: periodically probing the server clusters.

And detecting whether a normal server exists in the server cluster through the interface detection service, wherein the interface detection service is built through node. Js is a JavaScript running environment based on Chrome V8 engine (a JavaScript (an transliterated scripting language) engine), is used for conveniently building network or local application with high response speed and easy expansion, is light and efficient by using an event-driven and non-blocking I/O (input/output) model, and is very suitable for running data-intensive real-time application on distributed equipment.

Probing a server cluster refers to heuristically sending a data request to a server in the server cluster to determine whether there is a normal server in the server cluster that can provide the requested data, where the data request may be a real front-end data request or a simulated front-end data request.

The data request may be sent once at set time intervals. And after the current period is finished and the set time interval is passed, the detection of the next period is started.

The normal server, that is, the server is normal, means that the server can normally serve, that is, can provide data requested by the front end, specifically, if the server interface returns to normal, and the interface returns data corresponding to the data request, the server is a normal server. Accordingly, a server exception refers to a server that is not normally serviced, i.e., is not able to provide data requested by the front end, and in particular, if the server interface returns an exception, e.g., does not return data or returns some value to indicate an exception.

S102: after receiving a data request of a front end, judging whether the server which is detected last time is normal.

If the last detected server is normal, S103 is performed. If the server abnormality is detected last time, S104 is performed.

The received data request of the front end is, for example, a data request currently issued by the front end page.

S103: and sending the data request of the front end to the server which is detected last time to acquire data corresponding to the request rule of the data request.

A request rule is a set of request parameters.

S104: judging whether an undetected server exists in the current period, if so, sending the data request of the front end to an undetected target server, and acquiring data corresponding to the request rule of the data request from the target server under the condition that the target server is normal currently; otherwise, acquiring data corresponding to the request rule of the data request from the standby data.

The standby data is obtained from the normal server and stored in the database.

The database of embodiments of the present invention may be IndexDB (a database that holds structured data in a browser), MySQL (a relational database management system), or other database. IndexDB is a JavaScript-based object-oriented transactional database system. It uses a fixed list, allowing storage and retrieval of key-indexed objects; any object supported by structured clone algorithm may be stored. The method is used for storing a large amount of structured data by a client, and high-performance search of the data is realized by using an index.

Taking the database as IndexDB for example, the backup data is a set of data corresponding to each request rule stored in IndexDB.

And in the case that the server detected last time is abnormal and no undetected server exists in the current period, or in the case that the target server is abnormal currently, adding the request rule of the data request to a queue to be requested so as to request data corresponding to the request rule of the data request when a normal server exists in the server cluster.

And when a normal server exists in the server cluster, sequentially requesting data corresponding to each request rule from the normal server according to the sequence of the request times corresponding to each request rule in the queue to be requested from a large number to a small number.

S105: the acquired data is provided to the front end.

The acquired data is data acquired from the server, the target server, or the backup data that was last detected.

The data corresponding to the request rule of the data request, which is acquired from the server or the target server which is detected last time, can be intercepted, and the data corresponding to the request rule of the data request in the standby data can be updated according to the intercepted data.

In addition, after requesting the data corresponding to the request rule of the data request when a normal server exists in the server cluster, the data corresponding to the request rule of the data request in the backup data can be updated according to the requested data.

The step of updating the data corresponding to the request rule of the data request in the standby data may specifically include: judging whether a request rule of the data request exists in a database;

if yes, comparing whether the data corresponding to the request rule of the data request in the returned data and the standby data are consistent or not, and if yes, not executing updating; if the two are not consistent, updating the data corresponding to the request rule of the data request in the standby data into a union of the two, wherein the returned data refers to the requested data or the intercepted data;

if the data does not exist, the return data is stored in the database to be used as the data corresponding to the request rule of the data request in the standby data.

It should be noted that, the present invention may create a server interface detection node in the local environment of the client, or may create an interface detection service on other devices outside the client, where, in the case of creating the interface detection service locally at the client, the database may adopt an IndexDB (IndexDB for short); in the case of creating an interface probe service on another device, the database employs a database other than IndexDB, such as MySQL.

In the following, taking an example of creating an interface probe service locally at a client and using IndexDB as a database, the method for providing data according to the embodiment of the present invention is described in detail. In this embodiment, a server interface detection node. js service (interface detection service for short) is created in the local environment of the client, and a timing task is generated to detect whether a normal server exists in the server cluster according to a set time interval, for example, the server in the server cluster is detected every 60s (seconds). Specifically, after the interface detection service is started, an Ajax request (denoted as request 1) is sent to a currently detected server (denoted as a), and if the interface of the server a returns an exception, namely the request 1 is abnormal, data is not acquired from the server a; if the server a interface returns to normal, i.e. request 1 is normal, the data is acquired from server a. When data is acquired, the data is acquired in a rule matching mode, namely: data corresponding to (matching) the request rule of request 1, which is a set of request parameters of the Ajax request, is obtained.

The Ajax request may be a data request received from a front-end page or a data request of a front-end page emulated by an interface probe service. Ajax, asynchronous JavaScript and XML (extensible markup language), refers to a web page development technology for creating an interactive web page application without reloading the entire web page, and Ajax can implement asynchronous update of a web page by exchanging a small amount of data with a server in the background, which means that a certain part of a web page can be updated without reloading the entire web page.

Under the condition that the server a interface returns an exception, adding the request rule of the request 1 to a queue to be requested of the IndexDB bibliographic bottom service, recording the request times of the request rule of the request 1, and processing the request times by the IndexDB bibliographic bottom service, wherein the method specifically comprises the following steps: and triggering the interface detection service to start a timing task, periodically detecting the server cluster, and processing each Ajax request in the queue to be requested according to the queue priority rule when a normal server exists in the server cluster subsequently so as to obtain data corresponding to each request rule in the queue to be requested. The queue priority rule specifies that data corresponding to a request rule with a large number of requests is preferentially fetched from a normal server when the server can provide normal service.

In addition, if the server a interface returns an exception, at the next Ajax request (referred to as request 2), the interface probe service will automatically attempt to switch to a server capable of providing normal service, for example, automatically switch to a server b that has not been probed in the current period. And if the interface of the server b returns to be normal, acquiring data corresponding to the request rule of the request 2 from the server b. And if the interface of the server b returns an exception, adding the request rule of the request 2 into a queue to be requested of the IndexDB bottom service, recording the request times of the request rule of the request 2, and processing by the IndexDB bottom service, wherein the processing mechanism of the IndexDB bottom service is introduced above and is not described again.

If the interface of the server a returns an exception and the server a is the last server detected in the current period, providing IndexDB bottom-of-pocket service when the next Ajax request (request 2) is performed, and recording the request times of each request rule in the period so as to capture the data corresponding to the request rule with the large request times preferentially when the server provides normal service. And, the IndexDB bibliography service currently obtains data corresponding to the request rules of request 2 from the browser IndexDB.

Data obtained from a normal server detected by the interface detection service and data captured (or called requested) by the IndexDB bottom-of-pocket service when the server is normal are synchronously updated into the standby data of the browser IndexDB. When updating the spare data of the browser IndexDB, whether to update may be determined according to the time of writing, the content of writing, and the like.

FIG. 2 is a schematic diagram of system interaction, according to one embodiment of the present invention. As shown in fig. 2, the front-end page (client) acquires real-time data from the server when the server is normal, acquires data from the backup data of the browser IndexDB through the IndexDB bibliography service when the server is abnormal, and updates the backup data in the browser IndexDB in real time when the server is normal. The rule matching in fig. 2 means that data matched with (or called corresponding to) the request rule of the data request needs to be acquired when the data is acquired, the priority queue is a queue to be requested of the IndexDB bottom service, the request rule in the queue has a priority, and the data corresponding to the request rule with a large number of requests is preferentially acquired.

FIG. 3 is an interface probe service workflow diagram according to one embodiment of the invention. Js, the main purpose is to detect whether the interface works normally and provide a credible request scheme. The interface probe service and the IndexDB bottom-of-pocket service are always active after startup. The front-end request in fig. 3 refers to a number of data requests that are continuously sent to the interface probe service, which are referred to as requests for short, and may be data requests received from a front-end page or data requests of a front-end page simulated by the interface probe service. The flow of fig. 3 is embodied by the process of the interface probe service handling the number of data requests, rather than for a single request. The flow of fig. 3 is explained in detail below.

Taking a certain request of the data requests as an example of the current request, the current request is sent to an interface detection service, the interface detection service forwards the request to a server for processing the request, and the server for processing the request is a server detected last time (and the server is normal) or a server detected last time (and the server is abnormal) and is a next undetected server. Judging whether a server processing the request is normal, if the server is normal, providing data corresponding to the request rule (short for rule) sent back by the server to a front-end page, and intercepting the data corresponding to the request rule to write the intercepted data into backup data for subsequent use, wherein if the backup data already contains the data corresponding to the request rule, it needs to be judged whether the backup data needs to be updated, and if the backup data needs to be updated, the backup data is updated according to the intercepted data, and specifically, the contents of the backup data are described in detail when the IndexDB bottom service is described in detail below.

If the server processing the request is abnormal, whether all the servers are detected or not is judged in the next request, if all the servers are detected, data corresponding to the request rule of the next request is obtained from the standby data, the request rule and the request frequency of the next request are recorded, and the IndexDB bottom-of-pocket service is used for processing the data. And when the next request is made, if all the servers are not detected, switching the servers to continue detecting when the next request is made.

Note that, even when the server of the present request is abnormal, the request rule and the number of requests of the present request need to be recorded so as to be handled by the IndexDB bibliography service.

The IndexDB bottom-in-pocket service triggers an interface probe service timing task at work, and probes the server every 60 seconds to determine whether any server can normally serve at the current time interval. And if so, sequentially processing each request in a queue to be requested of the IndexDB bottom-mounting service, and preferentially capturing data corresponding to the request rule with a large number of request times.

FIG. 4 is a diagram of IndexDB bibliographic service workflow according to one embodiment of the invention.

There are two modes of operation for the IndexDB bottom-in-pocket service: the front end requests a normal operating mode and the front end requests an abnormal operating mode. The front-end request is normal, namely that a normal server is currently in the server cluster, and the front-end request is abnormal, namely that no normal server is currently in the server cluster (all servers are abnormal). Wherein the content of the first and second substances,

in the normal operation mode of the front end request:

judging whether a request rule of a data request exists in the IndexDB, if not, writing data corresponding to the request rule acquired from the server into an IndexDB bottom-of-pocket service, and providing data for an abnormal request condition of the next request rule, wherein the abnormal request condition refers to the condition that a server interface of the requested data returns an abnormality, namely the server cannot normally service.

If yes, comparing whether the returned data of the request rule is consistent with the data of the request rule in the IndexDB, and if so, not updating the data of the request rule in the IndexDB; if not, the IndexDB bottom-of-pocket service is updated by taking the union of the two data sets (i.e., the return data for the request rule and the data for the request rule in IndexDB).

In the front-end request abnormal working mode:

the front-end request data is provided by the IndexDB bibliography service. And recording a request rule of each data request, writing the request rule into a queue to be requested in IndexDB bottom-of-pocket service, and capturing data of the queue to be requested by the timing task according to the priority of the queue when the service is normal, namely preferentially capturing data corresponding to the request rule with a large number of request times.

In fig. 4, the front-end request refers to a single data request, and determines whether the request is abnormal, that is, determines whether the server interface currently requested by the data request returns an abnormality. If the request is abnormal, writing the request rule (the rule for short) of the data request into a queue to be captured (namely a queue to be requested), and requesting data from a normal server according to the priority (referring to the queue priority) after the data is requested. If the request is not abnormal, determining whether the request rule exists in the IndexDB, and if the request rule exists in the IndexDB, determining whether data corresponding to the rule changes, specifically, determining whether intercepted data corresponding to the request rule (the intercepted data is currently acquired from the server) changes compared with the data corresponding to the rule in the IndexDB, and if the intercepted data changes, updating the data corresponding to the rule in the IndexDB, where the specific updating manner may be: updating the data corresponding to the rule in the IndexDB into a union of the data corresponding to the rule in the IndexDB and the intercepted data; if there is no change, the data corresponding to the rule in IndexDB does not need to be updated. If the request rule does not exist in the IndexDB, the data corresponding to the request rule is written into the IndexDB. The rule data in fig. 4 refers to the data corresponding to the request rule.

The embodiment of the invention stores the data acquired from the server under the normal condition of the server into the standby data, can add the corresponding data request to the queue to be requested under the abnormal condition of the server of the requested data, periodically detects the server in the server cluster to execute each data request in the queue to be requested, and updates the data corresponding to the request rule in the standby data after acquiring the data corresponding to the request rule from the server, thereby acquiring the data from the standby data under the abnormal condition of all the servers, reducing the dependence of front-end development on the server, ensuring that the development process of the front-end development is not influenced under the condition that the server is down or the back-end development is released for a long time, and greatly improving the development efficiency.

Fig. 5 is a schematic diagram of main blocks of an apparatus for providing data according to an embodiment of the present invention.

As shown in fig. 5, the apparatus 500 for providing data according to the embodiment of the present invention mainly includes: a server detection module 501, a data acquisition module 502 and a data providing module 503.

A server detection module 501, configured to periodically detect a server cluster. Specifically, whether a normal server exists in the server cluster can be detected through the interface detection service, and the interface detection service is built through node.

A data obtaining module 502, configured to determine whether the server detected last time is normal after receiving a data request from the front end, where:

if the server detected last time is normal, sending a data request to the server to acquire data corresponding to a request rule of the data request, wherein the request rule is a set of request parameters;

if the server detected last time is abnormal, judging whether an undetected server exists in the current period, if so, sending the data request to an undetected target server, and acquiring data corresponding to the request rule of the data request from the target server under the condition that the target server is normal currently; otherwise, acquiring data corresponding to the request rule of the data request from the standby data, wherein the standby data is acquired from the normal server and stored in the database.

The data acquisition module 502 is further configured to: and in the case that the server detected last time is abnormal and no undetected server exists in the current period, or in the case that the target server is abnormal currently, adding the request rule of the data request to the queue to be requested so as to request the data corresponding to the request rule of the data request when a normal server exists in the server cluster.

The data acquisition module 502 is further configured to: and when a normal server exists in the server cluster, sequentially requesting the normal server for the data corresponding to each request rule according to the sequence of the request times corresponding to each request rule in the queue to be requested from a large number to a small number.

A data providing module 503, configured to provide the acquired data to the front end.

The apparatus 500 for providing data may further include: the data acquisition module is used for acquiring data corresponding to a request rule of a data request from a server or a target server which is detected last time;

the data updating module is used for updating data corresponding to the request rule of the data request in the standby data according to the intercepted data, or updating the data corresponding to the request rule of the data request in the standby data according to the requested data after requesting the data corresponding to the request rule of the data request when a normal server exists in the server cluster in the follow-up process.

The data update module may be specifically configured to: judging whether a request rule of a data request exists in the database; if yes, comparing whether the data corresponding to the request rule of the data request in the returned data and the standby data are consistent or not, and if yes, not executing updating; if the two are not consistent, updating the data corresponding to the request rule of the data request in the standby data into a union of the two, wherein the returned data is the requested data or the intercepted data; if the data does not exist, the returned data is stored in the database and is used as the data corresponding to the request rule of the data request in the standby data.

In addition, the detailed implementation of the apparatus for providing data in the embodiment of the present invention has been described in detail in the above-described method for providing data, and therefore, the repeated content will not be described again.

Fig. 6 illustrates an exemplary system architecture 600 to which a method of providing data or an apparatus for providing data of an embodiment of the present invention may be applied.

As shown in fig. 6, the system architecture 600 may include

terminal devices

601, 602, 603, a network 604, and a server 605. The network 604 serves to provide a medium for communication links between the

terminal devices

601, 602, 603 and the server 605. Network 604 may include various types of connections, such as wire, wireless communication links, or fiber optic cables, to name a few.

A user may use the

terminal devices

601, 602, 603 to interact with the server 605 via the network 604 to receive or send messages or the like. The

terminal devices

601, 602, 603 may have installed thereon various communication client applications, such as shopping applications, web browser applications, search applications, instant messaging tools, mailbox clients, social platform software, etc. (by way of example only).

The

terminal devices

601, 602, 603 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop portable computers, desktop computers, and the like.

The server 605 may be a server providing various services, such as a background management server (for example only) providing support for shopping websites browsed by users using the

terminal devices

601, 602, 603. The backend management server may analyze and perform other processing on the received data such as the product information query request, and feed back a processing result (for example, product information — just an example) to the terminal device.

It should be noted that the method for providing data provided by the embodiment of the present invention is generally executed by the server 605, and accordingly, the apparatus for providing data is generally disposed in the server 605.

It should be understood that the number of terminal devices, networks, and servers in fig. 6 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.

Referring now to FIG. 7, shown is a block diagram of a computer system 700 suitable for use in implementing a terminal device or server of an embodiment of the present application. The terminal device or the server shown in fig. 7 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present application.

As shown in fig. 7, the computer system 700 includes a Central Processing Unit (CPU)701, which can perform various appropriate actions and processes in accordance with a program stored in a Read Only Memory (ROM)702 or a program loaded from a storage section 708 into a Random Access Memory (RAM) 703. In the RAM 703, various programs and data necessary for the operation of the system 700 are also stored. The CPU 701, the ROM 702, and the RAM 703 are connected to each other via a bus 704. An input/output (I/O) interface 705 is also connected to bus 704.

The following components are connected to the I/O interface 705: an input portion 706 including a keyboard, a mouse, and the like; an output section 707 including a display such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, and a speaker; a storage section 708 including a hard disk and the like; and a communication section 709 including a network interface card such as a LAN card, a modem, or the like. The communication section 709 performs communication processing via a network such as the internet. A drive 710 is also connected to the I/O interface 705 as needed. A removable medium 711 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 710 as necessary, so that a computer program read out therefrom is mounted into the storage section 708 as necessary.

In particular, according to the embodiments of the present disclosure, the processes described above with reference to the flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method illustrated in the flow chart. In such an embodiment, the computer program can be downloaded and installed from a network through the communication section 709, and/or installed from the removable medium 711. The computer program executes the above-described functions defined in the system of the present application when executed by the Central Processing Unit (CPU) 701.

It should be noted that the computer readable medium shown in the present invention can be a computer readable signal medium or a computer readable storage medium or any combination of the two. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present application, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In this application, however, a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, fiber optic cable, RF, etc., or any suitable combination of the foregoing.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The modules described in the embodiments of the present invention may be implemented by software or hardware. The described modules may also be provided in a processor, which may be described as: a processor comprises a server detection module, a data acquisition module and a data providing module. Where the names of these modules do not in some cases constitute a limitation of the module itself, for example, a server probe module may also be described as a "module for periodically probing a cluster of servers".

As another aspect, the present invention also provides a computer-readable medium that may be contained in the apparatus described in the above embodiments; or may be separate and not incorporated into the device. The computer readable medium carries one or more programs which, when executed by a device, cause the device to comprise: periodically probing the server cluster; after receiving a data request of a front end, judging whether a server which is detected last time is normal, wherein: if the server detected last time is normal, sending the data request to the server to acquire data corresponding to a request rule of the data request, wherein the request rule is a set of request parameters; if the server detected last time is abnormal, judging whether an undetected server exists in the current period, if so, sending the data request to an undetected target server, and acquiring data corresponding to the request rule of the data request from the target server under the condition that the target server is normal currently; otherwise, acquiring data corresponding to the request rule of the data request from standby data, wherein the standby data is acquired from a normal server and stored in a database; providing the acquired data to the front end.

According to the technical scheme of the embodiment of the invention, the server cluster is periodically detected; after receiving a data request of a front end, judging whether a server which is detected last time is normal, wherein: if the server detected last time is normal, sending a data request to the server to acquire data corresponding to a request rule of the data request, wherein the request rule is a set of request parameters; if the server detected last time is abnormal, judging whether an undetected server exists in the current period, if so, sending the data request to an undetected target server, and acquiring data corresponding to the request rule of the data request from the target server under the condition that the target server is normal currently; otherwise, acquiring data corresponding to the request rule of the data request from the standby data, wherein the standby data is acquired from the normal server and stored in the database; the acquired data is provided to the front end. The method has the advantages that when the server is down or the back-end development is released for a long time, the server capable of normally serving is automatically searched, manual operation is reduced, reliable standby data can be provided, front-end and back-end coupling is reduced, dependence of the front-end development on the server is reduced, the working process of the front-end development is not affected, the standby data can be automatically updated, the low-efficiency mode of manually creating JSON file MOCK data is avoided, and the front-end development efficiency is improved.

The above-described embodiments should not be construed as limiting the scope of the invention. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions can occur, depending on design requirements and other factors. Any modification, equivalent replacement, and improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A method of providing data, comprising:

periodically probing the server cluster;

after receiving a data request of a front end, judging whether a server which is detected last time is normal, wherein:

if the server detected last time is normal, sending the data request to the server to acquire data corresponding to a request rule of the data request, wherein the request rule is a set of request parameters;

if the server detected last time is abnormal, judging whether an undetected server exists in the current period, if so, sending the data request to an undetected target server, and acquiring data corresponding to the request rule of the data request from the target server under the condition that the target server is normal currently; otherwise, acquiring data corresponding to the request rule of the data request from standby data, wherein the standby data is acquired from a normal server and stored in a database;

providing the acquired data to the front end.

2. The method of claim 1, further comprising:

and in the case that the server detected last time is abnormal and no undetected server exists in the current period, or in the case that the target server is abnormal currently, adding the request rule of the data request to a queue to be requested so as to request data corresponding to the request rule of the data request subsequently when a normal server exists in the server cluster.

3. The method according to claim 2, wherein when there is a normal server in the server cluster subsequently, the normal server is sequentially requested for the data corresponding to each request rule according to the sequence of the number of times of requests corresponding to each request rule in the queue to be requested from the largest to the smallest.

4. The method of claim 2 or 3, further comprising: intercepting data corresponding to the request rule of the data request acquired from the server or the target server which is detected last time, and updating the data corresponding to the request rule of the data request in the standby data according to the intercepted data;

and the number of the first and second electrodes,

after subsequently requesting data corresponding to the request rule of the data request when a normal server exists in the server cluster, the method further includes:

and updating data corresponding to the request rule of the data request in the standby data according to the requested data.

5. The method of claim 4, wherein the step of updating the data corresponding to the request rule of the data request in the backup data comprises:

judging whether a request rule of the data request exists in the database;

if yes, comparing whether the data corresponding to the request rule of the data request in the returned data and the standby data are consistent or not, and if yes, not executing updating; if the two are not consistent, updating data corresponding to the request rule of the data request in the standby data into a union of the two, wherein the returned data is the requested data or the intercepted data;

and if the data does not exist, storing the return data into the database to serve as the data corresponding to the request rule of the data request in the standby data.

6. The method according to claim 1, characterized in that the presence of a normal server in the server cluster is detected by an interface probe service, which is built by node.

7. An apparatus for providing data, comprising:

the server detection module is used for periodically detecting the server cluster;

the data acquisition module is used for judging whether the server which is detected last time is normal after receiving the data request of the front end, wherein:

and the data providing module is used for providing the acquired data to the front end.

8. The apparatus of claim 7, wherein the data acquisition module is further configured to:

9. The apparatus according to claim 8, wherein the data obtaining module is further configured to, when there is a normal server in the server cluster subsequently, sequentially request the normal server for the data corresponding to each request rule according to a sequence of a number of request times corresponding to each request rule in the queue to be requested, the sequence being from a large number to a small number.

10. The apparatus of claim 8 or 9, further comprising: a data interception module and a data update module, wherein,

the data interception module is used for intercepting data which is acquired from the server which is detected last time or the target server and corresponds to the request rule of the data request;

the data updating module is used for updating data corresponding to the request rule of the data request in the standby data according to the intercepted data, or updating the data corresponding to the request rule of the data request in the standby data according to the requested data after requesting the data corresponding to the request rule of the data request when a normal server exists in a server cluster in the follow-up process.

11. The apparatus of claim 10, wherein the data update module is further configured to:

judging whether a request rule of the data request exists in the database;

12. The apparatus according to claim 7, wherein the server detection module detects whether there is a normal server in the server cluster through an interface detection service, and the interface detection service is built by node.

13. An electronic device, comprising:

one or more processors;

a memory for storing one or more programs,

the one or more programs, when executed by the one or more processors, cause the one or more processors to implement the method recited in any of claims 1-6.

14. A computer-readable medium, on which a computer program is stored, which, when being executed by a processor, carries out the method according to any one of claims 1-6.