High-concurrency-resistant three-level caching method suitable for server

Abstract

The invention relates to the technical field of server access, in particular to an anti-high-concurrency three-level caching method and system suitable for a server side, and the method comprises the following steps: a terminal device sends a request, analyzes the type of the request when the request enters a load balancer, and judges whether the request is a hotspot request or a long-tail request; if it is judged that the request is a hotspot request, the request is forwarded to a first-level cache layer; if the data required by the request does not exist in the cache, forwarding the request to a next-level cache layer step by step until the data is found; if the request is judged to be a long-tail request, the request is forwarded to a second-level cache layer or a third-level cache layer, and if data needed by the request does not exist in a corresponding cache, the request is gradually forwarded to a next-level cache layer until the data is found. The method has the advantages that the cache access path can be adjusted in a self-adaptive mode, and resources are prevented from being wasted in invalid requests; the hot data can be predicted more accurately, and cache distribution is optimized.

Description

Technical Field

[0001] The invention relates to the technical field of server access, in particular to a high-concurrency three-level cache method suitable for a server. Background Art

[0002] With the development of Internet applications and the increase in the number of mobile users, the server is facing the challenge of increasing concurrent requests. Traditional caching technologies are mainly divided into two categories: one is to cache data directly on the application server, and the other is to use a single cache layer (such as Redis) to cope with frequent data reading needs.

[0003] Specifically, traditional caching technology has the following shortcomings. 1. Performance bottleneck of single-layer cache: In large-scale high-concurrency scenarios, single-layer cache can easily become a performance bottleneck, causing cache resources to be exhausted. 2. Backend pressure caused by cache failure: When cached data expires or fails in large quantities, a large number of requests flow directly to the database, causing a sharp increase in backend system pressure and even causing system crashes. 3. Lack of multi-level cache management: Existing solutions lack an efficient hierarchical cache management method to quickly recover and relieve backend pressure when the cache fails. Summary of the invention

[0004] The purpose of the present invention is to overcome the shortcomings of the prior art and provide a three-level cache method suitable for the server to resist high concurrency, which solves the cache performance bottleneck, back-end pressure caused by cache failure, and lack of multi-level cache management in traditional cache technology, and also solves the technical problems of unsatisfactory processing efficiency and response speed in some existing multi-level cache technologies.

[0005] It should be noted that due to the shortcomings of the above-mentioned traditional caching technology, there are currently some methods on the market that set up multi-level caches between mobile terminals and server terminals; however, in these multi-level ring technologies, the scheduling and forwarding of requests are still basically completed by load balancers and gateways. This method does not take into account the cache hit rate, the timeliness of the data, and the changes in hot data, resulting in less than ideal processing efficiency and response speed.

[0006] The purpose of the present invention is achieved through the following technical solutions:

[0007] A method for three-level caching suitable for server-side high concurrency resistance is provided, comprising the following steps:

[0008] The terminal device sends a request. When the request enters the load balancer, the request type is analyzed to determine whether the request is a hot request or a long-tail request.

[0009] If it is determined to be a hot request, the request is forwarded to the first-level cache layer; if the cache does not have the data required by the request, the request is forwarded to the next-level cache layer step by step until the data is found;

[0010] If it is determined to be a long-tail request, the request is forwarded to the second-level cache layer or the third-level cache layer. If the corresponding cache does not have the data required by the request, the request is gradually forwarded to the next-level cache layer until the data is found.

[0011] Furthermore, the first-level cache layer is the Varnish first-level cache layer, the second-level cache layer is the Facade second-level cache layer, and the third-level cache layer is the Kafka third-level cache layer. If it is determined to be a hotspot request, it is forwarded to the Varnish first-level cache layer. If there is no data in the Varnish first-level cache layer, it is forwarded to the Facade second-level cache layer. If there is no data in the Facade second-level cache layer, it is forwarded to the Kafka third-level cache layer. If there is no data in the Kafka third-level cache layer, it is forwarded to the server. If it is determined to be a long-tail request: forwarded to the Facade second-level cache layer. If there is no data in the Facade second-level cache layer, it is forwarded to the Kafka third-level cache layer. If there is no data in the Kafka third-level cache layer, it is forwarded to the server; or forwarded to the Kafka third-level cache layer. If there is no data in the Kafka third-level cache layer, it is forwarded to the server.

[0012] Furthermore, the "specific analysis of the request type when the request enters the load balancer" also includes the analysis of user behavior; specifically, the characteristics used for behavior include: page browsing, that is, recording the access time and user ID of each page, which can be expressed as PageView or PV; click behavior, that is, recording the specific click event of the user on the page and its timestamp, which can be expressed as ClickAction; download operation, that is, recording the type of downloaded content, user ID and timestamp, which can be expressed as DownloadAction; stay time, that is, recording the number and time of events such as likes, comments, and shares, which can be expressed as SessionDuration; content interaction, that is, the number of interactions with the content, which can be expressed as ContentInteraction. These user behavior data are used as features to form a time series of user behavior; each feature of different dimensions in the time series of user behavior is processed by feature standardization; the time series of user behavior after feature standardization is used as training data and input into the training model. According to the model prediction results, the surge trend of specific behavior in a certain time window is judged, and the corresponding data is loaded into the corresponding cache layer in advance.

[0013] Furthermore, when user behavior data is used as a feature to form a time series of user behavior:

[0014] Aggregate statistics for each user behavior within a certain time window to form time series data; set the window length to Deltat, and count the following indicators for each behavior: PV_t: page views within the time window (t); Click_t: number of clicks within the time window (t); Download_t: number of downloads within the time window (t); Duration_t: average stay time within the time window (t); Interaction_t: number of interactive behaviors within the time window (t) - that is, the weighted sum of likes, comments, and shares; then arrange the above behavior statistics in chronological order to form multi-feature time series data, that is, form a time series of user behaviors.

[0015] Furthermore, the features of different dimensions in the time series of user behavior are processed according to the feature standard, which means:

[0016] The formula [X'=frac{X-mu}{sigma}] is used to standardize the different dimensions of PV_t, Click_t, Download_t, Duration_t, and Interaction_t, so that the features of these different dimensions have similar ranges; where mu is the feature mean and sigma is the standard deviation.

[0017] Furthermore, the “time series of user behaviors after feature normalization is used as training data, input into the training model, and predicted for the changing trend of the behaviors:

[0018] The training model is an ARIMA multivariate model, specifically

[0019] [begin{aligned}(1-sum{i=1}^{p}phiiL^i)(1-L)^dXt=c+(1+sum{j=1}^{q}thetajL^j)epsilontend{aligned}],

[0020] Among them, -(Xt) is a sequence composed of multiple behavioral features. Different features can be given different weights and then combined into a comprehensive sequence, or directly modeled separately. -(Xt=w1PVt+w2Clickt+w3Downloadt+w4Durationt+w5Interactiont), where (wi) is the feature weight. -Difference times (d): used to remove non-stationarity (such as linear trends). -(phii): autoregressive coefficient, indicating the impact of the feature value of the previous (i) time step on the current time step. -(theta_j): moving average coefficient, indicating the impact of the previous error on the current prediction value.

[0021] Furthermore, the “time series of user behaviors after feature normalization is used as training data, input into the training model, and predicted for the changing trend of the behaviors:

[0022] The training model is LSTM, and the calculation formula of LSTM is:

[0023] Forget gate: [ft = sigma (Wfcdot [h{t-1}, Xt] + b_f)]

[0024] Where (Xt) is the feature vector of the current time step: (Xt = [PVt, Clickt, Downloadt, Durationt, Interaction_t]); (h_{t-1}) is the hidden state of the previous time step; (Wf, bf) is the weight matrix and bias of the forget gate;

[0025] Input gate: [it = sigma (Wicdot [h{t-1}, Xt] + bi)] [tilde {C} t = tanh (WCcdot [h{t-1}, Xt] + bC)];

[0026] Memory update: [Ct = ft*C{t-1}+it*tilde{C}_t];

[0027] Output gate: [ot = sigma (Wocdot [h{t-1}, Xt] + bo)] [ht = ot * tanh (Ct)];

[0028] The standardized user behavior sequence ([PVt, Clickt, Downloadt, Durationt, Interaction_t]) is input into the LSTM unit of each time step to predict the comprehensive behavior trend of the next time step (t+1).

[0029] Furthermore, in the “using the time series of user behaviors after feature normalization as training data, inputting it into the training model, and predicting the changing trend of the behaviors”:

[0030] The training model is the Prophet model, specifically

[0031] [y(t)=g(t)+s(t)+h(t)+epsilon_t];

[0032] Among them, (g(t)): trend function, which can be fitted linearly or nonlinearly; (s(t)): periodic function (such as daily or weekly periodic behavior); (h(t)): the impact of sudden events or exogenous variables, user behavior characteristics (such as number of clicks, number of downloads, etc.) can be input as exogenous variables.

[0033] Furthermore, the data of the first-level cache layer, the data of the second-level cache layer, and the data of the third-level cache layer are updated to the corresponding first-level cache layer through the server if the request is determined to be a hotspot request after the last request of each terminal device is completed, and if the request is determined to be a long-tail request, the data required for the long-tail request is updated to the second-level cache layer or the third-level cache layer through the server. When the terminal device sends a request and forwards it to the corresponding cache layer, the data used by the cache layer at this time is the data updated by the server last time.

[0034] Furthermore, the data in each cache layer is detected and updated in real time through the time series model by analyzing log data and traffic conditions.

[0035] It should be noted that in the above-mentioned first and second aspects, the data cached in the cache layer according to hot spot requests / long tail requests is determined by each terminal device together to determine whether it is the data required for the hot spot request or the data required for the long tail request.

[0036] It should be noted that when a terminal device sends a request, it is determined whether the terminal device is a hotspot request / long-tail request through the requests of all other terminal devices.

[0037] The present invention has the following advantages:

[0038] (1) Compared with the traditional caching method, this solution has the following advantages: a. Through multi-level caching, especially the cooperation of memory cache and persistent cache, fast response is achieved; b. The number of times the application server directly accesses the database is reduced, the load on the database and back-end server is reduced, and the stability of the system is ensured; c. The three-level caching mechanism avoids the impact of single-point cache failure on the system through multi-layer cache isolation, effectively preventing the occurrence of cache avalanche and breakdown;

[0039] (2) Compared with some multi-level caches on the market, this solution has the following advantages: a. Adaptively adjust the cache access path according to the frequency and popularity of requests to avoid wasting resources in invalid cache paths; b. User behavior data can be used to build a multi-feature model in the time series model, which can capture complex access patterns and is suitable for changing access scenarios; user behavior features are used as input to more accurately predict hot data and optimize cache allocation compared to ordinary threshold judgment methods. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Figure 1 It is a schematic diagram of the present invention. DETAILED DESCRIPTION

[0041] The present invention is further described below in conjunction with the accompanying drawings, but the protection scope of the present invention is not limited to the following description.

[0042] It should be noted that the directions or positional relationships indicated by "left", "right", etc. are based on the directions or positional relationships shown in the accompanying drawings, or are the directions or positional relationships in which the inventive product is usually placed when in use, or are the directions or positional relationships commonly understood by those skilled in the art. Such terms are only for the convenience of describing the present invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific direction, be constructed and operated in a specific direction, and therefore cannot be understood as a limitation on the present invention.

[0043] It should be noted that in the traditional solution, the scheduling and forwarding of requests are basically completed by the load balancer and gateway. However, this method does not take into account the cache hit rate, the timeliness of data, and the changes in hot data. The following improvements can improve the processing efficiency and response speed of the system.

[0044] Therefore, the present invention introduces a three-level cache method suitable for the server to resist high concurrency. In essence, it is a dynamic request scheduling mechanism based on cache hit rate and data heat. When a request enters the load balancer, the requested URL or request type is first analyzed to determine whether it belongs to a "hotspot request" or a "long-tail request". The hotspot data (the data required for hotspot requests) is automatically detected by the algorithm, and the hotspot requests are forwarded to the first-level cache layer first to improve the cache hit rate and reading speed. The long-tail data (the data required for long-tail requests) is automatically detected by the algorithm, and is generally distributed through conventional paths. It will not enter the first-level cache layer first, but will directly enter the second or third-level cache layer.

[0045] This will be achieved through a specific implementation method as follows.

[0046] like Figure 1 As shown, this specific implementation provides a method for server-side high-concurrency three-level cache, including the following steps:

[0047] The terminal device sends a request. When the request enters the load balancer, the request type is analyzed to determine whether the request is a hot request or a long-tail request.

[0048] If it is determined to be a hot request, the request is forwarded to the first-level cache layer; if the cache does not have the data required by the request, the request is forwarded to the next-level cache layer step by step until the data is found;

[0049] If it is determined to be a long-tail request, the request is forwarded to the second-level cache layer or the third-level cache layer. If the corresponding cache does not have the data required by the request, the request is gradually forwarded to the next-level cache layer until the data is found.

[0050] For example, see Figure 1, the first-level cache layer is Varnish's first-level cache layer, the second-level cache layer is Facade's second-level cache layer, and the third-level cache layer is Kafka's third-level cache layer. When making a request: if it is determined to be a hotspot request, it is forwarded to Varnish's first-level cache layer. If there is no data in Varnish's first-level cache layer, it is forwarded to Facade's second-level cache layer. If there is no data in Facade's second-level cache layer, it is forwarded to Kafka's third-level cache layer. If there is no data in Kafka's third-level cache layer, it is forwarded to the server. When making a request: if it is determined to be a long-tail request, it is forwarded to Facade's second-level cache layer. If there is no data in Facade's second-level cache layer, it is forwarded to Kafka's third-level cache layer. If there is no data in Kafka's third-level cache layer, it is forwarded to the server; or, when it is determined to be a request, it is forwarded to Kafka's third-level cache layer. If there is no data in Kafka's third-level cache layer, it is forwarded to the server.

[0051] The following is a further explanation of "a terminal device sends a request, and when the request enters the load balancer, the request type is analyzed to determine whether the request is a hot request or a long-tail request."

[0052] "Perform specific analysis on request types when requests enter the load balancer" refers to the analysis of user behavior.

[0053] Specifically, the features used for behavior include: page browsing, that is, recording the access time and user ID of each page, which can be expressed as PageView or PV; click behavior, that is, recording the specific click events of users on the page and their timestamps, which can be expressed as ClickAction; download operation, that is, recording the type of downloaded content, user ID and timestamp, which can be expressed as DownloadAction; dwell time, that is, recording the number and time of events such as likes, comments, and shares, which can be expressed as SessionDuration; content interaction, that is, the number of interactions with the content, which can be expressed as ContentInteraction;

[0054] These user behavior data are used as features to form a time series of user behavior; each feature of different dimensions in the time series of user behavior is processed by feature standardization; the time series of user behavior after feature standardization is used as training data and input into the training model. According to the model prediction results, the surge trend of specific behaviors in a certain time window is determined, and the corresponding data is loaded into the corresponding cache layer in advance.

[0055] The following is a further explanation of "using these user behavior data as features to form a time series of user behavior."

[0056] Aggregate and count each user behavior within a certain time window to form time series data; set the window length to Deltat, and count the following indicators for each behavior:

[0057] PV_t: number of page views in the time window (t);

[0058] Click_t: number of clicks within the time window (t);

[0059] Download_t: the number of downloads within the time window (t);

[0060] Duration_t: average residence time in the time window (t);

[0061] Interaction_t: the number of interactive behaviors within the time window (t) - that is, the weighted sum of likes, comments, and shares;

[0062] Then the above behavior statistics are arranged in chronological order to form multi-feature time series data, that is, a time series of user behavior, such as ([PVt', Clickt', Downloadt', Durationt', Interaction_t']).

[0063] Exemplarily, the above behavior statistics are arranged in chronological order to form multi-feature time series data, which is expressed as follows:

[0064]

[0065] The following is a further explanation of "processing the features of different dimensions in the time series of user behavior with feature standards respectively".

[0066] The formula [X'=frac{X-mu}{sigma}] is used to standardize the different dimensions of PV_t, Click_t, Download_t, Duration_t, and Interaction_t, so that the features of these different dimensions have similar ranges; where mu is the feature mean and sigma is the standard deviation.

[0067] The time series of user behavior after normalization is ([PVt, Clickt, Downloadt, Durationt, Interaction_t]).

[0068] In the following, in "using the time series of user behavior after feature normalization as training data, inputting it into the training model, and predicting the changing trend of the behavior", the training model can adopt the ARIMA multivariate model, or the LSTM model, or the Prophet model.

[0069] (1) If the ARIMA multivariate model is used as the training model.

[0070] The model is [begin{aligned}(1-sum{i=1}^{p}phiiL^i)(1-L)^dXt=c+(1+sum{j=1}^{q}thetajL^j)epsilontend{aligned}],

[0071] Among them, -(Xt) is a sequence composed of multiple behavioral features. Different features can be given different weights and then combined into a comprehensive sequence, or directly modeled separately. -(Xt=w1PVt+w2Clickt+w3Downloadt+w4Durationt+w5Interactiont), where (wi) is the feature weight. -Difference times (d): used to remove non-stationarity (such as linear trends); -(phii): autoregressive coefficient, indicating the impact of the feature value of the previous (i) time step on the current time step; -(theta_j): moving average coefficient, indicating the impact of the previous error on the current prediction value.

[0072] (2) If the LSTM model is used as the training model.

[0073] The model calculation formula is as follows:

[0074] Forget gate: [ft = sigma (Wfcdot [h{t-1}, Xt] + b_f)]

[0075] Where (Xt) is the feature vector of the current time step: (Xt = [PVt, Clickt, Downloadt, Durationt, Interaction_t]); (h_{t-1}) is the hidden state of the previous time step; (Wf, bf) is the weight matrix and bias of the forget gate;

[0076] Input gate: [it = sigma (Wicdot [h{t-1}, Xt] + bi)] [tilde {C} t = tanh (WCcdot [h{t-1}, Xt] + bC)];

[0077] Memory update: [Ct = ft*C{t-1}+it*tilde{C}_t];

[0078] Output gate: [ot = sigma (Wocdot [h{t-1}, Xt] + bo)] [ht = ot * tanh (Ct)];

[0079] The standardized user behavior sequence ([PVt, Clickt, Downloadt, Durationt, Interaction_t]) is input into the LSTM unit of each time step to predict the comprehensive behavior trend of the next time step (t+1).

[0080] (3) If the Prophet model is used as the training model.

[0081] [y(t)=g(t)+s(t)+h(t)+epsilon_t];

[0082] Among them, (g(t)): trend function, which can be fitted linearly or nonlinearly; (s(t)): periodic function (such as daily or weekly periodic behavior); (h(t)): the impact of sudden events or exogenous variables, user behavior characteristics (such as number of clicks, number of downloads, etc.) can be input as exogenous variables.

[0083] The following describes the data cached in the first-level cache layer, the data cached in the second-level cache layer, and the data cached in the third-level cache layer.

[0084] Specifically, in order to cope with a large number of cache failures or burst traffic, a cache preheating mechanism is added to load hot data into the cache in advance to reduce the delay of the user's first access. The specific strategy of the preheating mechanism is: each time the system or cache layer is restarted, the cache is preheated in advance according to historical data and predicted hot data, and the hot data is loaded into the first-level cache layer and the second-level cache layer. In other words, the data in each cache layer is the data required by each terminal device after the last request is completed. If it is determined to be a hot request, the data required for the hot request is updated to the corresponding first-level cache layer through the server. If it is determined to be a long-tail request, the data required for the long-tail request is updated to the second-level cache layer or the third-level cache layer through the server; when the terminal device sends a request and forwards it to the corresponding cache layer, the data used by the cache layer at this time is the data updated by the server last time.

[0085] It should be noted that when detecting hot data / long-tail data: by analyzing log data and traffic conditions, hot data is detected and updated in real time, and the data is automatically loaded into the cache layer closest to the terminal, thereby improving the system's response speed in high-concurrency scenarios.

[0086] See also Figure 1 This specific implementation also discloses a system for a server-side high-concurrency three-level cache method, which is implemented based on the above-mentioned server-side high-concurrency three-level cache method, including:

[0087] Terminal device, used for user operation and sending various operation requests;

[0088] The load balancer is used to receive requests from terminal devices and forward the requests to the cache layer;

[0089] The cache layer unit has multiple cache layers. Each cache layer stores data for hot requests / long-tail requests. When the data required by the request is not available in the previous cache layer, the request is forwarded to the next layer until the data required by the request is found.

[0090] The service layer, i.e., the server, is used to store various request data; when the request does not find data in the cache unit, the request is forwarded to the server.

[0091] By way of example, the system is described.

[0092] Terminal devices (such as mobile phones) distribute requests to the cache layer through load balancing (LB).

[0093] Cache layer unit: The cache layer is divided into multiple modules, which read and cache data according to the three-level cache logic.

[0094] Kong: As an API gateway, it is responsible for forwarding user requests to other modules in the cache layer.

[0095] Varnish: A first-level cache layer, mainly used for memory cache processing to quickly read requests. When a terminal initiates a get request, Varnish first checks whether there is cached data; if there is cache, it directly reads the memory and returns it.

[0096] Facade: Second-level cache layer. When there is no cache in Varnish, the Facade module forwards the request to Redis (16G memory) and reads the cache data from Redis to ensure efficient read and write performance.

[0097] Kafka: As a message queue, it is mainly used for asynchronous cache write operations when there is no cache. When the Facade module confirms that there is no cache in Redis, it puts the write request into the Kafka queue for asynchronous processing to avoid the delay caused by synchronous writing.

[0098] Service layer: When a request does not hit the cache after passing through the three-level cache, it will finally access the application server, read data from the database (such as PostgreSQL and MySQL), and update the cache layer.

[0099] The above embodiments only express preferred implementation modes, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present invention. It should be pointed out that, for ordinary technicians in this field, several modifications and improvements can be made without departing from the concept of the present invention, and these all belong to the protection scope of the present invention.

Claims

1. A three-level cache method suitable for server-side high-concurrency resistance, characterized in that: The following steps are involved: The terminal device sends a request. When the request enters the load balancer, the request type is analyzed to determine whether the request is a hot request or a long-tail request. If it is determined to be a hot request, the request is forwarded to the first-level cache layer; if the cache does not have the required data, the request is forwarded to the next-level cache layer step by step until the data is found; If it is determined to be a long-tail request, the request is forwarded to the second-level cache layer or the third-level cache layer. If the corresponding cache does not have the data required by the request, the request is gradually forwarded to the next-level cache layer until the data is found.

2. According to claim 1, a method for server-side high-concurrency three-level cache, characterized in that: The first-level cache layer is the Varnish first-level cache layer, the second-level cache layer is the Facade second-level cache layer, and the third-level cache layer is the Kafka third-level cache layer; If it is determined to be a hotspot request, it is forwarded to the Varnish level 1 cache layer. If there is no data in the Varnish level 1 cache layer, it is forwarded to the Facade level 2 cache layer. If there is no data in the Facade level 2 cache layer, it is forwarded to the Kafka level 3 cache layer. If there is no data in the Kafka level 3 cache layer, it is forwarded to the server. If it is determined to be a long-tail request: Forward to the Facade secondary cache layer. If there is no data in the Facade secondary cache layer, forward to the Kafka third-level cache layer. If there is no data in the Kafka third-level cache layer, forward to the server. Or forward it to Kafka's third-level cache layer. If there is no data in Kafka's third-level cache layer, forward it to the server.

3. A method for server-side high-concurrency three-level caching according to claim 2, characterized in that: The aforementioned "specifically analyzing the request type when the request enters the load balancer" also includes analysis of user behavior; Specifically, the characteristics used for behavior include: Page browsing, that is, recording the access time and user ID of each page, which can be expressed as PageView or PV; Click behavior, that is, recording the specific click events of users on the page and their timestamps, can be expressed as ClickAction; Download operation, i.e. recording the downloaded content type, user ID and timestamp, can be represented as DownloadAction; The dwell time, i.e. the number and time of likes, comments, shares and other events, can be expressed as SessionDuration; Content interaction, that is, the number of interactions with content, can be expressed as ContentInteraction; These user behavior data are used as features to form a time series of user behavior; each feature of different dimensions in the time series of user behavior is processed by feature standardization; the time series of user behavior after feature standardization is used as training data and input into the training model. According to the model prediction results, the surge trend of specific behaviors in a certain time window is determined, and the corresponding data is loaded into the corresponding cache layer in advance.

4. According to claim 3, a method for server-side high-concurrency three-level cache, characterized in that: When using user behavior data as features to form a time series of user behavior: Aggregate and count each user behavior within a certain time window to form time series data; set the window length to Deltat, and count the following indicators for each behavior: PV_t: number of page views in the time window (t); Click_t: The number of clicks within the time window (t). Download_t: The number of downloads within the time window (t). Duration_t: Average residence time within the time window (t). Interaction_t: the number of interactive behaviors within the time window (t) - that is, the weighted sum of likes, comments, and shares; Then the above behavior statistics are arranged in chronological order to form multi-feature time series data, that is, a time series of user behavior.

5. A method for server-side high-concurrency three-level caching according to claim 4, characterized in that: The features of different dimensions in the time series of user behavior are processed by feature standards respectively, which means: The formula [X'=frac{X-mu}{sigma}] is used to standardize the different dimensions of PV_t, Click_t, Download_t, Duration_t, and Interaction_t, so that the features of these different dimensions have similar ranges; where mu is the feature mean and sigma is the standard deviation.

6. A method for three-level caching suitable for server side to resist high concurrency according to claim 5, characterized in that: In the above “using the time series of user behaviors after feature normalization as training data, inputting it into the training model, and predicting the changing trend of the behaviors”: The training model is an ARIMA multivariate model, specifically [begin{aligned}(1-sum{i=1}^{p}phiiL^i)(1-L)^dXt=c+(1+sum{j=1}^{q}thetajL^j)epsilontend{aligned}], Among them, -(Xt) is a sequence composed of multiple behavioral features. Different features can be given different weights and then synthesized into a comprehensive sequence, or directly modeled separately; -(Xt=w1PVt+w2Clickt+w3Downloadt+w4Durationt+w5Interactiont), where (wi) is the feature weight. -Difference times (d): used to remove non-stationarity (such as linear trends); -(phii): autoregressive coefficient, indicating the impact of the feature value of the previous (i) time step on the current time step; -(theta_j): moving average coefficient, indicating the impact of the previous error on the current prediction value.

7. A method for three-level caching applicable to a server to resist high concurrency according to claim 5, characterized in that: The "time series of user behavior after feature normalization is used as training data, input into the training model, and predicted for the changing trend of behavior: The training model is LSTM, and the calculation formula of LSTM is: Forget gate: [ft = sigma (Wfcdot [h{t-1}, Xt] + b_f)] Where (Xt) is the feature vector of the current time step: (Xt = [PVt, Clickt, Downloadt, Durationt, Interaction_t]); (h_{t-1}) is the hidden state of the previous time step; (Wf, bf) is the weight matrix and bias of the forget gate; Input gate: [it = sigma (Wicdot [h{t-1}, Xt] + bi)] [tilde {C} t = tanh (WCcdot [h{t-1}, Xt] + bC)]; Memory update: [Ct = ft*C{t-1}+it*tilde{C}_t]; Output gate: [ot = sigma (Wocdot [h{t-1}, Xt] + bo)] [ht = ot * tanh (Ct)]; The standardized user behavior sequence ([PVt, Clickt, Downloadt, Durationt, Interaction_t]) is input into the LSTM unit of each time step to predict the comprehensive behavior trend of the next time step (t+1).

8. The method for three-level cache with high concurrency resistance applicable to a server according to claim 5, characterized in that: The "time series of user behavior after feature normalization is used as training data, input into the training model, and predicted for the changing trend of behavior: The training model is the Prophet model, specifically [y(t)=g(t)+s(t)+h(t)+epsilon_t]; Among them, (g(t)): trend function, which can be fitted linearly or nonlinearly; (s(t)): periodic function (such as daily or weekly periodic behavior); (h(t)): the impact of sudden events or exogenous variables, user behavior characteristics (such as number of clicks, number of downloads, etc.) can be input as exogenous variables.

9. A method for server-side high-concurrency three-level cache according to claim 1, characterized in that: The data of the first-level cache layer, the data of the second-level cache layer, and the data of the third-level cache layer are updated to the corresponding first-level cache layer through the server if the request is determined to be a hotspot request after the last request of each terminal device is completed; if the request is determined to be a long-tail request, the data required for the long-tail request is updated to the second-level cache layer or the third-level cache layer through the server; When a terminal device sends a request and forwards it to the corresponding cache layer, the data used by the cache layer at this time is the data updated by the server last time.

10. A method for server-side high-concurrency three-level cache according to claim 1, characterized in that: The data in each cache layer is detected and updated in real time through the analysis of log data and traffic conditions using a time series model.

Images