A method and apparatus for providing data

Abstract

The application discloses a method and device for providing data, and relates to the technical field of computers. A specific implementation of the method comprises the following steps: periodically detecting a server cluster; after receiving a data request from a front end, determining whether the server detected last time is normal, if yes, sending the data request to the server to obtain data; if not, determining whether there is an undetected server in the current period, if yes, sending the data request to a target server, and obtaining data from the target server under the condition that the target server is normal; otherwise, obtaining data from a backup data; and providing the obtained data to the front end. The implementation can automatically find a normal server, reduces manual operation, reduces the coupling between the front end and the back end, reduces the dependence of front-end development on the server, and improves the front-end development efficiency.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method and apparatus for providing data. Background Technology

[0002] As Web (Internet) applications become increasingly feature-rich, the division of labor among software developers in current Internet software development models is becoming more and more clearly defined. A typical division of labor is between server-side development (i.e., backend development) and client-side development (i.e., frontend development). This work model results in a high degree of coupling between the frontend and backend, and frontend development heavily relies on server stability. During development, when the server crashes or the backend development team takes a long time to deploy to the server, the frontend development process will be affected to varying degrees. Furthermore, the high communication costs between frontend and backend development also reduce development efficiency.

[0003] Current solutions primarily rely on manually switching request servers or manually creating JSON (JavaScript Object Notation) files to generate mock data (simulating backend data) to ensure the data required for frontend development. However, manually switching request servers cannot guarantee that the switched server will provide normal service, introducing uncertainty. Manually creating JSON files to generate test data requires ensuring synchronization, meaning the data structure needs to be synchronized with the server's returned data, necessitating real-time updates to the JSON file. Furthermore, both manually switching request servers and manually creating JSON files suffer from frequent operations and low efficiency.

[0004] In the process of realizing this invention, the inventors discovered at least the following problems in the prior art:

[0005] The front-end and back-end are highly coupled, front-end development heavily relies on server stability, has high uncertainty, requires frequent manual intervention, and has low front-end development efficiency. Summary of the Invention

[0006] In view of this, embodiments of the present invention provide a method and apparatus for providing data, which can automatically find a server that can provide normal service when the server is down or the backend development takes a long time to release, reduce manual operation, and provide reliable backup data, thereby reducing the coupling between the front-end and back-end, thereby reducing the dependence of front-end development on the server, without affecting the front-end development process, and the backup data can be automatically updated, getting rid of the inefficient mode of manually creating JSON files and locking data, and improving the efficiency of front-end development.

[0007] To achieve the above objectives, according to one aspect of the present invention, a method for providing data is provided.

[0008] A method for providing data includes: periodically probing a server cluster; upon receiving a data request from a frontend, determining whether the most recently detected server is functioning correctly, wherein: if the most recently detected server is functioning correctly, the data request is sent to that server to obtain data corresponding to a request rule for the data request, the request rule being a set of request parameters; if the most recently detected server is abnormal, determining whether there are any undetected servers in the current period, and if so, sending the data request to an undetected target server, and if the target server is currently functioning correctly, obtaining data corresponding to the request rule for the data request from the target server; otherwise, obtaining data corresponding to the request rule for the data request from backup data, the backup data being data previously obtained from functioning servers and stored in a database; and providing the obtained data to the frontend.

[0009] Optionally, it also includes: if a server anomaly was detected in the most recent instance and there are no undetected servers in the current period, or if the target server is currently anomaly, adding the request rule of the data request to the pending request queue so that data corresponding to the request rule of the data request can be requested later when there are normal servers in the server cluster.

[0010] Optionally, when there are normal servers in the server cluster, the data corresponding to each request rule is requested from the normal server in descending order of the number of requests corresponding to each request rule in the queue to be requested.

[0011] Optionally, it further includes: intercepting data corresponding to the request rule of the data request obtained from the most recently detected server or the target server, and updating the data in the backup data corresponding to the request rule of the data request according to the intercepted data; and, after requesting data corresponding to the request rule of the data request when there is a normal server in the server cluster, it further includes: updating the data in the backup data corresponding to the request rule of the data request according to the requested data.

[0012] Optionally, the step of updating the data in the backup data corresponding to the request rule of the data request includes: determining whether the request rule of the data request exists in the database; if it exists, comparing whether the returned data and the data in the backup data corresponding to the request rule of the data request are consistent; if they are consistent, no update is performed; if they are inconsistent, updating the data in the backup data corresponding to the request rule of the data request to the union of the two, wherein the returned data is the requested data or the intercepted data; if it does not exist, storing the returned data in the database as the data in the backup data corresponding to the request rule of the data request.

[0013] Optionally, an interface detection service can be used to detect whether there are normal servers in the server cluster. The interface detection service is built using Node.js.

[0014] According to another aspect of the present invention, an apparatus for providing data is provided.

[0015] An apparatus for providing data includes: a server detection module for periodically detecting a server cluster; a data acquisition module for, upon receiving a data request from a front-end, determining whether the most recently detected server is functioning normally, wherein: if the most recently detected server is functioning normally, the data request is sent to that server to obtain data corresponding to a request rule of the data request, the request rule being a set of request parameters; if the most recently detected server is abnormal, determining whether there are any undetected servers in the current period, and if so, sending the data request to an undetected target server, and if the target server is currently functioning normally, obtaining data corresponding to the request rule of the data request from the target server; otherwise, obtaining data corresponding to the request rule of the data request from backup data, the backup data being data previously obtained from normal servers and stored in a database; and a data providing module for providing the acquired data to the front-end.

[0016] Optionally, the data acquisition module is further configured to: add the request rule of the data request to the pending request queue when a server anomaly was recently detected and there are no undetected servers in the current period, or when the target server is currently abnormal, so that data corresponding to the request rule of the data request can be requested later when there are normal servers in the server cluster.

[0017] Optionally, the data acquisition module is further configured to request data corresponding to each request rule from the normal server in the server cluster in descending order of the number of requests corresponding to each request rule in the queue to be requested when there is a normal server in the server cluster.

[0018] Optionally, it further includes: a data interception module and a data update module, wherein the data interception module is used to intercept data corresponding to the request rule of the data request obtained from the most recently detected server or the target server; the data update module is used to update the data in the backup data corresponding to the request rule of the data request according to the intercepted data, or after requesting data corresponding to the request rule of the data request when there is a normal server in the server cluster, update the data in the backup data corresponding to the request rule of the data request according to the requested data.

[0019] Optionally, the data update module is further configured to: determine whether the request rule of the data request exists in the database; if it exists, compare whether the returned data and the data in the backup data corresponding to the request rule of the data request are consistent; if they are consistent, no update is performed; if they are inconsistent, update the data in the backup data corresponding to the request rule of the data request to the union of the two, wherein the returned data is the requested data or the intercepted data; if it does not exist, store the returned data in the database as the data in the backup data corresponding to the request rule of the data request.

[0020] Optionally, the server detection module detects whether there are normal servers in the server cluster through an interface detection service, which is built using Node.js.

[0021] According to another aspect of the present invention, an electronic device is provided.

[0022] An electronic device includes: one or more processors; and a memory for storing one or more programs that, when executed by the one or more processors, cause the one or more processors to implement the method of providing data according to the present invention.

[0023] According to another aspect of the present invention, a computer-readable medium is provided.

[0024] A computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements the method of providing data according to the present invention.

[0025] One embodiment of the above invention has the following advantages or beneficial effects: It periodically probes the server cluster; after receiving a data request from the front end, it determines whether the most recently probed server is normal, wherein: if the most recently probed server is normal, the data request is sent to that server to obtain data corresponding to the request rule of the data request, the request rule being a set of request parameters; if the most recently probed server is abnormal, it determines whether there is an unprobeaged server in the current period; if so, the data request is sent to an unprobeaged target server, and if the target server is currently normal, data corresponding to the request rule of the data request is obtained from the target server; otherwise, data corresponding to the request rule of the data request is obtained from backup data, which is data previously obtained from normal servers and stored in a database; the obtained data is provided to the front end. This allows for automatic search for a server that can provide normal service when the server is down or when backend development takes a long time to deploy, reducing manual operation and providing reliable backup data. This reduces the coupling between the front end and back end, thereby reducing the front end's dependence on the server and not affecting the front end's development process. Furthermore, the backup data can be automatically updated, eliminating the inefficient mode of manually creating JSON files and locking data, thus improving front end development efficiency.

[0026] The further effects of the aforementioned unconventional alternative methods will be explained below in conjunction with specific implementation methods. Attached Figure Description

[0027] The accompanying drawings are provided to better understand the invention and are not intended to unduly limit the scope of the invention. Wherein:

[0028] Figure 1 This is a schematic diagram of the main flow of a method for providing data according to an embodiment of the present invention;

[0029] Figure 2 This is a schematic diagram of system interaction according to an embodiment of the present invention;

[0030] Figure 3 This is a flowchart of an interface detection service according to an embodiment of the present invention;

[0031] Figure 4 This is a flowchart of the IndexDB fallback service workflow according to an embodiment of the present invention;

[0032] Figure 5 This is a schematic diagram of the main modules of a data-providing device according to an embodiment of the present invention;

[0033] Figure 6 This is an exemplary system architecture diagram in which embodiments of the present invention can be applied;

[0034] Figure 7This is a schematic diagram of the structure of a computer system suitable for implementing terminal devices or servers of the present invention. Detailed Implementation

[0035] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of the present invention, including various details to aid understanding. These details should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0036] Those skilled in the art will recognize that embodiments of the present invention can be implemented as a system, apparatus, device, method, or computer program product. Therefore, this disclosure can be specifically implemented in the following forms: entirely hardware, entirely software (including firmware, resident software, microcode, etc.), or a combination of hardware and software.

[0037] Figure 1 This is a schematic diagram of the main flow of a method for providing data according to an embodiment of the present invention.

[0038] like Figure 1 As shown, the main process of the data provision method in this embodiment of the invention includes S101 to S105.

[0039] S101: Periodic probe server cluster.

[0040] An API probing service can be used to detect whether a normal server exists in the server cluster. This service is built using Node.js. Node.js is a JavaScript runtime environment based on the Chrome V8 engine (a JavaScript engine, an interpreted scripting language). It is used to easily build fast and scalable network or local applications. It uses an event-driven, non-blocking I / O (input / output) model, making it lightweight and efficient, and ideal for running data-intensive real-time applications on distributed devices.

[0041] Probing a server cluster refers to tentatively sending data requests to servers in a server cluster to determine whether there are any normal servers in the cluster that can provide the requested data. This data request can be a real front-end data request or a simulated front-end data request.

[0042] A data request can be sent at a set time interval. Each time all servers in the server cluster are probed, it constitutes a cycle. After the current cycle ends, the set time interval will be elapsed before the next cycle begins.

[0043] A normal server, meaning the server is functioning correctly, can provide the data requested by the frontend. Specifically, if the server interface returns the data corresponding to the data request, then the server is considered normal. Conversely, an abnormal server, meaning the server cannot provide the data requested by the frontend. Specifically, if the server interface returns an exception, such as not returning data or returning a value indicating an error, then the server is considered abnormal.

[0044] S102: After receiving a data request from the front end, determine whether the most recently detected server is functioning correctly.

[0045] If the most recently detected server is normal, proceed to step S103. If the most recently detected server is abnormal, proceed to step S104.

[0046] The received data request from the front end is, for example, the data request currently being sent by the front end page.

[0047] S103: Send the data request from the front end to the most recently detected server to obtain the data corresponding to the request rule of the data request.

[0048] A request rule is a collection of request parameters.

[0049] S104: Determine if there are any undetected servers in the current period. If so, send the front-end data request to an undetected target server and, if the target server is currently functioning normally, obtain the data corresponding to the request rule of the data request from the target server; otherwise, obtain the data corresponding to the request rule of the data request from the backup data.

[0050] The backup data is obtained from the normal server and stored in the database.

[0051] The database in this embodiment of the invention can be IndexDB (a database for storing structured data in a browser), MySQL (a relational database management system), or other databases. IndexDB is a JavaScript-based object-oriented transactional database system. It uses a fixed list, allowing the storage and retrieval of objects indexed by keys; it can store any object supported by the structured clone algorithm. It is used for client-side storage of large amounts of structured data, using indexes to achieve high-performance searching of that data.

[0052] Taking IndexDB as an example, the backup data is a collection of data corresponding to each request rule stored in IndexDB.

[0053] If a server anomaly was detected in the most recent instance and there are no undetected servers in the current period, or if the target server is currently anomaly, add the request rule for this data request to the pending request queue so that data corresponding to the request rule can be requested later when there are normal servers in the server cluster.

[0054] Subsequently, when there are normal servers in the server cluster, the data corresponding to each request rule is requested from the normal server in descending order of the number of requests for each request rule in the pending request queue.

[0055] S105: Provide the acquired data to the front end.

[0056] The data obtained is from the most recently detected server, the target server, or backup data.

[0057] Specifically, it can intercept data corresponding to the request rule of the data request obtained from the most recently detected server or target server, and update the data in the backup data corresponding to the request rule of the data request based on the intercepted data.

[0058] In addition, when a normal server in the server cluster requests data corresponding to the request rule of the data request, the data in the backup data corresponding to the request rule of the data request can be updated according to the requested data.

[0059] The steps for updating the data in the backup data that corresponds to the request rule of the data request may specifically include: determining whether the request rule of the data request exists in the database;

[0060] If they exist, compare whether the data in the returned data and the backup data that corresponds to the request rule of the data request is consistent. If they are consistent, no update is performed. If they are inconsistent, update the data in the backup data that corresponds to the request rule of the data request to the union of the two. Here, the returned data refers to the requested data or the intercepted data.

[0061] If it does not exist, the returned data will be stored in the database as backup data corresponding to the request rule of the data request.

[0062] It should be noted that this invention can create a server interface detection Node.js service (hereinafter referred to as the interface detection service) in the local environment of the client, or it can create an interface detection service on other devices outside the client. When creating the interface detection service locally on the client, the database can be the browser's IndexDB (hereinafter referred to as IndexDB); when creating the interface detection service on other devices, the database can be a database other than IndexDB, such as MySQL.

[0063] The following example illustrates the data provision method of this invention, using the creation of an interface probing service on the client's local environment with IndexDB as the database. This embodiment creates a server interface probing Node.js service (hereinafter referred to as the interface probing service) in the client's local environment, generating a scheduled task to probe the server cluster for the presence of a normal server at set time intervals, for example, probing the server cluster every 60 seconds. Specifically, after the interface probing service starts, it sends an Ajax request (referred to as request 1) to the currently probed server (denoted as 'a'). If server a's interface returns an exception (i.e., request 1 is abnormal), no data is obtained from server a; if server a's interface returns a normal response (i.e., request 1 is normal), data is obtained from server a. Data is obtained through rule matching, specifically: data corresponding to (matching) the request rule of request 1 is obtained. The request rule is a set of request parameters from the Ajax request.

[0064] Ajax requests can be data requests received from the front-end page or data requests simulated by the API probe service. Ajax, short for Asynchronous JavaScript and XML (Extensible Markup Language), is a web development technique that allows the creation of interactive web applications without reloading the entire webpage. By exchanging small amounts of data with the server in the background, Ajax enables asynchronous updates to webpages, meaning that parts of a webpage can be updated without reloading the entire page.

[0065] If server A returns an exception, the request rule for request 1 is added to the pending request queue of the IndexDB fallback service, and the number of requests for request rule 1 is recorded. The IndexDB fallback service then handles this by: triggering a scheduled task in the interface probing service to periodically probe the server cluster; and when a normal server is subsequently found in the cluster, processing each Ajax request in the pending request queue according to the queue priority rules to retrieve the data corresponding to each request rule. The queue priority rules stipulate that when a server can provide normal service, data corresponding to request rules with higher request counts is retrieved first from the normal server.

[0066] Additionally, if server A's interface returns an exception, the interface probing service will automatically attempt to switch to a server that can provide normal service in the next Ajax request (denoted as request 2), for example, automatically switching to server B, which has not been probed in the current period. If server B's interface returns normally, the data corresponding to the request rule for request 2 is retrieved from server B. If server B's interface returns an exception, the request rule for request 2 is added to the pending request queue of the IndexDB fallback service, and the number of requests for the request rule for request 2 is recorded. The IndexDB fallback service will then handle this, and its processing mechanism has been described above and will not be repeated here.

[0067] If server A returns an exception, and server A is already the last server probed in the current period, then in the next Ajax request (request 2), an IndexDB fallback service will be provided to record the request count of each request rule during this period. This allows the data corresponding to the request rules with the most requests to be fetched first when the server is providing normal service. Furthermore, the IndexDB fallback service will currently retrieve the data corresponding to the request rule of request 2 from the browser's IndexDB.

[0068] Data obtained from normal servers detected by the interface probing service, and data fetched (or requested) by the IndexDB fallback service when the server is normal, will be synchronously updated in the browser's IndexDB backup data. When updating the browser's IndexDB backup data, the update can be determined based on the write time, the content written, etc.

[0069] Figure 2 This is a schematic diagram of system interaction according to an embodiment of the present invention. Figure 2 As shown, when the server is functioning normally, the front-end page (client) obtains real-time data from the server. When the server is abnormal, it obtains data from the backup data in the browser's IndexDB through the IndexDB fallback service. Furthermore, when the server is functioning normally, the backup data in the browser's IndexDB is updated in real time. Figure 2 In-process rule matching refers to retrieving data that matches (or corresponds to) the request rule of the data request. The priority queue is the pending request queue of the IndexDB fallback service. The request rules in this queue have priorities, and the data corresponding to the request rule with the most requests is retrieved first.

[0070] Figure 3 This is a flowchart illustrating the workflow of an interface detection service according to an embodiment of the present invention. The interface detection service is built using Node.js, and its main purpose is to detect whether an interface is functioning correctly and to provide a reliable request scheme. The interface detection service and the IndexDB fallback service operate continuously after startup. Figure 3 A front-end request refers to a series of data requests continuously sent to the interface probing service, or simply a request. These requests can be data requests received from the front-end page or data requests from the front-end page simulated by the interface probing service. Figure 3 The process described here reflects how the interface probing service handles multiple data requests, rather than focusing on a single request. A detailed explanation follows. Figure 3 The process.

[0071] Taking one of the aforementioned data requests as an example, this request is sent to the interface probing service. The interface probing service forwards this request to the server that handles it. This server is either the server that was previously probed (and is functioning normally), or the next unprobing server after the server that was previously probed (and is malfunctioning). The system checks if the server handling the request is functioning normally. If it is, the system provides the front-end page with the data corresponding to the request rule (hereinafter referred to as the rule) returned by the server. Furthermore, it intercepts the data corresponding to the request rule and writes the intercepted data into the backup data for later use. It should be noted that if the backup data already contains data corresponding to the request rule, it needs to be determined whether the backup data needs to be updated. If an update is needed, the backup data is updated based on the intercepted data. This part will be explained in detail below when discussing the IndexDB fallback service.

[0072] If the server handling the request malfunctions, the next request will determine whether all servers have been probed. If all servers have been probed, the data corresponding to the request rules for the next request will be retrieved from the backup database, and the request rules and number of requests for the next request will be recorded. This will then be handled by the IndexDB fallback service. If not all servers have been probed in the next request, a server will be switched to continue probing.

[0073] It should be noted that in the event of a server malfunction during this request, the request rules and number of requests should also be recorded so that IndexDB's fallback service can handle the situation.

[0074] The IndexDB fallback service triggers a scheduled task for interface probing every 60 seconds to check if any servers are operational within the current time interval. If so, it processes all requests in the IndexDB fallback service's queue, prioritizing the data corresponding to the requests with the highest frequency.

[0075] Figure 4 This is a flowchart of the IndexDB fallback service workflow according to an embodiment of the present invention.

[0076] IndexDB's fallback service has two operating modes: a normal front-end request mode and a normal front-end request mode. A normal front-end request mode means that there are currently healthy servers in the server cluster, while a normal front-end request mode means that there are currently no healthy servers in the server cluster (all servers are abnormal).

[0077] In the normal working mode of frontend requests:

[0078] It checks whether the request rule for the data request exists in IndexDB. If it does not exist, it writes the data corresponding to the request rule obtained from the server into the IndexDB fallback service to provide data for the next abnormal request status of the request rule. An abnormal request status refers to the server interface of the requested data returning an exception, that is, the server cannot provide normal service.

[0079] If it exists, compare the returned data of the request rule with the data of the request rule in IndexDB to see if they are consistent. If they are consistent, there is no need to update the data of the request rule in IndexDB. If they are inconsistent, take the union of the two datasets (i.e., the returned data of the request rule and the data of the request rule in IndexDB) and update the IndexDB fallback service.

[0080] In the abnormal working mode of frontend requests:

[0081] The front-end request data is provided by the IndexDB fallback service. The request rules for each data request are recorded and written to the pending request queue in the IndexDB fallback service. When the service is running normally, a scheduled task retrieves data from the pending request queue based on queue priority, prioritizing data corresponding to request rules with the most frequent requests.

[0082] Figure 4A front-end request refers to a single data request. The process of determining if a request is abnormal involves checking if the server interface for that data request returns an error. If the request is abnormal, the request rule (hereinafter referred to as the rule) is written to the pending queue (i.e., the queue to be requested), and data is subsequently requested from normal servers according to priority (queue priority). If the request is normal, the process checks if the request rule exists in the IndexDB. If the request rule exists in the IndexDB, it checks if the data corresponding to that rule has changed. Specifically, it compares the intercepted data corresponding to the request rule (the intercepted data currently retrieved from the server) with the data corresponding to that rule in the IndexDB. If there is a change, the data corresponding to that rule in the IndexDB is updated. This update can be done by updating the data in the IndexDB to the union of the data corresponding to that rule in the IndexDB and the intercepted data. If there is no change, there is no need to update the data corresponding to that rule in the IndexDB. If the request rule does not exist in the IndexDB, the data corresponding to that request rule is written to the IndexDB. Figure 4 The rule data in the text refers to the data corresponding to the request rule.

[0083] This invention stores data obtained from the server under normal server conditions into backup data. In the event of a server malfunction for the requested data, the corresponding data request can be added to a pending request queue. Servers in the server cluster are periodically probed to execute data requests in the pending request queue. After obtaining data corresponding to the request rule from the server, the data corresponding to that request rule in the backup data is updated. Thus, even if all servers are malfunctioning, data can be obtained from the backup data. This reduces the dependence of front-end development on the server and ensures that the front-end development process is not affected when the server crashes or the back-end development takes a long time to deploy, greatly improving development efficiency.

[0084] Figure 5 This is a schematic diagram of the main modules of a data-providing device according to an embodiment of the present invention.

[0085] like Figure 5 As shown, the data providing device 500 of this embodiment mainly includes: a server detection module 501, a data acquisition module 502, and a data providing module 503.

[0086] Server detection module 501 is used to periodically probe the server cluster. Specifically, it can use an interface detection service to detect whether there are normal servers in the server cluster. The interface detection service is built using Node.js.

[0087] The data acquisition module 502 is used to determine whether the most recently detected server is functioning correctly after receiving a data request from the front end.

[0088] If the most recently detected server is normal, a data request is sent to that server to retrieve data corresponding to the request rule, which is a set of request parameters.

[0089] If the most recently detected server is abnormal, then determine if there is an undetected server in the current period. If so, send the data request to an undetected target server and, if the target server is currently normal, retrieve the data corresponding to the request rule of the data request from the target server; otherwise, retrieve the data corresponding to the request rule of the data request from the backup data, which is the data previously obtained from normal servers and stored in the database.

[0090] The data acquisition module 502 is further configured to: add the request rule of the data request to the pending request queue when the server anomaly was detected most recently and there are no undetected servers in the current period, or when the target server is currently anomaly, so that the data corresponding to the request rule of the data request can be requested later when there are normal servers in the server cluster.

[0091] The data acquisition module 502 is further configured to: when there is a normal server in the server cluster, request the data corresponding to each request rule from the normal server in descending order of the number of requests corresponding to each request rule in the queue to be requested.

[0092] The data providing module 503 is used to provide the acquired data to the front end.

[0093] The data providing device 500 may further include: a data interception module and a data update module, wherein the data interception module is used to intercept data corresponding to the request rules of the data request obtained from the most recently detected server or target server;

[0094] The data update module is used to update the data in the backup data that corresponds to the request rule of the data request based on the intercepted data, or to update the data in the backup data that corresponds to the request rule of the data request based on the requested data after a normal server in the server cluster requests the data that corresponds to the request rule of the data request.

[0095] The data update module can be specifically used to: determine whether the request rule for the data request exists in the database; if it exists, compare whether the data corresponding to the request rule in the returned data and the backup data are consistent; if they are consistent, no update is performed; if they are inconsistent, update the data corresponding to the request rule in the backup data to the union of the two, wherein the returned data is the data requested or intercepted; if it does not exist, store the returned data in the database as the data corresponding to the request rule in the backup data.

[0096] Furthermore, the specific implementation details of the data-providing device in the embodiments of the present invention have been described in detail in the data-providing method described above, so the details will not be repeated here.

[0097] Figure 6 An exemplary system architecture 600 is shown, in which a method or apparatus for providing data can be applied according to embodiments of the present invention.

[0098] like Figure 6 As shown, system architecture 600 may include terminal devices 601, 602, and 603, a network 604, and a server 605. Network 604 serves as the medium for providing communication links between terminal devices 601, 602, and 603 and server 605. Network 604 may include various connection types, such as wired or wireless communication links or fiber optic cables, etc.

[0099] Users can use terminal devices 601, 602, and 603 to interact with server 605 via network 604 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 601, 602, and 603, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).

[0100] Terminal devices 601, 602, and 603 can be various electronic devices with displays and web browsing capabilities, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0101] Server 605 can be a server that provides various services, such as a backend management server that supports shopping websites browsed by users using terminal devices 601, 602, and 603 (for example only). The backend management server can analyze and process data such as received product information query requests, and feed back the processing results (such as product information - for example only) to the terminal devices.

[0102] It should be noted that the data provision method provided in the embodiments of the present invention is generally executed by server 605, and correspondingly, the data provision device is generally located in server 605.

[0103] It should be understood that Figure 6 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0104] The following is for reference. Figure 7 It shows a schematic diagram of the structure of a computer system 700 suitable for implementing terminal devices or servers in the embodiments of this application. Figure 7 The terminal device or server shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0105] like Figure 7 As shown, the computer system 700 includes a central processing unit (CPU) 701, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 702 or programs loaded from storage section 708 into random access memory (RAM) 703. The RAM 703 also stores various programs and data required for the operation of the system 700. The CPU 701, ROM 702, and RAM 703 are interconnected via a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0106] The following components are connected to the I / O interface 705: an input section 706 including a keyboard, mouse, etc.; an output section 707 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 708 including a hard disk, etc.; and a communication section 709 including a network interface card such as a LAN card, modem, etc. 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 disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 710 as needed so that computer programs read from it can be installed into the storage section 708 as needed.

[0107] In particular, according to the embodiments disclosed in this invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 709, and / or installed from removable medium 711. When the computer program is executed by central processing unit (CPU) 701, it performs the functions defined above in the system of this application.

[0108] It should be noted that the computer-readable medium shown in this invention can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0109] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0110] The modules described in the embodiments of the present invention can be implemented in software or hardware. The described modules can also be housed in a processor; for example, a processor may be described as including a server detection module, a data acquisition module, and a data provision module. The names of these modules do not necessarily limit the module itself; for example, a server detection module may also be described as "a module for periodically detecting server clusters."

[0111] In another aspect, the present invention also provides a computer-readable medium, which may be included in the device described in the above embodiments; or it may exist independently and not assembled into the device. The computer-readable medium carries one or more programs, which, when executed by the device, cause the device to include: periodically probing a server cluster; upon receiving a data request from the front end, determining whether the most recently detected server is normal, wherein: if the most recently detected server is normal, the data request is sent to that server to obtain data corresponding to a request rule for the data request, the request rule being a set of request parameters; if the most recently detected server is abnormal, determining whether there is an undetected server in the current period, if so, sending the data request to an undetected target server, and if the target server is currently normal, obtaining data corresponding to the request rule for the data request from the target server; otherwise, obtaining data corresponding to the request rule for the data request from backup data, the backup data being data previously obtained from normal servers and stored in a database; and providing the obtained data to the front end.

[0112] According to the technical solution of this invention, the server cluster is periodically probed. After receiving a data request from the front end, it is determined whether the most recently probed server is normal. If the most recently probed server is normal, the data request is sent to that server to obtain data corresponding to the request rule of the data request, where the request rule is a set of request parameters. If the most recently probed server is abnormal, it is determined whether there is an unprobeaged server in the current period. If so, the data request is sent to an unprobeaged target server, and if the target server is currently normal, data corresponding to the request rule of the data request is obtained from the target server. Otherwise, data corresponding to the request rule of the data request is obtained from backup data, which is data previously obtained from normal servers and stored in a database. The obtained data is then provided to the front end. This method can automatically find a server that can provide normal service when the server is down or when backend development takes a long time to release, reducing manual operation and providing reliable backup data. This reduces the coupling between the front end and the back end, thereby reducing the front end's dependence on the server and not affecting the front end's work process. Furthermore, the backup data can be automatically updated, eliminating the inefficient mode of manually creating JSON files and locking data, thus improving the efficiency of front end development.

[0113] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can occur depending on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method of providing data, characterized by, The method comprises: periodically probing a server cluster; tentatively sending a data request to one server in the server cluster, and probing all servers in the server cluster once is one period; after receiving the data request from the front end, judging whether the last-probed server is normal, wherein: if the last-probed server is normal, sending the data request to the server to obtain data corresponding to the request rule of the data request, the request rule being a set of request parameters; if the last-probed server is abnormal, judging whether there is an unprobed server in the current period, if yes, sending the data request to a target server, and obtaining data corresponding to the request rule of the data request from the target server if the target server is normal; otherwise, obtaining data corresponding to the request rule of the data request from backup data, the backup data being data previously obtained from a normal server and saved in a database; providing the obtained data to the front end; the method further comprises probing whether there is a normal server in the server cluster through an interface created by a local client, and the database uses IndexDB.

2. The method of claim 1, wherein, Further comprising: in the case that the last-probed server is abnormal and there is no unprobed server in the current period, or in the case that the target server is abnormal, adding the request rule of the data request to a to-be-requested queue, so as to request data corresponding to the request rule of the data request from a normal server in the server cluster subsequently.

3. The method of claim 2, wherein, subsequently, when there is a normal server in the server cluster, requesting data corresponding to each request rule in the to-be-requested queue from the normal server in the order from more to less according to the request times of the request rules.

4. The method according to claim 2 or 3, characterized in that, Further comprising: intercepting data corresponding to the request rule of the data request obtained from the last-probed server or the target server, and updating data corresponding to the request rule of the data request in the backup data according to the intercepted data; and, after requesting data corresponding to the request rule of the data request from a normal server in the server cluster subsequently, further comprising: updating data corresponding to the request rule of the data request in the backup data according to the requested data.

5. The method of claim 4, wherein, The step of updating data corresponding to the request rule of the data request in the backup data comprises: judging whether the request rule of the data request exists in the database; if yes, comparing whether data corresponding to the request rule of the data request in the returned data and the backup data are consistent, if yes, not updating; if no, updating data corresponding to the request rule of the data request in the backup data to the union of the returned data and the backup data, wherein the returned data is the requested data or the intercepted data; if no, storing the returned data in the database as data corresponding to the request rule of the data request in the backup data.

6. The method of claim 1, wherein, The interface detection service is built through Node.js.

7. An apparatus for providing data, the apparatus comprising: Comprise: A server detection module for periodically detecting a server cluster; A tentative data request is sent to one server in the server cluster, and all servers in the server cluster are detected once as a period; A data acquisition module for determining whether the last detected server is normal after receiving a data request from the front end, wherein: If the last detected server is normal, the data request is sent to the server to obtain data corresponding to the request rule of the data request, and the request rule is a set of request parameters; If the last detected server is abnormal, it is determined whether there is an undetected server in the current period, if so, the data request is sent to an undetected target server, and if the target server is currently normal, data corresponding to the request rule of the data request is obtained from the target server; Otherwise, data corresponding to the request rule of the data request is obtained from the backup data, which is previously obtained from a normal server and saved in the database; A data providing module for providing the obtained data to the front end; The server detection module detects whether there is a normal server in the server cluster through the interface detection service created in the local client, and the database uses IndexDB.

8. The apparatus of claim 7, wherein, The data acquisition module is also used for: In the case that the last detected server is abnormal and there is no undetected server in the current period, or in the case that the target server is currently abnormal, the request rule of the data request is added to the request queue, so that the data corresponding to the request rule of the data request is requested when there is a normal server in the server cluster.

9. The apparatus of claim 8, wherein, The data acquisition module is also used for subsequently requesting the data corresponding to each request rule in the request queue according to the order of the request times of the request rules from more to less when there is a normal server in the server cluster.

10. The apparatus of claim 8 or 9, wherein, Also include: A data interception module and a data update module, wherein The data interception module is used to intercept the data corresponding to the request rule of the data request obtained from the last detected server or the target server; The data update module is used to update the data corresponding to the request rule of the data request in the backup data according to the intercepted data, or to update the data corresponding to the request rule of the data request in the backup data according to the requested data after subsequently requesting the data corresponding to the request rule of the data request when there is a normal server in the server cluster.

11. The apparatus of claim 10, wherein, The data update module is also used for: Determine whether the request rule of the data request exists in the database; If the comparison returns that the data corresponding to the request rule of the data request in the backup data and the returned data are consistent, no update is performed; if the comparison returns that the data corresponding to the request rule of the data request in the backup data and the returned data are inconsistent, the data corresponding to the request rule of the data request in the backup data is updated to the union of the two, wherein the returned data is the requested data or the intercepted data; If not, the returned data is stored in the database as the data corresponding to the request rule of the data request in the backup data.

12. The apparatus of claim 7, wherein, The interface detection service is built through Node.js.

13. An electronic device, comprising: Comprise: One or more processors; Memory for storing one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors implement the method as claimed in any one of claims 1-6.

14. A computer readable medium having stored thereon a computer program, characterized in that, The program is executed by the processor to implement the method as claimed in any one of claims 1-6. The program is executed by the processor to implement the method as claimed in any one of claims 1-6.

Images