缓冲的使用和设计
-
缓存的使用和设计
-
缓存的受益与成本
-
受益
- 加速读写
- 通过缓存加速读写速度：cpu l1/l2l3 cache，linux page Cache加速硬盘读写，浏览器缓存，ehcache缓存数据库结果
- 降低后端的负载
- 后端服务器通过前端缓存降低负载：业务端使用redis降低后端mysql负载等
-
成本
- 数据不一致：缓存层和数据层有时间窗口不一致，和更新策略有关
- 代码维护成本：多了一层缓存逻辑
- 运维成本：例如：rediscluster
-
使用场景
- 降低后端负载
- 对高消耗的sql：join结果集/分组统计结果缓存
- 加速请求响应
- 利用redis/memcache优化io响应时间
- 大量写合并为批量写
- 如计数器先redis累加再批量写db
- 降低后端负载
-
-
缓存的更新策略
- lru/lfu/fifo算法剔除：例如maxmemory-policy
- 超时剔除：例如expire
- 主动更新：开发控制生命周期
- 两条建议
- 低一致性：最大内存和淘汰策略
- 高一致性：超时剔除和主动更新结合，最大内存和淘汰策略兜底
-
缓存的粒度控制
- 通用性：全量属性更好
- 占用空间：部分属性更好
- 代码维护：表面上全量属性会更好
-
缓存穿透优化
- 业务代码自身问题
- 恶意攻击，爬虫等等
- 如何发现
- 业务的响应时间
- 业务本身问题
- 相关指标：总调用数，缓存层命中数，存储层命中数
- 两个问题
- 需要更多的键
- 缓存层和存储层数据，“短期”不一致
- 布隆过滤器拦截
-
无底洞问题优化
- 问题关键点
- 更多的机器！=更高的性能
- 批量接口需求（mget,mset等）
- 数据增长和水平扩展需求
- 优化io的几种方法
- 命令本身优化：例如查询keys，hgetall bigkey
- 减少网络通信次数
- 降低接入成本：例如客户端长连接/连接池，nio等
- 问题关键点
-
缓存雪崩优化
- 缓存层高可用，客户端降级，提前演练时解决雪崩问题的重要方法
-
热点key重建优化
- 热点key+较长的重建时间
- 三个目标和两个解决
- 减少重缓存的次数
- 数据尽可能一致
- 减少潜在危险
- 两个解决
- 互斥锁
- 永不过期
- 缓存层面：没有设置过期时间（没有用expire）
- 功能层面：为每个value值添加逻辑过期时间，但是发现超过逻辑过期时间后，会使用单独的线程去构建缓存
-
| 方案 | 优点 | 缺点 |
|---|---|---|
| 互斥锁 | 思路简单，保证一致性 | 代码复杂度增加，存在死锁风险 |
| 永远不过期 | 基本杜绝热点key重建问题 | 不保证一致性，逻辑过期时间增加维护成本和内存成本 |
redis云平台cachecloud
- redis规模化运维
- 遇到的问题
- 发布构建繁琐，私搭乱建
- 节点&机器等运维成本
- 监控报警初级
- 功能
- 一件开启redis（standalone，sentinel,cluster)
- 机器，应用，实例监控和报警
- 客户端：透明使用，性能上报
- 可视化运维：配置，扩容，failover，机器、应用、实例上下线
- 已经存在的redis直接接入和数据迁移
- https://github.com/sohutv/cachecloud
- 使用规模
- 300+亿commands/day
- 3tb memory total
- 1300+instances total
- 200+ machines total
- 使用场景
- 全量视屏缓存（视屏播放api）：跨机房高可用
- 消息队列同步（redismq中间件）
- 分布式布隆过滤器（百万qps）
- 计数系统：计数（播放数）
- 其他：排行榜，社交（直播）实时计算（反作弊）等
- 遇到的问题
- 快速构建
- 集群部署
- 机器添加部署脚本：ssh账号，redis安装部署
- cachecloud添加机器
- 应用接入
- 用户功能
- 运维功能
其它：
- MySQL通过source命令执行sql文件
https://github.com/hbn1326317071/studyRedis/