Redis学习笔记（十）：缓存的使用与优化与CacheCloud云平台

0.学习准备：

主要介绍三个方面：

1)收益：

2)成本：

3)使用场景：

有时候缓存的数据和数据库的数据不一致(如上面的计数器)，而缓存需要进行定时的刷新来保证空间的可用性(删除某些key)。

1)缓存更新策略：

2)关于更新策略的建议：

3)缓存粒度简介：

Redis缓存的使用原理图：
模拟基本流程：
- 1.从MySQL中获取用户信息：select * from user where id={id}
- 2.设置用户缓存：set user:id 'select * from user where id={id}'
缓存的粒度：
如上，缓存的到底是select *还是仅仅是需要的一些属性。
粒度控制从三个角度去考虑：
- 通用性：全量属性会更好
- 占用空间：部分属性更好
- 代码维护上：表面上看全量属性会更好
从大部分应用来看：
选择部分属性可能会更好，很多时候不用去考虑扩展性，而是缓存的优化。
选择粒度需要综合去考虑。

1)缓存穿透问题介绍、原因与发现：

缓存穿透：
大量请求不命中，数据直接从存储层读取，使缓存失去了保护存储层的意义。
简单示意图：
产生的原因：
- 业务代码自身的问题
- 恶意攻击或者爬虫等(一个不存在的URL)
如何发现：
- 业务响应时间:监控系统()
- 业务本身的一些问题：产品的代码出现一些问题
- 相关指标：
  总调用数，存储层调用数，缓存层命中数，存储命中数等。

2）缓存穿透的优化：

解决方法一：缓存空对象
如果对象不存在,或者出于某些原因不可用，那么就把空对象作为结果保存到缓存中
解决方案一会出现的两个问题及解决：
- 需要更多的键来保存空对象：
  解决：一般会设置key的过期时间
- 缓存和存储层数据短暂的不一致：数据层(接口)短暂不停供服务
  解决：订阅数据层或接口的消息，使其恢复服务时更新缓存
解决方法二：布隆过滤器拦截
在缓存之前再做一层布隆过滤器拦截，如果被过滤掉了则说明请求失败。

优点是可以使用一个很小的内存来是实现数据的过滤。
布隆过滤器方式的注意事项：
对于数据比较固定的情况会比较好。
数据经常改变时可能不是一个很好的选择。

1)无底洞问题介绍：

2)无敌洞问题优化(优化I/O)：

命令本身的优化：减少使用慢查询及hgetall bigkey等这种命令
优化网络时间：减少网络通信时间(Redis这种命令执行很快的主要优化这个)
具体一点可以查看前面的集群中的批量操作。
(在Mysql这种命令执行较慢的数据库中一般会去选择优化SQL语句本身)
降低客户端连接成本：长连接，连接池，NIO(非阻塞IO)等。

1)问题简介：

2)两个解决方案：

两个解决方案：
- 互斥锁
- 永不过期
互斥锁示意图：

在进行查询及重建的过程中其他线程阻塞。
互斥锁的简单代码：
永远不过期方案：
缓存层面：不会设置key的expire过期时间
功能层面：为每个value添加一个逻辑过期时间，额外创建一个单独的线程来管理逻辑过期时间，如果超过了这个过期时间则进行重建。
(会出现数据不一致的情况，但是不会阻塞线程)
永远不过期的示意图：
两种方案的对比：

CacheCloud目录

1)规模化运维的问题与CacheCloud简介：