Shulou(Shulou.com)06/02 Report--

This article mainly shows you the "sample analysis of java caching core technologies", which is easy to understand and well-organized. I hope it can help you solve your doubts. Let the editor lead you to study and learn the article "sample analysis of java caching core technologies".

Text

Caching is quite familiar to every developer, in order to improve the performance of the program, we will add caching, but where to add caching, how to add caching?

Suppose a website needs to improve performance, and the cache can be placed in a browser, in a reverse proxy server, in an application process, and in a distributed cache system.

From the user request data to the data return, the data goes through the browser, CDN, proxy server, application server, and database. Caching technology can be used in every link.

Request data from the browser / client, get the changes of the data through HTTP and CDN, and get static resources through reverse proxy when you arrive at the proxy server (Nginx).

Further down to the application server, you can obtain data through in-process (in-heap) caching, distributed caching and other progressive ways. If none of the above caches hit the data, it will be back to the database.

The request order of the cache is: the user requests → HTTP cache → CDN cache → proxy server cache → distributed cache → database in the → process.

It seems that caching can be added to every aspect of the architecture of the technology to see how caching technology is applied in each link.

1. HTTP cache

When the user requests the server through the browser, the HTTP request is initiated, and if each HTTP request is cached, the pressure on the application server can be reduced.

When the first request is made, the browser's local cache does not cache data, so it fetches the data from the server and puts it into the browser's cache. The next time the request is made, the local or service information is read according to the cache policy.

The transmission of general information is transmitted through the HTTP request header Header. At present, there are two common caching methods, namely:

Force caching

Contrast caching

1.1. Force caching

When the browser local cache holds the cache information, the cache data can be used directly if the cache data is not invalidated. Otherwise, you need to retrieve the data.

This caching mechanism seems straightforward, so how to determine whether the cached data is invalid? Here you need to pay attention to the two fields Expires and Cache-Control in HTTP Header.

Expires is the expiration time returned by the server. When the client requests the server for the first time, the server will return the expiration time of the resource. If the client requests the server again, the request time is compared with the expiration time.

If the request time is less than the expiration time, then the cache has not expired, and the information from the local cache can be used directly.

On the contrary, it means that the data has expired and the information must be re-obtained from the server, and the latest expiration time will be updated after it is obtained.

This approach is used more frequently in HTTP 1.0, and will be replaced by Cache-Control in HTTP 1.1.

There is a max-age attribute in Cache-Control, in seconds, to indicate the expiration time of the cached content on the client side.

For example, the max-age is 60 seconds and there is no data in the current cache. After the client requests for the first time, the data is put into the local cache.

Then if the client sends a request within 60 seconds, it will not request the application server, but will return the data directly from the local cache. If the interval between the two requests is more than 60 seconds, then the data needs to be obtained through the server.

1.2. Contrast caching

You need to compare the cache flags before and after to determine whether or not to use the cache. The first time the browser requests, the server returns the cache identity with the data, and the browser backs up both to the local cache. When the browser requests again, send the cache identity of the backup to the server.

The server judges according to the cache identification, and if the judgment data has not changed, it sends the 304 status code to the browser.

At this point, the browser can use the cached data. The server returns only Header and does not contain Body.

Here are two identification rules:

1.2.1. Last-Modified/If-Modified-Since rule

When the client requests for the first time, the server returns the last modification time of the resource, recorded as Last-Modified. The client caches this field along with the resource.

After the Last-Modified is saved, it will be sent as the Last-Modified-Since field on the next request.

When the client requests the server again, the Last-Modified will be sent to the server together with the requested resources, and the Last-Modified will be named If-Modified-Since, and the contents will be the same.

When the server receives a request, it compares the If-Modified-Since field with the Last-Modified field saved on the server:

If the last modification time of the Last-Modified on the server is longer than the requested If-Modified-Since, the resource (including Header+Body) will be returned to the browser and the status code 200 will be returned if the resource has been changed.

If the last modification time of the resource is less than or equal to If-Modified-Since, it means that the resource has not been changed, only Header will be returned, and the status code 304 will be returned. Upon receiving this message, the browser can use the data from the local cache.

Note: Last-Modified and If-Modified-Since refer to the same value, but they are called differently on the client side and the server side.

1.2.2. ETag / If-None-Match rule

The first time the client requests it, the server generates an ETag tag for each resource. This ETag is a unique Hash string generated based on each resource, and how the resource changes ETag changes accordingly, and then the ETag is returned to the client, which caches the requested resource and ETag locally.

After the ETag is saved, it will be sent as an If-None-Match field on the next request.

The second time the browser requests the same resource from the server, the ETag corresponding to the resource is sent to the server. ETag is converted to If-None-Match when requested, but its content remains the same.

When the server receives the request, it compares the If-None-Match with the ETag of the resource on the server:

If it is inconsistent, indicating that the resource has been changed, the resource (Header+Body) is returned and the status code 200 is returned.

If it is consistent, indicating that the resource has not been changed, Header is returned and the status code is returned. Upon receiving this message, the browser can use the data from the local cache.

Note: ETag and If-None-Match refer to the same value, but they are called differently on the client side and the server side.

2. CDN cache

HTTP caching mainly caches static data and caches the data obtained from the server to the client / browser.

If you add a layer of CDN between the client and the server, you can have CDN provide caching for the application server, and if you cache it on the CDN, you no longer have to request the application server. And the two strategies mentioned in the HTTP cache can also be implemented on the CDN server.

The full name of CDN is Content Delivery Network, that is, content delivery network.

Let's see how it works:

The client sends URL to the DNS server.

DNS directs the request to the DNS load balancer in the CDN network through domain name resolution.

The DNS load balancer tells DNS,DNS the IP of the latest CDN node to tell the client the IP of the latest CDN node.

The client requests the nearest CDN node.

The CDN node takes resources from the application server and returns them to the client, caching static information at the same time. Note: the next object the client will interact with is the CDN cache, and the CDN can synchronize the cache information with the application server.

CDN accepts requests from the client, which is the nearest server to the client, and links multiple servers behind it, which acts as a cache and load balancing.

3. Load balancing cache

After talking about HTTP caching and CDN caching, we are getting closer and closer to the application service, and the request goes through the load balancer before reaching the application service.

Although its main job is to load balance the application server, it can also be cached. Some data with low frequency of modification can be cached here, such as user information and configuration information. Refresh the cache periodically through the service.

Taking Nginx as an example, let's look at how it works:

The user requests to access the Nginx load balancer before reaching the application server, and if any cached information is found, it will be returned directly to the user.

If no cache information is found, Nginx goes back to the application server to get the information.

In addition, there is a cache update service that periodically updates relatively stable information from the application server to the Nginx local cache.

4. In-process cache

Through the client, CDN, load balancer, we finally came to the application server. Applications are deployed on the application server, and these applications run as processes, so what is the cache in the process?

In-process cache is also called managed heap cache. Take APC as an example, it is also affected by managed heap recovery algorithm.

Because it runs in memory and responds quickly to data, we usually put hot data here.

When the in-process cache misses, we search for out-of-process or distributed caches. The advantage of this cache is that there is no serialization and deserialization, and it is the fastest cache. The disadvantage is that the cache space is not too large, which has an impact on the performance of the garbage collector.

Here we need to focus on several cache recycling strategies. The specific implementation architecture will have different recycling strategies, but the general thinking is the same:

FIFO (First In First Out): first-in, first-out algorithm in which the data that is first cached is removed first.

LRU (Least Recently Used): recently, the least algorithm has been used to remove the cache of data that has not been used for the longest time.

LFU (Least Frequently Used): the least commonly used algorithm in which the least frequently used data is removed from the cache over a period of time.

In today's distributed architecture, there will be the problem of data consistency if in-process caching is used in multi-applications.

Here are two recommended options:

Message queue modification scheme

Timer modification scheme

4.1. Message queue modification scheme

After modifying its own cached data and database data, the application sends a data change notification to the message queue, while other applications subscribe to the message notification and modify the cached data when the notification is received.

4.2. Timer modification scheme

To avoid coupling and reduce complexity, it is insensitive to "real-time consistency". Each application launches a Timer, pulls the latest data from the database regularly, and updates the cache.

However, after some applications update the database, other nodes will read dirty data between getting data through Timer. Here, we need to control the frequency of Timer, as well as applications and scenarios that do not require high real-time performance.

What are the usage scenarios of in-process caching?

Scenario 1: read-only data, which can be loaded into memory when the process starts. Of course, loading data into an out-of-process caching service like Redis can also solve this problem.

Scenario 2: high concurrency, you can consider using in-process cache, such as second kill.

5. Distributed cache

After talking about in-process caching, it naturally transitions to out-of-process caching. Unlike in-process caching, out-of-process caching exists outside the process in which the application is running, it has a larger cache capacity, and can be deployed to different physical nodes, usually using distributed caching.

Distributed caching is a caching service separated from applications. The most important feature is that it is an independent application / service, isolated from local applications, and multiple applications can directly share one or more caching applications / services.

Since it is a distributed cache, the cached data will be distributed to different cache nodes, and the size of the data cached by each cache node is usually limited.

Data is cached to different nodes. In order to easily access these nodes, we need to introduce cache proxies, similar to Twemproxy. He will help the request to find the corresponding cache node.

At the same time, if the cache node is added, the agent will only recognize and slice the new cache data to the new node for horizontal expansion.

In order to improve the availability of cache, the design of Master/Slave will be added to the original cache node. When cached data is written to the Master node, one copy is synchronized to the Slave node at the same time.

Once the Master node fails, you can switch to the Slave node directly through the proxy, and then the Slave node becomes the Master node to ensure the normal operation of the cache.

Each cache node also provides a mechanism for cache expiration, and periodically saves the cache content to the file as a snapshot, making it convenient to start warm-up loading after the cache crash.

5.1. High performance

When the cache is distributed, the data is allocated to each cache application / service according to a certain rule.

If we call these cache applications / services cache nodes, each node can generally cache a certain amount of data, for example: Redis a node can cache 2G data.

If the amount of data that needs to be cached is relatively large, you need to expand multiple cache nodes. With so many cache nodes, the client does not know which node to access. How do you put the cached data on these nodes?

The cache proxy service has helped us solve these problems, for example, Twemproxy can not only help cache routing, but also manage cache nodes.

Here are three algorithms for caching data slicing. With these algorithms, the cache proxy can easily find the sliced data.

5.1.1. Hash algorithm

Hash table is the most common data structure, which is realized by Hash the key values of data records, and then allocating the remainder obtained by modulating the number of cache nodes that need to be segmented.

For example, there are three records of data which are respectively R _ 1 ~ ~ R _ 2 ~ R _ 3. Their ID is 01mem02mem03 respectively. Assuming that the ID of these three records is used as the key value, the result of the Hash algorithm is still 01meme02mem03.

We want to put these three pieces of data into three cache nodes, and we can take the result to get the remainder of the number 3, which is the cache node where the three records are placed respectively.

The Hash algorithm is average placement to some extent, and the strategy is relatively simple. If you want to add cache nodes, there will be great changes to the existing data.

5.1.2. Consistent hash algorithm

Consistent Hash maps data to an end-to-end Hash ring according to eigenvalues, and also maps cache nodes to this ring.

If you want to cache the data, find your location on the ring through the key value (Key) of the data. These data are arranged on the ring in order according to the values obtained after the Hash is fetched by their own ID.

If you want to insert a new piece of data with an ID of 115 at this time, you should insert it into the location shown in the figure below.

Similarly, if you want to add a cache node N4 150, you can also put it in the following figure.

The cost of this algorithm is relatively small for adding cached data and caching nodes.

5.1.3. Range Based algorithm

This approach is to divide the data into different intervals according to key values (such as ID), and each cache node is responsible for one or more intervals. It's kind of like a consistent hash.

For example, there are three cache nodes that are respectively N1Magic N2MaginN3. The intervals they use to store data are N1 (0100], N2 (100,200], N3 (300,400).

Then the results of Hash based on their own ID as keywords will be placed in these areas respectively.

These are all the contents of the article "sample Analysis of java caching Core Technologies". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.