Method for realizing CDN (Content Delivery Network) based on distributed load balancing system

Abstract

The invention particularly relates to a method for realizing a CDN (Content Delivery Network) based on a distributed load balancing system. According to the method for realizing the CDN based on the distributed load balancing system, the distributed load balancing system is deployed by adopting a hard anti-affinity strategy, and an open source Nginx is adopted as a load balancer in a load balancing node; configuring a cache, and caching the data to a data disk; collecting cache information in real time through a monitoring module, and if the cache content is updated, refreshing the cache of the Nginx on the load balancing node; an interface for refreshing all caches is exposed through the management module, and it is guaranteed that after applications in the cloud server are updated, the load balancing node can clean and update the caches in time. According to the method for realizing the CDN based on the distributed load balancing system, the network access speed and stability are effectively improved, two high-quality network service requirements of load balancing and CDN can be met at the same time, and the method has relatively high expandability and flexibility and adapts to continuously changing network environments and user requirements.

Description

Technical Field

[0001] The present invention relates to the technical field of cloud computing, and in particular to a method for implementing CDN based on a distributed load balancing system. Background Art

[0002] With the popularization and rapid development of the Internet, users have higher and higher requirements for network content access speed and experience. The traditional single server architecture can no longer meet the needs of large-scale user access and massive data transmission. Therefore, the content distribution network (CDN) came into being. It caches content on multiple distributed nodes, allowing users to access these nodes nearby to obtain content, thereby improving user access speed and overall network performance.

[0003] However, with the further development of the Internet, the traditional CDN architecture is also facing some challenges. The traditional CDN architecture usually adopts a centralized load balancing mechanism, and all requests need to be distributed through the central node, which may lead to performance bottlenecks and single point failure problems of the central node. Secondly, purchasing a load balancing system and a CDN system at the same time may greatly increase user costs, and the increase in costs may discourage some users.

[0004] In order to solve the above problems, the present invention proposes a method for implementing CDN based on a distributed load balancing system. Summary of the invention

[0005] In order to make up for the defects of the prior art, the present invention provides a simple and efficient method for realizing CDN based on a distributed load balancing system.

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

[0007] A method for implementing CDN based on a distributed load balancing system includes the following steps:

[0008] Step S1: Environment preparation and business system deployment

[0009] A hard anti-affinity strategy is used to deploy a distributed load balancing system, and the open source Nginx is used as the load balancer inside the load balancing node;

[0010] The load balancer includes the http proxy ngx_http_proxy_module module and the third-party open source ngx_cache_purge module;

[0011] Among them, the ngx_http_proxy_module is used to cache static resources (such as images, CSS / JS files, etc.) or user-defined selected dynamic content, so as to reduce the processing requirements of the server, reduce the CPU and memory usage of the cloud server, thereby improving the processing power and response speed of the server, and reducing the access of repeated requests to the cloud server, thus saving internal bandwidth, reducing the data transmission time, and improving the access speed;

[0012] The ngx_cache_purge module is used to refresh the cache.

[0013] A single node of the distributed load balancing system adopts a specification of 8C16G, and a hard anti-affinity strategy is adopted for deployment among the load balancing nodes to avoid single-point failures caused by hardware server failures; each load balancing node is configured with a 100G system disk and a 500G data disk, and preferably an SSD or other type of high-performance cloud hard disk is used for the data disk.

[0014] Step S2: Configure Nginx on the load balancing node

[0015] Configure the cache, and cache the data to a data disk with higher performance instead of the system disk to speed up the cache writing and reading efficiency, so that the load balancing node can cache the content responded by the backend server, thereby directly using the cache response in subsequent requests, reducing the requests to the backend server, speeding up the response speed, and reducing the load of the server;

[0016] In the step S2, the steps for configuring the cache are as follows:

[0017] Step S2.1: First, define a cache area through the proxy_cache_path directive to store cache data; then specify the mounting path of the data disk of the load balancing node, define the storage hierarchy of the cache files, and define a shared memory area to store cache keys and metadata;

[0018] Step S2.2: Define the maximum value of the cache, the longest storage time of the cache items, and whether to use a temporary storage path;

[0019] Step S2.3: Define the cache key, and use the $uri variable as the cache key for caching static resources;

[0020] Step S2.4: Define the matching rules for static resources. After successful matching, first query according to the cache key value:

[0021] If there is a corresponding key value in the cache, the cache is hit, and the load balancer reads the cache value to reply to the request;

[0022] If there is no corresponding key in the cache, the load balancer forwards the request to the cloud server. After the cloud server replies to the request, the load balancer decides whether to cache the request result in the cache area based on the specific configuration for the next request to read.

[0023] Step S2.5, configure the validity period of the proxy cache. For responses with status codes 200 and 302, the cache will be valid for one day;

[0024] For responses with status code 404, the cache will be valid for ten minutes;

[0025] For responses with any other status code, the cache will be valid for one hour.

[0026] Step S2.6: Customize the configuration according to specific business needs to determine whether expired cached responses can be used when the backend server or source server is unavailable.

[0027] Step S3: monitor cache

[0028] The monitoring module collects cache information in real time and monitors whether the cache content is updated. If updated, the cache of Nginx on the load balancing node is refreshed.

[0029] In the step S3, by analyzing the Nginx log, the cached interface is recorded, and only the interface with the http corresponding status code of 200 is saved; a key-value pair is maintained, the key is the cache key (proxy_cache_key), that is, the $uri variable of Nginx, the value is the MD5 value of the response body of the request, that is, the MD5 value of the response body, and a counter is maintained, and the initial value is 1440;

[0030] A scheduled task is performed every minute to traverse all key-value pairs. For each key value, the backend cloud server interface is called once, and the MD5 value of the request return result is compared and analyzed to see if it is the same as the saved MD5 value:

[0031] If they are the same, it means that the cache content is consistent with the return result of the backend cloud server interface. There is no need to refresh the cache. The counter is reduced by one and waits for the scheduled task detection in the next minute.

[0032] If they are not the same, it means that the cache content is inconsistent with the return result of the backend cloud server interface. The backend cloud server has been updated and the cache needs to be refreshed. Call the agent inside all load balancing nodes to execute the following command to clean up the cache:

[0033] curl-X PURGE "$scheme: / / $host / $uri"

[0034] Among them, $scheme is the protocol used, such as http or https, $host is the domain name, and $uri is the uri corresponding to the interface;

[0035] After clearing the cache, if the client calls the corresponding interface again, when the request reaches the load balancing node, it cannot hit the cache because the cache has been deleted. Therefore, the load balancing node forwards the request to the backend cloud server. After the cloud server returns a response, a new cache is established inside the load balancing node for the client to call.

[0036] Step S4: Refresh cache interface when application is updated

[0037] An interface for refreshing all caches is exposed through the management module to ensure that after the application inside the cloud server is updated, the load balancing node can clean up the cache in time, relieve the pressure on the monitoring module, and update the cache in time.

[0038] When the application inside the cloud server is updated and a large amount of cache information becomes invalid, all caches need to be refreshed. At this time, in step S4, the management module is called to refresh the interface of all caches. The interface calls all load balancing node agents inside to execute the following command:

[0039] curl-X PURGE "$scheme: / / $host / *"

[0040] Among them, * represents clearing all caches;

[0041] The refreshed API is provided to operation and maintenance personnel for application update scenarios within the cloud server.

[0042] A device for implementing CDN based on a distributed load balancing system, comprising:

[0043] The business system deployment module is responsible for deploying the distributed load balancing system using the hard anti-affinity strategy. The open source Nginx is used as the load balancer inside the load balancing node. The load balancer includes the http proxy ngx_http_proxy_module module and the third-party open source ngx_cache_purge module.

[0044] Among them, the ngx_http_proxy_module module is used to cache static resources (such as pictures, CSS / JS files, etc.) or dynamic content selected by the user;

[0045] The ngx_cache_purge module is used to refresh the cache;

[0046] The single node of the distributed load balancing system adopts the specification of 8C16G, and the load balancing nodes are deployed with a hard anti-affinity strategy to avoid single point failure caused by hardware server failure; each load balancing node is configured with a 100G system disk and a 500G data disk, where the data disk is preferably an SSD or other type of high-performance cloud hard disk, because cache file writing and reading will affect disk I / O, and it is recommended to use a fast storage solution. The configuration of the load balancing node can be determined according to the needs of the business system, and the above is only used as an example.

[0047] The configuration module is responsible for configuring the cache and caching data to a higher-performance data disk instead of a system disk to speed up cache writing and reading efficiency, so that the load balancing node can cache the content of the backend server response, so that the cache response can be directly used in subsequent requests, reducing requests to the backend server, speeding up the response speed, and reducing the server load;

[0048] The monitoring module is responsible for collecting cache information in real time and monitoring whether the cache content is updated. If updated, it refreshes the Nginx cache on the load balancing node.

[0049] The management module is responsible for refreshing all cached interfaces to ensure that after the application inside the cloud server is updated, the load balancing node can clean up the cache in time, relieve the pressure on the monitoring module, and update the cache in time.

[0050] A device for implementing CDN based on a distributed load balancing system, characterized in that it includes a memory and a processor; the memory is used to store a computer program, and the processor is used to implement the above method steps when executing the computer program.

[0051] A readable storage medium, characterized in that: a computer program is stored on the readable storage medium, and the computer program implements the above method steps when executed by a processor.

[0052] The beneficial effects of the present invention are as follows: the method for implementing CDN based on a distributed load balancing system can not only effectively improve network access speed and stability, but also meet users' needs for two high-quality network services, load balancing and CDN; it also has high scalability and flexibility, and can adjust the cache strategies of server nodes and load balancing according to actual needs to adapt to the ever-changing network environment and user needs. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the accompanying drawings required for the description of the embodiments or the prior art. Obviously, the accompanying drawings in the following description are some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0054] Attached Figure 1 It is a schematic diagram of the method for implementing CDN based on a distributed load balancing system according to the present invention. Specific implementation manners

[0055] To enable those skilled in the art of this technology to better understand the technical solutions in the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the scope of protection of the present invention.

[0056] The method for implementing CDN based on a distributed load balancing system includes the following steps:

[0057] Step S1, Environment preparation and business system deployment

[0058] Deploy a distributed load balancing system using a hard anti-affinity strategy, and use the open-source Nginx as the load balancer inside the load balancing nodes;

[0059] The load balancer includes the ngx_http_proxy_module module for http proxy and the third-party open-source ngx_cache_purge module;

[0060] Among them, the ngx_http_proxy_module module is used to cache static resources (such as pictures, CSS / JS files, etc.) or user-defined selected dynamic content to reduce the processing requirements of the server, reduce the use of the cloud server's CPU and memory, thereby improving the processing ability and response speed of the server, and reducing the access to the cloud server by repeated requests, thereby saving internal bandwidth, reducing the data transmission time, and improving the access speed;

[0061] The ngx_cache_purge module is used to refresh the cache. When the source station resources are updated or the version is upgraded, it is very important to update the cache of Nginx on the load balancing nodes. Otherwise, it will cause a delay for a quite long time (depending on the specific configuration), which will lead to inconsistent return results between the source station and the load balancing nodes. The function of refreshing the cache is also one of the core features of CDN.

[0062] Distributed load balancing is a network technology that distributes network or application traffic among multiple servers or service nodes to ensure high availability, high performance, and reliability of the system. In this architecture, the load balancer is not concentrated in one location, but distributed throughout the network, which can more efficiently handle cross-regional traffic and better cope with large-scale traffic and high concurrent requests. For the implementation of the distributed load balancing system, please refer to other solutions, which will not be repeated here.

[0063] The single node of the distributed load balancing system adopts the specification of 8C16G, and the load balancing nodes are deployed with a hard anti-affinity strategy to avoid single point failure caused by hardware server failure; each load balancing node is configured with a 100G system disk and a 500G data disk, where the data disk is preferably an SSD or other type of high-performance cloud hard disk, because cache file writing and reading will affect disk I / O, and it is recommended to use a fast storage solution. The configuration of the load balancing node can be determined according to the needs of the business system, and the above is only used as an example.

[0064] Step S2: Configure Nginx on the load balancing node

[0065] Configure cache to cache data to a higher-performance data disk instead of a system disk to speed up cache writing and reading, so that the load balancing node can cache the content of the backend server response, so that the cache response can be directly used in subsequent requests, reducing requests to the backend server, speeding up the response, and reducing the server load;

[0066] In step S2, the cache configuration steps are as follows:

[0067] Step S2.1, first define a cache area through the proxy_cache_path instruction to store cache data; then specify the mount path of the load balancing node data disk, define the storage hierarchy of the cache file, and define a shared memory area to store the cache key and metadata;

[0068] Step S2.2, define the maximum value of the cache, the maximum storage time of the cache item, and whether to use a temporary storage path;

[0069] Step S2.3, define the cache key, and use the $uri variable as the cache key for caching static resources;

[0070] Step S2.4: Define static resource matching rules. After a successful match, first query based on the cache key value:

[0071] If there is a corresponding key value in the cache, the cache is hit, and the load balancer reads the cache value to reply to the request;

[0072] If there is no corresponding key in the cache, the load balancer forwards the request to the cloud server. After the cloud server replies to the request, the load balancer decides whether to cache the request result in the cache area based on the specific configuration for the next request to read.

[0073] Step S2.5, configure the validity period of the proxy cache. For responses with status codes 200 and 302, the cache will be valid for one day;

[0074] For responses with status code 404, the cache will be valid for ten minutes;

[0075] For responses with any other status code, the cache will be valid for one hour.

[0076] Step S2.6: Customize the configuration according to specific business needs to determine whether expired cached responses can be used when the backend server or source server is unavailable.

[0077] The following is an example of Nginx configuration:

[0078]

[0079] The proxy_cache_path directive defines a cache area for storing cached data. Among them, / path / cache is the mount path of the load balancing node data disk mentioned in step S1. Caching data to a higher-performance data disk instead of a system disk can speed up the efficiency of cache writing and reading; levels defines the storage hierarchy of cache files; keys_zone defines a shared memory area for storing cache keys and metadata; max_size defines the maximum size of the cache, which is defined as 480G and can be defined based on the actual size of the data disk. Generally, this value is slightly smaller than the available size of the data disk; inactive refers to how long it takes for the cache item to be deleted after it has not been accessed; use_temp_path is whether to use a temporary storage path, which is defined as off here, and does not use a temporary storage path.

[0080] proxy_cache_key defines the cache key. Generally, the $uri variable can be used to cache static resources.

[0081] proxy_cache_purge PURGE from 127.0.0.1 indicates that the cache purge method is PURGE, and only cache purge requests from 127.0.0.1 are accepted. For security reasons, only the local node of the load balancing server is allowed to call this request, which can avoid calling cache purge requests when users access the system. This configuration is used by the monitoring module in the next step.

[0082] Configure multiple locations in a server block, where "location~*^.+\.(css|js|ico|gif|jpg|jpeg|png|html|htm)$" defines the matching rules, which means matching requests ending with these strings, which are all static resources (such as pictures, CSS / JS files, etc.). If there are dynamic resources that need to be cached, they can be implemented according to specific business needs. After matching this location, first query according to the cache key value configured by proxy_cache_key. If it is in the cache, it hits the cache, and the load balancer will read the cache value to reply to the request; if it is not in the cache, the load balancer will forward the request to the cloud server. After the cloud server replies to the request, the load balancer will decide whether to cache the request result in the cache area based on the specific configuration for the next request to read.

[0083] expires 1d means that each cache result is cached for up to one day, after which the cache content will be cleared; proxy_cache_valid is used to configure the validity period of the proxy cache. In the above configuration:

[0084] For responses with status codes 200 and 302, the cache will be valid for one day;

[0085] For responses with status code 404, the cache will be valid for ten minutes;

[0086] For responses with any other status code, the cache will be valid for one hour.

[0087] proxy_cache_valid needs to be set according to specific business needs.

[0088] proxy_cache_use_stale is used to control whether expired cache responses can be used when the backend server or source server is unavailable. This can improve the availability of the business system and user experience to a certain extent, because it allows Nginx to still provide content when there is a problem with the backend server, even if the content may not be the latest. In the above configuration, error means that the expired cache is used when the backend server returns an error (for example, connection failure, timeout, etc.); timeout means that the expired cache is used when the backend server does not respond within a specified time; invalid_header means that the expired cache is used when the response header returned by the backend server is invalid; updating means that the expired cache is used when the cache is being updated and the new content is not yet ready; http_50x means that the request with a response status code of 50x uses the expired cache. It also needs to be configured according to specific business needs.

[0089] The "location / " part defines the default configuration. If no other location configuration is matched, it will be forwarded to the default configuration. Do not enable caching in the default location definition because some dynamic resources, such as http requests of POST and DELETE methods, cannot be cached.

[0090] Step S3: monitor cache

[0091] The monitoring module collects cache information in real time and monitors whether the cache content is updated. If updated, the cache of Nginx on the load balancing node is refreshed.

[0092] In the step S3, by analyzing the Nginx log, the cached interface is recorded, and only the interface with the http corresponding status code of 200 is saved; a key-value pair is maintained, the key is the cache key (proxy_cache_key), that is, the $uri variable of Nginx, the value is the MD5 value of the response body of the request, that is, the MD5 value of the response body, and a counter is maintained, and the initial value is 1440;

[0093] A scheduled task is performed every minute to traverse all key-value pairs. For each key value, the backend cloud server interface is called once, and the MD5 value of the request return result is compared and analyzed to see if it is the same as the saved MD5 value:

[0094] If they are the same, it means that the cache content is consistent with the return result of the backend cloud server interface. There is no need to refresh the cache. The counter is reduced by one and waits for the scheduled task detection in the next minute.

[0095] If they are not the same, it means that the cache content is inconsistent with the return result of the backend cloud server interface. The backend cloud server has been updated and the cache needs to be refreshed. Call the agent inside all load balancing nodes to execute the following command to clean up the cache:

[0096] curl-X PURGE "$scheme: / / $host / $uri"

[0097] Among them, $scheme is the protocol used, such as http or https, $host is the domain name, and $uri is the uri corresponding to the interface;

[0098] After clearing the cache, if the client calls the corresponding interface again, when the request reaches the load balancing node, it cannot hit the cache because the cache has been deleted. Therefore, the load balancing node forwards the request to the backend cloud server. After the cloud server returns a response, a new cache is established inside the load balancing node for the client to call.

[0099] Step S4: Refresh cache interface when application is updated

[0100] An interface for refreshing all caches is exposed through the management module to ensure that after the application inside the cloud server is updated, the load balancing node can clean up the cache in time, relieve the pressure on the monitoring module, and update the cache in time.

[0101] When the application inside the cloud server is updated and a large amount of cache information becomes invalid, all caches need to be refreshed. At this time, in step S4, the management module is called to refresh the interface of all caches. The interface calls all load balancing node agents inside to execute the following command:

[0102] curl-X PURGE "$scheme: / / $host / *"

[0103] Among them, * represents clearing all caches;

[0104] The refreshed API is provided to operation and maintenance personnel for application update scenarios within the cloud server.

[0105] The device for implementing CDN based on the distributed load balancing system includes:

[0106] The business system deployment module is responsible for deploying the distributed load balancing system using the hard anti-affinity strategy. The open source Nginx is used as the load balancer inside the load balancing node. The load balancer includes the http proxy ngx_http_proxy_module module and the third-party open source ngx_cache_purge module.

[0107] Among them, the ngx_http_proxy_module module is used to cache static resources (such as pictures, CSS / JS files, etc.) or dynamic content selected by the user;

[0108] The ngx_cache_purge module is used to refresh the cache;

[0109] The single node of the distributed load balancing system adopts the specification of 8C16G, and the load balancing nodes are deployed with a hard anti-affinity strategy to avoid single point failure caused by hardware server failure; each load balancing node is configured with a 100G system disk and a 500G data disk, where the data disk is preferably an SSD or other type of high-performance cloud hard disk, because cache file writing and reading will affect disk I / O, and it is recommended to use a fast storage solution. The configuration of the load balancing node can be determined according to the needs of the business system, and the above is only used as an example.

[0110] The configuration module is responsible for configuring the cache and caching data to a higher-performance data disk instead of a system disk to speed up cache writing and reading efficiency, so that the load balancing node can cache the content of the backend server response, so that the cache response can be directly used in subsequent requests, reducing requests to the backend server, speeding up the response speed, and reducing the server load;

[0111] The monitoring module is responsible for collecting cache information in real time and monitoring whether the cache content is updated. If updated, it refreshes the Nginx cache on the load balancing node.

[0112] The management module is responsible for refreshing all cached interfaces to ensure that after the application inside the cloud server is updated, the load balancing node can clean up the cache in time, relieve the pressure on the monitoring module, and update the cache in time.

[0113] The device for implementing CDN based on a distributed load balancing system includes a memory and a processor; the memory is used to store a computer program, and the processor is used to implement the above method steps when executing the computer program.

[0114] The readable storage medium stores a computer program, and when the computer program is executed by a processor, the above method steps are implemented.

[0115] This method of implementing CDN based on a distributed load balancing system deploys a load balancer on multiple distributed nodes, reasonably distributes user requests to each node, and then caches static resources (such as images, CSS / JS files, etc.) or specific dynamic content on the load balancing node, thereby achieving load balancing and content distribution.

[0116] Compared with the existing technology, it has the following characteristics:

[0117] First, there is no need for a separate CDN system. The distributed load balancing system alone can achieve the functions of load balancing and CDN. Although it is not as comprehensive as a separate CDN system, it can meet the most core basic functions, save resources, and reduce user costs.

[0118] Second, by caching static resources (such as images, CSS / JS files, etc.) or specific dynamic content, the server's processing requirements can be reduced, the use of CPU and memory can be reduced, thereby improving the server's processing power and response speed.

[0119] Third, caching reduces data transmission time. Users can obtain content directly from the cache of the load balancing node without having to load it from the source server every time. This significantly reduces loading time, increases business system access speed, and improves user experience.

[0120] Fourth, the best path can be selected to distribute requests to server nodes based on the user's geographic location and network conditions, reducing network latency and packet loss rate.

[0121] The embodiment described above is only one specific implementation of the present invention. Common changes and substitutions made by those skilled in the art within the scope of the technical solution of the present invention should be included in the protection scope of the present invention.

Claims

1. A method for implementing CDN based on a distributed load balancing system, characterized in that: The following steps are involved: Step S1: Environment preparation and business system deployment A hard anti-affinity strategy is used to deploy a distributed load balancing system, and the open source Nginx is used as the load balancer inside the load balancing node; Step S2: Configure Nginx on the load balancing node Configure cache to cache data to the data disk instead of the system disk to speed up cache writing and reading efficiency, so that the load balancing node can cache the content of the backend server response, so that the cache response can be directly used in subsequent requests, reducing requests to the backend server, speeding up the response speed, and reducing the server load; Step S3: monitor cache The monitoring module collects cache information in real time and monitors whether the cache content is updated. If updated, the cache of Nginx on the load balancing node is refreshed. Step S4: Refresh cache interface when application is updated An interface for refreshing all caches is exposed through the management module to ensure that after the application inside the cloud server is updated, the load balancing node can clean up the cache in time, relieve the pressure on the monitoring module, and update the cache in time.

2. The method for implementing CDN based on a distributed load balancing system according to claim 1, characterized in that: The load balancer includes the http proxy ngx_http_proxy_module module and the third-party open source ngx_cache_purge module; Among them, the ngx_http_proxy_module module is used to cache static resources or user-defined dynamic content; The ngx_cache_purge module is used to refresh the cache.

3. The method for implementing CDN based on a distributed load balancing system according to claim 1, characterized in that: A single node of the distributed load balancing system adopts the specification of 8C16G, and a hard anti-affinity strategy is adopted between the load balancing nodes to avoid single point failure caused by hardware server failure; Each load balancing node is configured with a 100G system disk and a 500G data disk, where the data disk uses an SSD or cloud hard disk.

4. The method for implementing CDN based on a distributed load balancing system according to claim 1, characterized in that: In step S2, the cache configuration steps are as follows: Step S2.1, first define a cache area through the proxy_cache_path instruction to store cache data; then specify the mount path of the load balancing node data disk, define the storage hierarchy of the cache file, and define a shared memory area to store the cache key and metadata; Step S2.2, define the maximum value of the cache, the maximum storage time of the cache item, and whether to use a temporary storage path; Step S2.3, define the cache key, and use the $uri variable as the cache key for caching static resources; Step S2.4, define static resource matching rules. After a successful match, first query based on the cache key value: if there is a corresponding key value in the cache, the cache is hit, and the load balancer reads the cache value to reply to the request; If there is no corresponding key in the cache, the load balancer forwards the request to the cloud server. After the cloud server replies to the request, the load balancer decides whether to cache the request result in the cache area based on the specific configuration for the next request to read. Step S2.5, configure the validity period of the proxy cache. For responses with status codes 200 and 302, the cache will be valid for one day; For responses with status code 404, the cache will be valid for ten minutes; For responses with any other status code, the cache will be valid for one hour; Step S2.6: Customize the configuration according to specific business needs to determine whether expired cached responses can be used when the backend server or source server is unavailable.

5. The method for implementing CDN based on a distributed load balancing system according to claim 1, characterized in that: In the step S3, by analyzing the Nginx log, the cached interface is recorded, and only the interface with the http corresponding status code of 200 is saved; a key-value pair key-value is maintained, the key key is the cache key, that is, the $uri variable of Nginx, the value value is the MD5 value of the response body of the request, that is, the MD5 value of the response body, and a counter is maintained, and the initial value is 1440; A scheduled task is performed every minute to traverse all key-value pairs. For each key value, the backend cloud server interface is called once, and the MD5 value of the request return result is compared and analyzed to see if it is the same as the saved MD5 value: If they are the same, it means that the cache content is consistent with the return result of the backend cloud server interface. There is no need to refresh the cache. The counter is reduced by one and waits for the scheduled task detection in the next minute. If they are not the same, it means that the cache content is inconsistent with the return result of the backend cloud server interface. The backend cloud server has been updated and the cache needs to be refreshed. Call the agent inside all load balancing nodes to execute the following command to clean up the cache: curl-X PURGE "$scheme: / / $host / $uri" Among them, $scheme is the protocol used, $host is the domain name, and $uri is the uri corresponding to the interface; After clearing the cache, if the client calls the corresponding interface again, when the request reaches the load balancing node, it cannot hit the cache because the cache has been deleted. Therefore, the load balancing node forwards the request to the backend cloud server. After the cloud server returns a response, a new cache is established inside the load balancing node for the client to call.

6. The method for implementing CDN based on a distributed load balancing system according to claim 1, characterized in that: In step S4, the management module is called to refresh the interface of all caches, and all load balancing node agents are called internally in the interface to execute the following command: curl-X PURGE "$scheme: / / $host / *" Among them, * represents clearing all caches; The refreshed API is provided to operation and maintenance personnel for application update scenarios within the cloud server.

7. A device for implementing CDN based on a distributed load balancing system, characterized in that: include: The business system deployment module is responsible for deploying the distributed load balancing system using the hard anti-affinity strategy. The open source Nginx is used as the load balancer inside the load balancing node. The load balancer includes the http proxy ngx_http_proxy_module module and the third-party open source ngx_cache_purge module. Among them, the ngx_http_proxy_module module is used to cache static resources or user-defined dynamic content; the ngx_cache_purge module is used to refresh the cache; The configuration module is responsible for configuring the cache and caching data to a higher-performance data disk instead of a system disk to speed up cache writing and reading efficiency, so that the load balancing node can cache the content of the backend server response, so that the cache response can be directly used in subsequent requests, reducing requests to the backend server, speeding up the response speed, and reducing the server load; The monitoring module is responsible for collecting cache information in real time and monitoring whether the cache content is updated. If updated, it refreshes the Nginx cache on the load balancing node. The management module is responsible for refreshing all cached interfaces to ensure that after the application inside the cloud server is updated, the load balancing node can clean up the cache in time, relieve the pressure on the monitoring module, and update the cache in time.

8. The device for implementing CDN based on a distributed load balancing system according to claim 1, characterized in that: A single node of the distributed load balancing system adopts a specification of 8C16G, and a hard anti-affinity strategy is deployed between the load balancing nodes to avoid single point failures caused by hardware server failures; each load balancing node is configured with a 100G system disk and a 500G data disk, where the data disk adopts an SSD or cloud hard disk.

9. A device for implementing CDN based on a distributed load balancing system, characterized in that: The method comprises a memory and a processor; the memory is used to store a computer program, and the processor is used to implement the method according to any one of claims 1 to 6 when executing the computer program.

10. A readable storage medium, characterized in that: The readable storage medium stores a computer program, and when the computer program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.

Images