数据库缓存

缓存

缓存就是在内存中存储的数据备份，当数据没有发生本质改变的时候，我们就不让数据的查询去数据库进行操作，而去内存中取数据，这样就大大降低了数据库的读写次数，而且从内存中读数据的速度比去数据库查询要快一些，这样同时又提高了效率。

内存经常用于数据库缓存。

应用场景

针对数据库的增、删、查、改，数据库缓存技术应用场景绝大部分针对的是“查”的场景。比如，一篇经常访问的帖子/文章/新闻、热门商品的描述信息、好友评论/留言等。因为在常见的应用中，数据库层次的压力有80%的是查询，20%的才是数据的变更操作。所以绝大部分的应用场景的还是“查”缓存。当然，“增、删、改”的场景也是有的。比如，一篇文章访问的次数，不可能每访问一次，我们就去数据库里面加一次吧？这种时候，我们一般“增”场景的缓存就必不可少。否则，一篇文章被访问了十万次，代码层次不会还去做十万次的数据库操作吧。

应用举例

读操作流程

有了数据库和缓存两个地方存放数据之后（uid->money），每当需要读取相关数据时（money），操作流程一般是这样的：

（1）读取缓存中是否有相关数据，uid->money

（2）如果缓存中有相关数据money，则返回【这就是所谓的数据命中“hit”】

（3）如果缓存中没有相关数据money，则从数据库读取相关数据money【这就是所谓的数据未命中“miss”】，放入缓存中uid->money，再返回

缓存的命中率 =

命中缓存请求个数/总缓存访问请求个数 = hit/(hit+miss)

上面举例的余额场景，99%的读，1%的写，这个缓存的命中率是非常高的，会在95%以上。

数据库缓存常见开源技术

要说用于数据库缓存场景的开源技术，那必然是memcache和redis这两个中间件。有持久化需求或者对数据结构和处理有高级要求的应用，选择redis。其他简单的key/value存储，选择memcache。所以根据自身业务特性，数据库缓存来选择适合自己的技术。

Redis介绍

它支持丰富的数据结构(类型)，比如String/List/Hash/Set/Sorted Set。

缓存与数据库不一致的解决方案

当数据money发生变化的时候，是更新缓存中的数据，还是淘汰缓存中的数据呢？

什么是更新缓存：数据不但写入数据库，还会写入缓存什么是淘汰缓存：数据只会写入数据库，不会写入缓存，只会把数据淘汰掉

那到底是选择更新缓存还是淘汰缓存呢，主要取决于“更新缓存的复杂度”。

例如，上述场景，只是简单的把余额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)
更新缓存的代价很大，此时我们应该更倾向于淘汰缓存。

当写操作发生时，假设淘汰缓存作为对缓存通用的处理方式，又面临两种抉择：
（1）先写数据库，再淘汰缓存
（2）先淘汰缓存，再写数据库
究竟采用哪种时序呢？
假设先写数据库，再淘汰缓存：第一步写数据库操作成功，第二步淘汰缓存失败，则会出现DB中是新数据，Cache中是旧数据，数据不一致。
假设先淘汰缓存，再写数据库：第一步淘汰缓存成功，第二步写数据库失败，则只会引发一次Cache miss。
先淘汰缓存，再写数据库。

结论强调

（1）淘汰缓存是一种通用的缓存处理方式

（2）先淘汰缓存，再写数据库的时序是毋庸置疑的

（3）服务化是向业务方屏蔽底层数据库与缓存复杂性的一种通用方式

参考链接：
http://blog.csdn.net/u012129558/article/details/52278091
https://yq.aliyun.com/articles/11228