Front and back end fusion hot data multi-level active cache method and device

Abstract

The application provides a front and back end fused hot data multi-level active caching method and device. Based on the data calling of the client browser based on the negotiation cache and the strong cache, the static resource request is distributed to the static resource server group through the proxy server for querying and reading static resources and forwarding the dynamic resource request to the dynamic resource server group for querying dynamic resources. Meanwhile, the access volume statistics and trend prediction are used to identify the bypass of hot and cold data, monitor the changes of hot and cold data and the changes of data in the original database to actively update, add or delete the multi-level cache including the browser local cache, the proxy server cache and the distributed cache, improve the response speed and reading efficiency of hot data access, and the effect is outstanding in the scene where the business scene is clear, the trend is linear, the data update frequency is relatively frequent, and the data consistency requirement is relatively high.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data caching, and in particular to a front-end and back-end fusion hot data multi-level active caching method and device. BACKGROUND

[0002] Hot data refers to frequently accessed and used data. These data usually need to be accessed and responded quickly, so they are usually stored on storage media with high performance and fast access speed, and usually provide more optimized access solutions.

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

[0004] With the development of the Internet, the access volume of hot data in applications is increasing, which leads to a sudden increase in network, application, database, storage and I / O (input / output) pressure, and it is urgent to solve how to efficiently process these high-frequency access hot data. In particular, in the scene 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 demand, so a fusion caching architecture combining front-end caching, back-end multi-level caching and trend prediction algorithm is needed to improve system performance and data response speed. SUMMARY

[0005] In view of this, the present application embodiment provides a front-end and back-end fusion hot data multi-level active caching method and device to eliminate or improve one or more defects in the prior art and solve the caching pressure generated by the prior art in the face of hot data access improvement.

[0006] One aspect of the present application provides a front-end and back-end fusion hot data multi-level active caching method, which comprises the following steps:

[0007] The client browser queries the resource update state to the proxy server based on the negotiation caching mechanism when requesting resources, 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 a client access request, distributes static resource requests therein to a static resource server group for querying static resource update status and reading when updated, forwards dynamic resource requests therein to a dynamic resource server group for querying dynamic resource update status and reading when updated; the dynamic resource server group adopts distributed caching; the proxy server performs the negotiation caching mechanism and the strong caching mechanism based on proxy server caching;

[0009] The proxy server establishes data access logs under each service scenario for the dynamic resource requests based on bypass caching, counts access frequencies to each data item as access heat and writes into a hot data access list for each service scenario according to a preset time period and a preset time slice, and counts the hot data access list and writes into an access heat accumulation table; after discarding data items with access heat less than a hot data identification standard acceptance threshold, the first set number of data items are stored into a hot data identification table according to the access heat size order; the access heat of each data item in the hot data identification table is revised by introducing trend prediction;

[0010] The proxy server marks data items existing in a previous time period but not existing in a current time period in the hot data identification table as new hot data, and defines data items not existing in the previous time period but existing in the current time period as cold data; and pushes the contents of the new hot data and the cold data to a proactive cache scheduling server;

[0011] The proactive cache scheduling server drives the new hot data to be added and the cold data to be deleted in the browser local cache, the proxy server cache and the distributed cache based on heat, and drives old hot data in the browser local cache, the proxy server cache and the distributed cache to be actively updated or deleted according to data changes in the database based on data.

[0012] In some embodiments, the method combines the browser local cache, the proxy server cache and the distributed cache with the database based on a read-write penetration strategy.

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

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

[0015] Based on linear trend prediction, the access heat of a single data item at each time slice in the current time period is fitted, and the predicted access heat value corresponding to each time slice in the next time period is speculated, expressed as:

[0016] ;

[0017]

[0018] wherein, represents the actual observed value of the access hotness of the data item in the target time slice in the current time period t, represents the predicted access hotness value of the data item in the target time slice in the next time period t; is the intercept of the linear fitting, is the slope of the linear fitting; is the mean value of is the mean value of is the mean value of time; n represents the number of data points;

[0019] The observed value of the access hotness of each data item in each time slice in the hot data access list in the current time period is weighted and averaged with the predicted access hotness value in each time slice in the next time period to revise the access hotness of each data item.

[0020] In some embodiments, the access hotness of each data item in the hot data identification table is revised by introducing trend prediction, comprising:

[0021] The observed values of the access hotness of the data item in the corresponding time slice in multiple time periods are weighted and averaged with the number of occurrences of the data item in the corresponding time slice in multiple time periods as the weight, to obtain the predicted access hotness value of the data item in the corresponding time slice in the next time period, and the calculation formula is:

[0022]

[0023] wherein, represents the observed value of the access hotness of the data item in the target time slice in the i-th time period, represents the weight of the i-th time period, and n represents the number of time periods; represents the predicted access hotness value;

[0024] The observed value of the access hotness of each data item in each time slice in the hot data access list in the current time period is weighted and averaged with the predicted access hotness value in each time slice in the next time period to revise the access hotness of each data item.

[0025] In some embodiments, in the weighted average of the observed value of the access hotness of each data item in the hot data identification table and the predicted access hotness value to revise the access hotness of each data item, the weight of the observed value of the access hotness is 1, and the weight of the predicted access hotness value is the ratio of the preset time period to the preset time slice length.

[0026] In some embodiments, the hot data access list, the access hotness accumulation table and the hot data identification table mark the data items with hash values of uniform resource locators of the data.

[0027] In another aspect, the application also provides a front-end and back-end integrated hot data multi-level active caching device, comprising:

[0028] a client, configured to load a browser, query resource update status from the proxy server based on a negotiation caching mechanism when requesting resources, and preferentially call data in the browser local cache based on a strong caching mechanism when there is no update;

[0029] a static resource server group, configured to cache static resources;

[0030] a dynamic resource server group, configured to store dynamic resources by using a distributed cache;

[0031] a proxy server, configured to receive the client access request, distribute static resource requests in the access request to the static resource server group to query static resource update status and read when there is an update, forward dynamic resource requests in the access request to the dynamic resource server group to query dynamic resource update status and read when there is an update, establish data access logs for the dynamic resource requests based on a bypass cache in each business scenario, count access frequencies of each data item as access hotness according to a preset time period and a preset time slice for each business scenario and write the access hotness into a hot data access list, count the hot data access list and write the access hotness into an access hotness accumulation table, discard data items with access hotness less than a hot data identification standard acceptance threshold, sort the data items according to the access hotness, store the first preset number of data items in a hot data identification table, revise the access hotness of each data item in the hot data identification table by introducing trend prediction, mark data items existing in a previous time period but not existing in a current time period in the hot data identification table as new hot data, define data items not existing in the previous time period but existing in the current time period as cold data, and push contents of the new hot data and the cold data to an active cache scheduling server; and the proxy server executes the negotiation caching mechanism and the strong caching mechanism based on a proxy server cache;

[0032] an active cache scheduling server, configured to add the new hot data and delete the cold data in the browser local cache, the proxy server cache and the distributed cache based on hotness driving, and actively update or delete old hot data existing in the browser local cache, the proxy server cache and the distributed cache based on data driving according to data changes in a database;

[0033] a database, configured 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.

[0034] In another aspect, the present application also provides a computer readable storage medium having stored thereon computer programs / instructions which, when executed by a processor, implement the steps of the above method.

[0035] In another aspect, the present application also provides a computer program product comprising computer programs / instructions which, when executed by a processor, implement the steps of the above method.

[0036] The present application has at least the following beneficial effects:

[0037] In the front-end and back-end fusion hot data multi-level active caching method and device, on the basis of the client browser calling data based on negotiated caching and strong caching, the proxy server distributes the static resource request to the static resource server group for querying and reading static resources and forwards the dynamic resource request to the dynamic resource server group for querying dynamic resources, and the cold and hot data are bypassed and identified through access volume statistics and trend prediction, the cold and hot data and the data in the original database are monitored to actively update, add or delete the multi-level cache including the browser local cache, the proxy server cache and the distributed cache, the response speed and reading efficiency of hot data access are improved, and the effect is outstanding in the scene where the business scene is clear, the trend is linear, the data update frequency is relatively frequent, and the data consistency requirement is relatively high.

[0038] Additional advantages, objects, and features of the application will be set forth in part by the description that follows, and will become apparent to those skilled in the art upon examination of the following detailed description and drawings in which:

[0039] Those skilled in the art will appreciate that the objects and advantages of the application can not be limited to the specifically described above, and the above and other objects achieved by the application will be more clearly understood according to the following detailed description. BRIEF DESCRIPTION OF DRAWINGS

[0040] The drawings described herein are used to provide further understanding of the application, form part of the present application, and do not constitute a limitation of the application. In the drawings:

[0041] Figure 1 The flowchart of the front-end and back-end fusion hot data multi-level active caching method according to an embodiment of the present application.

[0042] Figure 2 The static and dynamic separation structure diagram in the front-end and back-end fusion hot data multi-level active caching method according to an embodiment of the present application.

[0043] Figure 3 The front-end and back-end fusion hot data multi-level active cache method is shown in the schematic diagram of hot data accumulation logic.

[0044] Figure 4 The front-end and back-end fusion hot data multi-level active cache method is shown in the schematic diagram of hot data bypass identification logic.

[0045] Figure 5 The front-end and back-end fusion hot data multi-level active cache method is shown in the schematic diagram of hot data bypass identification logic with trend prediction.

[0046] Figure 6 The front-end and back-end fusion hot data multi-level active cache method is shown in the schematic diagram of new hot data and cold data identification logic.

[0047] Figure 7 The front-end and back-end fusion hot data multi-level active cache method is shown in the structural diagram of cold and hot data bypass identification.

[0048] Figure 8 The front-end and back-end fusion hot data multi-level active cache method is shown in the schematic diagram of active cache scheduling logic.

[0049] Figure 9 The front-end and back-end fusion hot data multi-level active cache method is shown in the schematic diagram of front-end cache management logic.

[0050] Figure 10 The front-end and back-end fusion hot data multi-level active cache method is shown in the schematic diagram of the overall structure. DETAILED DESCRIPTION

[0051] To make the objectives, technical solutions, and advantages of the present application clearer, further detailed description will be given to the present application in combination with embodiments and drawings. Herein, the illustrative embodiments of the present application and their descriptions are used to explain the present application, but not as a limitation to the present application.

[0052] It should be noted that, in order to avoid the present application being obscured by unnecessary details, only the structures and / or processing steps closely related to the solutions according to the present application are shown in the drawings, and other details not closely related to the present application are omitted.

[0053] It should be emphasized that the term "comprises / comprising" is used herein to indicate the presence of a feature, element, step, or component, but not to exclude the presence or addition of one or more other features, elements, steps, or components.

[0054] It is to be understood that the terms "connected" or "connecting" or "coupled" or "coupling" as used herein refer to any connection or coupling, either direct or indirect, between otherwise-adjacent items, and can encompass the presence of one or more intermediate items.

[0055] Hereinafter, embodiments of the present application will be described with reference to the accompanying drawings. In the drawings, like reference numerals refer to like or identical components, or like or identical steps.

[0056] The present application is directed to a hot data high-frequency access application scenario with faster update frequency, moderate data size, and higher data consistency requirement, and provides a front-end and back-end integrated multi-level cache technology architecture to meet the read and write access requirements for hot data. In the commonly used multi-level bypass cache architecture, the cache architecture technology of the server is focused on, and the integration and use of the front-end cache lack systematic analysis. In the commonly used application scenarios of the Internet, the total data size is generally large, and the full cache solution is usually not considered. In this case, for the non-full small-scale hot data in the Internet application, designing an active multi-level cache architecture AMC (Active Multilevel Cache) that integrates front-end and back-end cache scheduling technology will be more suitable.

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

[0058] Step S101: When requesting resources, the client browser queries the resource update state to the proxy server based on the negotiation cache mechanism, and in the case of no update, the data in the browser local cache is called based on the strong cache mechanism.

[0059] Step S102: 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 state and reading when updated, and forwards the dynamic resource request therein to the dynamic resource server group for querying the dynamic resource update state and reading when updated; 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.

[0060] Step S103: The proxy server establishes data access logs for dynamic resource request based on bypass cache in each service scenario, and according to the preset time period and the preset time slice, the access frequency of each data item is counted as the access heat and written into the hot data access list, and the hot data access list is counted and written into the access heat accumulation table. After discarding the data items with access heat less than the hot data identification standard acceptance threshold, the data items are sorted according to the access heat, and the first set number of data items are stored in the hot data identification table. The access heat of each data item in the hot data identification table is introduced into the trend prediction for revision.

[0061] Step S104: The proxy server marks the data items existing in the last time period in the hot data identification table but not existing in the current time period as new hot data, and the data items not existing in the last time period but existing in the current time period are defined as cold data. The contents of the new hot data and the cold data are pushed to the active cache scheduling server.

[0062] Step S105: The active cache scheduling server drives the browser local cache, the proxy server cache and the distributed cache to add new hot data and delete cold data based on the heat, and drives the existing browser local cache, the proxy server cache and the distributed cache to actively update or delete the old hot data based on the data changes in the database.

[0063] In steps S101-S105, the main logic is that when the client's browser initiates a data request, data reading is performed based on the negotiation cache mechanism and the strong cache mechanism. In the case of synchronizing cache data and database data update state, the data in the browser local cache is preferred. 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 groups are designed according to the different characteristics of dynamic and static resources, which can improve the efficiency. The proxy server also identifies the hot and cold data based on the bypass cache, and introduces the trend prediction for revision. Based on the identification results of the hot and cold data, the new hot data is added and the cold data is deleted in the multi-level cache, and the data changed in the database is modified, so as to meet the rapid access demand of the client to the hot data and improve the access efficiency.

[0064] In step S101, the client is a device that directly interacts with the user, and accesses and processes data through a loaded browser or application. The negotiation cache mechanism refers to the browser sending a request to the server to inquire whether the accessed resource has been updated. The server will reply to the browser whether to use the browser cache or the server resource according to the update status of the resource. The negotiation cache relies 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 response, indicating the last modification time of the resource. This time is the time that the server considers the resource to have been last modified. When the browser requests a resource, the server will tell the browser the last modification time of the resource through Last-Modified, and the browser can determine whether the cached resource is expired through this time. If-Modified-Since is an HTTP header attached by the browser when requesting, indicating the time when the browser cached the resource last time. The browser will set If-Modified-Since to the stored Last-Modified time in the subsequent request to inquire whether the server has updated the resource. When the browser re-requests the resource, it sends an If-Modified-Since request header, and the server can determine whether the resource has changed according to 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 state of the resource. Unlike Last-Modified, ETag is based on the hash value or unique identifier of the resource content, which makes it provide more accurate cache control. The value of ETag changes each time the resource content changes. ETag allows the server to more accurately determine 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. The browser sends the If-None-Match request header when requesting, sending the cached ETag value to the server to inquire whether the resource has changed. The strong cache mechanism refers to the browser checking whether the local cache exists a copy of the resource when requesting the resource, and whether the copy is expired. If the copy of the resource is not expired, the browser directly uses the local cache and does not send a request to the server, thereby speeding up the webpage loading. The implementation of strong cache relies on two fields in the HTTP response header: Expires and Cache-Control.Expires is a kind of HTTP response header, used to specify the expiration time of a resource, that is, the invalid date and time of the browser caching the resource. Before this time, the browser can directly use the resource from the cache without requesting the server again. Cache-Control is a response header introduced by HTTP / 1.1 standard, used to replace or supplement Expires. It provides more control options to manage browser caching, using relative time (seconds) to specify the cache duration of the resource, which is more flexible and accurate.

[0065] At the same time, by constructing a front-end database, for data resources with a more No Sql database form, especially those data sets that may further need to perform front-end filtering, screening, searching and other computing operations, IndexedDB can be used for data caching and operation. IndexedDB is a client-side database provided by the browser, which can store a large amount of structured data and support transaction operations.

[0066] The browser will bypass the pre-caching of resources or listen to the caching of resource applications. Generally, it is implemented using Service Worker script technology, mainly relying on Web Worker scheduling and using localStorage and IndexDB for caching. When accessing, the corresponding resource request can be directly intercepted, and when it can be hit, it can be directly obtained from the local cache without sending a real request to the server. When the cache strategy is effective, it can still provide basic page access functions in poor network environment or offline situation. When using Service Worker to schedule browser caching, data consistency can also be ensured through the negotiation caching mechanism.

[0067] In step S102, the proxy server is a server located between the client and the original (resource) server, in order to obtain content from the original server, the client sends a request to the proxy server and specifies the target original server, and 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, the proxy service as a link on the network resource access and acquisition chain can also support the negotiation cache and forced cache strategy in the HTTP protocol. Proxy service caching relies on two fields in the HTTP response header in the HTTP response header: Expires and Cache-Control fields. When the Cache-Control value is public, all content will be cached (both the client and the proxy server can cache). But even when the Cache-Control value is other, the proxy server can also ignore this setting and use the proxy service cache. Distributed caching is a technology that caches data on multiple nodes to improve data access speed. It supports horizontal linear expansion and can improve cache capacity and performance by adding more nodes. It has high performance and can improve concurrent access speed by distributing stored data. At the same time, it can also avoid single point failure and ensure high availability of cache services through multiple copies and copy consistency.

[0068] The proxy server distinguishes between dynamic and static resources for client access requests and separates dynamic and static resources. 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 improving the access performance and maintainability of the entire application.

[0069] As shown in Figure 2 , dynamic and static separation is mainly implemented by corresponding settings on the reverse proxy server. At this time, the proxy server as a dynamic and static separation gateway can distribute static resource requests to a common simpler and faster Web server group, and forward dynamic resource (dynamic data) requests to the back-end application server group for processing. This architecture design method can improve the accessibility and maintainability of the entire service. Each link can be designed according to the different characteristics of dynamic and static resources.

[0070] The distributed cache of the dynamic resource server group is a technology that caches data on multiple nodes to improve data access speed. It supports horizontal linear expansion and can improve cache capacity and performance by adding more nodes. It has high performance and can improve concurrent access speed by distributing stored data. At the same time, it can also avoid single point failure and ensure high availability of cache services through multiple copies and copy consistency.

[0071] In step S103, the proxy server performs hot data bypass identification, using a shared access log of the proxy server or load server to identify using a bypass hot data identification system (HDBDS: Hot Data Bypass Detection System). The access log is stored in fixed time slices (here, a separate file is generated daily), which can further improve access log read / write efficiency. The hot data bypass identification application server reads the corresponding new log at regular intervals and performs statistics on the log.

[0072] Access popularity (AP) refers to one access of a user to a piece of data (Data) generating one "access point" (Point) of the data. The sum of all access point values in a statistical time period is the access popularity of the data item.

[0073] Based on the LFU (Least Frequency Used) algorithm, it is considered that the data with the highest frequency of occurrence in historical data is hot data. The core idea is that hot data that is more likely to be accessed in the future is data that is frequently accessed in the past. In order to implement this algorithm, the number of accesses of each data in the access pattern needs to be counted, and the data is sorted according to the size of the access count. When the cache capacity is insufficient, the data with the least access count in the cache is eliminated.

[0074] Define the hot data statistical time range (TR: Time Range). Different dimensions of hot data statistics will have different statistical time ranges. For example, the statistical time range length of "24-hour hot news" in a certain content publishing application can be 24 hours. For "real-time hot spots", the statistical time slice length can be 1 hour.

[0075] Define the hot data statistical time slice (TS: Time Slice). Different dimensions of hot data statistics will also have different "statistical time slices". For example, in a certain content publishing application, the "24-hour hot news", the length of the hot data statistical time granularity is about 30 minutes, which is suitable for the control of the calculation frequency and the rapid presentation of information with rapidly rising popularity. For "real-time hot spots", the shorter the statistical time granularity length, the better, and 1 minute is suitable for the control of the calculation frequency and the rapid presentation of information with rapidly rising popularity.

[0076] Define the access popularity statistics table (APST: Access Popularity Statistics Table). For analysis of hot data in a certain dimension, the access log of each data in the application needs to be accumulated.

[0077] AsFigure 3 The implementation is a TR / TS length of the hot data access list (APRL: Access Popularity Record List) as shown. When the system runs to a TS length trigger point, record the current time The Time, then:

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

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

[0080] When all the access operations in the data access log within the This TS time range are accumulated, the sum (SUM) of the accumulated result value of each APST sub-table can be obtained. The total access point value of the current Data in the TR range is the current hotness AP, and the AP value of the corresponding item in the APST table is updated (see Figure 2 ⑥⑦).

[0081] After analyzing the log on the bypass and obtaining all the data APST, the AP can be sorted. In the sorting process, historical data can be discarded to simplify the calculation.

[0082] Define the hot data value number (QHD: Quantity of Hot Data). For the sorted access hotness accumulation table, finally determine which data in the access hotness accumulation table is hot data. This value is usually directly related to the size of the cache space that the system can allocate.

[0083] Define the hot data recognition standard acceptance threshold (THD: Threshold of Hot Data). The hot data recognition standard acceptance threshold is usually half of the minimum AP value in the last hot data calculation result, which is the minimum requirement for data items to be recognized as hot data. It is mainly used for the half-value discard process to simplify the calculation amount.

[0084] Define a Hot Data Table (HDT). The final result of the hot data identification calculation is saved in the hot data identification table.

[0085] like Figure 4 As shown, during Hot Data Detection, all data records with AP less than THD in the APST calculated for this detection are first discarded and not included in the sorting calculation (see...). Figure 3 (At positions ① and ② in the middle).

[0086] APST values ​​higher than the threshold are saved into the HDT-1 table and sorted (see...). Figure 3 (See point ③ in the middle), and the result is saved into table HDT-2. According to business logic requirements, the first QHD data points sorted in table HDT-2 are pre-identified as hot data and stored in the hot data identification table HDT (see...). Figure 3 (Points 4 and 5 in the middle).

[0087] In practice, the above two-step calculation process can be further optimized by using a bubble sort to discard and sort data.

[0088] This concludes the calculation of this round of thermal data. Finally, based on the result set of thermal data, the minimum AP value in the result set needs to be used to update the thermal data acceptance threshold THD (see [link to THD]). Figure 3 (at locations ⑥ and ⑦). In some embodiments, the heat data acceptance threshold (THD) is half of the minimum access popularity in the previous time period's accumulated access popularity table.

[0089] In business scenarios with obvious trend characteristics, the data access trend of the next time slice (TS) can be further predicted.

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

[0091] To balance the resource conflicts between computing resources and cache scheduling optimization, a linear trend prediction algorithm with low computational cost is used here.

[0092] In some embodiments, the access hotness of each data item in the hot data identification table introduces trend prediction for revision, including steps S201-S202:

[0093] Step S201: based on the linear trend prediction, the access hotness of a single data item at each time slice in the current time period is fitted, and the predicted access hotness value corresponding to each time slice in the next time period is inferred, expressed as:

[0094] ;

[0095]

[0096] wherein, represents the actual observation value of the time slice at time t in the current time period, represents the predicted access hotness value of the time slice at time t in the next time period; is the intercept of the linear fitting, is the slope of the linear fitting; is the mean value of , and is the mean value of time; n represents the number of data points.

[0097] The advantage of this method is that the algorithm is simple, the computing resources are small, it is suitable for various fields, and it can provide a certain prediction accuracy. The disadvantage is that it assumes that the data is linear, and the prediction effect is not good for non-linear data, so it cannot capture short-term fluctuations in data.

[0098] Step S202: the access hotness observation value of each data item in the hot data access list in the current time period is weighted and averaged with the predicted access hotness value in each time slice in the next time period to revise the access hotness of each data item.

[0099] In real business, there are business scenarios where the trend rises obviously on some boundaries. For example, in a full-voting scenario of a certain group of people, the future trend value cannot be greater than the number of full members, but due to the obvious rising amplitude of the initial trend, the linear trend prediction algorithm may predict a trend value much greater than the number of full members. To further balance the absolute influence of trend prediction value on hot data identification, the influence of historical AP data needs to be further considered. Here, a new algorithm is introduced.

[0100] In some embodiments, the access hotness of each data item in the hot data identification table introduces trend prediction for revision, including steps S301-S302:

[0101] Step S301: Weighted average of the observed values of the access hotness of the data items in the corresponding time slices in the plurality of time periods, with the number of times of the data items appearing in the corresponding time slices in the plurality of time periods as the weight, to obtain the predicted access hotness value of the data items in the corresponding time slices in the next time period, the calculation formula being:

[0102]

[0103] wherein, represents the observed value of the access hotness of the data items in the target time slice in the i-th time period, represents the weight of the i-th time period, and n represents the number of time periods; represents the predicted access hotness value.

[0104] Step S302: Weighted average of the observed values of the access hotness of the data items in each time slice in the current time period hot data access list and the predicted access hotness values in each time slice in the next time period to revise the access hotness of each data item.

[0105] The method has the advantages of simple calculation, easy implementation, and high flexibility. The weighted average method gives different weights to different data, and the size of the weight can be adjusted according to the specific business needs, so as to better reflect the actual situation. The importance of different indicators is considered: in the weighted average method, different indicators are weighted, and the weight can be adjusted according to the actual demand and the importance of the indicators, which can more truly reflect the actual situation of the data, so that the final result is more objective and accurate. The influence of abnormal data can be further reduced, and the abnormal value in the data can be balanced by adjusting the weight, so as to obtain more accurate data average. The main disadvantage is that the subjective factor is large, and the adjustment of the weight usually relies on human experience and machine learning. Different experiences of people and sample coverage of machine learning will lead to differences in weight setting, affecting the result of the weighted average method. The data distribution is required to be high: the weighted average method is suitable for the case of normal distribution of data, and if the data has skew distribution or extreme value, the result of the weighted average method will be affected.

[0106] In steps S202 and S302, the observed value of the access hotness of each data item in the hot data identification table and the predicted access hotness value are weighted and averaged to revise the access hotness of each data item, and the weight of the observed value of the access hotness is 1, and the weight of the predicted access hotness value is the ratio of the preset time period to the preset time slice length. For the data items AP in the hot data access list APRL, the weight is assigned as 1 in the weighted average process, and for the calculated trend value TAP, the weight is assigned as TR / TS. The value calculated by weighted average of all AP values and TAP values in the APRL table and the corresponding weight is the final HDT table AP value.

[0107] In step S104, in the new hot data and cold data identification process, as shown in Figure 6 the identified HDT table can be compared with the OHDT (Old Hot Data Table) of the previous round to identify the new hot data and cold data.

[0108] The new hot data (NHDT: New Hot Data Table) is data that exists in the current HDT table but does not exist in the OHDT table. These data need to be added to the cache, and the calculation formula is NHDT = HDT - OHDT.

[0109] The cold data (CDT: Cold Data Table) is 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, and the calculation formula is CDT = OHDT - HDT.

[0110] After identifying the new hot data and cold data, the identified content is pushed to the proactive cache scheduling server, which executes the next proactive cache scheduling on the corresponding data.

[0111] Using access logs as input, different hot data accumulation and identification modules are triggered according to different business scenarios, and finally the hot data table of the current TS round and business scenario is formed and output. After further access trend calculation, the HDT is output, and the CDT is output after comparison with the HDT result of the previous TS round, to form a complete cold and hot data bypass identification subsystem. The function architecture of the subsystem is shown in Figure 7 .

[0112] In step S105, proactive cache scheduling is performed, which is triggered in two cases: the first is hotness-driven, which changes the cache in the system after the cold and hot data of the current TS round are determined. That is, when the HDT, NHDT, and CDT of a business scenario are identified, proactive cache scheduling is triggered. The second is data-driven, which updates or deletes the existing cache according to the specific situation when the data source itself changes. In the current system architecture, the proactive cache scheduling of hot data triggered by the second change of the data source itself mainly depends on the capture of the changed data, and the system actively schedules the distributed cache (Redis) and proxy server cache (Nginx) according to the change to achieve the scheduling.

[0113] As shown in Figure 8As shown, where the data publisher is various types of database for data persistence storage, in this architecture, the MySql database is taken as an example. Since most databases do not support active publishing services, the change data capture (CDC) software can be used to realize data publishing. Common software includes Debezium and the like.

[0114] When Debezium finds that there is change data in the database, it will push the corresponding data to Kafka to generate the corresponding topic (Kafka Topic).

[0115] At this time, the dynamic cache scheduling module subscribing to the corresponding topic will be triggered, and the distributed cache, proxy server cache and browser cache will be sequentially scheduled.

[0116] When the hotness-driven trigger is triggered, if there is a data item in the NHDT table, it indicates that new hot data is generated. At this time, the content of the cache with the key value of the DataKey in the NHDT table in the multi-level cache needs to be added. If there is a data item in the CDT table, it indicates that new cold data is generated. At this time, the content of the cache with the key value of the DataKey in the CDT table in the multi-level cache needs to be deleted.

[0117] When the data-driven trigger is triggered, the primary key of the received change data item is assembled into DataKey. The specific process is to construct the front-end access url according to the data primary key and the front-end business access logic, and then perform Hash operation on it to obtain the DataKey of the current data. Then, according to the three operation types, the processing is carried out respectively.

[0118] The first kind is the addition operation. The record of the data is added in the APST, and the TR / TS structure table is created, and the access hotness accumulation of the data is started.

[0119] The second kind is the update operation. First, find the DataKey in the HDT. If it exists, it indicates that the hot data has changed. At this time, the content of the cache with the key value of the DataKey in the multi-level cache needs to be updated. Especially, the response header field Last-Modified should be added in the corresponding data record, and the specific value should be the actual change time of the source data, so as to provide the server response directly.

[0120] Thirdly, the delete operation, first find the DataKey in the HDT, if it exists, it means that there is hot data deletion. At this time, the content of the cache corresponding to the key value DataKey in the multi-level cache needs to be deleted. It should be noted that when the data source generates a delete operation, the scheduler needs to delete the cache in addition to the cache deletion scheduling. It also needs to synchronize the deletion of all records of the data in the APST access hotness accumulation table and the HDT table. In order to prevent the deleted data from polluting the calculation results when the next TS time point is bypassed to determine the hot and cold data.

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

[0122] The implementation of the addition and deletion of the proxy server cache (Nginx) is relatively complex. Nginx itself is not a programming language environment, but a lightweight HTTP and reverse proxy server. Therefore, Nginx itself does not support active cache scheduling functions and cannot implement active cache loading. Only by installing third-party module plug-ins, such as ngx_http_purge_module, can the cache scheduling be performed. The purge module can only delete the specified cache that needs to be cleaned, and cannot actively load the corresponding new cache. For cache data that needs to be specified, only after the purge module is deleted, the read-write penetration cache mechanism is relied on to automatically generate the corresponding cache when the first data access request is requested by the client.

[0123] In some embodiments, the method combines the browser local cache, proxy server cache and distributed cache with the database based on the read-write penetration strategy. The read-write penetration cache strategy (Read / Write Through) is to tightly integrate the cache (usually referring to the cache service) with the database. The application will operate through the cache layer when reading and writing data. If the cache is not hit, 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 into the cache and writes the data into the database through the cache layer. In this way, the data is consistent between the cache and the database.

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

[0125] In various large application scenarios, there is a demand for further improving speed and reducing delay in obtaining and using existing data. Front-end computing can move part of the computing task from the server to the client, so that some data processing and analysis are closer to the customer, thereby significantly reducing the number of data transmission times, time and network bandwidth occupation. The front-end persistent data storage technology supporting this kind of front-end computing application scenario is the front-end database.

[0126] Further, in the architecture, data for front-end complex computing and data for ordinary display are distinguished. The front-end cache cooperates with the back-end cache to separate static and dynamic strategies and is processed differently. 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. Dynamic resources (dynamic data) use a bypass cache architecture that still depends on the time effectiveness of the back-end multi-level cache. The cache of all access results is determined by the header information whether to cache. In the architecture, the Service Worker is used for front-end bypass cache scheduling, further unified management of the cache is performed in the bypass, and the re-verification time-out strategy is used to verify the data consistency. The implementation logic is as shown in Figure 9 .

[0127] When using the Service Worker, a situation about the 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. The fetch event handling function in the Service Worker may perform specific processing when detecting that a resource returns the 304 status code. First, it is necessary to ensure that the requested resource is correctly cached and the cache is used when the resource is valid. Secondly, when the resource changes, it is necessary to ensure that the ServiceWorker can update the resource in the cache.

[0128] Corresponding to the above method, the application also provides a device / system, which comprises a computer device, the computer device comprising a processor and a memory, the memory storing computer instructions, and the processor being configured to execute the computer instructions stored in the memory, so that the device / system implements the steps of the method as described above.

[0129] The embodiment of the application also provides a computer readable storage medium, which stores a computer program, and the computer program is executed by a processor to implement the steps of the edge computing server deployment method. The computer readable storage medium can be a tangible storage medium, such as a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a floppy disk, a hard disk, a removable storage disk, a CD-ROM, or any other form of storage medium known in the technical field.

[0130] In another aspect, the application also provides a front-end and back-end integrated hot data multi-level active cache device, comprising:

[0131] a client, configured to load a browser, query resource update status from the proxy server based on a negotiation cache mechanism when requesting a resource, and preferentially call data in the browser local cache based on a strong cache mechanism when there is no update;

[0132] a static resource server group, configured to cache static resources;

[0133] a dynamic resource server group, configured to store dynamic resources by using a distributed cache;

[0134] a proxy server, configured to receive the client access request, distribute static resource requests in the access request to the static resource server group for querying static resource update status and reading when there is an update, forward dynamic resource requests in the access request to the dynamic resource server group for querying dynamic resource update status and reading when there is an update, establish data access logs in each business scenario based on a bypass cache for the dynamic resource requests, count the access times to each data item as access heat in each business scenario according to a preset time period and a preset time slice, and write the access heat into a hot data access list, count the hot data access list and write the access heat into an access heat accumulation table, discard data items with access heat less than a hot data identification standard acceptance threshold, sort the data items according to the access heat, store the first preset number of data items in a hot data identification table, revise the access heat of each data item in the hot data identification table by introducing trend prediction, mark data items existing in a previous time period but not existing in a current time period in the hot data identification table as new hot data, define data items not existing in the previous time period but existing in the current time period as cold data, and push the contents of the new hot data and the cold data to an active cache scheduling server; and the proxy server executes the negotiation cache mechanism and the strong cache mechanism based on a proxy server cache;

[0135] an active cache scheduling server, configured to add the new hot data and delete the cold data in the browser local cache, the proxy server cache and the distributed cache based on heat driving, and actively update or delete old hot data existing in the browser local cache, the proxy server cache and the distributed cache based on data driving according to data changes in a database;

[0136] a database, configured to store original data, and synchronize the browser local cache, the proxy server cache and the distributed cache based on a read-write penetration strategy.

[0137] the cache scheduling process of which is as follows Figure 10As shown, when a client's browser initiates a request, the ServiceWorker takes over and determines the request's validity. If the request is for static resources, no further processing is performed; the browser's default mechanism handles the request. If the request is for dynamic data, the ServiceWorker first requests the data and loads it into the browser cache. Other scripts on the page then read the data directly from the cache when they need it, without making further data requests.

[0138] Requests initiated by the front end to the system first reach the static and dynamic resource separation gateway. Requests for static resources are then forwarded to the static resource load balancer (which also acts as a static resource proxy service cache). This server will, depending on the specific circumstances, return its local cache to the request, or further forward the request to the backend static resource server group.

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

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

[0141] Log files generated by user access are periodically analyzed by a hot data bypass identification module that incorporates trend prediction factors. Hot and cold data are identified according to different business scenarios, and the results are saved to the database. Then, the popularity-driven mechanism triggers the proactive cache scheduling module to update multi-level caches.

[0142] Meanwhile, if the application server's related services perform write operations on confirmed hot data, the change data capture module will capture this, and the data-driven mechanism will trigger the active cache scheduling module to update the multi-level cache.

[0143] To sum up, in the front-end and back-end fusion hot data multi-level active cache method and device, on the basis of the client browser calling data based on negotiation cache and strong cache, the proxy server is used to distribute the static resource request to the static resource server group to query and read static resources and forward the dynamic resource request to the dynamic resource server group to query dynamic resources, the cold and hot data are bypassed and determined through access volume statistics and trend prediction, the cold and hot data and the data in the original database are monitored to actively update, add or delete the multi-level cache including the browser local cache, the proxy server cache and the distributed cache, the response speed and reading efficiency of hot data access are improved, and the effect is outstanding in the scene where the business scene is clear, the trend is linear, the data update frequency is relatively frequent, and the data consistency requirement is relatively high.

[0144] Those skilled in the art should understand that the exemplary components, systems and methods described in connection with the embodiments disclosed herein can be implemented in hardware, software or a combination thereof. The choice of hardware or software implementation is dependent on the particular application and design constraints imposed on the solution. Skilled persons can use different methods to implement the described functions for each particular application, but such implementation should not be considered beyond the scope of the present application. 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, etc. When implemented in software, the elements of the present application are program or code segments used to perform the required tasks. The program or code segments can be stored in a machine-readable medium or transmitted through a data signal carried in a carrier wave in a transmission medium or communication link.

[0145] It should be clear that the present application is not limited to the specific configurations and processes described above and shown in the drawings. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of the present application is not limited to the specific steps described and shown, and 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 application.

[0146] In the present application, the features described and / or exemplified for one embodiment can be used in the same way or in a similar way in one or more other embodiments, and / or in combination with or instead of the features of other embodiments.

[0147] The above merely illustrates the preferred embodiments of the present application, and is not used to limit the present application. The embodiments of the present application can be variously changed and modified by those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall fall within the scope of protection of the present application.

Claims

1. A front and back end fusion hot data multi-level proactive caching method, characterized in that, The method comprises the following steps: The client browser queries the proxy server for resource update status based on the negotiation cache mechanism when requesting resources, and preferentially calls data in the browser local cache based on the strong cache mechanism in the case of no update; The proxy server receives a client access request, distributes static resource requests in the request to a static resource server group for querying static resource update status and reading in the case of update, and forwards dynamic resource requests in the request to a dynamic resource server group for querying dynamic resource update status and reading in the case of update; the dynamic resource server group adopts a distributed cache; the proxy server executes the negotiation cache mechanism and the strong cache mechanism based on a proxy server cache; The proxy server establishes data access logs in various business scenarios for the dynamic resource requests based on a bypass cache, counts access frequencies to each data item as access heat for each business scenario according to a preset time period and a preset time slice, and writes the access heat into a hot data access list; after discarding data items with access heat less than a hot data identification standard acceptance threshold, the first preset number of data items are stored into a hot data identification table according to the access heat size; the access heat of each data item in the hot data identification table is revised by introducing trend prediction; The proxy server marks data items existing in a previous time period but not existing in a current time period in the hot data identification table as new hot data, and defines data items not existing in the previous time period but existing in the current time period as cold data; and pushes the contents of the new hot data and the cold data to an 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 driving; and actively updates or deletes old hot data existing in the browser local cache, the proxy server cache and the distributed cache based on data driving according to data changes in a database. 2.The front-back-end converged hot data multi-level proactive caching method of claim 1, wherein, 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 front-back-end converged hot data multi-level proactive caching method of claim 1, wherein, The hot data identification standard acceptance threshold is half of the minimum access heat in the access heat accumulation table in the previous time period. 4.The front-back-end converged hot data multi-level proactive caching method of claim 1, wherein, The access heat of each data item in the hot data identification table is revised by introducing trend prediction, comprising: The access heat of each time slice in the current time period is fitted based on linear trend prediction, and predicted access heat values corresponding to each time slice in the next time period are speculated, and the expression is: ； in, This represents the actual observed value of the time slice at time t in the current time period. This represents the predicted access popularity value of the time slice at time t in the next time period; The intercept of the straight line fitting is given. The slope of the fitted line; for The mean, The mean over time; n represents the number of data points; The observed values of the access heat of each data item in each time slice in the hot data access list in the current time period are weighted and averaged with the predicted access heat values in each time slice in the next time period to revise the access heat of each data item. 5.The front-back-end converged hot data multi-level proactive caching method of claim 1, wherein, The access heat of each data item in the hot data identification table is revised by introducing trend prediction, comprising: The observation value of the access hotness of the data item in the corresponding time slice in the plurality of time periods is weighted and averaged according to the number of times of occurrence of the data item in the corresponding time slice in the plurality of time periods as the weight, to obtain a predicted access hotness value of the data item in the corresponding time slice in the next time period, and the calculation formula is: wherein, represents the observed value of the access hotness of the data item within the i-th time period target time slice, represents the weight of the i-th time period, n represents the number of time periods; represents the predicted access hotness value; The observation value of the access hotness of each data item in each time slice in the hot data access list in the current time period is weighted and averaged with the predicted access hotness value in each time slice in the next time period to revise the access hotness of each data item.

6. The front-back-end converged hot data multi-level proactive caching method according to any one of claims 4 or 5, characterized in that, The observation value of the access hotness of each data item in the hot data identification table is weighted and averaged with the predicted access hotness value, the weight of the observation value of the access hotness is 1, and the weight of the predicted access hotness value is the ratio of the preset time period to the preset time slice length.

7. The front and back-end converged hot data multi-level proactive caching method of claim 1, wherein, The hot data access list, the access hotness accumulation table and the hot data identification table mark the data item by using the hash value of the uniform resource locator of the data.

8. A front-end and back-end converged hot data multi-level proactive caching apparatus, characterized in that, Comprise: A client loads a browser, queries a proxy server for resource update status based on a negotiation cache mechanism when requesting a resource, and preferentially calls data in a browser local cache based on a strong cache mechanism when there is no update; A static resource server group buffers static resources; A dynamic resource server group stores dynamic resources by using a distributed cache; A proxy server receives an access request of the client, distributes a static resource request therein to the static resource server group for querying a static resource update status and reading when updated, and forwards a dynamic resource request therein to the dynamic resource server group for querying a dynamic resource update status and reading when updated; and establishes a data access log in each business scenario based on a bypass cache for the dynamic resource request, counts the number of accesses to each data item as access hotness according to a preset time period and a preset time slice for each business scenario, and writes the access hotness into a hot data access list; and counts the hot data access list and writes the access hotness into an access hotness accumulation table; After discarding data items with access hotness less than a hot data identification standard acceptance threshold, sorting according to the access hotness, storing the first set number of data items in a hot data identification table; the access hotness of each data item in the hot data identification table is revised by introducing trend prediction; data items existing in the last time period but not existing in the current time period in the hot data identification table are marked as new hot data, data items not existing in the last time period but existing in the current time period are defined as cold data, and the contents of the new hot data and the cold data are pushed to an active cache scheduling server; The proxy server executes the negotiation cache mechanism and the strong cache mechanism based on a proxy server cache; An active cache scheduling server is used to add the new hot data and delete the cold data in the browser local cache, the proxy server cache and the distributed cache based on hotness driving; And data driving is used to actively update or delete old hot data existing in the browser local cache, the proxy server cache and the distributed cache according to data changes in a database; a database for storing raw data and synchronizing 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 stored thereon computer programs / instructions, characterized in that, The computer program / instructions, when executed by a processor, implement the steps of the method of any of claims 1 to 7.

10. A computer program product comprising computer programs / instructions, characterized in that, The computer program / instructions, when executed by a processor, implement the steps of the method of any of claims 1 to 7.

Images