1 缓存根本思维
1、不同的存储介质拜访提早不一样，雷同老本存储容量不一样：
SSD/DISK、Memory、L3 cache、L2 cache、L1 cache 五种存储介质，拜访提早逐步升高，然而等同老本的容量却逐步增大。
2、工夫局限性原理
被获取过一次的数据在将来会被屡次获取
3、以空间换工夫
开拓一块高速独立空间，提供高速拜访
4、性能老本衡量
拜访提早性低、性能越高，等容量老本越高
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。
- redis4.0 之后，异步删除；
- 汇合类型：用scan，读取局部数据删除；
- hash类型，用Hscan，读取局部数据删除
2、拆分
- string类型，拆分成多个key
- 汇合或者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...