Front-end and rear-end fused multi-stage braking caching method and device for hot data

Abstract

The invention provides a front-end and rear-end fused multi-stage braking caching method and device for hot data. A client browser performs data calling on the basis of negotiation caching and strong caching; the method comprises the following steps: distributing a static resource request to a static resource server group through a proxy server for querying and reading static resources and forwarding a dynamic resource request to a dynamic resource server group for querying dynamic resources, and performing bypass identification on cold and hot data through page view statistics and trend prediction; cold and hot data changes and data changes in an original database are monitored to perform active data updating, adding or deleting on multi-level caches including a browser local cache, a proxy server cache and a distributed cache, so that the response speed and the reading efficiency of hot data access are improved; the method has outstanding effects in scenes with clear business scenes, linear trend, frequent data updating frequency and high data consistency requirements.

Description

Technical Field

[0001] The present invention relates to the technical field of data caching, and in particular, to a multi-level braking cache method and device for hot data with front-end and back-end integration. Background Art

[0002] Hot data refers to data that is frequently accessed and used. Such data usually needs to be accessed and responded to quickly, so it is usually stored on a storage medium with high performance and fast access speed, and usually provides a more optimized access implementation solution.

[0003] The judgment of hot and cold data is mostly based on two criteria: (1) The frequency of access, that is, the more times a data is accessed within a period of time, the higher its data heat. (2) The timeliness of access, that is, the closer the accessed data is to the current time point, the higher its data heat. Because most application scenarios have locality in time and space, the probability of accessing the currently accessed data next is relatively large.

[0004] With the development of the Internet, the access volume of hot data in applications has been increasing continuously, resulting in a sudden increase in network, application, database, storage, and I / O (input / output) pressure. It is urgent to solve how to efficiently process these hot data with high-frequency access. Especially in scenarios where data is updated frequently, the scale is moderate, and the data consistency requirement is high, the traditional single caching scheme is difficult to meet the requirements. Therefore, a fusion caching architecture combining front-end caching, back-end multi-level caching, and trend prediction algorithms is needed to improve system performance and data response speed. Summary of the Invention

[0005] In view of this, embodiments of the present invention provide a multi-level braking cache method and device for hot data with front-end and back-end integration to eliminate or improve one or more defects existing in the prior art and solve the caching pressure generated by the increase in hot data access in the prior art.

[0006] One aspect of the present invention provides a multi-level braking cache method for hot data with front-end and back-end integration, and the method includes the following steps:

[0007] When the client browser requests a resource, it queries the resource update status from the proxy server based on the negotiation caching mechanism, and preferentially calls the data in the browser local cache based on the strong caching mechanism in the case of no update;

[0008] The proxy server receives client access requests, distributes static resource requests therein to the static resource server group to query the update status of static resources and read them when updated, and forwards dynamic resource requests therein to the dynamic resource server group to query the update status of dynamic resources and read them when updated; the dynamic resource server group adopts distributed caching; the proxy server executes the negotiated caching mechanism and the strong caching mechanism based on the proxy server cache;

[0009] Based on bypass caching, the proxy server establishes data access logs for each business scenario for the dynamic resource requests, counts the number of accesses to each data item as the access popularity according to a preset time period and preset time slices for each business scenario and writes it into the hot data access list, counts the hot data access list and writes it into the access popularity accumulation table; after discarding the data items with access popularity less than the acceptance threshold of the hot data recognition standard, sort them according to the access popularity size, and store the first set number of data items into the hot data recognition table; the access popularity of each data item in the hot data recognition table is revised by introducing trend prediction.

[0010] The proxy server marks the data items that existed in the previous time period but do not exist in the current time period in the hot data recognition table as new hot data, and defines the data items that did not exist in the previous time period but exist in the current time period as cold data; pushes the content of the new hot data and the cold data to the active cache scheduling server.

[0011] The active cache scheduling server adds the new hot data and deletes the cold data in the browser local cache, the proxy server cache and the distributed cache based on heat drive; and actively updates or deletes the old hot data existing in the browser local cache, the proxy server cache and the distributed cache based on data drive according to the data changes in the database.

[0012] In some embodiments, the browser local cache, the proxy server cache and the distributed cache are combined with the database based on the read-write through strategy in the method.

[0013] In some embodiments, the acceptance threshold of the hot data recognition standard is one half of the minimum access popularity in the access popularity accumulation table in the previous time period.

[0014] In some embodiments, the access popularity of each data item in the hot data recognition table is revised by introducing trend prediction, including:

[0015] Based on linear trend prediction, the access popularity of a single data item in each time slice of the current time period is fitted, and the predicted access popularity values corresponding to each time slice in the next time period are speculated. The expression is:

[0016]

[0017] Among them, y t represents the actual observed value of the time slice at time t in the current time period, represents the predicted access heat value of the time slice at time t in the next time period; a is the intercept of the linear fitting, and b is the slope of the linear fitting; is the mean value of y t , is the mean value of time; n represents the number of data points;

[0018] The access heat observed values of the data items in each time slice in the hot data access volume list in the current time period and the predicted access heat values in each time slice in the next time period are weighted and averaged to revise the access heat of each data item.

[0019] In some embodiments, the access heat of each data item in the hot data recognition table is revised by introducing trend prediction, including:

[0020] Taking the number of times the data item appears in the corresponding time slice in multiple time periods as the weight, the observed values of the access heat of the data item in the corresponding time slice in multiple time periods are weighted and averaged to obtain the predicted access heat value of the corresponding time slice of the data item in the next time period. The calculation formula is:

[0021]

[0022] Among them, x i represents the observed value of the access heat of the data item in the target time slice in the i-th time period, w i represents the weight of the i-th time period, and n represents the number of time periods; represents the predicted access heat value;

[0023] The access heat observed values of the data items in each time slice in the hot data access volume list in the current time period and the predicted access heat values in each time slice in the next time period are weighted and averaged to revise the access heat of each data item.

[0024] In some embodiments, when the access heat observed values and the predicted access heat values of each data item in the hot data recognition table are weighted and averaged to revise the access heat of each data item, the weight of the access heat observed value is 1, and the weight of the predicted access heat value is the ratio of the preset time period to the preset time slice length.

[0025] In some embodiments, the data items in the hot data access list, the access heat accumulation table, and the hot data recognition table are marked with the hash value of the uniform resource locator of the data.

[0026] On the other hand, the present invention also provides a hot data multi-level braking cache device with front-end and back-end integration, including:

[0027] A client, which is used to load a browser, query the resource update status from the proxy server based on the negotiation cache mechanism when requesting resources, and preferentially call the data in the browser local cache based on the strong cache mechanism in the case of no update;

[0028] A static resource server group, which is used to cache static resources;

[0029] A dynamic resource server group, which is used to cache dynamic resources based on distributed storage;

[0030] A proxy server, which is used to receive the access request from the client, distribute the static resource request therein to the static resource server group to query the static resource update status and read it when updated, forward the dynamic resource request therein to the dynamic resource server group to query the dynamic resource update status and read it when updated; and, establish a data access log for each business scenario for the dynamic resource request based on bypass caching, count the access times of each data item as the access heat for each business scenario according to a preset time period and a preset time slice and write it into the hot data access list, count the hot data access list and write it into the access heat accumulation table; after discarding the data items with an access heat less than the acceptance threshold of the hot data recognition standard, sort them according to the access heat size, and store the first set number of data items in the hot data recognition table; the access heat of each data item in the hot data recognition table is revised by introducing trend prediction; the proxy server executes the negotiation cache mechanism and the strong cache mechanism based on the proxy server cache;

[0031] An active cache scheduling server, which is used to drive the addition of the new hot data and deletion of the cold data in the browser local cache, the proxy server cache and the distributed cache based on heat; and actively update or delete the old hot data existing in the browser local cache, the proxy server cache and the distributed cache based on data according to the data change in the database;

[0032] A database, which is used to store the original data and synchronize it with the browser local cache, the proxy server cache and the distributed cache based on the read-write through strategy.

[0033] On the other hand, the present invention also provides a computer-readable storage medium, on which a computer program / instructions are stored, and when the computer program / instructions are executed by a processor, the steps of the above method are implemented.

[0034] On the other hand, the present invention also provides a computer program product, including computer program / instructions, and when the computer program / instructions are executed by a processor, the steps of the above method are implemented.

[0035] The beneficial effects of the present invention are at least as follows:

[0036] In the method and device for multi-level braking cache of hot data with front-end and back-end integration according to the present invention, based on the negotiation cache and strong cache for data calling by the client browser, the proxy server distributes static resource requests to the static resource server group for querying and reading static resources and forwards dynamic resource requests to the dynamic resource server group to query dynamic resources. At the same time, through access volume statistics and trend prediction, the cold and hot data are identified by bypass, and the changes of cold and hot data and the data changes in the original database are monitored to actively update, add or delete the multi-level cache including the browser local cache, proxy server cache and distributed cache, improving the response speed and reading efficiency of accessing hot data, and having outstanding effects in scenarios with clear business scenarios, linear trend directions, relatively frequent data updates, and high data consistency requirements.

[0037] The additional advantages, objectives, and features of the present invention will be partially described below, and will become partially obvious to those of ordinary skill in the art after studying the following text, or can be learned from the practice of the present invention. The objectives and other advantages of the present invention can be achieved and obtained through the structures specifically pointed out in the specification and the drawings.

[0038] Those skilled in the art will understand that the objectives and advantages that can be achieved by the present invention are not limited to the above specific descriptions, and the above and other objectives that the present invention can achieve will be more clearly understood according to the following detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] The drawings described herein are used to provide a further understanding of the present invention, form a part of this application, and do not limit the present invention. In the drawings:

[0040] Figure 1 It is a schematic flowchart of the method for multi-level braking cache of hot data with front-end and back-end integration according to an embodiment of the present invention.

[0041] Figure 2 It is a structure diagram of separating static and dynamic data in the method for multi-level braking cache of hot data with front-end and back-end integration according to an embodiment of the present invention.

[0042] Figure 3 It is a schematic diagram of the hot data accumulation logic in the method for multi-level braking cache of hot data with front-end and back-end integration according to an embodiment of the present invention.

[0043] Figure 4 It is a schematic diagram of the hot data bypass identification logic in the method for multi-level braking cache of hot data with front-end and back-end integration according to an embodiment of the present invention.

[0044] Figure 5 Schematic diagram of the hot data bypass determination logic with trend prediction in the front - end and back - end integrated multi - level braking cache method according to an embodiment of the present invention.

[0045] Figure 6 Schematic diagram of the new hot data and cold data determination logic in the front - end and back - end integrated multi - level braking cache method according to an embodiment of the present invention.

[0046] Figure 7 Structural diagram of the hot and cold data bypass determination in the front - end and back - end integrated multi - level braking cache method according to an embodiment of the present invention.

[0047] Figure 8 Schematic diagram of the active cache scheduling logic in the front - end and back - end integrated multi - level braking cache method according to an embodiment of the present invention.

[0048] Figure 9 Schematic diagram of the front - end cache management logic in the front - end and back - end integrated multi - level braking cache method according to an embodiment of the present invention.

[0049] Figure 10 Overall structural diagram of the front - end and back - end integrated multi - level braking cache method according to an embodiment of the present invention. Detailed implementation manners

[0050] In order to make the objectives, technical solutions and advantages of the present invention more clear and understandable, the present invention will be further described in detail below in combination with the implementation manners and the accompanying drawings. Here, the illustrative implementation manners of the present invention and their descriptions are used to explain the present invention, but do not limit the present invention.

[0051] Here, it also needs to be noted that in order to avoid obscuring the present invention due to unnecessary details, only the structures and / or processing steps closely related to the solution of the present invention are shown in the drawings, while other details less related to the present invention are omitted.

[0052] It should be emphasized that the term "including / comprising" when used herein refers to the presence of features, elements, steps or components, but does not exclude the presence or addition of one or more other features, elements, steps or components.

[0053] Here, it also needs to be noted that if not otherwise specified, the term "connection" in this article can not only refer to direct connection, but also represent indirect connection with intermediaries.

[0054] Hereinafter, embodiments of the present invention will be described with reference to the drawings. In the drawings, the same reference numerals represent the same or similar components, or the same or similar steps.

[0055] The present invention provides a front - end and back - end integrated multi - level cache technology architecture for the application scenario of high - frequency access to hot data with a relatively fast update frequency, a moderate data volume scale, and a high requirement for data consistency, so as to meet the read - write access requirements for hot data. In the currently common multi - level bypass cache architecture, the cache architecture technology of the server side is mainly focused on, and there is no systematic sorting out of the integrated use of the front - end cache. In the more common application scenarios of the Internet, the total amount of data is generally large, and the full - volume cache scheme is usually not considered. In this case, for the relatively small - scale hot data that is not full - volume in Internet applications, it is more suitable to design an active multi - level cache architecture AMC (Active Multilevel Cache) that unifies and integrates the front - end and back - end cache scheduling technologies.

[0056] One aspect of the present invention provides a multi - level active cache method for hot data with front - end and back - end integration, referring to Figure 1 and Figure 9 , the method includes the following steps S101 - S105. In the operating environment of the method, there are a client, a proxy server, a static resource server group, a dynamic resource server group, and a database.

[0057] Step S101: When the client browser requests a resource, it queries the resource update status from the proxy server based on the negotiation cache mechanism. In the case of no update, it preferentially calls the data in the browser local cache based on the strong cache mechanism.

[0058] Step S102: The proxy server receives the client access request, distributes the static resource request therein to the static resource server group to query the static resource update status and reads it when updated, and forwards the dynamic resource request therein to the dynamic resource server group to query the dynamic resource update status and reads it when updated; the dynamic resource server group adopts distributed caching; the proxy server executes the negotiation cache mechanism and the strong cache mechanism based on the proxy server cache.

[0059] Step S103: The proxy server establishes a data access log for each business scenario for the dynamic resource request based on the bypass cache, counts the access times of each data item as the access heat for each business scenario according to a preset time period and a preset time slice, and writes it into the hot data access list, counts the hot data access list and writes it into the access heat accumulation table; after discarding the data items with an access heat less than the acceptance threshold of the hot data determination standard, sort them according to the access heat size, and store the first set number of data items into the hot data determination table; the access heat of each data item in the hot data determination table is revised by introducing trend prediction.

[0060] Step S104: The proxy server marks the data items that existed in the previous time period but do not exist in the current time period in the hot data recognition table as new hot data, and defines the data items that did not exist in the previous time period but exist in the current time period as cold data; and pushes the content of the new hot data and cold data to the active cache scheduling server.

[0061] Step S105: The active cache scheduling server adds new hot data and deletes cold data in the browser local cache, proxy server cache, and distributed cache based on heat drive; and actively updates or deletes the old hot data existing in the browser local cache, proxy server cache, and distributed cache according to the data changes in the database based on data drive.

[0062] In steps S101 to S105, the main logic is to read data based on the negotiated cache mechanism and strong cache mechanism when the client's browser initiates a data request. In the case of synchronizing the cache data and the data update status in the database, the data in the browser local cache is preferentially used. For the client's data request, the proxy server hands over the static resources to the static resource server group for processing, and hands over the dynamic resources to the dynamic resource server group. The two perform targeted architecture design according to the different characteristics of the dynamic and static resources, which can improve efficiency. The proxy server also conducts bypass recognition of hot and cold data for hot data, and introduces trend prediction for revision. Based on the recognition results of hot and cold data, new hot data in the multi-level cache is added, cold data is deleted, and the data that has changed in the database is modified to meet the client's fast access requirements for hot data and improve access efficiency.

[0063] In step S101, the client is a device that directly interacts with the user. It accesses and processes data by loading a browser or an application. The negotiation caching mechanism means that the browser first sends a request to the backend server to inquire whether the resource to be accessed has been updated. The server will reply to the browser whether to use the browser cache or the server-side resources based on the update status of the resource. The negotiation cache depends on the Last-Modified or ETag in the HTTP response header and the If-Modified-Since and If-None-Match fields in the HTTP request header. Last-Modified is an HTTP header returned by the server in the response, indicating the last modification time of the resource. This time is the time when the server believes the resource was last modified. When the browser requests a certain resource, the server tells the browser the last modification time of the resource through Last-Modified, and the browser can use this time to determine whether the resource in the cache has expired. If-Modified-Since is an HTTP header attached by the browser when making a request, indicating the time when the browser last cached the resource. The browser will set If-Modified-Since to the Last-Modified time stored in the cache in subsequent requests to inquire whether the resource has been updated. When the browser requests the resource again, it will send an If-Modified-Since request header, and the server can judge whether the resource has changed based on this time. If the resource has not changed since the last cache, the server will return a 304 Not Modified response, indicating that the client can continue to use the cached version. If the resource has changed, the server will return the new resource. ETag is a unique identifier generated by the server, which represents the content or status of the resource. Different from Last-Modified, ETag is based on the hash value or unique identifier of the resource content, which enables it to provide more precise cache control. Each time the resource content changes, the value of ETag also changes. ETag allows the server to more precisely judge whether the resource has been updated. Even if the modification time of the resource has not changed, as long as the content of the resource has changed, the value of ETag will change. When the browser makes a request, it will send an If-None-Match request header and send the ETag value saved during caching to the server to inquire whether the resource has changed. The strong caching mechanism means that when the browser requests a resource, it will first check whether there is a copy of the resource in the local cache and whether the copy has expired. If the copy of the resource has not expired, the browser directly uses the local cache and does not send a request to the server, thus accelerating the web page loading speed. The implementation of the strong cache depends on two fields in the HTTP response header: Expires and Cache-Control.Expires is one of the HTTP response headers used to specify the expiration time of a resource, that is, the date and time when the browser's cache of the resource becomes invalid. Before this time, the browser can directly use the resource from the cache without having to request the server again. Cache-Control is a response header introduced by the HTTP / 1.1 standard, which is used to replace or supplement Expires. It provides more control options for managing browser caches, using relative time (in seconds) to specify the cache duration of resources, which is more flexible and precise.

[0064] At the same time, by building a front-end database, for data resources in the form of NoSql databases, especially those data sets that may further require front-end filtering, screening, searching and other computational operations, IndexedDB can be used for data caching and operations. IndexedDB is a client-side database provided by the browser that can store a large amount of structured data and supports transaction operations.

[0065] The browser will pre-cache resources on the side or listen for caches for resource requests, etc. This is generally implemented using the Service Worker scripting technology, mainly relying on Web Worker scheduling and using localStorage and IndexDB for caching. During access, it can directly intercept corresponding resource requests. When a hit can be made, it can directly obtain from the local cache without actually sending a request to the server. When the cache policy is effective, it can still provide basic page access functions in a poor network environment or when the network is disconnected. When using Service Worker for browser cache scheduling, the negotiation cache mechanism can also be used to ensure data consistency.

[0066] In step S102, the proxy server is a server located between the client and the original (resource) server. To obtain content from the original server, the client sends a request to the proxy server and specifies the target original server. Then the proxy server forwards the request and returns the obtained content to the client. The proxy server is often used as an application gateway. At the same time, as a link in the network resource access and acquisition chain, the proxy service can also support the negotiated caching and forced caching policies in the HTTP protocol. The proxy service caching depends on two fields in the HTTP response header of the HTTP response: the Expires and Cache-Control fields. When the value of Cache-Control is public, all content will be cached (both the client and the proxy server can cache). However, even when the value of Cache-Control is other, the proxy server can also ignore this setting and force the use of the proxy service cache. Distributed caching is a technology that caches data on multiple nodes to improve data access speed. It supports horizontal linear scaling and can increase the cache capacity and performance by adding more nodes. It has high performance and can improve the concurrent access speed by dispersing the storage of data. At the same time, it can also avoid single points of failure and ensure the high availability of the cache service through multiple replicas and replica consistency.

[0067] The proxy server differentiates between dynamic and static resources for the client access request and performs dynamic and static separation. Dynamic and static separation refers to a method of separating static resources (static data) and dynamic resources (dynamic data) into different system architecture designs in a typical Web application architecture, thereby further improving the access performance and maintainability of the entire application.

[0068] As Figure 2 shown, dynamic and static separation is mainly achieved by making corresponding settings on the reverse proxy server. At this time, the proxy server, as the dynamic and static separation gateway, can distribute requests for static resources to a common, simpler, and faster Web server group, and forward requests for dynamic resources (dynamic data) to the backend application server group for processing. This architecture design method can improve the accessibility and maintainability of the entire service. It enables the services at each link to be architected according to the different characteristics of dynamic and static resources.

[0069] The distributed caching of the dynamic resource server group is a technology that caches data on multiple nodes to improve data access speed. It supports horizontal linear scaling and can increase the cache capacity and performance by adding more nodes. It has high performance and can improve the concurrent access speed by dispersing the storage of data. At the same time, it can also avoid single points of failure and ensure the high availability of the cache service through multiple replicas and replica consistency.

[0070] In step S103, the proxy server performs hot data bypass determination and uses the shared access logs of the proxy server or the load server to confirm using the Hot Data Bypass Detection System (HDBDS). The access logs are stored at fixed time slices (here, an independent file is generated daily), which can further improve the read and write efficiency of the access logs. The hot data bypass determination application server reads the corresponding new logs regularly and statistically analyzes the logs.

[0071] Access Popularity (AP) means that one access by a user to a piece of data generates one "access point" for this data. The sum of all access point values within a statistical time period is the access popularity of this data item.

[0072] Based on the Least Frequency Used (LFU) algorithm, it is considered that the data with the highest frequency of occurrence in historical data is hot data. Its core idea is that hot data that is likely to be accessed in the future is the data that has been frequently accessed in the past. To implement this algorithm, it is necessary to count the number of accesses of each data item in the access pattern and sort the data in ascending order according to the number of accesses. When the cache capacity is insufficient, the data with the fewest accesses in the cache is eliminated.

[0073] Define the hot data statistical time range (TR). Different statistical time ranges are required for hot data statistics in different dimensions. Taking the "24-hour hot news" in a certain content publishing application as an example, the length of its statistical time range can be 24 hours. For "real-time hotspots", the length of its statistical time slice can be 1 hour.

[0074] Define the hot data statistical time slice (TS). Different "statistical time slices" are also required for hot data statistics in different dimensions. Taking the "24-hour hot news" in a certain content publishing application as an example, considering the control of the calculation frequency and the requirement for quickly presenting information with rapidly increasing popularity, the length of its hot data statistical time granularity is preferably about 30 minutes. For "real-time hotspots", the shorter the length of its statistical time granularity, the better. Considering the control of the calculation frequency and the requirement for quickly presenting information with rapidly increasing popularity, 1 minute is appropriate.

[0075] Define the Access Popularity Statistics Table (APST). For the hot data analysis of a certain dimension, it is necessary to accumulate each data access log in the application.

[0076] Such asFigure 3 As shown, the implementation method is a list of access popularity records (APRL) for the length of a TR / TS. When the system runs to a TS duration trigger point, the current time TheTime is recorded, then:

[0077] The statistical time interval for this round, This TS, is: [The Time - TS, The Time]; the slice sequence number in the statistical table, APST SEQ, is: Mod(The Time - TR Begin Time, The Time).

[0078] The statistical application server will collect all the data acquisition behaviors GetData (see ① in Figure 2 below) within the time interval of This TS in all the access log information of the current TS, and accumulate them with DataKey (the keyword of the data is usually the Hash value of the URL for data acquisition, and this URL value should also be saved for subsequent cache scheduling) as the statistical classification (see ② in Figure 2 below). The corresponding accumulation operation of the data should be updated into the APST SEQ item in the APST sub - table (see ④⑤ in Figure 2 below).

[0079] After accumulating all the acquisition operations in the data access log within the time range of This TS, the sum (SUM) of the accumulated result items in each APST sub - table can be calculated to obtain the total access point value of the current Data within the TR range, that is, the current popularity AP, and update the AP value of the corresponding item in the APST table (see ⑥⑦ in Figure 2 below).

[0080] After obtaining the APST of all data after analyzing the logs in the bypass, the AP can be sorted. During the sorting process, half - value discarding can be performed according to historical data to simplify the calculation.

[0081] Define the quantity of hot data (QHD). For the access popularity accumulation table that has been sorted, determine which data in the access popularity accumulation table are hot data ultimately. Usually, this value is also directly related to the size of the cache space that the system can allocate.

[0082] Define the threshold of hot data acceptance (THD). The threshold of hot data acceptance usually uses half of the minimum AP value in the result of the previous hot data calculation, which is the minimum requirement for data items to be recognized as hot data. It is mainly used for the half - value discarding process to reduce the calculation amount.

[0083] Define the Hot Data Table (HDT). For the final result after hot data determination calculation, save it into the Hot Data Table.

[0084] As Figure 4 shown, during hot data detection, first discard all data records in the APST of this determination calculation where the AP is less than THD, and do not participate in the sorting calculation (see Figure 3 ①② in

[0085] Save the APST with an AP value higher than the threshold into the HDT-1 table and sort it (see Figure 3 ③ in Figure 3 ), and save the result into the HDT-2 table. According to the business logic requirements, pre-determine the hot data for the first QHD data sorted in the HDT-2 table and store it in the hot data determination table HDT (see

[0086] ④⑤ in

[0087] At this point, the hot data calculation for this round is completed. Finally, according to the result set of the hot data, take the minimum AP value in the result set to update the hot data determination standard acceptance threshold THD (see Figure 3 ⑥⑦ in

[0088] In a business scenario with obvious trend characteristics, the data access trend of the next time slice TS can be further predicted.

[0089] As Figure 5 shown, when the trend value of the next TS in the business logic will not absolutely affect the AP value of the HDT, half-value discard can be performed in advance, otherwise this step should be skipped. Add a TAP field to the HDT-1 table after half-value discard to store the trend prediction value for the next TS cycle. At this time, the AP values of all TSs in this TR cycle corresponding to this DATA in the APRL can be used for trend calculation. The calculation result is the AP prediction value for the next TS period, denoted as TAP here, and stored in the TAP field. Let the trend function be Trend, expressed as: TAP = Trend(known_x's, known_y's).

[0090] To balance the calculation resources and the resource conflict of cache scheduling optimization, the straight-line trend prediction algorithm with less calculation amount is used here.

[0091] In some embodiments, the access heat of each data item in the hot data recognition table is revised by introducing trend prediction, including steps S201 to S202:

[0092] Step S201: Fit the access heat of a single data item at each time slice in the current time period based on linear trend prediction, and infer the predicted access heat value corresponding to each time slice in the next time period. The expression is:

[0093]

[0094] where y t represents the actual observed value of the time slice at time t in the current time period, represents the predicted access heat value of the time slice at time t in the next time period; a is the intercept of the linear fit, and b is the slope of the linear fit; is the mean value of y t , is the mean value of time; n represents the number of data points.

[0095] The advantages of this method are that the occupied algorithm is simple, the consumed computing resources are small, it is applicable to various fields, and it can provide a certain prediction accuracy. The disadvantage is that it assumes a linear relationship between data, and the prediction effect for non-linear relationship data is not good, so it cannot capture the short-term fluctuations of data.

[0096] Step S202: Perform weighted averaging on the observed access heat values of the data items in each time slice in the hot data access volume list in the current time period and the predicted access heat values in each time slice in the next time period to revise the access heat of each data item.

[0097] In real-world operations, there are business scenarios where there are obvious boundaries in certain rising trends. For example, in the scenario of a full-population voting of a certain group of people, the future trend value cannot be greater than the total population. However, due to the overly obvious rising amplitude of the starting trend, the linear trend prediction algorithm may predict a trend value far greater than the total population. To further balance the absolute impact of the trend prediction value on hot data recognition, it is necessary to further consider the impact of historical AP data. Here, a new algorithm is introduced.

[0098] In some embodiments, the access heat of each data item in the hot data recognition table is revised by introducing trend prediction, including steps S301 to S302:

[0099] Step S301: Use the number of occurrences of the data item at the corresponding time slice in multiple time periods as the weight, and perform weighted averaging on the observed access heat values of the data item at the corresponding time slice in multiple time periods to obtain the predicted access heat value of the data item at the corresponding time slice in the next time period. The calculation formula is:

[0100]

[0101] Among them, x i represents the observed value of the access popularity of the data item within the target time slice in the i-th time period, and w i represents the weight of the i-th time period, and n represents the number of time periods; represents the predicted access popularity value.

[0102] Step S302: Perform a weighted average on the observed access popularity values of the data items in each time slice in the hot data access volume list of the current time period and the predicted access popularity values in each time slice of the next time period to revise the access popularity of each data item.

[0103] The advantages of this method are simple calculation and easy implementation. Especially, it has high flexibility. The weighted average method assigns different weights to different data, and the size of the weights can be adjusted according to specific business needs, so as to better reflect the actual situation. Considering the importance of different indicators: In the weighted average method, different indicators are weighted, and the weights can be adjusted according to actual needs and the importance of the indicators, which can more truly reflect the actual situation of the data and make the final result more objective and accurate. It can also further reduce the impact of abnormal data. By adjusting the weights, the abnormal values in the data can be balanced, so as to obtain a more accurate data average. The main disadvantages are that the subjective factor is relatively large. The adjustment of weights usually relies on human experience and machine learning. Different human experiences and the sample coverage of machine learning will lead to differences in weight settings, affecting the results of the weighted average method. It has relatively high requirements for data distribution: The weighted average method is applicable to the case of normal data distribution. If the data has a skewed distribution or extreme values, it will affect the results of the weighted average method.

[0104] In steps S202 and S302, when performing a weighted average on the observed access popularity values and the predicted access popularity values of the data items in the hot data recognition table to revise the access popularity of each data item, the weight of the observed access popularity value is 1, and the weight of the predicted access popularity value is the ratio of the preset time period to the preset time slice length. For the data item AP in the hot data access volume list APRL, the weights are all assigned as 1 during the weighted average process, and for the calculated trend value TAP, the weight is TR / TS. The value obtained by performing a weighted average calculation using all the AP values and TAP values in the APRL table and the corresponding weights is the final AP value in the HDT table.

[0105] In step S104, during the process of identifying new hot data and cold data, as Figure 6 shown, after obtaining the confirmed HDT table, it is possible to compare it with the OHDT (Old Hot Data Table) of the previous round to confirm new hot data and cold data.

[0106] New hot data (NHDT: New Hot Data Table) refers to data that exists in the current HDT table but does not exist in the OHDT table. These data need to be newly cached. The calculation formula is: NHDT = HDT - OHDT.

[0107] Cold data (CDT: Cold Data Table) refers to data that does not exist in the current HDT table but exists in the OHDT table. These data need to be deleted from the cache. The calculation formula is: CDT = OHDT - HDT.

[0108] After the new hot data and cold data are identified, the identified content is pushed to the active cache scheduling server, and the active cache scheduling server performs the next step of active cache scheduling on the corresponding data.

[0109] Taking the access log as the input, different hot data accumulation and hot data identification modules are triggered according to different business scenarios, and finally the hot data table of this business scenario in this TS round is formed and output. After further access trend calculation, HDT is output, and after comparison with the HDT result of the previous TS round, CDT is output for the use of the active cache scheduling subsystem, thus forming a complete cold and hot data bypass identification subsystem. The functional architecture of this subsystem is as Figure 7 shown.

[0110] In step S105, active cache scheduling is executed and triggered in two cases: The first is heat-driven. When the cold and hot data are determined in this TS round, the cache in the system is changed and scheduled. That is, when the HDT, NHDT, and CDT of a business scenario are identified, the active cache scheduling can be triggered. The second is data-driven. When the data source itself has corresponding changes, the cache scheduling subsystem needs to perform corresponding active updates or cache deletions on the old hot data in the existing cache according to specific situations. In the current system architecture, for the active cache scheduling of hot data caused by the change of the data source itself, it mainly relies on capturing the changed data. The system actively schedules the distributed cache (Redis) and the proxy server cache (Nginx) according to the change situation to achieve this.

[0111] As Figure 8 shown, where the data publisher is various databases for data persistent storage. In this architecture, the MySql database is taken as an example. Since most databases do not support active publishing services, change data capture (CDC: ChangeData Capture) software can be used to implement data publishing. Common software includes Debezium, etc.

[0112] When Debezium detects changed data in the database, it will push the corresponding data to Kafka and generate a corresponding topic (Kafka Topic).

[0113] At this time, the dynamic cache scheduling module that subscribes to the corresponding topic will be triggered, and the distributed cache, proxy server cache, and browser cache will be scheduled accordingly in sequence.

[0114] When the heat drive is triggered, if there is a data item in the NHDT table, it means that new hot data has been generated. At this time, an addition operation needs to be performed on the content of the cache in the multi-level cache whose corresponding key value is DataKey in the NHDT table. If there is a data item in the CDT table, it means that new cold data has been generated. At this time, a deletion operation needs to be performed on the content of the cache in the multi-level cache whose corresponding key value is DataKey in the CDT table.

[0115] When the data drive is triggered, the primary key of the received changed data item is assembled into DataKey. The specific process is to construct the front-end access url based on the primary key of the data and the front-end business access logic, and then perform a Hash operation on it to obtain the DataKey of the current data, and then process it according to the three operation types respectively.

[0116] First, for the addition operation, a record of this data is added to APST, and a TR / TS structure table is created to start accumulating the access heat of this data.

[0117] Second, for the update operation, first find DataKey in HDT. If it exists, it means that hot data has changed. At this time, an update operation needs to be performed on the content of the cache in the multi-level cache whose corresponding key value is DataKey. In particular, the response header field Last-Modified needs to be added to the corresponding data record, and its specific value should be the actual change time of the source data for the server response to output directly.

[0118] Third, for the deletion operation, first find DataKey in HDT. If it exists, it means that hot data has been deleted. At this time, a deletion operation needs to be performed on the content of the cache in the multi-level cache whose corresponding key value is DataKey. It should be noted that when the data source generates a deletion operation, in addition to performing cache deletion scheduling, the scheduler also needs to synchronously delete all records of this data in the APST access heat accumulation table and the data record in the HDT table. To prevent the calculation result from being polluted by the deleted data when performing cold and hot data bypass determination at the next TS time point.

[0119] The addition, deletion, and modification of the distributed cache (Redis) usually directly use the set and del methods for direct operation.

[0120] The implementation of adding and deleting the proxy server cache (Nginx) is relatively cumbersome. Nginx itself is not a programming language environment. It is a lightweight HTTP and reverse proxy server. Therefore, Nginx itself does not support the active cache scheduling function and cannot implement active cache loading. Only by installing third-party module plugins, such as ngx_http_purge_module, can cache scheduling be performed. The purge module can only delete the specified cache that needs to be cleared and cannot actively load the corresponding new cache. For the cache data that needs to be specified for loading, only after being deleted by the purge module, relying on the read-write through cache mechanism, the corresponding cache will be automatically generated when the client requests the first data access request.

[0121] In some embodiments, in the method, the browser local cache, the proxy server cache, and the distributed cache are combined with the database based on the read-write through strategy. The read-write through cache strategy (Read / Write Through) tightly combines the cache (usually referring to the cache service) with the database. When the application reads and writes data, it will operate through the cache layer. If the cache misses, the application will query the data from the database through the cache layer and write the data into the cache; when writing data, the application first writes to the cache and then writes the data into the database through the cache layer. In this way, the data remains consistent between the cache and the database.

[0122] In some embodiments, in the hot data access list, the access heat accumulation table, and the hot data determination table, the hash value of the uniform resource locator of the data is used to mark the data item.

[0123] In various large-scale application scenarios, there is a need to further improve the speed and reduce the latency in the acquisition and utilization of existing data. Front-end computing can move some computing tasks from the server side to the client side, making some data processing and analysis calculations closer to the customer, thereby significantly reducing the number of data transmissions, the time, and the network bandwidth occupation. And the front-end persistent data storage technology that supports this type of front-end computing application scenario is the front-end database.

[0124] Furthermore, in this architecture, to distinguish between the data for front-end complex calculations and the data for ordinary display. The front-end cache cooperates with the dynamic and static separation strategy of the back-end cache and performs differential processing. The cache of static resources (static data) is not actively scheduled by the front-end and completely relies on the cache strategy of the browser itself. The dynamic resources (dynamic data) adopt the architecture of bypass cache and still rely on the time validity of the multi-level back-end cache. The cache of all access results will be bypassed according to the header information to determine whether to cache. In this architecture, Service Worker is used for front-end bypass cache scheduling, and the cache is further uniformly managed in the bypass. The revalidation when stale strategy is used to verify the data consistency, and its implementation logic is asFigure 9 as shown

[0125] When using a Service Worker, a situation regarding HTTP status code 304 may be encountered. The 304 status code means that the requested resource has not been modified and the cached version can be used continuously. When the fetch event handler in the Service Worker detects that a certain resource returns a 304 status code, specific processing may be carried out. First, ensure that the requested resource is correctly cached and use the cache when the resource is valid. Second, when the resource changes, ensure that the Service Worker can update the resource in the cache.

[0126] Correspondingly to the above method, the present invention also provides a device / system, which includes a computer device. The computer device includes a processor and a memory. Computer instructions are stored in the memory. The processor is used to execute the computer instructions stored in the memory. When the computer instructions are executed by the processor, the device / system implements the steps of the method described above.

[0127] The embodiment of the present invention also provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, it implements the steps of the aforementioned edge computing server deployment method. The computer-readable storage medium can be a tangible storage medium, such as random access memory (RAM), memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, floppy disks, hard disks, removable storage disks, CD-ROMs, or any other form of storage medium well-known in the technical field.

[0128] On the other hand, the present invention also provides a multi-level braking cache device for hot data with front-end and back-end integration, including:

[0129] A client, which is used to load a browser, query the resource update status from the proxy server based on the negotiation cache mechanism when requesting a resource, and preferentially call the data in the browser local cache based on the strong cache mechanism in the case of no update;

[0130] A static resource server group, which is used to cache static resources;

[0131] A dynamic resource server group, which is used to cache dynamic resources based on distributed storage;

[0132] A proxy server is used to receive the client access request, distribute the static resource request therein to the static resource server group for querying the static resource update status and reading it when updating, and forward the dynamic resource request therein to the dynamic resource server group for querying the dynamic resource update status and reading it when updating; and, based on the bypass cache, establish a data access log under each business scenario for the dynamic resource request, count the number of accesses to each data item as the access heat according to the preset time period and preset time slice for each business scenario and write it into a hot data access list, count the hot data access list and write it into an access heat accumulation table; after discarding the data items whose access heat is less than the acceptance threshold of the hot data identification standard, sort them according to the access heat size, and store the first set number of data items into the hot data identification table; the access heat of each data item in the hot data identification table is revised by introducing trend prediction; the proxy server executes the negotiated cache mechanism and the strong cache mechanism based on the proxy server cache;

[0133] An active cache scheduling server is used to drive the browser local cache, the proxy server cache and the distributed cache to add the new hot data and delete the cold data based on the heat; and to actively update or delete the old hot data already in the browser local cache, the proxy server cache and the distributed cache based on the data change in the database based on the data drive;

[0134] The database is used to store original data and synchronize with the browser local cache, the proxy server cache and the distributed cache based on a read-write penetration strategy.

[0135] The cache scheduling process is as follows: Figure 10 As shown. When the client's browser initiates a request, ServiceWorker will take over and judge the request. When the request is for static resources, no further processing is performed and it is completed by the browser's own default mechanism. When the request is for dynamic data, Service Worker first requests the data and loads it into the browser cache. When other scripts on the page need to use data, they directly read it from the cache without making data requests.

[0136] The request initiated by the front end to the system first reaches the dynamic and static separation gateway. Among them, the corresponding static resource request will be forwarded to the static resource load balancing server (also static resource proxy service cache), which will return the local cache to the request according to the specific situation, or further forward the request to the rear static resource server group.

[0137] The corresponding dynamic data requests will be forwarded to the dynamic data load balancing server (which also serves as the dynamic data proxy service cache). This server will return the local cache to the request according to the specific situation, or further forward the request to the back-end application server group, while recording the corresponding access records in the log file on the distributed file server.

[0138] When the request penetrates the dynamic data proxy service cache and reaches the application server, the application server will query the distributed cache. If a hit occurs, it will return the data in the distributed cache. If not, it will further perform database or file system read operations to obtain the data and then return it to the client.

[0139] The log files generated by user access will be regularly analyzed by the hot data bypass recognition module with trend prediction factors. The hot and cold data will be recognized according to different business scenarios, and the corresponding results will be saved in the database. Then, the heat-driven trigger will activate the active cache scheduling module to update the multi-level cache.

[0140] Meanwhile, if the relevant business of the application server performs corresponding write operations on the confirmed hot data. After being captured by the change data capture module, the data-driven trigger will activate the active cache scheduling module to update the multi-level cache.

[0141] In summary, in the method and device for multi-level active caching of hot data with front-end and back-end integration described in the present invention, based on the data call of the client browser using negotiated caching and strong caching, the proxy server distributes static resource requests to the static resource server group for querying and reading static resources and forwards dynamic resource requests to the dynamic resource server group to query dynamic resources. At the same time, the hot and cold data are bypass-recognized through access volume statistics and trend prediction, and the changes in hot and cold data as well as the data changes in the original database are monitored to actively update, add, or delete the multi-level cache including the browser local cache, proxy server cache, and distributed cache, improving the response speed and reading efficiency for accessing hot data, and showing outstanding effects in scenarios with clear business scenarios, linear trend directions, relatively frequent data updates, and high data consistency requirements.

[0142] Those of ordinary skill in the art should understand that the various exemplary components, systems, and methods described in connection with the embodiments disclosed herein can be implemented in hardware, software, or a combination of both. Specifically, whether to implement in hardware or software depends on the specific application and design constraints of the technical solution. Professional technicians can use different methods for each specific application to implement the described functions, but such implementation should not be considered to exceed the scope of the present invention. When implemented in hardware, it can be, for example, an electronic circuit, an application-specific integrated circuit (ASIC), appropriate firmware, a plug-in, a functional card, and so on. When implemented in software, the elements of the present invention are programs or code segments used to perform the required tasks. The program or code segment can be stored in a machine-readable medium or transmitted via a data signal carried in a carrier wave on a transmission medium or a communication link.

[0143] It should be clear that the present invention is not limited to the specific configurations and processes described above and illustrated in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and illustrated as examples. However, the method process of the present invention is not limited to the specific steps described and illustrated. Those skilled in the art can make various changes, modifications, and additions, or change the order between steps after understanding the spirit of the present invention.

[0144] In the present invention, the features described and / or illustrated for one embodiment can be used in the same or a similar manner in one or more other embodiments, and / or combined with the features of other embodiments or replace the features of other embodiments.

[0145] The above are only the preferred embodiments of the present invention and are not used to limit the present invention. For those skilled in the art, various changes and modifications can be made to the embodiments of the present invention. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included within the protection scope of the present invention.

Claims

1. A multi-level braking cache method for hot data with front-end and back-end fusion, characterized in that: The method comprises the following steps: When requesting a resource, the client browser queries the proxy server for resource update status based on the negotiated cache mechanism, and in the absence of an update, preferentially calls the data in the browser local cache based on the strong cache mechanism; The proxy server receives the client access request, distributes the static resource request therein to the static resource server group for querying the static resource update status and reading it when updating, and forwards the dynamic resource request therein to the dynamic resource server group for querying the dynamic resource update status and reading it when updating; the dynamic resource server group adopts distributed cache; the proxy server executes the negotiation cache mechanism and the strong cache mechanism based on the proxy server cache; The proxy server establishes a data access log for each business scenario for the dynamic resource request based on the bypass cache, counts the number of accesses to each data item as the access heat and writes it into a hot data access list according to a preset time period and a preset time slice for each business scenario, counts the hot data access list and writes it into an access heat accumulation table; after discarding the data items whose access heat is less than the acceptance threshold of the hot data identification standard, sorts them according to the size of the access heat, and stores the first set number of data items into the hot data identification table; the access heat of each data item in the hot data identification table is revised by introducing trend prediction; The proxy server marks the data items in the hot data identification table that existed in the previous time period but not in the current time period as new hot data, and defines the data items that did not exist in the previous time period but exist in the current time period as cold data; and pushes the content values ​​of the new hot data and the cold data to the active cache scheduling server; The active cache scheduling server adds the new hot data and deletes the cold data in the browser local cache, the proxy server cache and the distributed cache based on heat drive; and actively updates or deletes the old hot data already in the browser local cache, the proxy server cache and the distributed cache based on data drive according to data changes in the database.

2. The hot data multi-level braking cache method with front-end and back-end fusion according to claim 1 is characterized in that: In the method, the browser local cache, the proxy server cache and the distributed cache are combined with the database based on a read-write penetration strategy.

3. The hot data multi-level braking cache method with front-end and back-end fusion according to claim 1 is characterized in that: The acceptance threshold of the hot data identification standard is half of the minimum access heat in the access heat accumulation table in the previous period.

4. The hot data multi-level braking cache method with front-end and back-end fusion according to claim 1 is characterized in that: The access popularity of each data item in the hot data identification table is revised by introducing trend prediction, including: Based on the linear trend prediction, the access popularity of a single data item in each time slice in the current time period is fitted, and the predicted access popularity value corresponding to each time slice in the next time period is inferred. The expression is: Among them, y t Represents the actual observed value of the time slice at time t in the current time period, Indicates the predicted access heat value of the time slice at time t in the next time period; a is the intercept of the straight line fitting, and b is the slope of the straight line fitting; for y t The mean of is the mean of time; n represents the number of data points; The access heat observation value of the data item in each time slice in the hot data access volume list of the current time period and the predicted access heat value in each time slice of the next time period are weighted averaged to revise the access heat of each data item.

5. The hot data multi-level braking cache method with front-end and back-end fusion according to claim 1 is characterized in that: The access popularity of each data item in the hot data identification table is revised by introducing trend prediction, including: Taking the number of times the data item appears in the corresponding time slices in multiple time periods as the weight, the observed values ​​of the access heat of the data item in the corresponding time slices in multiple time periods are weighted averaged to obtain the predicted access heat value of the data item in the next time period corresponding to the corresponding time slice. The calculation formula is: Among them, x i represents the observed value of the access heat of the data item in the target time slice of the i-th time period, w i represents the weight of the i-th time period, and n represents the number of time periods; Indicates the predicted access heat value; The access heat observation value of the data item in each time slice in the hot data access volume list of the current time period and the predicted access heat value in each time slice of the next time period are weighted averaged to revise the access heat of each data item.

6. The front-end and back-end fused hot data multi-level braking cache method according to any one of claims 4 or 5, characterized in that: The access heat observation value and the predicted access heat value of each data item in the hot data identification table are weighted averaged to revise the access heat of each data item, where the weight of the access heat observation value is 1, and the weight of the predicted access heat value is the ratio of the preset time period to the preset time slice length.

7. The hot data multi-level braking cache method with front-end and back-end fusion according to claim 1 is characterized in that: The hot data access list, the access heat accumulation table and the hot data identification table use the hash value of the uniform resource locator of the data to mark the data item.

8. A multi-level braking cache device for hot data with front-end and back-end fusion, characterized in that: include: The client is used to load the browser, query the proxy server for resource update status based on the negotiated cache mechanism when requesting resources, and preferentially call the data in the browser local cache based on the strong cache mechanism when there is no update; Static resource server group, used to cache static resources; Dynamic resource server group, used for caching dynamic resources based on distributed storage; A proxy server is used to receive the client access request, distribute the static resource request therein to the static resource server group for querying the static resource update status and reading it when updating, and forward the dynamic resource request therein to the dynamic resource server group for querying the dynamic resource update status and reading it when updating; and, based on the bypass cache, establish a data access log for each business scenario for the dynamic resource request, count the number of accesses to each data item as access heat according to a preset time period and a preset time slice for each business scenario and write it into a hot data access list, count the hot data access list and write it into an access heat accumulation table; After discarding the data items whose access heat is less than the acceptance threshold of the hot data identification standard, the first set number of data items are sorted according to the access heat, and stored in the hot data identification table; the access heat of each data item in the hot data identification table is revised by introducing trend prediction; the proxy server executes the negotiation cache mechanism and the strong cache mechanism based on the proxy server cache; An active cache scheduling server, used for driving, based on heat, adding the new hot data and deleting the cold data in the browser local cache, the proxy server cache and the distributed cache; And actively updating or deleting old hot data already in the browser local cache, the proxy server cache and the distributed cache based on data drive according to data changes in the database; The database is used to store original data and synchronize with the browser local cache, the proxy server cache and the distributed cache based on a read-write penetration strategy.

9. A computer-readable storage medium having a computer program / instruction stored thereon, characterized in that: When the computer program / instructions are executed by a processor, the steps of the method as claimed in any one of claims 1 to 7 are implemented.

10. A computer program product comprising a computer program / instructions, characterized in that When the computer program / instructions are executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images