The use of cache in programming

Caching is one of the most common ways to optimize system performance. By adding cache before time-consuming components (such as databases), you can reduce the number of actual calls and reduce response time. But be sure to think twice before introducing caching.

Obtaining resources through the Internet is slow and costly. To this end, the HTTP protocol includes a cache control part so that the HTTP client can cache and reuse previously obtained resources, thereby optimizing performance and improving experience. Although the cache control part of HTTP has some changes as the protocol evolves. But I feel that as a back-end programmer, when developing Web services, you only need to pay attention to the request header If-None-Match, the response header ETag, and the response header Cache-Control. Because these three HTTP headers can meet your needs, and most of today's browsers support these three HTTP headers. All we have to do is ensure that each server response provides the correct HTTP header directives to instruct the browser when and for how long it can cache the response.

Where is the cache?

There are three roles in the above figure, browser, web proxy and server. As shown in the figure, HTTP cache exists in the browser and web proxy. Of course, there are also various caches inside the server, but this is no longer the HTTP cache to be discussed in this article. The so-called Http cache control is an agreement to control the cache usage strategies of browsers and web proxies by setting different response headers Cache-Control, and to control the cache by setting the request header If-None-Match and the response header ETag. Verify the effectiveness.

Response header ETag

The full name of ETag is Entity Tag, which is used to identify a resource. In the specific implementation, the ETag can be the hash value of the resource or an internally maintained version number. But no matter what, ETag should be able to reflect changes in resource content, which is the basis for Http caching to work properly.

As shown in the above example, when the server returns a response, it usually includes some metadata information about the response in the Http header, of which ETag is one of them. In this example, the ETag with the value x1323ddx is returned. When the content of the resource/file changes, the server should return a different ETag.

Request header If-None-Match

For the same resource, such as /file in the previous example, after making a request, the browser already has a version of /file content, and this version of ETag. When the user needs this resource next time and the browser requests the server again, the request header If-None-Match can be used to tell the server that it already has a /file with an ETag of x1323ddx, so , if /file on the server has not changed, that is to say, if the ETag of /file on the server is also x1323ddx, the server will not return the content of /file, but will return a 304 response, telling the browser that the resource has not changed. , the cache is valid.

As shown in the above example, after using If-None-Match, the server only needs a small response to achieve the same result, thereby optimizing performance.

Response header Cache-Control

Each resource can define its own caching strategy through the Http header Cache-Control. Cache-Control controls who can cache the response and under what conditions. how long. The fastest requests are the ones that don't have to communicate with the server: with a local copy of the response, we avoid all network latency and the data cost of data transfer. To this end, the HTTP specification allows servers to return a series of different Cache-Control directives that control how browsers or other relay caches cache a response and for how long.

The Cache-Control header is defined in the HTTP/1.1 specification, replacing headers previously used to define response caching policies (such as Expires). All current browsers support Cache-Control, so using it is enough.

Below I will introduce the common instructions that can be set in Cache-Control.

max-age

This directive specifies the maximum time (in seconds) that the obtained response is allowed to be reused starting from the current request. For example: Cache-Control:max-age=60 means The response can be cached and reused for another 60 seconds. It should be noted that within the time specified by max-age, the browser will not send any requests to the server, including requests to verify whether the cache is valid, that is, if within this period If the resources on the server change within this time, the browser will not be notified and will use the old version of the resources. Therefore, you need to be careful when setting the length of the cache time.

public and private

If public is set, it means that the response can be cached in the browser or any relayed Web proxy. Public is the default value, that is, Cache-Control:max-age=60 is equivalent to Cache-Control:public, max -age=60.

When the server is set to private such as Cache-Control:private, max-age=60, it means that only the user's browser can cache private responses and no relay web proxy is allowed. Caching it – For example, a user's browser can cache an HTML page that contains the user's private information, but a CDN cannot cache it if the server sets no-cache in the response. That is, Cache-Control: no-cache, then the browser must confirm with the server whether the returned response has been changed before using the cached resource. If the resource has not been changed, this can avoid downloading the previous response. This is achieved through the request header If-None-match and the response header ETag introduced above.

It should be noted that the name no-cache is a bit misleading, and it does not mean that after setting no-cache. The browser no longer caches the data, but when using the cached data, the browser needs to first confirm whether the data is still consistent with the server. If no-cache is set and the ETag implementation does not reflect the resource changes, it will happen. This causes the browser's cached data to never be updated.

no-store

If the server sets no-store, that is, Cache-Control: no-store, in the response, then the browser The server and any relayed Web proxy will not store the corresponding data this time. When the resource is requested next time, the browser can only request the server again and read the resource from the server again.

How to determine a resource. What about the Cache-Control strategy of resources?

The following flow chart can help you.

Common errors

Caching at startupSometimes, we will find that the application starts very slowly, It was eventually discovered that one of the dependent services took a long time to respond. What should I do?

Generally speaking, when encountering this kind of problem, it means that the dependent service cannot meet the demand. If this is a third-party service and the control is not in our hands, we may introduce caching at this time.

The problem with introducing cache at this time is that the cache invalidation strategy is difficult to take effect, because the original intention of cache design is to request as few dependent services as possible.

Premature caching

The "early" mentioned here is not the life cycle of the application, but the development cycle. Sometimes we see that some developers have estimated system bottlenecks and introduced caching in the early stages of development.

In fact, this approach masks possible performance optimization points. Anyway, the return value of this service will be cached by then. Why should I spend time optimizing this part of the code?

Integrated Cache

The "S" in the SOLID principle stands for - Single responsibility principle. When the application integrates the cache module, the cache module and the service layer are strongly coupled and cannot run independently without the participation of the cache module.

Cache all content

Sometimes, in order to reduce the response delay, you may blindly add caching to external calls. In fact, such behavior can easily prevent developers and maintainers from realizing the existence of the cache module, and ultimately make a wrong assessment of the reliability of the underlying dependent modules.

Cascading Cache

Caching everything, or just most of the content, may result in cached data that contains other cached data.

If the application contains this cascading cache structure, it may lead to a situation where the cache expiration time is uncontrollable. The top-level cache needs to wait until each level of cache is invalidated and updated before the final returned data is completely updated.

Cannot refresh the cache

Normally, the cache middleware will provide a tool to refresh the cache. For example, with Redis, maintainers can delete some data or even refresh the entire cache through the tools it provides.

However, some temporary caches may not contain such tools. For example, caches that simply store data within the content usually do not allow external tools to modify or delete the cached content. At this time, if abnormal cache data is found, maintenance personnel can only restart the service, which will greatly increase operation and maintenance costs and response time. What's more, some caches may write cache contents to the file system for backup. At this time, in addition to restarting the service, you also need to ensure that the cache backup on the file system is deleted before the application starts.

The impact of caching

The common errors that may be caused by the introduction of caching are mentioned above. These problems will not be considered in a cache-free system.

Deploying a system that relies heavily on cache may spend a lot of time waiting for the cache to expire. For example, if you cache content through a CDN, it may take several hours to refresh the CDN configuration and content cached by the CDN after the system is released.

In addition, prioritizing caching when a performance bottleneck occurs will cause performance problems to be covered up and not be truly solved. In fact, many times the time spent tuning code is not much different from introducing caching components.

Finally, for systems that include caching components, debugging costs will increase significantly. It often happens that the code is traced for half a day, and the resulting data comes from the cache and has nothing to do with the components that the actual logic should depend on. The same problem may also occur after all relevant test cases have been executed, but the modified code has not actually been tested.

How to make good use of cache?

Abandon caching!

Well, many times caching is unavoidable. In Internet-based systems, it is difficult to completely avoid the use of cache. Even the http protocol header contains cache configuration: Cache-Control: max-age=xxx.

Understand the data

If you want to access the data into the cache, you first need to understand the data update strategy. Only by clearly understanding when the data needs to be updated can we use the If-Modified-Since header to determine whether the data requested by the client needs to be updated. Should we simply return a 304 Not Modified response and let the client reuse the previous local cached data, or should we return the latest data? . In addition, in order to make better use of the cache in the http protocol, it is recommended to distinguish versions of the data, or use eTag to mark the version of the cached data.

Optimize performance instead of using caching

As mentioned earlier, using caching often masks potential performance issues. Use performance analysis tools whenever possible to find the real cause of your application's slow response and fix it. For example, reduce invalid code calls, optimize SQL according to SQL execution plan, etc.

Here is the code to clear all caches of the application

/* 
 * 文 件 名:  DataCleanManager.java 
 * 描   述:  主要功能有清除内/外缓存，清除数据库，清除sharedPreference，清除files和清除自定义目录 
 */  
package com.test.DataClean;  
  
import java.io.File;  
  
import android.content.Context;  
import android.os.Environment;  
  
/** 
 * 本应用数据清除管理器 
 */  
public class DataCleanManager {  
    /** 
     * 清除本应用内部缓存(/data/data/com.xxx.xxx/cache) 
     *  
     * @param context 
     */  
    public static void cleanInternalCache(Context context) {  
        deleteFilesByDirectory(context.getCacheDir());  
    }  
  
    /** 
     * 清除本应用所有数据库(/data/data/com.xxx.xxx/databases) 
     *  
     * @param context 
     */  
    public static void cleanDatabases(Context context) {  
        deleteFilesByDirectory(new File("/data/data/"  
                + context.getPackageName() + "/databases"));  
    }  
  
    /** 
     * 清除本应用SharedPreference(/data/data/com.xxx.xxx/shared_prefs) 
     *  
     * @param context 
     */  
    public static void cleanSharedPreference(Context context) {  
        deleteFilesByDirectory(new File("/data/data/"  
                + context.getPackageName() + "/shared_prefs"));  
    }  
  
    /** 
     * 按名字清除本应用数据库 
     *  
     * @param context 
     * @param dbName 
     */  
    public static void cleanDatabaseByName(Context context, String dbName) {  
        context.deleteDatabase(dbName);  
    }  
  
    /** 
     * 清除/data/data/com.xxx.xxx/files下的内容 
     *  
     * @param context 
     */  
    public static void cleanFiles(Context context) {  
        deleteFilesByDirectory(context.getFilesDir());  
    }  
  
    /** 
     * 清除外部cache下的内容(/mnt/sdcard/android/data/com.xxx.xxx/cache) 
     *  
     * @param context 
     */  
    public static void cleanExternalCache(Context context) {  
        if (Environment.getExternalStorageState().equals(  
                Environment.MEDIA_MOUNTED)) {  
            deleteFilesByDirectory(context.getExternalCacheDir());  
        }  
    }  
  
    /** 
     * 清除自定义路径下的文件，使用需小心，请不要误删。而且只支持目录下的文件删除 
     *  
     * @param filePath 
     */  
    public static void cleanCustomCache(String filePath) {  
        deleteFilesByDirectory(new File(filePath));  
    }  
  
    /** 
     * 清除本应用所有的数据 
     *  
     * @param context 
     * @param filepath 
     */  
    public static void cleanApplicationData(Context context, String... filepath) {  
        cleanInternalCache(context);  
        cleanExternalCache(context);  
        cleanDatabases(context);  
        cleanSharedPreference(context);  
        cleanFiles(context);  
        for (String filePath : filepath) {  
            cleanCustomCache(filePath);  
        }  
    }  
  
    /** 
     * 删除方法 这里只会删除某个文件夹下的文件，如果传入的directory是个文件，将不做处理 
     *  
     * @param directory 
     */  
    private static void deleteFilesByDirectory(File directory) {  
        if (directory != null && directory.exists() && directory.isDirectory()) {  
            for (File item : directory.listFiles()) {  
                item.delete();  
            }  
        }  
    }  
}

Summary

Caching is a very useful tool, but it can be easily abused. Don't use caching until the last minute and prioritize other ways to optimize application performance.