Overview
CDN cache problem encountered when the front and back ends are not separated ( freemaker ). There are mainly the following two problems:
htmlobtained by the page request is the link of the old version numberscriptscriptscript link is the new version number but the old script code is pulled
problem analysis
html obtained by the page request contains the old version number script link
Before analyzing the problem, we must first know the following knowledge points:
(1) freemaker page project is to back-end services to ftl processed into html returned
(2) During deployment, the ftl file will be traversed, and all the script links will be marked with the version number
// 构建前 supplierQuoteDetailPaging.ftl
<!DOCTYPE html>
<head>
<script type="text/javascript" src="${Global.getConfig("web.app.static.url")}/js/supplierQuoteDetail.js"></script>
</head>
</html>
// 在`Jenkins`构建后会对请求静态脚本的`url`加上版本号 supplierQuoteDetailPaging.ftl
<!DOCTYPE html>
<head>
<script type="text/javascript" src="${Global.getConfig("web.app.static.url")}/js/supplierQuoteDetail.js?version=1638706227856"></script>
</head>
</html>(3) The back-end is a cluster service, and the deployment adopts rolling release, which means that the node service is updated batch by batch during deployment, until all the instances in the cluster are updated to the new version, instead of being updated in full at once
When the project is still deployed, because the service uses rolling release, during this period the new service and the old service will exist at the same time. If you visit the page at this stage, the page interface may hit the old service or the new service. When it hits the old service, the script html is marked with the old version number; when the deployment is completed, all instances in the group All are updated to the new version, the page request hits the new service, and the script html is marked with the new version number.
Solution: Refresh the page after the project is deployed
2, script script link is the new version number but the old script code
Normally, after deploying the project, the browser requests the static script file on CDN CDN is no script file corresponding to the new version number in the 061b05e4562413 cache, it will pull the new script from the back-end service, and then CDN When doing a cache, the following script request is directly returned CDN
However, if the deployment is not completed and the browser is accessed, at this stage, the new service and the old service exist at the same time. When the script corresponding to the new version number CDN , it will go to the service request. The request hits the old service (the service response has nothing to do with the version number), the old service returns the old script, and then CDN caches the old script corresponding to the new version number, so that each subsequent request pulls the script cached on CDN Therefore, the above-mentioned problem arises.
Our actual solution is that maintains two release tasks (repetitive batches) for this type of project, that is, deploys twice. Let's first assume the mapping relationship between the version number and the script of the three deployment process:
| version number | script | |
|---|---|---|
| Last deployment | V1.0 | J1.0 |
| Repeat batch 1 | V1.1 | J1.1 |
| Repeat batch 2 | V1.2 | J1.2 |
Note: There is no change in the codes of repeated batch 1 and repeated batch 2, and theJ1.1J1.2exactly the same
If the repeat batch 1 deployment is not completed, the access goes through the wrong hit process, CDN caches <V1.0，J1.0> , then any subsequent access to get the wrong script code. When the rolling release of the repeated batch 1 service is completed, the scripts on the service are all J1.1 . If the repeated batch 2 is deployed again, the request when the deployment is not completed may hit the script J1.1 or J1.2 . J1.2 J1.1 and 061b05e456261b are exactly the same, the CDN cache <V1.0，J1.1> or <V1.0，J1.2> , the results are correct; if the request is initiated when the deployment is completed, the hit script is J1.2 , CDN cache <V1.0，J1.2> , the result is also correct.
In addition, there are some other solutions, such as CDN refresh and preheat
CDN refresh and warm up
CDN provides resource refresh and warm-up functions. Through the refresh function, you can force the CDN node to return to the source and obtain the latest files; through the warm-up function, you can warm up popular resources during peak business periods to improve resource access efficiency. The difference between cache refresh and cache warm-up is as follows:
- Cache refresh: After submitting the cache refresh request,
CDNnode will be forced to expire. When a user requests a resourceCDNCDNwill directly return to the origin site to request the corresponding resource and return it to the user, and cache it. - Cache warm-up: After submitting the cache warm-up request, the origin site will actively cache the corresponding resources to the
CDNnode. When the user requests for the first time, he canCDNnode, and there is no need to go back to the origin site to request.
There are two types of refresh: URL refresh and catalog refresh.
URLrefresh: By providing files in the directory, theCDNnode is forced to return to the source obtain the latest file, within 5 minutes of the effective time, theAPIinterface RefreshObjectCaches .- Directory refresh: By providing the directory and all files in the directory, the
CDNnode is forced to return to the source to obtain the latest files. The effective time is within 5 minutes, and theAPIinterface is the same as above.
calling this interface on
- Support
postrequest, the parameters use theformform. - Refresh preheating interface includes
RefreshObjectCachesrefreshing interface andPushObjectCachepreheating interface. - The same
IDcan submit up to 2000URLrefreshes and 100 catalog refreshes per day. - Each request can only submit up to 1000
URLrefreshes. - Up to 50 requests per second.
In addition to the above figure, there is a parameter Action with a value of RefreshObjectCaches , and the return value is consistent with the preheat interface, as shown below:
Sample code:
https://cdn.aliyuncs.com?Action=RefreshObjectCaches
&ObjectPath=abc.com/image/1.png\nabc.com/image/2.png
&ObjectType=File
&<公共请求参数> warm support only full URL warm-up, warm-up is not supported directory , the specified resource initiative preheated to CDN of L2 two nodes , the user can directly access the first cache hit. Effective time is within 5 minutes, API interface PushObjectCache .
Call PushObjectCache to actively warm up the content of the origin site to the L2 Cache node. Your first access can directly hit the cache to relieve the pressure on the origin site. Before calling this interface, please note:
- Support
postrequest, parameters useformform. - Refresh and preheat interface includes
RefreshObjectCachesrefresh interface andPushObjectCachepreheat interface. - The same ID can submit up to 500
URLper day for preheating. - Each request can only submit up to 100
URLpreheating. - Up to 50 requests per second.
- The maximum limit of the preheating queue for a single
IDis 100, which is preheated according to the order of submission. If the queue tasks accumulate to 100, you need to wait for the submitted warm-up request to be completed before submitting a new one, so as to keep the queue size never exceeding 100. CDNofL2 Cachenode set up inL1 Cachebetween the node and the source station, the source station to help you relieve stress.
http(s)://cdn.aliyuncs.com/?Action=PushObjectCache
&ObjectPath=abc.com/image/1.png\nabc.com/image/2.png
&<公共请求参数>Q&A
Q: What should I do if the cache fails to warm up?
A: The possible reasons for the cache preheating failure are:
- When you perform centralized preheating of a large number of files, it may cause your origin site's bandwidth resources to be full. Please try to perform the preheating in batches as much as possible. You can also increase the preheating efficiency by expanding the bandwidth of the source station.
- Check whether the cache expiration time corresponding to the resource is 0, if it is 0, disabling the cache will cause preheating failure;
cache-controlconfiguration of the source siteprivate、no-cache、no-storewill causeCDNfail to cache and cause preheating failure. If not configured, the default is private.- Currently, preheating directories, dynamic files, and cache expiration time of
urlare not supported. - When you preheat multiple
URLseparated by ";", you need to switch to the English state, the ";" in the Chinese state will cause preheat failure
Q: After refreshing and warming up operations, why the accessed files are still old?
A: It may be that the interval between refreshing and warming up your cache is too close, causing the refresh to fail. It is recommended that the interval between refreshing and warming up is more than five minutes.
refer to:
HUAWEI CLOUD CDN
CDN refresh and warm-up
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。