CN118484609A

CN118484609A - Data caching method, device, terminal equipment and computer program product

Info

Publication number: CN118484609A
Application number: CN202410828167.0A
Authority: CN
Inventors: 冯金明; 梁剑锋; 郭立平
Original assignee: China Merchants Bank Co Ltd
Current assignee: China Merchants Bank Co Ltd
Priority date: 2024-06-25
Filing date: 2024-06-25
Publication date: 2024-08-13

Abstract

The application discloses a data caching method, a device, terminal equipment and a computer program product, and relates to the technical field of computer application, wherein the data caching method comprises the following steps: the configuration server side sends a pre-configured data caching strategy to the client side; the client acquires a data caching strategy sent by the configuration server; intercepting a URL request initiated by a page through a Hook, and judging whether the URL request hits a data caching strategy or not; if yes, judging whether the response data is recorded in a local database; if not, caching and rendering are carried out based on response data returned by the page server; if yes, rendering by using response data in a local database; based on the CDN white list and the type of the URL request, whether to initiate an asynchronous request to the page server is determined. According to the scheme, through a data caching strategy, the request data of the webpage is effectively controlled, the loading speed of the webpage is improved, and the flow saving and the real-time refreshing of the webpage are realized by combining a CDN white list and an asynchronous request.

Description

Data caching method, device, terminal equipment and computer program product

Technical Field

The present application relates to the field of computer application technologies, and in particular, to a data caching method, a data caching device, a terminal device, and a computer program product.

Background

With the rapid development of the mobile internet, the mobile communication networks 4G and 5G are popular, and the service carried by the mobile App end is increasing. The mainstream mobile App is in Hybrid architecture design mode realized by using h5+ native code, the native code supports development of basic functional components of the mobile phone, and service functions are mainly carried by H5 pages. With more and more business, various marketing activity pages and more applets are included, page contents are more diversified, and the loading speed of the H5 page directly influences the actual use experience of a user.

At present, two schemes exist in the aspect of improving the loading speed of a page, the first is a default caching strategy provided in a browser http/https protocol, but the method needs to strictly adhere to a related protocol formulated by the browser http/https protocol, and meanwhile, needs configuration and cooperation of a server side, so that the caching scheme is complex and depends on a network environment seriously. The web page and the server development have limited options in the aspects of controlling and configuring the cache, are difficult to fine-tune, have low degree of freedom and poor operability; the second is an offline cache package scheme, wherein an H5 offline package is downloaded according to configuration, and is used for displaying when a page is opened later, but the scheme takes the whole resource package as cache granularity, and small changes all need to be downloaded again, so that user flow data is wasted greatly; the offline package cache depends on the resources which are already downloaded to the local, and the latest content can be displayed after the downloading of the resource package is completed during updating, so that the problem of untimely updating exists.

In summary, the prior art cannot realize the technical problem of fine cache control of the request data.

Disclosure of Invention

The application mainly aims to provide a data caching method, a data caching device, terminal equipment and a computer program product, and aims to realize fine cache control of request data.

In order to achieve the above object, the present application provides a data caching method, which is applied to a client, and the method includes:

acquiring a data caching strategy sent by a configuration server;

Intercepting a Uniform Resource Locator (URL) request initiated by a page through a Hook, and judging whether the URL request hits the data caching strategy;

If the URL request hits the data caching strategy, judging whether response data corresponding to the URL request is recorded in a local database or not;

if the response data corresponding to the URL request is not recorded in the local database, caching and H5 page rendering are carried out based on the response data corresponding to the URL request returned by the page server;

If the response data corresponding to the URL request is recorded in the local database, rendering the H5 page by using the response data in the local database;

And determining whether to initiate an asynchronous request to the page server based on the content distribution network CDN white list and the type of the URL request.

In one embodiment, the step of determining whether the URL request hits the data caching policy if the URL request hits the data caching policy includes:

Judging whether the domain name requested by the URL exists in a domain name white list or not;

If the domain name of the URL request exists in the domain name white list, matching a Path array of the URL request in a prefix matching mode;

And if the matching is successful, the URL request hits the data caching strategy.

In an embodiment, if the response data corresponding to the URL request is not recorded in the local database, the step of caching and H5 page rendering based on the response data corresponding to the URL request returned by the page server includes:

sending the URL request to a page server for the page server to return corresponding response data of the URL request to the client for caching based on the URL request;

Intercepting and receiving corresponding response data of the URL request returned by the page server;

and caching the response data into a local database, and rendering the response data to an H5 page.

In one embodiment, if the response data corresponding to the URL request is already recorded in the local database, the step of performing the H5 page rendering using the response data in the local database includes:

reading data and related configuration information corresponding to the URL request through the URL request in the local database;

based on the data corresponding to the URL request and the related configuration information, splicing and constructing corresponding response data of the URL request;

And sending the corresponding response data of the URL request to the page so as to render the page by the H5 page.

In an embodiment, the step of determining whether to initiate an asynchronous request to the page server based on the content distribution network CDN whitelist and the URL request type includes:

judging whether the type of the URL request is a picture or not, and judging whether the URL request hits the CDN white list or not;

if yes, an asynchronous request is not initiated to the page server;

if not, an asynchronous request is initiated to the page server, so that the page server returns new response data based on the asynchronous request.

In an embodiment, after the step of initiating the asynchronous request to the page server if not, the method further includes:

Intercepting and receiving new response data returned by the page server;

Calculating the hash value of the response data in the local database and the hash value of the new response data returned by the page server;

Judging whether the hash value of the response data in the local database is consistent with the hash value of the new response data returned by the page server;

if not, the new response data is cached, and a refreshing notification is sent to the H5 page.

In addition, in order to achieve the above objective, the present application further provides a data caching method, where the method is applied to a configuration server, and the method includes:

and sending the pre-configured data caching strategy to the client so that the client can judge whether the URL request hits the data caching strategy.

In an embodiment, before the step of sending the pre-configured data caching policy to the client to determine whether the URL request hits the data caching policy, the method further includes:

configuring a data caching strategy main switch, a data validity period and a hash value through corresponding fields;

Configuring a domain name white list and a content distribution network CDN white list through the Path and the domain name of the URL request;

And obtaining a data caching strategy based on the caching rule main switch, the data validity period, the domain name white list and the CDN white list.

In an embodiment, after the step of obtaining the data caching policy based on the caching rule master switch, the data validity period, the hash value, the domain name whitelist and the CDN whitelist, the method further includes:

comparing whether the hash value in the data caching strategy is consistent with the hash value of the caching strategy calculated according to the local configuration data;

if the data caching strategies are consistent, the data caching strategies are not sent to the client;

and if the data caching strategies are inconsistent, sending the data caching strategies to the client.

In addition, in order to achieve the above object, the present application also provides a data caching device, where the data caching device includes a client and a server; the client comprises:

the acquisition module is used for acquiring a data caching strategy sent by the configuration server;

The request interception and judgment module is used for intercepting all URL requests initiated by the page and judging whether the URL requests meet the data caching strategy or not;

the cache management module is used for judging whether response data corresponding to the URL request is recorded in a local database or not if the URL request hits the data cache policy;

The cache management module is further configured to cache and render an H5 page based on response data of the URL request returned by a page server if the response data of the URL request is not recorded in the local database;

The cache management module is further configured to perform the H5 page rendering using the response data in the local database if the response data corresponding to the URL request is already recorded in the local database;

The request initiating module is used for determining whether to initiate an asynchronous request to the page server based on a Content Distribution Network (CDN) white list and the type of the URL request;

the configuration server comprises:

and the sending module is used for sending the pre-configured data caching strategy to the client so that the client can judge whether the URL request hits the data caching strategy.

In addition, to achieve the above object, the present application further provides a data cache terminal device, which includes: a memory, a processor and a computer program stored on the memory and executable on the processor, the computer program being configured to implement the steps of the data caching method as described above.

In addition, to achieve the above object, the present application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, which when being executed by a processor, implements the steps of the data caching method as described above.

Furthermore, to achieve the above object, the present application provides a computer program product comprising a computer program which, when executed by a processor, implements the steps of the data caching method as described above.

The application provides a data caching method, which comprises the steps that a configuration server side sends a pre-configured data caching strategy to a client side so that the client side can judge whether a URL request hits the data caching strategy or not; acquiring a data caching strategy sent by a configuration server through a client; intercepting a Uniform Resource Locator (URL) request initiated by a page through a Hook, and judging whether the URL request hits the data caching strategy or not; if the URL request hits the data caching strategy, judging whether response data corresponding to the URL request is recorded in a local database or not; if the response data corresponding to the URL request is not recorded in the local database, caching and H5 page rendering are carried out based on the response data corresponding to the URL request returned by the page server; if the response data corresponding to the URL request is recorded in the local database, performing H5 page rendering by using the response data in the local database; and determining whether to initiate an asynchronous request to the page server based on the content distribution network CDN white list and the type of the URL request. According to the scheme, through the dynamic data caching strategy of the client and the configuration server, effective control can be achieved on the request data of the webpage, flexibility and pertinence of the caching strategy are improved, the loading speed of the webpage data is improved while the instantaneity of the data is guaranteed, the purpose of saving network traffic is achieved by combining the types of CDN white lists and URL requests, and the effect of refreshing the webpage in real time is achieved through asynchronous requests.

Drawings

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

In order to more clearly illustrate the embodiments of the application or the technical solutions of the prior art, the drawings which are used in the description of the embodiments or the prior art will be briefly described, and it will be obvious to a person skilled in the art that other drawings can be obtained from these drawings without inventive effort.

FIG. 1 is a flowchart of a data buffering method according to an embodiment of the present application;

FIG. 2 is a schematic flow chart of a data buffering method according to a second embodiment of the present application;

FIG. 3 is a flowchart of a third embodiment of a data buffering method according to the present application;

FIG. 4 is a flowchart of a data buffering method according to a fourth embodiment of the present application;

FIG. 5 is a block diagram of an overall scheme of the data caching method of the present application;

FIG. 6 is a frame structure diagram of a data management module according to a first and a third embodiment of the present application;

Fig. 7 is a frame structure diagram of a request intercepting module according to a first embodiment and a third embodiment of the present application;

FIG. 8 is a schematic block diagram of a data buffering device according to an embodiment of the present application;

fig. 9 is a schematic device structure diagram of a hardware operating environment related to a data caching method in an embodiment of the present application.

The achievement of the objects, functional features and advantages of the present application will be further described with reference to the accompanying drawings, in conjunction with the embodiments.

Detailed Description

It should be understood that the specific embodiments described herein are merely illustrative of the technical solution of the present application and are not intended to limit the present application.

For a better understanding of the technical solution of the present application, the following detailed description will be given with reference to the drawings and the specific embodiments.

The main solutions of the embodiments of the present application are: the client acquires a data caching strategy sent by the server; intercepting a Uniform Resource Locator (URL) request initiated by a page, and judging whether the URL request meets a data caching strategy; if the URL request meets the data caching strategy, judging whether response data corresponding to the URL request is recorded in a local database; if the response data corresponding to the URL request is not recorded in the local database, caching and H5 page rendering are carried out based on the response data corresponding to the URL request returned by the page server; if the response data corresponding to the URL request is recorded in the local database, performing H5 page rendering by using the response data in the local database; and determining whether to initiate an asynchronous request to the page server based on the content distribution network CDN white list and the type of the URL request. And the configuration server side sends the pre-configured data caching strategy to the client side so that the client side can judge whether the URL request meets the data caching strategy.

Because two schemes exist in the aspect of improving the loading speed of the page at present, the first is a default caching strategy provided in the browser http/https protocol, but the method needs to strictly adhere to the related protocol formulated by the browser http/https protocol, and meanwhile needs to configure and cooperate with a server side, so that the caching scheme is complex and depends heavily on the network environment. The web page and the server development have limited options in the aspects of controlling and configuring the cache, are difficult to fine-tune, have low degree of freedom and poor operability; the second is an offline cache package scheme, wherein an H5 offline package is downloaded according to configuration, and is used for displaying when a page is opened later, but the scheme takes the whole resource package as cache granularity, and small changes all need to be downloaded again, so that user flow data is wasted greatly; the offline package cache depends on the resources which are already downloaded to the local, and the latest content can be displayed after the downloading of the resource package is completed during updating, so that the problem of untimely updating exists.

According to the application, the data caching strategy is configured at the configuration server side, so that the client side can perform data fine caching control based on the fine data caching strategy, the technical problem that the fine caching control of the request data cannot be realized is solved, the cache granularity of H5 data is accurate to each URL request, when the same URL request is initiated again, the cache data is directly used, the page loading speed is improved obviously, and if the URL request type is a picture and the domain name of the picture hits the CDN domain name white list, the link of asynchronous request can be omitted directly, and the flow resource of a user is saved.

It should be noted that, the execution body of the present embodiment may be a computing service device having functions of data processing, network communication, and program running, such as a mobile phone, or an electronic device capable of implementing the above functions. The present embodiment and the following embodiments will be described below with reference to a mobile phone as an example.

Based on this, an embodiment of the present application provides a data caching method, which is applied to a client, and referring to fig. 1, fig. 1 is a flow chart of a first embodiment of the data caching method of the present application.

In this embodiment, the data caching method includes steps S10 to S60:

step S10, acquiring a data caching strategy sent by a configuration server;

it should be noted that, the data caching policy refers to a set of defining criteria of policies that instruct how data is cached, when to use the cached data, and the validity period of the cached data. The data caching policy may include the following aspects:

Caching objects: define which types of resources or URL (Uniform Resource Locator ) paths should be cached, such as static resources like CSS, javaScript, pictures, etc., or specific API requests;

Cache condition: defining which conditions the request meets before the cache is applied;

buffer finite period: setting the maximum time length of data stored in a cache, cleaning expiration data after expiration and the like;

cache update policy: the setting data is updated when which conditions are met.

The client judges whether a caching scheme is started, which URL requests are to be intercepted and which picture requests can save traffic for each intercepted URL request according to a data caching strategy configured by the configuration server.

Step S20, intercepting a Uniform Resource Locator (URL) request initiated by a page through a Hook, and judging whether the URL request hits the data caching strategy or not;

The client listens for and captures each URL request generated during page loading or running through Hook technology. And after intercepting each request, judging whether the URL request meets a data caching strategy pre-configured by the server side.

In a first possible embodiment, step S20 may include steps S21 to S23:

Step S21, judging whether the domain name requested by the URL exists in a domain name white list or not;

It should be noted that the domain name white list is a list of domain names that include permission or special processing. In this strategy, only domain name initiated requests within the domain name whitelist are considered for caching. This is for security and compliance considerations to ensure that only data of a trusted source is cached, avoiding potential security risks or unwanted data being stored.

If the domain name of the URL request is not in the domain name white list, the URL request is not in accordance with the requirement of continuing to execute the data caching strategy.

Step S23, if the domain name of the URL request exists in the white list, matching the Path array of the URL request in a prefix matching mode;

it should be noted that prefix matching is a character string matching technique for checking whether a path portion of a URL starts with a specified series of characters (prefixes).

The user may define in advance a series of path prefixes that correspond to the type of content or particular resources that it is desired to cache. For example, if the request type is a picture resource, the path prefix of the request may be set to/images/. When a path of response data corresponding to a URL request starts with a domain name in the white list and these preset prefixes are added, it is considered that it meets the buffering condition.

Step S23, if the matching is successful, the URL request hits the data caching strategy.

If the path array of the URL request is successfully matched, the URL request meets the data caching strategy. Data caching operations, such as caching response data to requests or other processing, may be performed as desired.

Through the steps, by combining with the Hook technology, all network requests of the system in the WebView process can be intercepted, so that no invasion to service functions, no invasion to an H5 page end and no invasion to a server end are realized. And judging whether the intercepted URL request meets a data caching strategy according to the domain name white list and the path matching rule, and efficiently utilizing a data caching mechanism to optimize the webpage performance.

Step S30, if the URL request hits the data caching strategy, judging whether response data corresponding to the URL request is recorded in a local database;

it should be noted that, since there is a one-to-one correspondence between URL requests and corresponding response data, when using URL requests as a primary key to query the local database, whether the corresponding response data exists is queried in the local database through the URL requests.

Step S40, if the response data corresponding to the URL request is not recorded in the local database, caching and H5 page rendering are carried out based on the response data corresponding to the URL request returned by the page server;

In this embodiment, the page server refers to a server that provides web content and response data. In the network device, the page server is responsible for receiving the URL request and returning the corresponding page content or data. And the configuration server is used for managing the data caching strategy of the equipment so as to ensure the normal operation of the equipment and provide the required service.

In addition, it is to be noted that, on the basis of determining that the response data corresponding to the URL request hits the data caching policy, and that the response data corresponding to the URL request is not recorded in the local database, it is a precondition for executing step S40.

In a first possible embodiment, step S40 may include steps S41 to S43:

Step S41, sending the URL request to a page server for the page server to return corresponding response data of the URL request to the client for caching based on the URL request;

the response data includes data and response data. Data generally refers to information that is retrieved from a server and stored for subsequent quick access. These data may be the result of API requests, web content, user personal information, etc., which are cached for the purpose of reducing duplicate network requests and speeding up application responses.

It should be noted that, response data refers to an information packet returned to the client by the server after the client initiates a request to the server. Which contains the actual data part of the client request and also contains metadata describing this response.

Specifically, after judging that the URL request is not recorded in the local database, the URL request is sent to the page server, and the page server obtains corresponding response data based on the URL request and returns the response data corresponding to the URL request to the client.

Step S42, corresponding response data of the URL request returned by the page server is intercepted and received;

After intercepting and receiving response data corresponding to the URL request returned by the page server through the Hook, the data caching strategy of the http/https in the response data returned by the page server needs to be cleared. If not removed, the web (webpage) kernel may execute the self-contained data caching policy of the response data, so that the client cannot intercept the subsequent returned data and proxy method.

And step S43, caching the response data into a local database, and rendering the response data to an H5 page.

After intercepting response data returned by the page server, the client caches the response data in a local database, and simultaneously sends the response data to the page for the page to display.

The main purpose of the client-side intercepting the response data returned by the page server-side is to record or update the cache data in the local database, and when the same URL request is initiated by the next page, the cached response data can be directly returned to the page for rendering so as to achieve the effect of acceleration during page loading.

Through the steps, the data interaction and page display flow between the client and the page server are realized, and the user experience and the page loading speed are improved through caching and rendering response data.

And step S50, if the response data corresponding to the URL request is recorded in the local database, performing the H5 page rendering by using the response data in the local database.

It should be noted that, on the basis of determining that the response data corresponding to the URL request hits the data caching policy, and that the URL request has been recorded in the local database, it is a precondition for executing step S50.

In one possible implementation, step S50 may include steps S51 to 53:

step S51, reading data and related configuration information corresponding to the URL request through the URL request in the local database;

It should be noted that, in this embodiment, the local database stores not only cached data, but also some configuration information related to a specific URL request. The configuration information may include specific rules for how to handle the URL request, data format requirements, or data stitching logic

After determining that the current URL request finds the corresponding cache record in the local database, the URL request may be used as a primary key to query the local database for all necessary information associated therewith, including but not limited to preprocessing logic, data structure templates, or connections to other data tables, etc.

And step S52, splicing and constructing corresponding response data of the URL request based on the corresponding data of the URL request and the related configuration information.

Based on the data read in the local database and the relevant configuration information, the splicing and construction of the corresponding response data of the URL request is started, i.e. comprising construction data and response data.

And constructing response data, including response header information, response body content and the like, and ensuring that the data format meets the HTTP protocol requirements.

And step S53, the corresponding response data of the URL request is sent to a page so as to render the page by the H5 page.

After the construction of response data (data and response data) is completed in the local database, the response data is returned to the page, and the page performs page presentation based on the response data.

In addition, it should be noted that, in general, the data cached in the local database will be emptied in the following cases, including but not limited to response data:

1. When the data caching strategy main switch is closed, the data caching strategy is not executed any more, and the system can empty all cached data. The data caching strategy master switch is a parameter of a fusing switch under an extreme abnormal scene, which is configured by a server side when defining the data caching strategy;

2. the user can manually clear all cache data by setting a cache clearing button of the center page;

3. When the App starts asynchronous pulling of the configuration data, the outdated cache data is deleted by comparing the storage time of the cache data with the validity period of the configuration data.

Through the steps, the URL request recorded in the local database is processed, data is read from the local database, response data is constructed according to relevant configuration information, the constructed response data is directly used for caching and webpage rendering, and the response data is not required to be returned to the webpage server, so that direct interaction with the webpage server is omitted, and the effect of accelerating webpage loading speed is achieved.

Step S60, determining whether to initiate an asynchronous request to the page server based on the content distribution network CDN white list and the type of the URL request.

It should be noted that, the white list of the CDN (Content Delivery Network, content distribution network) refers to a list of domain names or IP addresses that are provided by a Content Distribution Network (CDN) service and allowed to access CDN resources.

In one possible embodiment, step S60 may include steps S61 to S63:

step S61, judging whether the type of the URL request is a picture, and judging whether the URL request hits a CDN white list of a content distribution network;

Since the picture resources are mostly deployed on the CDN resource server, one picture corresponds to one URL path by default. The client needs to determine whether the type of the intercepted URL request is a picture resource and whether the domain name of the URL request is in the CDN whitelist.

Step S62, if yes, an asynchronous request is not initiated to the page server;

When the client judges that the type of the URL request is a picture resource and the domain name of the URL request is in a CDN white list, the client does not send an asynchronous request to the page server to acquire new response data, so that the effect of saving flow is achieved.

Step S63, if not, an asynchronous request is initiated to the page server for the page server to return new response data based on the asynchronous request.

It should be noted that the asynchronous request is that after the URL request is initiated, it is not necessary to wait for the response of the ULR request to return immediately, but other operations may be continued. In an asynchronous request, after the URL request is sent to the page server, the client may continue to perform other tasks without blocking waiting for the page server's response.

When the client judges that the type of the URL request is not a picture resource and the domain name of the URL request is not in the CDN white list, the client sends an asynchronous request to the page server to request the page server to return new response data.

Through the steps, whether the URL request meets the CDN domain name white list or not and whether the URL request type is picture resources or not are judged, if yes, asynchronous requests are not initiated to the page server side, and therefore the effect of saving data flow of requested pictures is achieved.

The method comprises the steps that a client acquires a data caching strategy sent by a configuration server; intercepting a Uniform Resource Locator (URL) request initiated by a page through a Hook, and judging whether response data corresponding to the URL request hits a data caching strategy or not; if the response data corresponding to the URL request hits the data caching strategy, judging whether the response data corresponding to the URL request is recorded in a local database; if not, caching and page rendering are carried out based on corresponding response data of the URL request returned by the page server; if yes, performing page rendering by using response data in the local database; and determining whether to initiate an asynchronous request to the page server based on the content distribution network CDN white list and the type of the URL request. Through the dynamic data caching strategy of the client and the configuration server, the request data of the webpage can be effectively controlled, the flexibility and pertinence of the caching strategy are improved, the loading speed of the webpage data is improved while the instantaneity of the data is ensured, and the stream saving and the real-time webpage refreshing are realized by combining a CDN white list and an asynchronous request.

In the second embodiment of the present application, the same or similar content as in the first embodiment of the present application may be referred to the description above, and will not be repeated. On this basis, referring to fig. 2, after step S63, the data caching method further includes steps S631 to S634:

Step S631, new response data returned by the page server is intercepted and received;

And after receiving the asynchronous request, the page server processes the asynchronous request according to the content of the request and generates new response data. The page server sends these new response data back to the client.

After receiving the new response data returned by the page server, the client can continue to perform hash value comparison and page update operation based on the new response data.

Step S632, calculating the hash value of the response data cached in the local database and the hash value of the new response data returned by the page server;

When the asynchronous request is completed and the response data is received, a hash value is calculated for the response data. Hash functions (e.g., MD5, SHA-256) are capable of mapping data of arbitrary length to fixed length output, and small changes in any input data result in large differences in hash values, and are therefore commonly used for data integrity verification and unique identification.

Step S633, judging whether the hash value of the response data cached in the local database is consistent with the hash value of the new response data returned by the page server;

And comparing the hash value of the cache data obtained from the local database with the hash value of the new response data returned by the page server.

And judging whether the hash value of the new response data is consistent with the hash value of the cached data in the local database, and determining whether the new data and the old data (namely the cached data originally cached in the local database) are changed.

Step S634, if not, caching the new response data and sending a refreshing notification to the H5 page;

if the hash value of the new response data does not match the hash value of the cached data in the local database, it is indicated that the new data has changed from the old data.

And then, updating the cache data of the local database by using new response data returned by the page server to ensure that the local cache data is consistent with the latest data.

By the embodiment, the asynchronous request sent by the page can be monitored and processed, the consistency of the data is ensured, the data is updated in time, and meanwhile, the refreshing notification is sent to the page according to the need, so that the user experience and the accuracy of the data are improved.

The embodiment of the application provides a data caching method, which is applied to a configuration server, and referring to fig. 3, fig. 3 is a schematic flow chart of a third embodiment of the data caching method of the application.

In this embodiment, the data caching method includes step S70:

step S70, the data caching strategy is sent to the client side so that the client side can judge whether the URL request hits the data caching strategy.

And the configuration server sends the formulated caching strategy to the client, and after the client receives the data caching strategy, the client judges whether a caching scheme is started, which URL requests are intercepted and which picture requests can save flow for each URL request initiated by the webpage according to the data caching strategy defined by the configuration server.

In a first possible implementation manner, before step S70, steps S701 to S703 are further included:

step S701, configuring a data caching strategy main switch, a data validity period and a hash value through corresponding fields;

The cache policy master switch is mainly used as a fuse switch in an extreme abnormal scene. The server configures a caching strategy master switch in a caching data strategy, and provides a master switch means of various modes for the client:

1. a configuration switch DisableWebCache (disable network caching) configured at the mobile client;

2. When App is started, the whole configuration data asynchronously requested is in a space time;

3. and when the expiration time value of 'expiredDays' (effective days) in the configuration data is less than or equal to 0.

The data validity period, namely the expiration time of the data, corresponds to the 'expiredDays' field in the configuration data, and is mainly used for comparing with the local page cache and clearing the expired cache data. The time for clearing is each time App starts asynchronous pull configuration data.

The configuration Hash value corresponds to a 'WHITELISTHASH' (white list Hash value) field in the configuration, which is the Hash value of the whole configuration data, is returned by the server and uploaded when the configuration is requested, and whether the configuration data changes can be judged through the Hash value. If the data is not changed, the server can empty the data, so that the effect of saving the flow is achieved.

Step S702, configuring a domain name white list and a content distribution network CDN white list through a Path and a domain name requested by a URL;

The domain name whitelist is the most critical configuration data, corresponding to "WHITELIST" (whitelist) in the configuration data. The configuration data consists of a domain name and a Path array. When judging whether a certain URL request can execute a data caching strategy or not, the domain name is used as a Key value, and when judging whether the URL request can execute the data caching strategy, the domain name is preferentially compared with the domain name of the URL request, if the domain name is not in a domain name white list, the client is considered to be not allowed to execute the data caching strategy; if the domain name is in the domain name white list, the Path array is continuously compared, wherein the Path array can be compared through a prefix matching method, and if the matching is successful, the client can be considered to execute a data caching strategy, so that interception processing is carried out in a subsequent request.

Since some picture resources are mostly deployed on CDN (Content Delivery Network ) resource servers, one picture corresponds to one URL path by default. When the client judges that the URL request is a picture resource and the URL domain name is on the CDN white list, the client directly uses the cache data in the local database, so that the effect of saving the data flow of the requested picture is achieved.

Step S703, obtaining a data caching policy based on the caching rule master switch, the data validity period, the hash value, the domain name whitelist and the CDN whitelist.

Based on the configured cache rule master switch, the data validity period, the hash value, the domain name white list and the CDN white list, a set of data cache strategies is generated, and cache data can be processed based on the data cache strategies at a subsequent client.

According to the method, the server side sends the pre-configured data caching strategy to the client side, so that the client side can judge whether response data corresponding to the URL request meets the data caching strategy. Through the dynamic data caching strategy of the client and the configuration server, the request data of the webpage can be effectively controlled, the flexibility and pertinence of the caching strategy are improved, the real-time performance of the data is ensured, and the loading speed of the webpage data is improved.

In the fourth embodiment of the present application, the same or similar contents as those of the fourth embodiment of the present application can be referred to the above description, and the description thereof will not be repeated. On this basis, referring to fig. 4, after step S703, the data caching method further includes steps C1 to C2:

Step C1, comparing whether the hash value in the data caching strategy is consistent with the hash value of the caching strategy obtained by calculation according to the local configuration data;

the hash value in the data caching policy is already obtained in step S71, so it is only necessary to directly compare the configured hash value in the data caching policy with the hash value of the caching policy calculated according to the local configuration data.

The system calculates a hash value of the caching policy of the local configuration data. This is to compare with the hash value of the new data caching policy to determine if there is a change.

And step C2, if the data caching strategies are consistent, not sending the data caching strategies to the client.

If the comparison result shows that the hash values are consistent, the client has the latest caching strategy, and the configuration server does not need to send the data caching strategy to the client again at the moment, and the data caching strategy cached in the local database is directly multiplexed. This saves network resources and reduces unnecessary communication overhead.

And step C3, if the data caching strategies are inconsistent, sending the data caching strategies to the client.

If the comparison result shows that the hash values are inconsistent, the cache policy owned by the client is expired, and the server needs to be configured to send a new data cache policy to the client.

By the method, namely by comparing the hash value of the data caching strategy defined by the configuration server with the hash value of the data caching strategy in the local database, the effects of saving flow and network resources can be achieved.

For an example, to help understand the implementation flow of the data caching method obtained by combining the first embodiment and the third embodiment, please refer to fig. 5, fig. 5 provides an overall scheme frame diagram of the data caching method, specifically:

The client intercepts each URL request initiated by the webpage end by means of data cache configuration and an AOP (Aspect-oriented programming) programming thought, and achieves a cache scheme accurate to URL granularity. Determining whether the URL request is subject to cache and cache management depends on the data management module; the interception and processing of all requests of a page depend on a request control module.

The user can select the service function to be performed through the H5 page of the mobile phone App, at this time, the page can generate a URL request related to the service function, and the URL request is sent to the client and the server for cache interception and processing. The data management module is mainly divided into configuration data and cache data, wherein the configuration data is mainly completed by the server side, and the cache data is mainly completed by the client side.

The request control module includes response (cache data) interception and requeset (network request) interception.

For an example, to help understand the implementation flow of the data caching method obtained by combining the first embodiment and the third embodiment, please refer to fig. 6, fig. 6 is a frame structure diagram of the data management module, specifically:

the data management module is mainly divided into two parts: configuration data and cache data.

The essence of the data caching scheme is still to replace the network requested data with cached data. The decision as to whether or not to enable the caching scheme, which URL requests are to be intercepted, and which picture requests are able to save traffic depends on the configuration data module. After the intercepted URL request is satisfied, the client queries and extracts data from the local database, and constructs a response replacement network request. The storage logic, update and clearing time of the cache data are managed by the cache data module.

Wherein defining the data caching policy needs to be performed at the configuration service end based on the configuration data. The configuration data is asynchronously pulled from the server side when the App is started and is stored in a local manner in a lasting mode. Based on the configuration data, a data caching policy may be defined. The data caching policy may include defining a caching scheme main switch, a data expiration time, a URL request whitelist, a hash value of the data caching policy, a picture domain name whitelist, and the like. Among them, URL request whitelist is the most critical configuration data, as it determines whether the client can execute the data caching policy.

The client intercepts each URL request initiated by a page based on a data caching strategy defined by the server, judges whether the request meets the condition of executing the data caching strategy, and caches the URL request according to the data caching strategy, wherein the data caching strategy comprises interception, reading mode, updating mode, deleting mode and the like of the request.

For an example, to help understand the implementation flow of the data caching method obtained by combining the first embodiment and the third embodiment, please refer to fig. 7, fig. 7 is a frame structure diagram of the request intercepting module, specifically:

The application mainly integrates the AOP (tangent plane oriented) thought, and Hook initiates all network requests (requests) and network Request returns (responses) of the webpage, and precisely controls the cache to each URL Request, thereby realizing no invasion to service functions and no invasion to the webpage end and the server end.

The Hook is mainly aimed at webpage requests, and has no influence on native requests. The core idea of implementing the runtime replacement of the data request by injecting Ajax, fetch, submit, sendBeacon data request JS into the Hook is to record the initial Ajax, fetch, submit, sendBeacon method by window or other global objects, and then re-implement Ajax, fetch, submit, sendBeacon method to perform the Hook.

For the URL request hitting the domain name white list, namely the domain name of the URL request exists in the domain name white list, response data returned by the client side from the page server side can be intercepted through the Hook technology, so that the response data can be recombined by the client side. After intercepting a network Request (Request) through the Hook technology, corresponding data and relevant configuration information are read from a cache database through a URL, and returned response data, namely data and response, are spliced.

Based on the request interception module, the Hook has the advantages that all network requests of the system in the WebView process are not invaded by service functions, the H5 page end and the server end.

It should be noted that the foregoing examples are only for understanding the present application, and are not meant to limit the data buffering method of the present application, and more forms of simple transformation based on the technical concept are all within the scope of the present application.

The application also provides a data caching device, please refer to fig. 8, which includes a client and a server; the client comprises:

the acquisition module 10 is used for acquiring a data caching strategy sent by the configuration server;

The request interception and judgment module 20 is used for intercepting all URL requests initiated by a page and judging whether the URL requests meet the data caching strategy;

The cache management module 30 is configured to determine whether response data corresponding to the URL request is recorded in a local database if the response data corresponding to the URL request hits the data cache policy;

The cache management module 30 is further configured to cache and render an H5 page based on response data of the URL request returned by a page server if the response data of the URL request is not recorded in the local database;

The cache management module 30 is further configured to perform H5 page rendering using the response data in the local database if the response data corresponding to the URL request is already recorded in the local database;

a request initiating module 40, configured to determine whether to initiate an asynchronous request to the page server based on a content distribution network CDN whitelist and a type of the URL request;

the configuration server comprises:

And the sending module 50 is configured to send a pre-configured data caching policy to a client, so that the client can determine whether the URL request hits the data caching policy.

The data caching device provided by the application can solve the technical problem that the fine caching control of the request data can not be realized by adopting the data caching method in the embodiment. Compared with the prior art, the beneficial effects of the data caching device provided by the application are the same as those of the data caching method provided by the embodiment, and other technical features in the data caching device are the same as those disclosed by the method of the embodiment, so that the description is omitted herein.

The application provides a data caching terminal device, which comprises: at least one processor; and a memory communicatively coupled to the at least one processor; the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor, so that the at least one processor can execute the data caching method in the first embodiment.

Referring now to fig. 9, a schematic diagram of a data buffering terminal suitable for use in implementing an embodiment of the present application is shown. The data cache terminal device in the embodiment of the application can include, but is not limited to, a mobile terminal such as a mobile phone, a mobile phone and the like. The data buffering terminal device shown in fig. 9 is only an example, and should not impose any limitation on the functions and the scope of use of the embodiment of the present application.

As shown in fig. 9, the data cache terminal device may include a processing means 1001 (e.g., a central processor, a graphic processor, etc.), which may perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM) 1002 or a program loaded from a storage means 1003 into a random access Memory (RAM: random Access Memory) 1004. In the RAM1004, various programs and data required for the operation of the data cache terminal device are also stored. The processing device 1001, the ROM1002, and the RAM1004 are connected to each other by a bus 1005. An input/output (I/O) interface 1006 is also connected to the bus. In general, the following systems may be connected to the I/O interface 1006: input devices 1007 including, for example, a touch screen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, and the like; an output device 1008 including, for example, a Liquid crystal display (LCD: liquid CRYSTAL DISPLAY), a speaker, a vibrator, and the like; storage device 1003 including, for example, a magnetic tape, a hard disk, and the like; and communication means 1009. The communication means 1009 may allow the data caching terminal device to communicate wirelessly or by wire with other devices to exchange data. While data caching terminal devices with various systems are shown in the figures, it should be understood that not all of the illustrated systems are required to be implemented or provided. More or fewer systems may alternatively be implemented or provided.

In particular, according to embodiments of the present disclosure, the processes described above with reference to 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 shown in the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network through a communication device, or installed from the storage device 1003, or installed from the ROM 1002. The above-described functions defined in the method of the disclosed embodiment of the application are performed when the computer program is executed by the processing device 1001.

The data caching terminal equipment provided by the application can solve the technical problem that the fine caching control of the request data can not be realized by adopting the data caching method in the embodiment. Compared with the prior art, the beneficial effects of the data caching terminal device provided by the application are the same as those of the data caching method provided by the embodiment, and other technical features in the data caching terminal device are the same as those disclosed by the method of the previous embodiment, and are not described in detail herein.

It is to be understood that portions of the present disclosure may be implemented in hardware, software, firmware, or a combination thereof. In the description of the above embodiments, particular features, structures, materials, or characteristics may be combined in any suitable manner in any one or more embodiments or examples.

The foregoing is merely illustrative of the present application, and the present application is not limited thereto, and any person skilled in the art will readily recognize that variations or substitutions are within the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

The present application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon for performing the data caching method of the above-described embodiments.

The computer readable storage medium provided by the present application may be, for example, a U disk, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, or device, or a combination of any 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: random Access Memory), a Read-Only Memory (ROM: read Only Memory), an erasable programmable Read-Only Memory (EPROM: erasable Programmable Read Only Memory 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 this embodiment, 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, or device. Program code embodied on a computer readable storage medium may be transmitted using any appropriate medium, including but not limited to: wire, fiber optic cable, RF (Radio Frequency), and the like, or any suitable combination of the foregoing.

The computer readable storage medium may be contained in a data cache terminal device; or may exist alone without being assembled into the data buffering terminal device.

The computer-readable storage medium carries one or more programs that, when executed by a data caching terminal, cause the data caching terminal to: acquiring a data caching strategy sent by a configuration server through a client;

Intercepting a Uniform Resource Locator (URL) request initiated by a page through a Hook, and judging whether the URL request hits the data caching strategy or not;

If the URL request hits the data caching strategy, judging whether the URL request is recorded in a local database;

If not, caching and page rendering are carried out based on corresponding response data of the URL request returned by the page server;

if yes, caching and page rendering are carried out by using response data in the local database;

And sending the pre-configured data caching strategy to the client through the configuration server, so that the client can judge whether the URL request hits the data caching strategy.

Computer program code for carrying out operations of the present application may be written in any combination of one or more programming languages, including an object oriented programming language and also conventional procedural programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of remote computers, the remote computer may be connected to the user's computer through any kind of network, including a local area network (LAN: local Area Network) or a wide area network (WAN: wide Area Network), or may be connected to an external computer (for example, through the Internet using an Internet service provider).

The flowcharts 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 and/or flowchart illustration, and combinations of blocks in the block diagrams and/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 involved in the embodiments of the present application may be implemented in software or in hardware. Wherein the name of the module does not constitute a limitation of the unit itself in some cases.

The readable storage medium provided by the application is a computer readable storage medium, and the computer readable storage medium stores computer readable program instructions (namely computer program) for executing the data caching method, so that the technical problem that the fine cache control of the request data can not be realized can be solved. Compared with the prior art, the beneficial effects of the computer readable storage medium provided by the application are the same as those of the data caching method provided by the above embodiment, and are not described herein.

The application also provides a computer program product comprising a computer program which, when executed by a processor, implements the steps of a data caching method as described above.

The computer program product provided by the application can solve the technical problem that the fine cache control of the request data cannot be realized. Compared with the prior art, the beneficial effects of the computer program product provided by the application are the same as those of the data caching method provided by the above embodiment, and are not described herein.

The foregoing description is only a partial embodiment of the present application, and is not intended to limit the scope of the present application, and all the equivalent structural changes made by the description and the accompanying drawings under the technical concept of the present application, or the direct/indirect application in other related technical fields are included in the scope of the present application.

Claims

1. A method for caching data, the method being applied to a client, the method comprising:

acquiring a data caching strategy sent by a configuration server;

2. The data caching method as claimed in claim 1, wherein said step of determining whether a URL request hits said data caching policy if said URL request hits said data caching policy comprises:

3. The method of claim 1, wherein if the response data corresponding to the URL request is not recorded in the local database, the step of caching and H5 page rendering based on the response data corresponding to the URL request returned by the page server includes:

4. The data caching method as claimed in claim 1, wherein if the response data corresponding to the URL request has been recorded in the local database, the step of performing the H5 page rendering using the response data in the local database includes:

And sending the corresponding response data of the URL request to a page for rendering by the H5 page.

5. The data caching method as claimed in claim 1, wherein the step of determining whether to initiate an asynchronous request to the page server based on a content distribution network CDN whitelist and a type of URL request includes:

if yes, an asynchronous request is not initiated to the page server;

6. The method of claim 5, wherein after the step of initiating the asynchronous request to the page server if not, further comprising:

Intercepting and receiving new response data returned by the page server;

7. A data caching method, wherein the method is applied to a configuration server, and the method comprises:

8. The data caching method as claimed in claim 7, wherein before the step of sending the pre-configured data caching policy to the client for the client to determine whether the URL request hits the data caching policy, the method further comprises:

And obtaining a data caching strategy based on the caching rule main switch, the data validity period, the hash value, the domain name white list and the CDN white list.

9. The data caching method as claimed in claim 8, wherein after the step of obtaining the data caching policy based on the caching rule master switch, the data validity period, the hash value, the domain name whitelist and the CDN whitelist, the method further comprises:

10. The data caching device is characterized by comprising a client and a server; the client comprises:

The cache management module is further configured to cache and render an H5 page based on response data corresponding to the URL request returned by the page server if the response data corresponding to the URL request is not recorded in the local database;

the configuration server comprises:

11. A data caching terminal device, the device comprising: a memory, a processor and a computer program stored on the memory and executable on the processor, the computer program being configured to implement the steps of the data caching method of any one of claims 1 to 6 or 7 to 9.

12. A computer program product, characterized in that the computer program product comprises a computer program which, when executed by a processor, implements the steps of the data caching method of any one of claims 1 to 6 or 7 to 9.