Nginx cache system design principle

: This article mainly introduces the nginx cache system design principles. if you are interested in the PHP Tutorial, please refer to it. Here, we use the nginx cache system as a clue to discuss the design and related details of a cache server. I try my best to analyze it from the perspective of design and framework. I will not refer to the code here, for details, please join us.

After a cache server obtains a file from the backend, it is either directly sent to the client (the name is passthrough) or cached locally. when the same request is sent to the cache server in the future, you can use the local copy directly, if you can. If the locally cached file is accessed by subsequent requests, it is called Hit (Hit) in the cache ). If no file is cached locally, the cache server needs to configure or resolve the domain name to obtain the file from the backend. this is called cache miss, that is, miss. We will discuss more about the cache server when analyzing the nginx cache system.

Nginx storage systems are divided into two types. one is enabled through proxy_store, which is stored locally according to the file path in the url. For example,/file/2013/0001/en/test.html, nginx will create directories and files in sequence under the specified storage directory. The other type is enabled through proxy_cache. files stored in this way are not organized by url path, but managed in some special ways (this is called Custom mode ), the custom method is the key analysis. What are the advantages of these two methods?

The process of storing files by url path is simple, but the performance is poor. First, we need to create such a deep directory on the local file system, the file opening and searching will be very slow (think back to the process of finding inode through the path name in the kernel ). If you use a custom mode to process the mode, although the file and path are not required, it does not increase complexity and reduce performance due to the url length. In a sense, this is a user-mode file system, and the most typical is the CFS in squid. Nginx is relatively simple to use and mainly managed by the md5 value of the url. we will analyze it later.

The cache cannot be separated from the backend and then sent to the client. The specific processing method is easy to think of. it must be sent while receiving. Other methods are too inefficient, such as reading and sending. Here we will mention nginx side-by-side sending. The structure is ngx_event_pipe_t, which is the medium for communication between the backend and the client. Because this structure is a common component, some special tags are required to handle storage-related functions, so the member cacheable will take on this responsibility.

P-> cacheable = u-> cacheable | u-> store;

That is, if cacheable is 1, it needs to be stored; otherwise, it is not stored. What does u-> cacheable and u-> store represent? They represent the two methods mentioned above, namely proxy_cache and proxy_store.

(To add some knowledge, when nginx retrieves backend data, its behavior is controlled by proxy_buffering, and its role is to enable response buffering for backend servers. If caching is enabled, if the proxy server can quickly pass the response and put it into the buffer, you can use proxy_buffer_size and proxy_buffers to set relevant parameters. If the response cannot be fully stored in the memory, write it to the hard disk. If Buffering is disabled, responses sent from the backend are immediately sent to the client .)

Here are some edges, and we have not touched the core of the nginx cache function yet. In terms of implementation, there is a member in the nginx upstream structure called cache, whose type is ngx_shm_zone_t. If we enable the cache function, the cache member is used to manage the shared memory (why is the shared memory used ?), In other storage methods, this member is NULL. In addition, a file in the cache system is usually called a store object, that is, a cache object. Therefore, you must create a store object before caching. An important question is how to choose the creation time. what do you think? First, we need to check whether a file needs to be cached. Obviously, files requested by the GET method usually need to be cached. Therefore, we saw the GET method in the early stage of request processing, you can create an object first. However, in many cases, even files requested by a GET method cannot be cached. Therefore, creating an object too early will not only waste time but also space. In the end, it will be destroyed. So what will affect the storage of GET requests? That is, the Cache-control field in the response header. This field tells the proxy or browser whether the file can be cached. Generally, cache servers must Cache requests that do not contain the cache-control field in the response header.

Based on this consideration, the cache server we developed is to create a cache object after the response header is parsed and sufficient evidence can be cached. Unfortunately, nginx does not do this.

Nginx creates a cache object in the ngx_http_upstream_init_request function. what stage is this function in http processing? Before establishing a connection with the backend. In my opinion, this is not suitable... What do you think?

For the creation process, you can read the ngx_http_upstream_cache function. Here I will compare our cache with nginx for analysis. In our request, a store member is used to establish a connection with the cached object. Nginx is similar. its request structure has a cache member to do the same thing. The difference is that the space of our store members is in the shared memory, while nginx is applied in the r-> pool (why do we do this ?).

Next, nginx needs to generate the key of the cache object according to the configuration. md5 is usually used here. This key is the unique identifier of a cached object in the system. many people may worry about md5 collision. I think the requirements are not extremely demanding, and they are completely acceptable here, and the processing is relatively simple.

What will be processed later is how the files should be stored on the disk?

Take the previous example:/file/2013/0001/en/test.html. its md5 value is 8ef9229f02c5672c747dc7a324d658d0. nginx uses it as the file name. In this way, you can? What if we find a directory to store all these files? We know that in most file systems, there is a limit on the number of files in a single directory, so this simple and crude processing is not acceptable. What should we do? Nginx configuration allows you to use multi-level directories to solve this problem. To put it simply, nginx uses the levels command to specify the number of directory layers (separated by colons) and the number of characters in each directory name. In our example, assume that levels =, it means that two levels of directories are used. The first level of directory name is a character, and the second level uses two characters. However, nginx supports a maximum of three levels of directories, namely levels = xxx: xxx.

Where are the characters that constitute the directory name? Assume that our storage directory is/cache and levels =, the above files are stored as follows:

/Cache/0/8d/8ef9229f02c5672c747dc7a324d658d0

See how the names of the directories 0 and 8d come from.

After the object is created, the ngx_http_file_cache_exists will be processed in the cache object management structure.

If the current directory and file already exist when this file is created, what should I do? You can flip through the code to see how nginx works.

The discussion comes with a paragraph, but now it's all about preparation. next time we will discuss how to handle the arrival of backend content.

Additional reading:

Http://www.pagefault.info /? P = 123

Http://www.pagefault.info /? P = 375

The above introduces the nginx cache system design principles, including the content, hope to be helpful to friends interested in PHP tutorials.