database 什么是缓存？

What is caching?

提问by KingNestor

I'm constantly hearing about person y had performance issue x which they solved through caching.

我不断听说有人 y 有性能问题 x，他们通过缓存解决了这个问题。

Or, how doing x,y,z in your programs code can hurt your caching ability.

或者，如何在程序代码中执行 x,y,z 会损害您的缓存能力。

Even in one of the latest podcasts, Jeff Atwood talks about how they cache certain values for speedy retrieval.

即使在最新的播客之一中，Jeff Atwood 也谈到了他们如何缓存某些值以进行快速检索。

There seems to be some ambiguity in the terms "cache" and "caching" and it has led me to be confused about it's meaning in different cases. Whether you are referring to application or database caching, cpu, etc and what that means.

“缓存”和“缓存”这两个术语似乎有些含糊不清，这让我对它在不同情况下的含义感到困惑。无论您是指应用程序还是数据库缓存、cpu 等，以及这意味着什么。

What is caching and what are the different types?

什么是缓存，有哪些不同的类型？

From context I can get a sense of it, to store an oft retrieved value into main memory and have quicklook up access to it. However, what is it really?

This word seems to be used in a lot of different contexts with slightly different meaning (cpu, database, application, etc) and I'm really looking to clear it up.

从上下文中我可以了解它，将经常检索到的值存储到主内存中，并可以快速查找访问它。但是，什么是它 真的？

这个词似乎用在许多不同的上下文中，含义略有不同（cpu、数据库、应用程序等），我真的很想澄清一下。

Is there a distinction between how caching works in your applications vs your database caching?

应用程序中的缓存与数据库缓存的工作方式有区别吗？

When someone says that they found a piece of code that would hurt caching and after they fixed it, it improved the speed of their app, what are they talking about?

Is the program's caching something that is done automatically? How do you allow values to be cached in your programs? I've often read users on this site say that they cached a value in their application, I sit here and wonder what they mean.

Also, what does it really mean when someone talks about database caching? Is this simply a feature they turn on in their database? Do you have to explicitly cache values or does the database pick which ones to cache for you?

当有人说他们发现了一段会损害缓存的代码并且在修复它之后，它提高了他们的应用程序的速度时，他们在说什么？

程序的缓存是自动完成的吗？您如何允许将值缓存在您的程序中？我经常在这个站点上看到用户说他们在他们的应用程序中缓存了一个值，我坐在这里想知道他们的意思。

另外，当有人谈论数据库缓存时，它的真正含义是什么？这仅仅是他们在数据库中打开的功能吗？您是否必须显式缓存值，还是数据库会为您选择缓存哪些值？

How do I begin caching items myself to improve performance?

我如何开始自己缓存项目以提高性能？

Can you give me some examples of how I can begin caching values in my applications? Or again, is this something that is already done, under the hood and I simply have to write my code in a particular way to allow "caching"?

What about database caching, how do I begin that? I've heard about things like memcache. Is this type of utility required to cache in databases?

你能给我一些关于如何开始在我的应用程序中缓存值的例子吗？或者，这是否已经在幕后完成，我只需以特定方式编写代码以允许“缓存”？

数据库缓存怎么样，我该如何开始？我听说过诸如 memcache 之类的东西。在数据库中缓存是否需要这种类型的实用程序？

I'm looking to get a good distinction between caching in applications vs databases, how they are used and how it is implemented in both cases.

我希望在应用程序与数据库中的缓存、它们的使用方式以及在这两种情况下的实现方式之间有一个很好的区别。

采纳答案by cletus

Caching is just the practice of storing data in and retrieving data from a high-performance store (usually memory) either explicitly or implicitly.

缓存只是显式或隐式地在高性能存储（通常是内存）中存储和检索数据的做法。

Let me explain. Memory is faster to access than a file, a remote URL (usually), a database or any other external store of information you like. So if the act of using one of those external resources is significantthen you may benefit from caching to increase performance.

让我解释。访问内存比文件、远程 URL（通常）、数据库或任何其他您喜欢的外部信息存储更快。因此，如果使用这些外部资源之一的行为很重要，那么您可能会受益于缓存以提高性能。

Knuth once said that premature optimization is the root of all evil. Well, premature caching is the root of all headaches as far as I'm concerned. Don't solve a problem until you havea problem. Every decision you make comes at a cost that you'll pay to implement it now and pay again to change it later so the longer you can put off making a deicsion and changing your system the better.

Knuth 曾经说过，过早优化是万恶之源。好吧，就我而言，过早缓存是所有头痛的根源。直到你不解决问题有一个问题。你做出的每一个决定都会付出代价，你现在要付钱来实施它，然后再付钱来改变它，所以你可以推迟做出决定并改变你的系统的时间越长越好。

So first identify that you actually have a problem and where it is. Profiling, logging and other forms of performance testing will help you here. I can't stress enough how important this step is. The number of times I've seen people "optimize" something that isn't a problem is staggering.

因此，首先要确定您确实有问题以及问题出在哪里。分析、日志记录和其他形式的性能测试将在这里为您提供帮助。这一步的重要性再怎么强调也不为过。我见过人们“优化”一些没有问题的东西的次数是惊人的。

Ok, so you have a performance problem. Say your pages are running a query that takes a long time. If it's a read then you have a number of options:

好的，所以你有一个性能问题。假设您的页面正在运行一个需要很长时间的查询。如果是阅读，那么您有多种选择：

• Run the query as a separate process and put the result into a cache. All pages simply access the cache. You can update the cached version as often as is appropriate (once a day, once a week, one every 5 seconds, whatever is appropriate);
• Cache transparently through your persistence provider, ORM or whatever. Of course this depends on what technology you're using. Hibernate and Ibatis for example support query result caching;
• Have your pages run the query if the result isn't in the cache (or it's "stale", meaning it is calculated longer ago than the specified "age") and put it into the cache. This has concurrency problems if two (or more) separate processes all decide they need to update the result so you end up running the same (expensive) query eight times at once. You can handle this locking the cache but that creates another performance problem. You can also fall back to concurrency methods in your language (eg Java 5 concurrency APIs).

• 作为单独的进程运行查询并将结果放入缓存中。所有页面都只是访问缓存。您可以根据需要随时更新缓存版本（每天一次、每周一次、每 5 秒一次，只要合适）；
• 通过持久化提供程序、ORM 或其他方式透明地缓存。当然，这取决于您使用的技术。例如 Hibernate 和 Ibatis 支持查询结果缓存；
• 如果结果不在缓存中（或者它是“陈旧的”，这意味着它的计算时间比指定的“年龄”早），则让您的页面运行查询并将其放入缓存中。如果两个（或多个）单独的进程都决定它们需要更新结果，那么这就会产生并发问题，因此您最终会一次运行相同（昂贵的）查询八次。您可以处理这种锁定缓存的情况，但这会产生另一个性能问题。您还可以回退到您的语言中的并发方法（例如 Java 5 并发 API）。

If it's an update (or updates take place that need to be reflected in your read cache) then it's a little more complicated because it's no good having an old value in the cache and a newer value in the database such that you then provide your pages with an inconsistent view of the data. But broadly speaking there are four approaches to this:

如果它是一个更新（或发生的更新需要反映在您的读取缓存中），那么它会稍微复杂一些，因为在缓存中使用旧值并在数据库中使用更新值是不好的，这样您就可以提供您的页面对数据的看法不一致。但从广义上讲，有四种方法可以做到这一点：

• Update the cache and then queue a request to update the relevant store;
• Write through caching: the cache provider may provide a mechanism to persist the update and block the caller until that change is made; and
• Write-behind caching: same as write-through caching but it doesn't block the caller. The update happens asynchronously and separately; and
• Persistence as a Service models: this assumes your caching mechanism supports some kind of observability (ie cache event listeners). Basically an entirely separate process--unknown to the caller--listens for cache updates and persists them as necessary.

• 更新缓存，然后排队请求更新相关存储；
• 通过缓存写入：缓存提供者可能会提供一种机制来持久化更新并阻止调用者直到做出更改；和
• 后写缓存：与直写缓存相同，但它不会阻止调用者。更新是异步且单独发生的；和
• 持久性即服务模型：假设您的缓存机制支持某种可观察性（即缓存事件侦听器）。基本上是一个完全独立的进程——调用者不知道——监听缓存更新并在必要时保留它们。

Which of the above methodologies you choose will depend a lot on your requirements, what technologies you're using and a whole host of other factors (eg is clustering and failover support required?).

您选择上述哪种方法将在很大程度上取决于您的要求、您使用的技术以及许多其他因素（例如，是否需要集群和故障转移支持？）。

It's hard to be more specific than that and give you guidance on what to do without knowing muchmore detail about your problem (like whether or not you have a problem).

很难比这更具体的，给你做什么指导不知道太多关于您的问题更详细的（像你是否有问题）。

回答by cdonner

You will most likely read about caching in the context of web applications. Because of the nature of the Web, caching can make a big performance difference.

您很可能会阅读有关 Web 应用程序上下文中的缓存的信息。由于 Web 的性质，缓存可以产生很大的性能差异。

Consider the following:

考虑以下：

A web page request gets to the web server, which passes the request on to the application server, which executes some code that renders the page, which needs to turn to the database to dynamically retrieve data.

网页请求到达 Web 服务器，Web 服务器将请求传递给应用程序服务器，应用程序服务器执行一些呈现页面的代码，这些代码需要转向数据库以动态检索数据。

This model does not scale well, because as the number of requests for the page goes up, the server has to do the same thing over and over again, for every request.

这个模型不能很好地扩展，因为随着页面请求数量的增加，服务器必须一遍又一遍地为每个请求做同样的事情。

This becomes even more of an issue if web server, application server, and database are on different hardware and communicate over the network with each other.

如果 Web 服务器、应用程序服务器和数据库位于不同的硬件上并通过网络相互通信，这将成为一个更大的问题。

If you have a large number of users hitting this page, it makes sense to not go all the way through to the database for every request. Instead, you resort to caching at different levels.

如果您有大量用户访问此页面，则不要对每个请求都访问数据库。相反，您诉诸于不同级别的缓存。

Resultset Cache

结果集缓存

Resultset caching is storing the results of a database query along with the query in the application. Every time a web page generates a query, the applications checks whether the results are already cached, and if they are, pulls them from an in-memory data set instead. The application still has to render the page.

结果集缓存将数据库查询的结果与应用程序中的查询一起存储。每次网页生成查询时，应用程序都会检查结果是否已缓存，如果已缓存，则从内存数据集中提取它们。应用程序仍然必须呈现页面。

Component Cache

组件缓存

A web page is comprised of different components - pagelets, or whatever you may want to call them. A component caching strategy must know what parameters were used to request the component. For instance, a little "Latest News" bar on the site uses the user's geographical location or preference to show local news. Consequently, if the news for a location is cached, the component does not need to be rendered and can be pulled from a cache.

一个网页由不同的组件组成——pagelets，或者任何你想要的名字。组件缓存策略必须知道使用哪些参数来请求组件。例如，站点上的一个“最新消息”栏使用用户的地理位置或偏好来显示本地新闻。因此，如果缓存了某个位置的新闻，则不需要渲染该组件并且可以从缓存中提取该组件。

Page Cache

页面缓存

One strategy for caching entire pages is to store the query string and/or header parameters along with the completely renderered HTML. The file system is fast enough for this - it is still way less expensive for a web server to read a file than to make a call to the application server to have the page rendered. In this case, every user who sends the same query string will get the same cached content.

缓存整个页面的一种策略是将查询字符串和/或标头参数与完全渲染的 HTML 一起存储。文件系统已经足够快了——Web 服务器读取文件的成本仍然比调用应用程序服务器来呈现页面要便宜得多。在这种情况下，发送相同查询字符串的每个用户都将获得相同的缓存内容。

Combining these caching strategies intelligently is the only way to create really scalable web apps for large numbers of concurrent users. As you can easily see, the potential risk here is that if a piece of content in the cache cannot be uniquely identified by it's key, people will start to see the wrong content. This can get pretty complicated, particularly when users have sessions and there is security context.

智能地组合这些缓存策略是为大量并发用户创建真正可扩展的 Web 应用程序的唯一方法。正如您很容易看到的那样，这里的潜在风险是，如果缓存中的一段内容不能通过它的键唯一标识，人们就会开始看到错误的内容。这可能会变得非常复杂，特别是当用户有会话并且有安全上下文时。

回答by ChrisW

There are two meanings that I know of.

我知道有两种含义。

---

---

One is application caching. This is when, if data is slow to get from somewhere (e.g. from over the network) or slow to calculate, then the application caches a copy of the data (so that it doesn't need to get it again or to recalculate: it's already cached). Implementing a cache takes a bit of extra application software (logic to use the cache) and extra memory (in which to store the cached data).

一种是应用缓存。此时，如果数据从某处（例如，通过网络）获取或计算速度很慢，那么应用程序会缓存数据的副本（这样它就不需要再次获取或重新计算：它是已经缓存）。实现缓存需要一些额外的应用软件（使用缓存的逻辑）和额外的内存（用于存储缓存数据）。

That's "caching" being used as you're quoting here:

当您在此处引用时，正在使用“缓存”：

From context I can get a sense of it, to store an oft retrieved value into main memory and have quicklook up access to it.

从上下文中我可以了解它，将经常检索到的值存储到主内存中，并可以快速查找访问它。

---

---

Another is CPU caching, which is described in this Wikipedia article. CPU caching happens automatically. If you do a lot of reading from a small amount of memory, then the CPU can do most of those reads from its cache. OTOH if you read from a large amount of memory, it can't all fit in the cache and the CPU must spend more time working with the slower memory.

另一个是CPU 缓存，在这篇 Wikipedia 文章中进行了描述。CPU 缓存自动发生。如果您从少量内存中进行大量读取，那么 CPU 可以从其缓存中进行大部分读取。OTOH 如果您从大量内存中读取，它不能全部放入缓存中，CPU 必须花更多时间处理较慢的内存。

That's "caching" being used as you're quoting here:

当您在此处引用时，正在使用“缓存”：

When someone says that they found a piece of code that would hurt caching and after they fixed it, it improved the speed of their app, what are they talking about?

当有人说他们发现了一段会损害缓存的代码并且在修复它之后，它提高了他们的应用程序的速度时，他们在说什么？

It means they found a way to rearrange their code to cause fewer Cache misses.

这意味着他们找到了一种重新排列代码以减少缓存未命中的方法。

---

---

As for database caching, I don't know.

至于数据库缓存，我不知道。

回答by Will Hartung

There's a couple of issues.

有几个问题。

One, is granularity. Your application can have very fine levels of caching over and above what the database does. For example, the database is likely to simply cache pages of data, not necessarily specific rows.

一是粒度。您的应用程序可以拥有非常精细的缓存级别，而不是数据库所做的事情。例如，数据库可能只是缓存数据页，而不一定是特定的行。

Another thing is that the application can store data in its "native" format, whereas the DB obviously only caches in its internal format.

另一件事是应用程序可以以其“本机”格式存储数据，而数据库显然仅以其内部格式进行缓存。

Simple example.

简单的例子。

Say you have a User in the database, which is made of the columns: USERID, FIRSTNAME, LASTNAME. Very simple.

假设您在数据库中有一个 User，它由以下列组成：USERID, FIRSTNAME, LASTNAME。很简单。

You wish to load a User, USERID=123, into your application. What are the steps involved?

您希望将用户加载USERID=123到您的应用程序中。涉及哪些步骤？

1. Issuing the database call
2. Parsing the request(SELECT * FROM USER WHERE USERID = ?)
3. Planning the request (i.e. how is the system going to fetch the data)
4. Fetching the data from the disk
5. Streaming the data from the database to the application
6. Converting the Database data to application data (i.e. USERIDto an integer, say, the names to Strings.

1. 发出数据库调用
2. 解析请求( SELECT * FROM USER WHERE USERID = ?)
3. 计划请求（即系统将如何获取数据）
4. 从磁盘获取数据
5. 将数据从数据库流式传输到应用程序
6. 将数据库数据转换为应用程序数据（即USERID转换为整数，例如将名称转换为字符串。

The database cache will, likely, caches steps 2 and 3 (that's a statement cache, so it won't parse or replan the query), and caches the actual disk blocks.

数据库缓存可能会缓存第 2 步和第 3 步（这是一个语句缓存，因此它不会解析或重新规划查询），并缓存实际的磁盘块。

So, here's the key. Your user, USER ID 123, name JESSE JAMES. You can see that this isn't a lot of data. But the database is caching disk blocks. You have the index block (with the 123on it), then the data block (with the actual data, and all of the other rows that fit on that block). So what is nominally, say, 60-70 bytes of data actually has a caching and data impact on the DB of, probably, 4K-16K (depends on block size).

所以，这里是关键。您的用户，USER ID 123， name JESSE JAMES。你可以看到这不是很多数据。但是数据库正在缓存磁盘块。您有索引块（带有123），然后是数据块（带有实际数据，以及适合该块的所有其他行）。因此，名义上的 60-70 字节数据实际上对 DB 的缓存和数据影响可能为 4K-16K（取决于块大小）。

The bright side? If you need another row that's nearby (say USER ID = 124), odds are high the index and data are already cached.

光明的一面？如果您需要附近的另一行（例如USER ID = 124），则索引和数据已经缓存的可能性很高。

But even with that caching, you still have to pay the cost to move the data over the wire (and it's alway over the wire unless you're using a local DB, then that's loopback), and you're "unmarshalling" the data. That is, converting it from Database bits to language bits, to Application bits.

但即使有这种缓存，您仍然需要支付通过网络移动数据的成本（除非您使用本地数据库，否则它总是通过网络移动，然后这是环回），并且您正在“解组”数据. 也就是说，将其从数据库位转换为语言位，再到应用程序位。

Now, once the Application get its USER ID 123, it stuff the value in a long lived hash map.

现在，一旦应用程序获得它的USER ID 123，它就会将值填充到一个长期存在的哈希映射中。

If the application ever wants it again, it will look in the local map, the application cache, and save the lookup, wire transport, and marshalling costs.

如果应用程序再次需要它，它将在本地地图、应用程序缓存中查找，并节省查找、线路传输和编组成本。

The dark side of application caching is synchronization. If someone comes in and does a UPDATE USER SET LASTNAME="SMITH" WHERE USERID=123, your application doesn't "know that", and thus the cache is dirty.

应用程序缓存的阴暗面是同步。如果有人进来并执行了UPDATE USER SET LASTNAME="SMITH" WHERE USERID=123，您的应用程序不会“知道”，因此缓存是脏的。

So, then there's a bunch of details in handling that relationship to keep the application in sync with the DB.

因此，在处理这种关系以保持应用程序与数据库同步时有很多细节。

Having a LOT of database cache is very nice for large queries over a "hot" set of data. The more memory you have, the more "hot" data you can have. Up to the point if you can cache the entire DB in RAM, you eliminate the I/O (at least for reads) delay of moving data from the disk to a RAM buffer. But you still have the transport and marshalling costs.

拥有大量数据库缓存对于对“热”数据集进行大型查询非常有用。您拥有的内存越多，您可以拥有的“热”数据就越多。到目前为止，如果您可以将整个 DB 缓存在 RAM 中，则可以消除将数据从磁盘移动到 RAM 缓冲区的 I/O（至少对于读取）延迟。但是您仍然有运输和编组成本。

The Application can be much more selective, such as caching more limited subsets of data (DBs just cache blocks), and having the data "closer" to the application ekes out that much better performance.

应用程序可以更具选择性，例如缓存更多有限的数据子集（DB 只是缓存块），并使数据“更接近”应用程序，从而获得更好的性能。

The down side is that not everything is cached in the Application. The database tends to store data more efficiently, overall, than the application. You also lack a "query" language against your app cached data. Most folks simply cache via a simple key and go from there. Easy to find USER ID 123, harder for "ALL USERS NAMED JESSE".

不利的一面是并非所有内容都缓存在应用程序中。总体而言，数据库往往比应用程序更有效地存储数据。您还缺少针对应用缓存数据的“查询”语言。大多数人只是通过一个简单的键进行缓存，然后从那里开始。容易找到USER ID 123，对于“所有名为 JESSE 的用户”来说更难。

Database caching tends to be "free", you set a buffer number and the DBMS handles the rest. Low impact, reduces overall I/O and disk delays.

数据库缓存往往是“免费的”，您设置一个缓冲区编号，然后 DBMS 处理其余部分。低影响，减少整体 I/O 和磁盘延迟。

Application caching is, well, application specific.

应用程序缓存是特定于应用程序的。

It works very well for isolated "static" data. That's very easy. Load a bunch of stuff in to lookup tables at startup and restart the app if they change. That's easy to do.

它适用于孤立的“静态”数据。这很容易。在启动时将一堆东西加载到查找表中，如果它们发生变化，则重新启动应用程序。这很容易做到。

After that complexity starts to increase as you add in "dirty" logic, etc.

之后，随着您添加“脏”逻辑等，复杂性开始增加。

What it all comes down to, tho, is that as long as you have a Data API, you can cache incrementally.

归根结底，只要您拥有数据 API，就可以增量缓存。

So, as long as you call getUser(123)everywhere rather than hitting the DB, then you can later come back and add caching to getUserwithout impacting your code.

因此，只要您getUser(123)到处调用而不是访问数据库，那么您稍后就可以回来添加缓存，getUser而不会影响您的代码。

So, I always suggest some kind of Data Access Layer in everyone's code, to provide that bit of abstraction and interception layer.

所以，我总是建议在每个人的代码中使用某种数据访问层，来提供一点抽象和拦截层。

回答by Dave

The cache concept is an overloaded term here. I'm not familiar with the nuts and bolts of database caching.

缓存概念在这里是一个重载的术语。我不熟悉数据库缓存的具体细节。

In applications there are two uses of the term.

在应用程序中，该术语有两种用法。

When someone says that they found a piece of code that would hurt caching and after they fixed it, it improved the speed of their app, what are they talking about?

当有人说他们发现了一段会损害缓存的代码并且在修复它之后，它提高了他们的应用程序的速度时，他们在说什么？

In this case they're making reference to the CPU cache.

在这种情况下，他们引用了 CPU 缓存。

The CPU cache is on-CPU memory that's a lot quicker than RAM, but it doesn't have random access. What the CPU decides to load into cache can get a little complicated. See Ulrich Dreppers What every programmer should know about memoryfor lots of details.

CPU 缓存是 CPU 上的内存，它比 RAM 快得多，但它没有随机访问。CPU 决定加载到缓存中的内容可能会变得有点复杂。请参阅 Ulrich Dreppers了解每个程序员应该了解的有关内存的大量细节。

Being mindful of the CPU cache can speed things up pretty well - you just have to pay a little more attention to where things are going to placed relative to each other in physical memory and when they're likely to be used.

注意 CPU 缓存可以很好地加快速度——你只需要多注意一些东西在物理内存中相对于彼此的位置以及它们可能被使用的时间。

One example (also probably an anti-pattern for maintainability) is that is you have an array of structures and you do a lot of looping over the members of the structure you might be better served with a structure where the fields are all arrays. If the data you're looping over is contiguous in memory you have a better chance at non upsetting the cache.

一个例子（也可能是可维护性的反模式）是，您有一个结构数组，并且您对结构的成员进行了大量循环，您可能会更好地使用字段都是数组的结构。如果您循环的数据在内存中是连续的，您就有更好的机会不扰乱缓存。

All kinds of things can effect the efficiency of your cache usage - branch prediction for code loaded into the cache, size and alignment of data structures and access patterns, where and when to declare local variables that are going to be put onto the stack.

各种各样的事情都会影响缓存使用的效率 - 加载到缓存中的代码的分支预测、数据结构和访问模式的大小和对齐方式、在何处以及何时声明将要放入堆栈的局部变量。

The other common use of the term for application programming can be done by something called memoization. The factorial example on that wikipedia page explains things better than I would have done.

应用程序编程术语的另一种常见用法可以通过称为记忆的东西来完成。该维基百科页面上的阶乘示例比我所做的更好地解释了事情。

回答by Gregor Brandt

caching is taking the result of a long or cpu intensive algorithm and saving the answer so that you do not have to run the algorithm again, you just reuse the result.

缓存正在获取长时间或 cpu 密集型算法的结果并保存答案，以便您不必再次运行该算法，您只需重用结果。

回答by Jim Petkus

Caching in databases is typically a function the database and it is managed automatically by the database. Caching in applications is going to vary from one platform to another.

数据库中的缓存通常是数据库的一个功能，它由数据库自动管理。应用程序中的缓存会因平台而异。

An object cache is a mechanism that you can use to put commonly used objects into memory so that you don't need to pay the cost to retrieve the data and recreate them. This is generally managed via code and varies on what caching solution you are using.

对象缓存是一种可用于将常用对象放入内存的机制，这样您就无需支付检索数据和重新创建数据的成本。这通常通过代码进行管理，并且因您使用的缓存解决方案而异。

There are distributed cache solutions that involve setting up services on multiple servers to give you a cache farm of sorts. This provides scalability and redundancy. The clients can request the cached information across the network. Again this is a manual procedure in your code. An example of a distributed cache provider is memcached:

分布式缓存解决方案涉及在多台服务器上设置服务，为您提供各种缓存群。这提供了可扩展性和冗余。客户端可以通过网络请求缓存的信息。同样，这是您代码中的手动过程。分布式缓存提供程序的一个示例是 memcached：

http://www.danga.com/memcached/

http://www.danga.com/memcached/

An example of a specific type of caching would be the asp.net caching. Asp.net supports several kinds of cache. There is the traditional object cache (which can be used in all kinds of .net apps, not just websites). There is also caching features that allow you to configure pages and user controls to automatically cache their output. This doesn't cache data, it caches the end result (the HTML of the page) and serves that up when the user requests the same page with the same query string parms as a previous user.

特定类型缓存的一个示例是 asp.net 缓存。Asp.net 支持多种缓存。有传统的对象缓存（可用于各种 .net 应用程序，而不仅仅是网站）。还有缓存功能，允许您配置页面和用户控件以自动缓存其输出。这不会缓存数据，它会缓存最终结果（页面的 HTML），并在用户使用与前一个用户相同的查询字符串参数请求同一页面时提供该结果。

回答by Bill K

It's probably easier than you could imagine--and that's why people are trying to close it.

它可能比你想象的要容易——这就是人们试图关闭它的原因。

It just means to store the values in your memory rather than go back to the database for them every time.

它只是意味着将值存储在您的内存中，而不是每次都返回到数据库中。

There are lots of ways to do so, but the concept itself is trivial.

有很多方法可以做到这一点，但概念本身是微不足道的。

Edit: It can be done at ANY level too--anything that takes a long time can be cached somewhere that you can get to more quickly.

编辑：它也可以在任何级别完成——任何需要很长时间的东西都可以缓存在你可以更快到达的地方。

回答by Kevin Loney

Caching does not necessarily only apply to 'oft retrieved' values but to anything you can save time on by reducing the number of times you recompute it. A simple example that comes to mind is calculating the fibonacci sequence. The simplest recursive implementation looks like this (in psuedo-code):

缓存不一定只适用于“经常检索”的值，而是适用于任何可以通过减少重新计算次数来节省时间的东西。我想到的一个简单例子是计算斐波那契数列。最简单的递归实现如下所示（在伪代码中）：

function f(n)
    if n < 2 then
        return n;
    return f(n - 1) + f(n - 2)

This can be improved with caching to prevent recalculating already known values:

这可以通过缓存来改进，以防止重新计算已知值：

fib_cache = {}

function f(n)
    if n < 2 then
        return n;
    if fib_cache.contains(n) then
        return fib_cache[n]
    fib_cache[n] = f(n - 1) + f(n - 2)
    return fib_cache[n]