Redis系列之缓存原理&设计
Redis系列链接
缓存基本思想
缓存的使用场景
DB缓存，减轻服务器压力
一般情况下数据存在数据库中，应用程序直接操作数据库。当应用程序访问量上万，数据库压力突然增大，如果需要减轻数据库服务器的压力，有以下方法：
-
数据库读写分离
-
数据库分库分表
-
使用缓存，并实现换粗你的读写分离
缓存的作用：将应用程序已经访问过的内容或数据存储起来，当应用程序再次访问时先找缓存，缓存命中返回数据。不命中再查询数据库，并保存到缓存。
提高系统响应
数据库的数据是存在文件里，也就是硬盘。 与内存做交换(swap) 在大量瞬间访问时(高并发)MySQL单机会因为频繁IO而造成无法响应。
MySQL的InnoDB是有行锁，
将数据缓存在Redis中，也就是存在了内存中。内存天然支持高并发访问。可以瞬间处理大量请求。qps到达10万读请求
Session分离
传统的session是由tomcat自己进行维护和管理。集群或分布式环境，不同的tomcat管理各自的session。 只能在各个tomcat之间，通过网络和Io进行session的复制，极大的影响了系统的性能。
将登录成功后的Session信息，存放在Redis中，这样多个服务器(Tomcat)可以共享Session信息。
分布式锁和乐观锁(Redis)
- 分布式锁
一般讲锁是多线程的锁，是在一个进程中的多个进程(JVM)在并发时也会产生问题，也要控制时序性 可以采用分布式锁。使用Redis实现sexNX
- 乐观锁
同步锁和数据库中的行锁、表锁都是悲观锁 悲观锁的性能是比较低的，响应性比较差 高性能、高响应(秒杀)采用乐观锁 Redis可以实现乐观锁 watch + incr
常见缓存的分类
客户端缓存
-
页面缓存
-
页面缓存:页面自身对某些元素或全部元素进行存储，并保存成文件。
-
html5:Cookie、WebStorage(SessionStorage和LocalStorage)、WebSql、indexDB、ApplicationCache等
-
-
浏览器缓存
当客户端向服务器请求资源时，会先抵达浏览器缓存，如果浏览器有“要请求资源”的副本，就可以直接从浏览器缓存中提取而不是从原始服务器中提取这个资源。
浏览器缓存可分为强制缓存和协商缓存。
-
强制缓存:直接使用浏览器的缓存数据
-
协商缓存:服务器资源未修改，使用浏览器的缓存(304);反之，使用服务器资源(200)
-
APP缓存
原生APP中把数据缓存在内存、文件或本地数据库(SQLite)中。比如图片文件。
网络端缓存
通过代理的方式响应客户端请求，对重复的请求返回缓存中的数据资源。
- Web代理缓存
可以缓存原生服务器的静态资源，比如样式、图片等。比如nginx反向代理
- 边缘缓存
边缘缓存中典型的商业化服务就是CDN了。
CDN的全称是Content Delivery Network，即内容分发网络。
CDN通过部署在各地的边缘服务器，使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度 和命中率。
CDN的关键技术主要有内容存储和分发技术。现在一般的公有云服务商都提供CDN服务。
服务端缓存
服务器端缓存是整个缓存体系的核心。包括数据库级缓存、平台级缓存和应用级缓存。
-
数据库级缓存
-
数据库是用来存储和管理数据的。
-
MySQL在Server层使用查询缓存机制。将查询后的数据缓存起来。
-
K-V结构，Key:select语句的hash值，Value:查询结果
-
InnoDB存储引擎中的buffer-pool用于缓存InnoDB索引及数据块
-
-
平台级缓存
平台级缓存指的是带有缓存特性的应用框架。 比如:GuavaCache 、EhCache、OSCache等。 部署在应用服务器上，也称为服务器本地缓存。
- 应用级缓存
具有缓存功能的中间件:Redis、Memcached、EVCache、Tair等。 采用K-V形式存储。
利用集群支持高可用、高性能、高并发、高扩展。
缓存的优势、代价
优势
提升用户体验
-
用户在使用产品过程中建立起来的一种纯主观感受。
-
缓存的使用可以提升系统的响应能力，大大提升了用户体验。
减轻服务器压力
-
客户端缓存、网络端缓存减轻应用服务器压力。
-
服务端缓存减轻数据库服务器的压力。
提升系统性能
-
缩短系统的响应时间
-
减少网络传输时间和应用延迟时间
-
提高系统的吞吐量
-
增加系统的并发用户数
-
提高了数据库资源的利用率
缺点和代价
额外的硬件支出
-
缓存是一种软件系统中以空间换时间的技术
-
需要额外的磁盘空间和内存空间来存储数据
-
搭建缓存服务器集群需要额外的服务器
-
采用云服务器的缓存服务就不用额外的服务器了
-
阿里云，百度云，提供缓存服务
高并发缓存失效
-
在高并发场景下会出现缓存失效(缓存穿透、缓存雪崩、缓存击穿)
-
造成瞬间数据库访问量增大，甚至崩溃
缓存与数据库数据同步
-
缓存与数据库无法做到数据的时时同步
-
Redis无法做到主从时时数据同步
缓存并发竞争
- 多个redis的客户端同时对一个key进行set值得时候由于执行顺序引起的并发问题
缓存的读写模式
缓存一般有三种读写模式
Cache Aside Pattern(常用，旁路缓存)
Cache Aside Pattern，是最经典的缓存+数据库读写模式。
- 读的时候，先读缓存，缓存没有的话，就读数据库，然后取出数据后放入缓存，同时返回响应。
- 更新的时候，先更新数据库，然后再删除缓存。
高并发脏读的三种情况
- 1、先更新数据库，再更新缓存
update和commit之间，更新缓存，commit失败，则数据库数据与缓存数据不一致
- 2、先删除缓存，再更新数据库
update和commit之间，有新的读，缓存为空，读数据库数据到缓存是旧的数据，commit后数据库数据为新的数据，则数据库数据与缓存数据不一致
- 3、先更新数据库，再删除缓存(推荐)
Read/Write Through Pattern（直读直写穿透模式）
应用程序只操作缓存，缓存操作数据库。
Read-Through(穿透读模式/直读模式):应用程序读缓存，缓存没有，由缓存回源到数据库，并写入 缓存。
Write-Through(穿透写模式/直写模式):应用程序写缓存，缓存写数据库。
该种模式需要提供数据库的handler，开发较为复杂。
Write Behind Caching Pattern（异步缓存写入模式）
应用程序只更新缓存。
缓存通过异步的方式将数据批量或合并后更新到DB中不能时时同步，甚至会丢数据。
缓存架构的设计思路
多层次
数据类型
根据数据的不同，采用不同的数据类型
集群
-
哨兵+主从
-
RedisCluste
缓存的数据结构设计
-
1、与数据库表一致
- 数据库表和缓存是一一对应的
- 缓存的字段会比数据库表少一些
- 缓存的数据是经常访问的
-
2、与数据库表不一致
- 需要存储关系，聚合，计算等
