redis缓存与集群问题以及内存优化（三）

 

 

缓存策略的更新

 

缓存粒度控制

 

 

 

 

 

 

 

 

热点Key的重建

 

潜在危险是：线程池大量夯住 和死锁

会存在等待的过程  也会出现夯住的情况

 

 

redis规模化运维的问题与解决

缓存雪崩（缓存失效）

        如果缓存集中在一段时间内失效，发生大量的缓存穿透，所有的查询都落在数据库上，造成了缓存雪崩。

        缓存层宕掉后，流量会像奔逃的野牛一样，打向后端存储

    解决方法：

1. 在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。
2. 可以通过缓存reload机制，预先去更新缓存，再即将发生大并发访问前手动触发加载缓存
3. 不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀
4. 做二级缓存，或者双缓存策略。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能顺利进行

 

 

 

 

 

 

上面是不需要的数据