关于后端:redis缓存设计以及经典问题分析

1 缓存根本思维

1、不同的存储介质拜访提早不一样，雷同老本存储容量不一样：

SSD/DISK、Memory、L3 cache、L2 cache、L1 cache 五种存储介质，拜访提早逐步升高，然而等同老本的容量却逐步增大。

2、工夫局限性原理

被获取过一次的数据在将来会被屡次获取

3、以空间换工夫

开拓一块高速独立空间，提供高速拜访

4、性能老本衡量

拜访提早性低、性能越高，等容量老本越高

2 缓存劣势

1. 晋升拜访性能
2. 升高网络拥挤
3. 加重服务负载
4. 加强可扩展性

3 缓存代价

1. 零碎复杂性进步
2. 存储和部署老本变高
3. 数据一致性问题

4 缓存的三种模式

4.1 Cache Aside 旁路缓存

写操作：更新 DB 之后，间接将 key 从缓存中删除；

读操作：先读缓存，如果没有，则读 DB，同时将 DB 的数据同步到缓存中。

特点：业务端解决所有数据拜访细节，同时利用 lazy 懒加载思维，更新 DB 之后，间接删除缓存并通过 DB 更新，确保数据以 DB 为准，能够大幅升高缓存和 DB 之间的不统一的概率。

毛病：

1、如果删除缓存失败，可能会有问题；

解决办法：失败减少监控

2、如果同时有比拟高的 QPS 拜访刚插入或者更新的数据，可能会打垮 DB；

解决办法：应用多线程异步执行查问，避免这种问题。

场景：读多写少。比方用户数据，用户批改用户信息很少，然而各种业务场景用到用户数据的读场景比拟多。

4.2 Read/Write Through

核心思想：读写缓存和 DB 的操作，都有一个两头的数据服务代理。

写操作：先查缓存，如果缓存不存在，则只更新 DB；如果缓存中存在，则先更新缓存，再更新 DB，而后返回；

读操作：先查缓存，如果命中则间接返回。否则从 DB 中加载，而后回种到缓存中再返回。

特点：业务端不须要关怀数据细节，零碎隔离性好。

4.3 write-Back 或者 Write-Behind

承接 Write Through，写操作更新完缓存之后，异步 回写数据到 DB 或者批量回写数据到 DB。

毛病：异步或者批量回写，可能会导致数据失落。

特点：合并或者异步写 DB，DB 压力小。

应用场景：写频率很高，然而对于数据一致性要求不太高的业务。

5 redis 常见面试题

5.1 redis 雪崩

概念：大量的利用申请无奈在 Redis 缓存中进行解决，紧接着，
利用将大量申请发送到数据库层，导致数据库层的压力激增。

起因：

1、缓存中有大量数据同时过期，导致大量申请无奈失去解决

2、Redis 缓存实例产生故障宕机了

解决方案：

起因 1：办法 1：防止给大量的数据设置雷同的过期工夫；办法 2: 降级间接返回预约义信息、空值或是错误信息

起因 2：办法 1: 在业务零碎中实现服务熔断或申请限流机制；办法 2: 服务端 限流

事先预防：应用主从节点 构建 Redis 缓存高牢靠集群

5.2 击穿

概念：1、是产生在某个热点数据生效的场景下，大量申请间接拜访 DB，DB 压力骤增，业务响应提早。

起因：热点 key 过期生效或者同时生效。

解决办法：热点 key 不设置过期工夫；或者设置过期工夫为根底工夫 + 随机工夫。

5.3 穿透

概念：要拜访的数据既不在 Redis 缓存中，也不在数据库中，导致申请在拜访缓存时，产生缓存缺失，再去拜访数据库时，发现数据库中也没有要拜访的数据。

起因：1、业务层误删除数据了；2、歹意攻打：专门拜访数据库中没有的数据。

解决办法：

1、缺省值或者空值

2、应用布隆过滤器疾速判断数据是否存在，
防止从数据库中查问数据是否存在，加重数据库压力。

3、前端进行申请检测

5.4 bigkey

概念：一个缓存 key，存储数据过多。比方一个上万记录的 List；

危害：

1、造成内存调配不平均。比方在 Redis cluster 或者 codis 中，会造成节点的内存应用不平均；

2、超时阻塞。因为 Redis 单线程个性，如果操作某个 Bigkey 耗时比拟久，则前面的申请会被阻塞。

3、网络阻塞，耗费带宽。

4、过期删除，会很慢，会阻塞 redis。如果 Bigkey 设置了过期工夫，当过期后，这个 key 会被删除，如果没有应用 Redis 4.0 的过期异步删除，
就会存在阻塞 Redis 的可能性，并且慢查问中查不到（因为这个删除是外部循环事件）。

如何发现：

redis 命令：redis-cli –bigkeys

解决办法：

1、删除 bigkey。

1. redis4.0 之后，异步删除；
2. 汇合类型：用 scan，读取局部数据删除；
3. hash 类型，用 Hscan，读取局部数据删除

2、拆分

1. string 类型，拆分成多个 key
2. 汇合或者 hash 类型，拆分成多个 list 或者 hash

5.5 热 key

概念: 所谓热 key 问题就是，忽然有几十万的申请去拜访 redis 上的某个特定 key。
那么，这样会造成流量过于集中，达到物理网卡下限，从而导致这台 redis 的服务器宕机。

解决：

1、二级缓存——本地缓存。比方利用 ehcache，或者一个 HashMap 都能够。在你发现热 key 当前，把热 key 加载到零碎的 JVM 中。
针对这种热 key 申请，会间接从 jvm 中取，而不会走到 redis 层。

2、备份热 key。不要让 key 走到同一台 redis 上不就行了。咱们把这个 key，在多个 redis 上都存一份不就好了。
接下来，有热 key 申请进来的时候，咱们就在有备份的 redis 上随机选取一台，进行拜访取值，返回数据。

思维导图自取：https://www.processon.com/emb…

参考：https://segmentfault.com/a/11…