1.1. 缓存存在于应用程序的许多地方

1.1.1. 行应用程序的CPU具有高速多级硬件缓存，可以减少相对较慢的主内存访问

1.1.2. 数据库引擎可以利用主内存来缓存数据存储的内容，这样在许多情况下查询就可以不用访问速度相对较慢的磁盘

1.2. 分布式缓存是可扩展系统的重要组成部分

1.2.1. 缓存使耗时的查询和计算结果能够在后续请求中低成本地重用

1.2.2. 由于不必为每个请求重建缓存结果，系统的容量增加了，并且可以扩展来处理更大的工作负载

1.3. 应用缓存依赖业务逻辑，业务逻辑使用分布式缓存将预计算结果的缓存和访问结合在一起

1.4. Web缓存充分利用HTTP协议中内置的机制在网络提供的基础设施中缓存结果

1.5. 缓存是任何可扩展分布系统的重要组成部分

1.5.1. 缓存将许多客户端请求的信息存储在内存中，并利用这些信息为客户端请求提供服务

1.6. 使用分布式缓存的应用缓存是可扩展系统中最常用的缓存方法

1.7. 互联网还有内建的多级缓存基础设施

1.7.1. HTTP缓存使用得当的话可以显著减少下游服务和数据库的请求负载

1.8. 缓存是软件和系统的一个成熟领域

1.9. CDN本身就是一个复杂的、针对供应商的主题

1.9.1. 它们适用于用户群在地理上分散、内容需要快速交付的富媒体网站

2.1. 应用缓存旨在通过将查询和计算的结果存储在内存中来提高请求响应能力，以便为后续的请求提供服务

2.1.1. 缓存可以减轻数据库读取流量的负担，因为许多查询都可以直接从缓存中获取结果

2.1.2. 缓存最终效果是减少了服务和数据库的计算负担，并为更多请求创造了空间或容量

2.2. 缓存需要额外的资源和成本来存储缓存结果

2.2.1. 与升级数据库和服务节点以应对更高的请求负载相比，设计良好的缓存方案成本较低

2.3. 应用级缓存采用专用的分布式缓存引擎

2.3.1. 主流技术

2.3.1.1. memcached

2.3.1.2. Redis

2.3.1.3. 两者本质上都是分布式内存哈希表，为存储代表数据库查询结果或下游服务API调用结果的任意数据（字符串、对象）而设计

2.4. 缓存常见的使用场景是存储用户会话数据、动态网页和数据库查询结果

2.5. 缓存命中

2.5.1. 如果可用，它会将缓存的内容作为结果返回

2.5.2. 缓存命中率应该是多少并没有一个硬性的规定，因为它取决于构建缓存内容的成本和缓存项的更新频率

2.5.2.1. 理想的缓存设计应该是读取频率远高于更新频率

2.6. 如果数据不在缓存中，即缓存未命中，服务将从数据库中查询所请求的数据并将查询结果写入缓存，后续的客户端请求无须查询数据库即可使用这些数据

2.6.1. 当项目需要经常更新时，缓存未命中的成本可能会抵消缓存带来的好处

2.7. 当缓存值有效时，所有请求都会使用它

2.7.1. 无须为每个请求调用执行耗时的电梯等待时间的计算

2.8. 使用TTL之类的过期时间是使缓存内容失效的一种常用方法

2.8.1. 确保了服务不会向客户端提供过期的结果

2.8.2. 使系统能够对缓存内容进行一些控制，缓存的空间通常是有限的

2.9. 如果缓存项没有定期刷新，缓存将会填满

2.9.1. 在这种情况下，缓存将采用最近最少使用或最少访问之类的策略来选择要剔除的缓存条目并为更新、更及时的结果腾出空间

2.10. 应用缓存可以显著提高吞吐量、减少延迟并提高客户端应用程序的响应能力

2.11. 一般的设计原则是最大化缓存命中率和最小化缓存未命中率

2.11.1. 当发生缓存未命中时，必须通过查询数据库或下游服务来满足请求

2.11.2. 然后可以将请求的结果写入缓存，用于后续的访问

2.12. 应用级缓存也被称为旁路缓存(cache-aside)模式

2.12.1. 如果所需的结果在缓存中可用，则应用程序代码会高效地绕过数据存储系统

2.12.2. 旁路缓存策略的一个显著优势是它对缓存故障更具弹性

2.12.3. 在缓存不可用的情况下，所有请求基本上都当作缓存未命中来处理

2.12.4. 扩展Redis和memcached之类的旁路缓存平台非常简单，得益于其简单的分布式哈希表模型

2.12.5. 旁路缓存模式是大规模可扩展系统使用的主要方法

2.13. 缓存提供了“魔法”来确保缓存与后端存储系统进行适当的交互

2.14. NCache支持提供者接口(provider interface)由应用程序实现

2.14.1. 接口会在通读缓存未命中和通写缓存写入时自动调用

2.14.2. 通读、通写和后写策略需要这样一种缓存技术，该技术可以通过特定应用的处理程序进行扩充，以便在应用程序访问缓存时执行数据库的读取和写入

3.1. 应用通过访问缓存来满足所有请求

3.2. 如果所需的数据在缓存中不可用，则调用加载器来访问数据系统并将结果加载到缓存中以供应用使用

4.1. 应用总是将更新写入缓存

4.2. 当缓存更新时，将调用写入器将新的缓存值写入数据库

4.3. 当数据库更新后，应用可以完成请求

5.1. 回写缓存

5.2. 与通写缓存类似，只是应用不等待将值从缓存写入数据库

5.3. 这种模式是以可能丢失更新（如果缓存服务器在数据库更新完成之前崩溃）为代价来提高请求响应能力

5.4. 是大多数数据库引擎内部使用的策略

6.1. Web缓存会在定义的时间段内存储给定资源（例如，网页或图像）的副本

6.2. 由于缓存在物理上更靠近客户端，因此请求的延迟会更低

6.3. 边缘缓存，也叫内容分发网络(CDN)

6.3.1. 位于全球多个战略地理位置

6.3.2. 可以缓存靠近客户端的频繁访问的数据

6.3.3. 边缘缓存由CDN提供商在全球范围内部署

6.3.4. Akamai是最早的CDN提供商，拥有2000多个站点，并在全球提供高达30%的互联网流量

6.3.5. 对于拥有全球用户的富媒体站点，边缘缓存是必不可少的

6.4. 缓存通常只存储GET请求的结果，缓存键是与GET关联的URI

6.4.1. 任何具有所请求资源副本的缓存都可以响应请求

6.5. Cache-Control

6.5.1. 客户端请求和服务响应可以使用Cache-Control HTTP标头来定义缓存应该如何利用感兴趣的资源

6.6. Expires和Last-Modified HTTP标头与max-age指令互相配合以控制缓存数据的保留时间

6.6.1. 缓存存储的资源是有限的

6.6.2. 当请求访问一个有效资源时，缓存会用本地存储的结果提供服务，而无须联系源服务器

6.7. Etag

6.7.1. 可用于控制缓存项新鲜度的指令

6.7.2. Etag是一个不透明的值，Web缓存可以使用它来检查缓存的资源是否仍然有效

6.8. Web缓存如果能有效使用，可以显著减少延迟并节省网络带宽，对于图像和文档等大型项目尤其明显

6.9. Web缓存对部署静态数据（图像、视频和音频流）以及不经常变化的数据（如天气报告）最为有效

6.9.1. Squid和Varnish等代理缓存广泛部署在互联网上

6.10. HTTP缓存与代理和边缘缓存相结合所提供的强大功能是构建可扩展应用的宝贵工具