The working principle of CDN and its application in image business

How CDNs work

The Content Delivery Network (CDN for short) is a distributed network that is established and overlaid on the bearer network and consists of edge node server groups distributed in different regions.

CDN is widely used and supports content acceleration in various industries and scenarios, such as small picture files, large file downloads, video and audio on demand, live streaming media, site-wide acceleration, and security acceleration.

Borrow the example of Alibaba Cloud official website to briefly introduce the working principle of CDN.

Assume that the domain name accelerated by CDN is www.a.com, access the CDN network, and start using the acceleration service. When an end user (Beijing) initiates an HTTP request, the processing flow is as follows:

1. When an end user (Beijing) initiates a request to a specified resource under www.a.com, it first initiates a domain name resolution request to LDNS (local DNS).

2. LDNS checks whether there is an IP address record of www.a.com in the cache. If there is, it will be directly returned to the end user; if not, it will be queried to the authoritative DNS.

3. When authorizing DNS to resolve www.a.com, return the IP address corresponding to the domain name CNAME www.a.tbcdn.com.

4. The domain name resolution request is sent to the Alibaba Cloud DNS scheduling system, and the best node IP address is assigned to the request.

5. LDNS obtains the resolved IP address returned by DNS.

6. The user obtains and resolves the IP address.

7. The user initiates an access request to the resource to the obtained IP address.

If the node corresponding to the IP address has cached the resource, the data will be returned directly to the user, for example, steps 7 and 8 in the figure, the request ends.
If the node corresponding to the IP address does not cache the resource, the node initiates a request for the resource to the source station. After obtaining the resources, combined with the cache policy configured by the user, the resources are cached to the node, for example, the Beijing node in the figure, and returned to the user, and the request ends.
You can learn from this example:

1. CDN acceleration resources are bound to domain names.

2. To access resources through the domain name, the first step is to search for the IP of the CDN node (edge server) closest to the user through DNS

3. When accessing actual resources through IP, if there is no cached resource on the CDN, it will go to the origin site to request the resource and cache it on the CDN node, so that when the user visits next time, the CDN node will have the cache of the corresponding resource up.

deer pictures business background

The main picture of the product runs through the entire shopping guide and transaction link. Compared with text, pictures are more eye-catching, and the main picture has a great influence on consumers' shopping decisions. The content expressed on the main picture is various, but the expression of price must be indispensable among them.

For a long time, the price expression on the main map has been maintained by the merchants themselves. After the commodity price changes, the map is manually changed. Doing so creates 3 problems:

1. The accuracy of the price: The price of the picture manually filled by the merchant may not be consistent with the actual purchase price, resulting in a bad user experience.

2. Timeliness of price update: Sometimes, due to the invalidation of coupons/category coupons, the price of the product will change frequently, and the merchant has no time to change the picture.

3. The operating cost of the merchant: Manually modifying the price of the picture is still very expensive. It is necessary to modify the picture through software such as ps, upload it again, and edit the product.

This year's Double 11, the Department of Technology - Luban team tried to solve these problems through technical means. When the price of the product changes, the system automatically calculates the new price, automatically synthesizes the picture, and then updates the main picture of the product.

We know that there are hundreds of millions of products on the Internet, and there are tens of millions of products in Everbright Promotion. Therefore, the frequency of picture changes caused by price changes is very high. The highest point is at 0:00 on Double 11. The prices of all promotional items will change from daily prices to promotional prices.

This means that during the peak period of the big promotion, tens of millions of pictures will be accessed by users as soon as they are generated. So what problems will arise in this situation, let us first understand the structure of the image space and CDN, and it will be clear.

Image Space and CDN Architecture

The access link of the entire image has a three-level cache (client local, CDN L1, CDN L2), and all images are persistently stored in OSS. The real image processing system is the img-picasso system. Its functions are relatively complex, including reading files from OSS, scaling the image size, and encoding and decoding, so the machine cost is relatively high.

The CDN cache is divided into two levels, and the ratio of L1 and L2 is reasonably allocated. On the one hand, it can cache more content and improve the overall cache hit rate under the same resources through the means of consistent hash; on the other hand, it can Balance computing and IO, and make full use of the capabilities of machines with different configurations.

The process for users to access pictures is as follows:

Users use mobile phones to search for products or view baby details.

Details/Search/Recommendation returns the picture URL of the product by calling the product center.

If the client has a local cache of the image, it will directly render the image, otherwise it will go to the next step.

Return the source image from CDN L1. If L1 has a cache of the image, the client renders the image and caches it locally at the same time. If L1 does not have a cache, go to the next step.

Back to the source image from CDN L2, if L2 has the cache of the image, the client renders the image, and at the same time CDN L1 and the client cache the image content, if CDN L2 does not cache the image, go to the next step.

Back to the original picture from the picture space, the picture space will pull the picture source file from the OSS, scale the size according to the requirements, and then perform encoding and decoding, and return the picture content that the client can support, and then the client can render the picture, and at the same time the L1 of the CDN , L2, and the client cache image content.

Technical challenges brought about by frequent map changes


When the price of a product changes, we will use the new price to recombine the picture and update the picture URL stored in the product center. This creates 2 problems:

1. The image content originally cached by the CDN and the mobile phone is invalid, and the user accesses the image and all the images will be returned to the source of img-picasso.

2. Due to the change of the fields of the product, the cache of the core application of the transaction (shopping cart and product center) is also invalid. When the user browses and shops, the access to the product will go to the db.

Image processing on the source site img-picasso and querying the commodity DB consume a lot of resources. After the cache hit rate of the CDN and the product is reduced, there will be huge pressure on the origin site img-picsasso and db.

Taking CDN cache as an example, a simple calculation shows that the normal hit rate of CDN is 98%. Assuming that the hit rate decreases by 1 point, the pressure on the origin site will increase by 1/3 (originally responsible for 2% of the traffic, now it needs to bear 3 % traffic), which means that img-picasso needs to be expanded by 1/3. If half of the images on the entire network change at the same time, the hit rate of the CDN drops to 50%, and the number of visits to img-picasso will increase by 25 times. This expansion cost is definitely unacceptable.

There are two ways to solve these two problems:

1. Change the picture and keep the URL of the picture unchanged, which can avoid the cache failure of the product link.

2. Before the visit peak arrives, preheat the pictures to the CDN in advance, which can avoid the pressure of the CDN cache failure on the origin site.

Next, let's introduce how we do these two points.

Solutions for frequent map changes

▐ Change the picture and keep the picture URL unchanged

When the image content changes, perform the following two operations:

1. Update OSS content: replace the old picture content in OSS with new picture content

2. Refresh the CDN cache: clear the image content cached before the CDN

In this way, when the user accesses the picture again and finds that the CDN has no cache, it will go back to img-picasso to pull new picture content from OSS.

Since the image URL does not change, there is no need to update the image link in the product center, so that the cache of the product link can remain unchanged.

In the process of actually implementing this plan, I encountered several problems, which I would like to share with you:

Synchronization of OSS in three places

The picture space carries the guarantee of the uplink and downlink stability of all the pictures in Taobao. In order to ensure high availability, a resource will be stored in OSS in three places. When uploading pictures, only one place is uploaded by default, and the ability of OSS is used to automatically synchronize to the other two places.

However, using the URL unchanged solution, after the CDN cache has been cleared, if the OSS in the other two places has not been synchronized, the user will return to the old image content after accessing it, and find that the image content has not changed.

In response to this problem, we changed the mode of asynchronous and synchronous OSS soft links to synchronously build soft links in three places. After all three places return success, we will clear the CDN cache, which ensures that the pictures accessed by users must be the latest content.

Image size convergence

The same product picture will be used in different scene pits, and different pits have different requirements for the size of the picture. To this end, Image Space provides a function that can easily generate thumbnail images of different sizes. You only need to add different suffixes to the picture when accessing the picture, and the img-picasso source site can scale the picture as required.

Due to historical reasons, there were no restrictions on the types of zooming sizes before, resulting in as many as 2,400+ image suffix formats on the CDN, the coverage rate of TOP6 format is 46%, and the coverage rate of TOP15 format is 64%. This means that a picture may have up to 2400+ different URLs on the CDN. When the content of the picture changes, all these caches must be cleared to ensure that the pictures seen by all users are new.

To solve this problem, we converged on the domain name format.

The image space rules for image quality compression parameters are as follows:

There are 8 common picture quality parameters: Q90, Q75, Q50, Q30, q90, q75, q50, q30
There are three common types of picture sharpening parameters: s100, s150, s200
We redefine image quality as high-quality images and low-quality images, with convergent formats q90 and p50s150

In this way, more than 2,000 formats can be converged to 6 main formats, and it becomes feasible for CDN to clear the cache.

Multiple copies clear CDN cache

Through image size convergence, each image only needs to clear 6 different urls, so can the refresh efficiency be further improved?

To this end, Alibaba Cloud CDN provides us with a multi-copy refresh solution: each image with a different suffix is used as a copy of the image, and a layer of KV structure is added to the swift layer of the CDN to store the mapping relationship between URL and different copies. When clearing the cache, all copies can be found through this structure, and all copies can be cleared quickly. In this way, for each image, we only need to call the CDN cache clear interface once, which greatly improves the efficiency of CDN cache refresh.

There are more than 300 image domain names, mainly for the following two reasons:

1. The complete link of the picture is too long, so only the last paragraph is often saved when storing, and the business spells out the domain name by itself. Many businesses apply for a picture domain name to spell it out.

2. In the PC era, browsers have a limit on the number of concurrent requests under the same domain name. Different browsers are different, generally about 6. In order to break through this limitation, some businesses will apply for multiple domain names and randomly spell different domain names.

As we mentioned earlier, the CDN cache is bound to the domain name, whether it is a cache hit or a cache clear, it can only target one domain name.

It is obviously impossible for us to change a picture and call CDN refresh for 300 domain names. Therefore, we consider converging on the picture domain name, so that users' access to pictures is routed to the same domain name. We hope to converge all picture visits to picasso.alicdn.com. The specific implementation method is as follows:

1. For mobile Taobao and Maoke clients, image access is closed in the image library. We promote the transformation of the image library, and the urls that meet certain rules are uniformly converged to picasso.alicdn.com, realizing a one-size-fits-all domain name.

2. For the PC browser side, it is more troublesome, and there is no unified closing place. We can only settle for the next best thing, and configure domain name forwarding rules on the CDN for the 6 most visited domain names to redirect to the picasso domain name.

In this way, we have realized that more than 99% of the picture access traffic on the entire network is routed to the picasso domain name. When the content of the picture changes, by clearing the CDN cache of the picasso domain name, we can ensure that basically all scenes can see the new one. image content.

Client and browser caching

Through the convergence of multiple copies and image domain names, the caching problem of CDN has been solved. But on the CDN, the user's image access is first from the client or browser, and there will also be a layer of caching here.

As we all know, browser caches follow the standard http max-age protocol. After specifying this header, the picture will become invalid when the time comes, and a new picture will be accessed. Therefore, we can add the max-age protocol header when the source station img-picasso returns to the CDN, with a value of 1 minute, and the CDN will pass through to the browser intact, so that the browser can realize the image cache failure within 1 minute , and re-pull new image resources from CDN.

For mobile clients, we support the standard http protocol in addition to the original LRU cache mechanism. In this way, the mobile phone also realizes that the picture cache is invalidated within 1 minute.

▐ Preheat CDN images in advance

By changing the picture and keeping the picture URL unchanged, we solved the impact of the picture change on the product link cache. However, when the picture changes, although the URL has not changed, we have cleared the CDN cache, causing users to return to the source site of img-picasso when accessing, so the pressure on the source site of the picture still exists.

We found that most of the price changes of commodities occurred at the moment when the rhythm of the big promotion changed. Based on this feature, we synthesized images in advance and preheated them to CDN in advance, so that the image switching took effect instantly, and at the same time, there was no pressure on the origin site. The specific plan is as follows:

Synthesize multi-band images in advance: After we know the time points when merchants change pictures intensively during the big promotion period, we divide the display of pictures into multiple bands according to these time points, synthesize the pictures in each band in advance, and write the picture URL into the product center in advance in the extended structure.

Image access routing: The marketing system will tell Luban Picture Erfangbao according to the configured big promotion atmosphere switching plan, which band it is currently in, and Luban will return the correct image URL to each scene according to the current band and scene.

Image rendering: After each scene gets the image URL, it decides whether to display the image based on its own business logic.

CDN image preheating: In order to avoid crashing the source site when images are switched centrally, we will preheat these cold image content to CDN before centralized switching.

Changes in images within bands: After synthesizing images in each band in advance, merchants may temporarily issue coupons/change prices, causing product prices to change again. For this type of image change needs, in order to avoid updating the image URL in the product center, we use the previous chapter of this article It is implemented by saving the CDN cache.

Summary and Outlook

CDN technology is widely used in various scenarios of the Internet. Today's CDN service providers provide very simple business access methods, and the cost of CDN is decreasing every year, all of which make the access and use costs of CDN lower and lower. .

This article uses the example of the picture business to explain the problems and solutions that may be encountered in the process of using CDN.

In addition to the large number of visits, the picture business also faces the problem of frequent updates. Frequent updates of pictures will cause the product cache to become invalid due to the change of the picture URL on the product, and will greatly reduce the hit rate of CDN image access cache on the other hand.

Aiming at the problem that the product cache becomes invalid due to the change of the picture url, we have realized changing the picture and keeping the picture url unchanged by refreshing the CDN cache and returning to the source when the user visits. During this process, we have solved a series of problems, including : Synchronous update of OSS in three places, image size convergence, image domain name convergence, client and browser local cache.

To solve the problem of lowering the hit rate of CDN image cache by image modification, we synthesized images of different bands in advance according to the characteristics of the business, and preheated them to CDN to ensure the security of the origin site.

At present, the pictures that users see are all synthesized in advance. In the future, we consider synthesizing images in real time when users access images. Through this technology, more real-time information of the business can be perceived in real time, and based on this information, content such as copywriting/elements that are more suitable for the current user or the environment can be synthesized on the picture, bringing more surprises to users.

Of course, real-time image combination will face more challenges, such as computing power and image combination performance. In addition, for CDN, since the content accessed by each user is temporarily synthesized, the caching strategy of CDN is also a big challenge.