引用：
系统设计入门
缓存架构设计细节二三事
有哪些缓存级别
客户端缓存
缓存可以位于客户端（操作系统或者浏览器）。
CDN 缓存
CDN 也被视为一种缓存。
CDN边缘节点缓存策略因服务商不同而不同，但一般都会遵循 HTTP 标准协议，通过 HTTP 响应头中的 Cache-control: max-age 的字段来设置CDN边缘节点数据缓存时间。
当客户端向CDN节点请求数据时，CDN节点会判断缓存数据是否过期，若缓存数据并没有过期，则直接将缓存数据返回给客户端；否则，CDN节点就会向源站发出回源请求，从源站拉取最新数据，更新本地缓存，并将最新数据返回给客户端。
CDN服务商一般会提供基于文件后缀、目录多个维度来指定CDN缓存时间，为用户提供更精细化的缓存管理。
CDN缓存时间会对“回源率”产生直接的影响。若CDN缓存时间较短，CDN边缘节点上的数据会经常失效，导致频繁回源，增加了源站的负载，同时也增大的访问延时；若CDN缓存时间太长，会带来数据更新时间慢的问题。开发者需要增对特定的业务，来做特定的数据缓存时间管理。
Web 服务器缓存
反向代理和缓存可以直接提供静态和动态内容。Web 服务器同样也可以缓存请求，返回相应结果而不必连接应用服务器。
数据库缓存
数据库的默认配置中通常包含缓存级别，针对一般用例进行了优化。调整配置，在不同情况下使用不同的模式可以进一步提高性能。
当有很多相同的查询被执行了多次的时候，这些查询结果会被放到一个缓存中。
这样，后续的相同的查询就不用操作表而直接访问缓存结果了。
// 查询缓存不开启
$r = mysql_query("SELECT * FROM student WHERE signup_date = CURDATE()");
// 开启查询缓存
$today = date("Y-m-d");
$r = mysql_query("SELECT * FROM student WHERE signup_date = '$today'");
像 CURDATE(), NOW() 和 RAND() 或是其它的诸如此类的SQL函数都不会开启查询缓存。
因为这些函数的返回值是不定的。
应用缓存
基于内存的缓存比如 Memcached 和 Redis 是应用程序和数据存储之间的一种键值存储。由于数据保存在 RAM 中，它比存储在磁盘上的典型数据库要快多了。
Redis 有下列附加功能：
- 持久性选项
- 内置数据结构比如有序集合和列表
何时更新缓存
由于你只能在缓存中存储有限的数据，所以你需要选择一个适用于你用例的缓存更新策略。
缓存模式
应用从存储器读写。缓存不和存储器直接交互，应用执行以下操作：
- 在缓存中查找记录，如果所需数据不在缓存中
- 从数据库中加载所需内容
- 将查找到的结果存储到缓存中
- 返回所需内容
Memcached 通常用这种方式使用。
添加到缓存中的数据读取速度很快。缓存模式也称为延迟加载。只缓存所请求的数据，这避免了没有被请求的数据占满了缓存空间。
缺点：
- 请求的数据如果不在缓存中就需要经过三个步骤来获取数据，这会导致明显的延迟。
- 如果数据库中的数据更新了会导致缓存中的数据过时。这个问题需要通过设置TTL强制更新缓存或者直写模式来缓解这种情况。
直写模式
应用使用缓存作为主要的数据存储，将数据读写到缓存中，而缓存负责从数据库中读写数据：
- 应用向缓存中添加/更新数据
- 缓存同步地写入数据存储
- 返回所需内容
由于存写操作所以直写模式整体是一种很慢的操作，但是读取刚写入的数据很快。相比读取数据，用户通常比较能接受更新数据时速度较慢。缓存中的数据不会过时。
缺点：
- 由于故障或者缩放而创建的新的节点，新的节点不会缓存，直到数据库更新为止。
回写模式
在回写模式中，应用执行以下操作：
- 在缓存中增加或者更新条目
- 异步写入数据，提高写入性能。
缺点：
- 缓存可能在其内容成功存储之前丢失数据。
缓存的缺点：
- 需要保持缓存和真实数据源之间的一致性。
- 需要改变应用程序比如增加 Redis 或者 memcached。
- 无效缓存是个难题，什么时候更新缓存是与之相关的复杂问题。
缓存与数据库
缓存是一种提高系统读性能的常见技术，对于读多写少的应用场景，我们经常使用缓存来进行优化。
例如对于用户的余额信息表 account(uid, money)，业务上的需求是：
- 查询用户的余额，SELECT money FROM account WHERE uid=XXX，占 99% 的请求
- 更改用户余额，UPDATE account SET money=XXX WHERE uid=XXX，占 1% 的请求
由于大部分的请求是查询，我们在缓存中建立 uid 到 money 的键值对（uid -> money），能够极大降低数据库的压力。
读操作流程：
- 读取缓存中是否有相关数据，uid -> money
- 如果缓存中有相关数据 money，则返回【数据命中 hit】
- 如果缓存中没有相关数据 money，则从数据库读取相关数据 money【数据未命中 miss】，放入缓存中 uid -> money，再返回
缓存的命中率 = 命中缓存请求个数/总缓存访问请求个数 = hit / (hit + miss)
问题来了：
当余额数据 money 发生变化的时候：
- 是更新缓存中的数据，还是淘汰缓存中的数据呢？
- 是先操纵数据库中的数据再操纵缓存中的数据，还是先操纵缓存中的数据再操纵数据库中的数据呢？
- 缓存与数据库的操作，在架构上是否有优化的空间呢？
是更新缓存中的数据，还是淘汰缓存中的数据呢？
更新缓存：
- 数据不但写入数据库，还会写入缓存
- 优点：缓存不会增加一次 cache miss，命中率高
淘汰缓存：
- 数据只会写入数据库，不会写入缓存，只会把数据淘汰掉
- 优点：简单
- 缺点：增加了一次 cache miss
取决于 更新缓存的复杂度：
例如，上述场景，只是简单的把余额 money 设置成一个值，那么：
- 淘汰缓存的操作为 deleteCache(uid)
- 更新缓存的操作为 setCache(uid, money)
更新缓存的代价很小，此时我们应该更倾向于更新缓存，以保证更高的缓存命中率。
如果余额是通过很复杂的数据计算得出来的，例如业务上除了账户表 account，还有商品表 product，折扣表 discount。
业务场景是用户买了一个商品 product，这个商品的价格是 price，这个商品从属于 type 类商品，type类商品在做促销活动要打折扣 zhekou，购买了商品过后，这个余额的计算就复杂了，需要：
- 先把商品的品类，价格取出来：SELECT type, price FROM product WHERE pid=XXX
- 再把这个品类的折扣取出来：SELECT zhekou FROM discount WHERE type=XXX
- 再把原有余额从缓存中查询出来 money = getCache(uid)
- 再把新的余额写入到缓存中去 setCache(uid, money - price * zhekou)
更新缓存的代价很大，此时我们应该更倾向于淘汰缓存。
先操作数据库 VS 先操作缓存
当写操作发生时，假设 淘汰缓存 作为对缓存通用的处理方式，又面临两种抉择：
- 先写数据库，再淘汰缓存
- 先淘汰缓存，再写数据库
对于一个不能保证事务性的操作，一定涉及 哪个任务先做，哪个任务后做 的问题，解决这个问题的方向是：
如果出现不一致，谁先做对业务的影响较小，就谁先执行。
假设先写数据库，再淘汰缓存：
- 更新数据库操作成功，将编号 001 的账号的余额从 50 元更新为 100 元
- 可是淘汰缓存操作失败，缓存中是旧数据 50 元，从而造成了 数据不一致，用户查询时，在缓存中命中，返回 50 块的错误余额
结论是：应该先淘汰缓存，再写数据库。
这样即使第二步写数据库失败，则只会引发一次 cache miss。
缓存架构优化
传统架构：如下所示。缺点：业务方需要同时关注缓存与 数据库。
主流优化方案是 服务化：加入一个服务层，向上游提供数据访问接口，向上游屏蔽底层数据存储的细节，这样业务线不需要关注数据是来自于缓存还是数据库。
