In programming, how to use good cache?

Caching is one of the most common ways to optimize system performance by adding caches before time-consuming parts, such as databases, to reduce the number of actual calls and reduce response times. But before you introduce a cache, be sure to think twice. This article provides some suggestions on how to use good caches by using some common errors when caching is introduced.
I. Common Errors
1. Cache at startup
Sometimes we find that the application starts very slowly and finally discovers that one of the dependent service response times is very long.
In general, this type of problem indicates that the dependency service is unable to meet the requirements. If this is a third-party service, control is not on its own, and we may introduce a cache.
The problem with the introduction of caching is that the cache invalidation policy is difficult to take effect because the cache design is intended to be as few requests as possible to the dependent services.
2. Caching prematurely
This refers to "early", not the life cycle of the application, but the cycle of development. Sometimes we see that some developers have already estimated system bottlenecks and introduced caches in the early stages of development.
In fact, such a practice obscures the point at which performance optimizations might be performed. Anyway, the return value of this service will be cached, why should I take the time to optimize this part of the code?
3. Integrated Cache
The "S" representation in the solid principle-single function principle (responsibility principle). After the application integrates the cache module, the cache module and the service layer are strongly coupled and cannot be run alone without the participation of the cache module.
4. Cache All content
Sometimes in order to reduce the response delay, it is possible to blindly add cache to external calls. In fact, such behavior makes it easy for developers and maintainers to be unaware of the existence of the cache module and ultimately to evaluate the reliability of the underlying dependency module incorrectly.
5. Cascade Cache
Caching everything, or just caching most of the content, may cause other cached data to be included in the cached data.
If the application contains this cascading cache structure, it may result in an uncontrolled cache expiration time. The topmost cache needs to be updated after each level of cache is invalidated, and the final data returned will be completely updated.
6. Non-flush cache
Typically, the cache middleware provides a tool to flush the cache. For example, for Redis, maintenance personnel can delete part of the data and even refresh the entire cache through the tools they provide.
However, some temporary caches may not contain such a tool. For example, a simple cache that stores data in content does not normally allow external tools to modify or delete cached content. At this point, if the cache data is found to be abnormal, maintenance personnel can only take the way to restart the service, which will greatly increase operational costs and response time. What's more, some caches may write cache content to the file system for backup. 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.
7. The impact of caching
The above mentioned are the common errors that can be caused by introducing the cache, which are not considered in a cache-free system.
Deploying a system that relies heavily on caching may take a significant amount of time to wait for the cache to fail. For example, through CDN cache content, the system is released to refresh the CDN configuration, CDN cache content, may take several hours.
In addition, a performance bottleneck that takes precedence over caching can cause performance problems to be masked and not really resolved. In fact, there are times when tuning code takes a lot of time, and the introduction of cache components does not differ too much.
Finally, for systems that contain cache components, the cost of debugging is greatly increased. It often happens to trace a half-day code, and the resulting data comes from the cache, and there is no relation to the actual logically dependent component. The same problem may occur after all relevant test cases have been executed, and the modified code is not actually tested.
two. How to use a good cache?
1. Discard the cache!
Well, many times the cache is unavoidable. Internet-based systems, it is difficult to completely avoid the use of cache, and even the HTTP protocol header, including the cache configuration: Cache-control:max-age=xxx.
2. Understanding the Data
If you want to access the data cache, you first need to understand the data update strategy. Only when you have a clear understanding of when the data needs to be updated, can you use the If-modified-since header to determine if the data requested by the client needs to be updated, is it simple to return 304 not Modified the local cache data before the client is reused, or to return the latest data. In addition, to make better use of the cache in the HTTP protocol, it is recommended to differentiate the data version, or use the ETag to mark the version of the cached data.
3. Optimize performance rather than using caching
Using caching tends to obscure potential performance issues. Use performance analysis tools whenever possible to find the real cause of slow application response and fix it. For example, reduce invalid code calls, optimize SQL based on SQL execution plans, and more.
three. Summary
Caching is a very useful tool, but it is extremely easy to misuse. Do not use caching at the last minute, and prioritize other ways to optimize application performance.

In programming, how to use good cache?