本文主要讨论这么几个问题：
（1）“缓存与数据库”需求缘起
（2）“淘汰缓存”还是“更新缓存”
（3）缓存和数据库的操作时序
（4）缓存和数据库架构简析
本节是为下一部分 主从系统下的cache的铺垫。
需求缘起
缓存是一种提高系统读性能的常见技术，对于读多写少的应用场景，我们经常使用缓存来进行优化。由于大部分的请求是查询，我们在缓存中建立uid到money的键值对，能够极大降低数据库的压力。
读操作流程
有了数据库和缓存两个地方存放数据之后（uid->money），每当需要读取相关数据时（money），操作流程一般分为两种情况：
- 数据Hit：如果缓存中有相关数据money，则直接返回数据。
- 数据Miss：如果缓存中没有相关数据money，则从数据库读取相关数据money，然后放入缓存中uid->money，再返回数据。
更新缓存 vs 淘汰缓存
当数据发生写操作的时候，是应该更新缓存呢？还是应该淘汰缓存？
更新缓存的优点：缓存不会增加一次miss，命中率高。
淘汰缓存的优点：简单。
那到底是选择更新缓存还是淘汰缓存呢，主要取决于“更新缓存的复杂度”。
例如，上述场景，只是简单的把余额money设置成一个值，那么：
（1）淘汰缓存的操作为deleteCache(uid)
（2）更新缓存的操作为setCache(uid, money)
更新缓存的代价很小，此时我们应该更倾向于更新缓存，以保证更高的缓存命中率
如果余额是通过很复杂的数据计算得出来的，例如业务上除了账户表account，还有商品表product，折扣表discount
account(uid, money)
product(pid, type, price, pinfo)
discount(type, zhekou)
业务场景是用户买了一个商品product，这个商品的价格是price，这个商品从属于type类商品，type类商品在做促销活动要打折扣zhekou，购买了商品过后，这个余额的计算就复杂了，需要：
（1）先把商品的品类，价格取出来：SELECT type, price FROM product WHERE pid=XXX
（2）再把这个品类的折扣取出来：SELECT zhekou FROM discount WHERE type=XXX
（3）再把原有余额从缓存中查询出来money = getCache(uid)
（4）再把新的余额写入到缓存中去setCache(uid, money-price*zhekou)
更新缓存的代价很大，此时我们应该更倾向于淘汰缓存。
淘汰缓存是一种通用的缓存处理方式：操作简单，并且带来的副作用只是增加了一次cache miss
先操作数据库 vs 先操作缓存
当写操作发生时，假设淘汰缓存作为对缓存通用的处理方式，又面临两种抉择：
（1）先写数据库，再淘汰缓存
（2）先淘汰缓存，再写数据库
究竟采用哪种时序呢？由于写数据库与淘汰缓存不能保证原子性，所以一般遵循以下原则：
如果出现不一致，谁先做对业务的影响较小，就谁先执行。
以下的两个假设都是在单一业务（请求）的情况下，出现的错误。
假设先写数据库，再淘汰缓存：
第一步写数据库操作成功，第二步淘汰缓存失败，则会出现DB中是新数据，Cache中是旧数据，数据不一致。
假设先淘汰缓存，再写数据库：
第一步淘汰缓存成功，第二步写数据库失败，则只会引发一次Cache miss。
缓存架构优化
上述缓存架构有一个缺点：业务方需要同时关注缓存与DB，有没有进一步的优化空间呢？
主流优化方案是服务化：加入一个服务层，向上游提供帅气的数据访问接口，向上游屏蔽底层数据存储的细节，这样业务线不需要关注数据是来自于cache还是DB。
服务化是向业务方屏蔽底层数据库与缓存复杂性的一种通用方式。
