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

If this is the second time to see my article, you are welcome to scan the code at the end of the article to subscribe to my personal official account (cross-border architect).

The length of this article is 3578 words. It is recommended to read for 10 minutes.

Insist on originality, each article is written by heart ~

The previous "scalability" chapter is over, and this is the first article in the "High performance" chapter.

As long as a serious programmer naturally knows what "cache" is, even many of our operating sisters now and then come up with the word "cache" when communicating with the programmer's younger brother, which is stressful.

. (the "cache" discussed in this article all refers to the cache used at the software level.)

What we all know is that caching can make a slow page open in a second. Almost all the APP and websites you visit involve the use of caching.

So what is the role of caching other than speeding up data access?

In addition, everything has two sides, how can we give full play to the advantages of caching and avoid falling into its disadvantages?

What Brother Z wants to share with you today is my understanding and application of cache, hoping to enlighten you.

What can caching do? As mentioned earlier, the most common understanding is that when we encounter a page that opens very slowly, we will want to introduce caching so that the page will open quickly.

In fact, both fast and slow are relative. from a technical point of view, the cache is fast because the cache is based on memory, and the read and write speed of memory is X times faster than that of the hard disk. So using memory instead of the hard disk as the medium for reading and writing can naturally greatly improve the speed of accessing data.

The process goes something like this: speed up by storing the asked data in memory for subsequent access.

In fact, there are two other important ways to use cache, "pre-read" and "delayed write".

Pre-read pre-read is to read the data to be loaded in advance, which can also be called "cache warm-up". That is, before the system provides services, it loads part of the data in the hard disk into memory, and then provides services.

Why would you do that? Because some systems will face tens of thousands of requests once launched (especially in some toC projects), if you let these requests directly call the database, it is very likely that the database pressure will soar and the database will not be able to respond normally.

In order to alleviate this problem, it needs to be solved by "pre-reading".

You may ask, even if you use the cache or can not handle it? That's the time for scale-out + load balancing. (you can click on the link at the end of the article to read the previous "flexible Architecture" series.

)

If "pre-read" is to add a pre-buffer to the "data exit", then as the name implies, the "delayed write" below is the addition of a post-buffer after the "data entry".

Delayed writing

As you may know, the write speed of the database is slower than the read speed, because there are a series of mechanisms to ensure the accuracy of data when writing.

Therefore, if you want to improve the write speed, you can either do a separate database or table, or do a buffer through the cache, and then write to disk in batch at one time, so as to speed up.

Aside from the question: since sub-database and sub-table have great side effects on cross-table operation and multi-conditional combination query, the complexity of introducing it is much greater than that of introducing cache, so we should give priority to the scheme of introducing cache.

In that case, the process of accelerating "writing" through the caching mechanism can be called "deferred writing". That is, in advance, the data that needs to be written to disk or database is temporarily written to memory, and then the success is returned. Then write the data in memory in batches to disk at regular intervals.

You may think that if you write to memory, you will consider it successful. In case of accidents, power outages, outages, and other situations that lead to abnormal termination of the program, won't the data be lost?

Right. Therefore, "deferred write" is generally used only in scenarios where data integrity requirements are not so stringent. Such as the number of likes, ah, the number of participating users, and so on, can greatly ease the pressure caused by frequent changes to the database.

In fact, in the well-known distributed cache Redis, the default persistence mechanism-RDB, is also the same way of thinking.

In a mature system, there is not one place where caching can be applied. Next, Brother Z will help you sort out where we can "add cache".

Where can I add "cache"? Before we say where to cache, let's figure out one thing, what are we going to cache? That is, what characteristics of data need to be cached? After all, caching is an additional cost and good value for money.

Generally speaking, you can use these two criteria to judge: hot spot (accessed by high frequency, such as dozens of times per second) and static (rarely changed, reading is much larger than writing, such as changing every few days).

Then you can find a suitable place for them to cache.

The essence of caching is a "defensive" mechanism, and the data flow between systems is an orderly process. Therefore, choosing where to cache is equivalent to choosing where to set up a roadblock on a road. All roads behind this roadblock can be protected from being run over by traffic.

Then on the road where the end user is the starting point and the database used by the system is the end point, there are roughly the following locations that can be used as cache setting points.

Each setup point can block some traffic, resulting in a funnel-shaped interception effect to protect the back system and the final database.

Below, Brother Z will briefly describe each application scenario and the points that need to be paid attention to.

Browser cache is the closest place to the user to be cached, and with the help of the user's "resources" (the cached data is on the user's terminal device), it is the best cost-effective, allowing the user to help you share the pressure.

When you open the developer tool of the browser and see from cache or from memory cache or from disk cache, it means that the data has been cached on the user's terminal device (this is why part of the content can be accessed when there is no Internet).

This process is done by browsers for us, and is generally used to cache images, js, css, and so on. We can control it through the Cache-Control in the Http header, but we won't expand on the details here.

The global variables in js and the use of cookie also fall into this category.

The browser cache is located at the cache point on the user side, so we have much less control over it, and you can't take the initiative to update data without initiating a new request.

CDN caching service providers that provide CDN services deploy a large number of server nodes (called "edge servers") across the country or even around the world.

Then distributing the data to these distributed servers as a cache, allowing users to access the cached data on the nearest server, can have the effect of stress sharing and acceleration. This is particularly effective when applied to ToC-type systems.

However, it should be noted that due to the large number of nodes, updating cached data is slow, generally at least at the minute level. Therefore, it is generally only applicable to static data that do not change frequently.

Digression: there is also a solution, which is to follow the url with a self-increment or a unique mark, such as? vault 1001. Because different url will be treated as "new" data and files, will be re-create out.

The gateway (proxy) cache here to do the cache is on your own turf. In many cases, we will set up a gateway (or reverse proxy or forward proxy) in front of the origin server in order to provide some security mechanism or an entrance to a unified diversion policy.

It is also a good place to do caching. After all, the gateway is "business-independent", and the requests it can block are also of great benefit to the origin server behind it, reducing a lot of CPU operations.

The commonly used gateway (proxy) cache is Varnish,Squid,Ngnix. In general, a simple cache application scenario can be done with nginx, because most of the time we will use it for load balancing. If we can introduce one less technology, it will be less complex. If there are a large number of small files, you can use Varnish, while Squid is relatively large and comprehensive, and it is more expensive to use.

Caching a request in a process can come here to show that it is "business-related" and needs to be calculated by business logic.

Because of this, the cost of introducing caching from here is much higher than the previous three, because the requirement of "data consistency" between cache and database is higher.

Perhaps this is the first time most of us programmers deliberately use caching. There are a lot of details to pay attention to in the use of in-process and out-of-process caching, which are also the contents of our follow-up articles, so we'll talk about them later.

Everyone is familiar with out-of-process caching, such as redis, memcached, and so on. You can even write a program to store cached data for other programs to call remotely.

Again, we'll talk about the details here later, and here are a few more suggestions on how to choose redis and memcached.

If you pay special attention to the utilization of resources (cpu, memory, etc.), you can use Memcached, but the program needs to tolerate possible data loss when using it, because it is a pure memory mechanism. You can use redis if you can't tolerate this and are bold in resource utilization. And redis has more database structures. Memcached only has key value, which is more like a nosql storage.

The database cache database itself has its own cache module, otherwise it will not be called a memory killer. Basically, you can eat as much memory as you give.

Database caching is the internal mechanism of the database, so we won't go any further here. A configuration for setting the size of the cache space is generally given to allow you to intervene.

Finally, the disk itself has a cache. So you'll find that there are really twists and turns in order for data to be written smoothly to physical disks, and you don't know when there will be disks that are so fast that they don't need a program to consider caching to save us programmers.

Is "cache" Silver bullet? Maybe you want to cache so well, so you should go to cache as long as it is slow.

No matter how good a thing looks, it has its negative side. Caching also has a series of side effects to consider. In addition to the "cache update" and "cache-data consistency" issues mentioned above, there are also issues such as:

Cache avalanche

Cache penetration

Cache concurrency

Cache bottomless pit

Cache elimination

...

And so on, these Z brothers will be analyzed in depth with you in the following articles.

Those who want to know these things for the first time can "follow" Brother Z.

Summary

All right, let's sum up.

This time, Brother Z first introduced you to three ways to use caching.

Then it combs several places where caching can be set up in a complete system, and shares some experience about browser cache, CDN cache, gateway (proxy) cache.

I hope it will enlighten you.

In subsequent articles, I will focus on delving into the best practices of "in-process caching" and "out-of-process caching" until I reappear.

Related articles:

Distributed system concerns-only this article is needed to get through the "load balancing" properly.

Distributed system concern-how to implement "load balancing"?

Distributed system focus-can you add machines as soon as you do "load balancing"?

The focus of distributed system-- detailed explanation of "stateless"

The focus of distributed system-- detailed explanation of "High cohesion and low Coupling"

The focus of distributed system-- flexible Architecture

Author: Zachary

Source: https://www.cnblogs.com/Zachary-Fan/p/cache.html

If you like this article, you can click "thumb" in the lower left corner.

This will give me some feedback. :)

Thank you for your help.

▶ about the author: Zhang Fan (Zachary, personal WeChat account: Zachary-ZF). Persist in polishing each article with high quality and originality. Welcome to scan the QR code below.

Publish the original content regularly: architecture design, distributed system, product, operation, some thinking.

If you are a junior programmer, you want to promote but don't know how to do it. Or as a programmer for many years, I fell into some bottlenecks and wanted to broaden my horizons. Welcome to follow my official account "Cross-border architect", reply to "Technology" and send you a mind map that I have collected and sorted out for a long time.

If you are an operator, there is nothing you can do in the face of a changing market. Or you may want to understand the mainstream operation strategy in order to enrich your "warehouse". Welcome to follow my official account "Cross-border architect", reply to "Operation" and send you a mind map that I have collected and sorted out for a long time.

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.