缓冲的使用和设计
-
缓存的使用和设计
-
缓存的受益与成本
-
受益
- 加速读写
- 通过缓存加速读写速度: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/