redis缓存与集群问题以及内存优化(三)
缓存策略的更新
缓存粒度控制
热点Key的重建
潜在危险是:线程池大量夯住 和死锁
会存在等待的过程 也会出现夯住的情况
redis规模化运维的问题与解决
缓存雪崩(缓存失效)
如果缓存集中在一段时间内失效,发生大量的缓存穿透,所有的查询都落在数据库上,造成了缓存雪崩。
缓存层宕掉后,流量会像奔逃的野牛一样,打向后端存储
解决方法:
- 在缓存失效后,通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存,其他线程等待。
- 可以通过缓存reload机制,预先去更新缓存,再即将发生大并发访问前手动触发加载缓存
- 不同的key,设置不同的过期时间,让缓存失效的时间点尽量均匀
- 做二级缓存,或者双缓存策略。A1为原始缓存,A2为拷贝缓存,A1失效时,可以访问A2,A1缓存失效时间设置为短期,A2设置为长期。
不能使用in 和循环
用布隆过滤器解决上面的问题
误差率
表示value的一个标准,不要越过红线。
千兆网卡是128M 带宽 很多redis会影响带宽导致阻塞。。
会有后台线程 不会阻塞主线程
java客户端优化
连接池的优化
如何预估最大连接池
redis内存优化
自身内存 共享变量等 一般几百K 几乎不用担心
对象内存 key-value hash set等
缓冲内存 aof 客户端缓冲区等
内存碎片 系统分配和自身使用内存的差值
THP 是内核2.6的一个特性 加快fork速度 但是写时复制 内存页会扩大为 2M(之前为4k),会产生阻塞
overcommit_memory=1 使fork能顺利进行
上面是不需要的数据