The usage summary of each node cache in Internet Project _ Cache

The use of caching is ubiquitous in web and app projects. It is used to mitigate the impact of two time-consuming heihu on the user experience while minimizing the burden on the server: access to the disk network access
(Original article, reprint please indicate the CSDN blog that has been transferred from Clement-xu.) ）
Therefore, the introduction of caching is generally to reduce the number of these two visits. Due to the wide range of Internet project nodes, each node will consider its own caching scheme, and the corresponding protocols need to be established between different nodes to fully utilize the cache.
The choice and use of caching generally need to consider the following aspects: Storage mode: including: Local cache (unshared), Server caching (sharing), distributed, non-persistent, sustainable, and so on failure mechanism: including: automatic timing failure, conditional trigger failure, manual failure, and so on.
A typical network architecture for Internet applications is as follows:

Each of these nodes can use caching to improve service efficiency across the network.
Browser caching: There are generally two kinds: page/File caching: HTML, images, etc. are cached by the browser. Data caching: Data that needs to be cached, such as data dictionaries, are frequently used and infrequently modified. The method can be implemented by using cookies, JS objects (reference: http://blog.csdn.net/clementad/article/details/46807641), HTML5 's Localstorage and Sessionstorage (reference: http://blog.csdn.net/clementad/article/details/46841821), and so on.
Failure mechanism: The next time you request a page/file, the server returns status code 304 indicates that the page or file is not updated, you can use the contents of the cache, otherwise you do not use the cache. The caching of data is negotiated by a custom protocol, such as the expiration of a cookie that can be used to determine the expiration of the data, or when the browser is closed.
App caching: Generally there are two ways to cache data: Database (SQLite) caching method of file caching
Failure mechanism: General need and API server negotiation when the expiration. One approach is to request the latest data to the API server (with the timestamp as the request parameter with the updated local cache data) each time the data needs to be presented, and the server determines the timestamp of the cache and the time stamp of the server data, and returns the data if the data in the database is newer than the app Otherwise, a flag with no updates to the data is returned (similar to the 304/307 status code in the HTTP protocol). It is also possible to further reduce network interaction by combining app's own decision to request the latest data for a period of time (for example, within one hours) without invoking the API interface.
Proxy server caching: typically caching pages (including static and dynamic pages) and files (Pictures, mp3, videos, and so on). For example, Nginx can configure which pages are cached and under what circumstances.
Proxy server caching is useful for offsite access, such as the Web server in Beijing, proxy server in Guangzhou, then the Guangzhou users through Proxy server access, the Guangzhou proxy server can cache a data, so the next time the Guangzhou visit will not need to go to Beijing to get the data.
Web/api Server cache: Because WEB/API servers are generally distributed deployments of multiple servers, there are two types of data that need to be cached: data that needs to be shared: such as user-related information: Token after login, cell phone verification Code, session-related information, and so on. The caching of these data needs to be placed in a cache server that everyone can access, such as Redis. (Redis a brief distinction between various data structures/types: http://blog.csdn.net/clementad/article/details/46714293). In addition, Spring-data defines a number of interfaces, annotations, and implementations for access to various caches, which can be easily used. Data that you can not share: such as system configuration information, area information, some basic data, and so on. This information is typically configured in a database or file, which is typically rarely changed, so it can be stored directly in the memory of the WEB/API server, such as in Java Concurrenthashmap, or by using the encapsulated guava Cache (Reference: encapsulation and use of guava cache: http://blog.csdn.net/clementad/article/details/46491701).

Failure mechanism: Generally to the cached data will be set to automatic expiration time, such as mobile phone authentication code set two minutes automatic failure. For some configuration information, you can set a longer expiration time (such as a day), and you need to provide an interface that is manually disabled so that data that requires urgent modification can be immediately effective. In addition, some caches (such as guava cache) will set a maximum storage space, after the cache space is full, will be based on a certain elimination algorithm (FIFO, LRU, LFU, etc., reference: http://blog.csdn.net/clementad/article/ details/48229243) to clear out some data.
Application Server caching: Generally caching system configuration information, and some static, no need to compute the information. You can decide to use a caching server (such as Redis), or a local cache (such as guava cache:http://blog.csdn.net/clementad/article/details/46491701), depending on whether you want to synchronize and share between servers.
The expiration mechanism is similar to the WEB/API server cache.
Database caching: A database can cache the results of a query statement and fetch the data directly from the cache the next time you receive the same query request. Enabling query caching has a significant effect on performance (refer to: http://blog.csdn.net/clementad/article/details/46806469).
Failure mechanism: After the cache space is full, will release a part of the data according to a certain algorithm; the cache associated with this record is invalidated after a record in the database table has been modified.
Search engine and other server caching: Basically all server nodes will consider caching, such as SOLR can cache the results of the search, the next time the same search can save system overhead.
In general, where there are nodes, there can be caches. In addition, CDN can also be seen as a cache, the server in the cache of files to the nearest user place.