数据库缓存

一、什么是数据库缓存

我们知道常见的数据库，比如oracle、mysql等，数据都是存放在磁盘中。虽然在数据库层也做了对应的缓存，但这种数据库层次的缓存一般针对的是查询内容，而且粒度也太小，一般只有表中数据没有变更的时候，数据库对应的cache才发挥了作用。但这并不能减少业务系统对数据库产生的增、删、查、改的庞大IO压力。所以数据库缓存技术在此诞生，实现热点数据的高速缓存，提高应用的响应速度，极大缓解后端数据库的压力。
以下为memcache数据库缓存为例，以图说明一下什么是数据库缓存：

二、数据库缓存的技术特点

性能优越
数据库缓存的第一个技术特点就是提高性能，所以数据库缓存的数据基本上都是存储在内存中，相比io读写的速度，数据访问快速返回。而且在mysql 5.6的版本开始，已经把memcache这种跟数据库缓存直接挂钩的中间件直接集成进去了，已经等不及我们自己去单独部署对应数据库缓存的中间件了。
应用场景
针对数据库的增、删、查、改，数据库缓存技术应用场景绝大部分针对的是“查”的场景。比如，一篇经常访问的帖子/文章/新闻、热门商品的描述信息、好友评论/留言 等。因为在常见的应用中，数据库层次的压力有80%的是查询，20%的才是数据的变更操作。所以绝大部分的应用场景的还是“查”缓存。当然，“增、删、改”的场景也是有的。比如，一篇文章访问的次数，不可能每访问一次，我们就去数据库里面加一次吧？这种时候，我们一般“增”场景的缓存就必不可少。否则，一篇文章被访问了十万次，代码层次不会还去做十万次的数据库操作吧。
数据一致性
在很多应用场景中，当一个数据发生变更的时候，很多人在考虑怎么样确保缓存数据和数据库中数据保存一致性，确保从缓存读取的数据是最新的。甚至，有人在对应数据变更的时候，先更新数据库，然后再去更新缓存。我觉得这个考虑不太现实，一方面这会导致代码层次逻辑变得复杂，另外一方面也真想不明白还要缓存干什么了。在绝大多数的应用中，缓存中的数据和数据库中的数据是不一致的。即，我们牺牲了实时性换回了访问速度。比如，一篇经常访问的帖子，可能这篇帖子已经在数据库层次进行了变更。而我们每次访问的时候，读取的都是缓存中的数据（帖子）。既然是缓存，那么必然是对实时性可以有一定的容忍度的数据，容忍度的时间可以是5分钟，也可以是5小时，取决于业务场景的要求。相反，一定要求是实时性的数据库，就不应该从缓存里读取，比如库存，再比如价格。
高可用
自从有了缓存，代码每天快乐的去缓存中愉快的玩耍。为什么说高可用呢，我们知道缓存为数据库抵挡了很多压力，同时也为应用提供了良好的访问速度。但同时有没有想过缓存的感受，如果当数据库缓存“罢工”了，这会出现什么后果？特别在一些高并发的应用中，数据库层肯定是“消化不良“，最终导致应用全面崩溃。所以缓存的高可用显得非常重要。

三、数据库缓存常见开源技术

要说用于数据库缓存场景的开源技术，那必然是memcache和redis这两个中间件。

| 数据类型 | 持久性 | 分布式
----|------|---- | -----
memcache | 支持简单数据类型 | 不支持数据持久化存储 | 不支持主从、不支持sharing（代码层次通过hash可以实现）
redis | 数据类型丰富，支持set、list等类型| 支持数据磁盘持久化存储|支持主从，支持sharding(redis 3.0开始支持)
因为都是专注于内存缓存领域，memcache和redis向来都有争议。比如性能，到底是memcache性能好，还是redis性能更好等。同样都是内存缓存技术，它们都有自己的技术特性。没有更好的技术，只有更合适的技术。个人总结一下，有持久化需求或者对数据结构和处理有高级要求的应用，选择redis。其他简单的key/value存储，选择memcache。所以根据自身业务特性，数据库缓存来选择适合自己的技术。

暂不说用不用数据库缓存，见过有人把session存储在数据库中的，也见过把视频/文件转化成二进制存储在数据库的，这种行为无疑是逆天的。合理应用数据库缓存技术，且行且珍惜，切勿走向误区。

作者：耕云者
链接：https://www.jianshu.com/p/51be1b9ca60b
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。