缓存设计

1.读写方式

2.kv size

3.key数量

4.读写峰值，《=10w，10w-100wcache分层，本地+远程

5.命中率，容灾，主备，一致性hash

6.过期策略

 

7.平均缓存穿透加载时间

8.可运维性

9.安全性

 

1.常见问题：

1.大量key同时过期，同一批商品，热门动态批量导入。解决：base+random

2.缓存穿透。特殊，异常路径。解决1.缓存null值标志，缺点占用空间，可设置较短过期时间，或者分业务和公共2层缓存2.bloomFilter缓存过滤key，校验key的有效性。误判率问题，数组下标一对一映射不存在，否则用k次hash的结果集合判断存在误判率，但节省空间

3.缓存雪崩：1.不支持rehash，2.支持rehash，洪峰。解决1.增加db读写开关，满查询超过阀值，关闭开关，failfast2.多副本cache架构，任何cache池miss后，读其他chache副本3.实时监控，故障转移策略

4.数据不一致。场景（1.cache带宽打满/网络波动，更新cache失败，缓存rehash，节点异常，多次上下线）解决1.cache更新失败后，重试或消息队列2.调短过期时间DB重新加载，最终一致。3.拒绝rehash漂移，采用缓存分层策略

 

5.数据并发竞争（场景，车票缓存信息过期，微博缓存数据淘汰）方案1.全局锁2.缓存保持多个备份？

 

6.hot key。10w-100w用户一起访问一个key，请求打到一台机器，屋里网卡，带宽，cpu极限，从而导致服务异常。

（秒杀，新闻）1.先找出hotkey，2.hotkey分散处理，分散在多个节点或者，多级缓存和多slave 3.本地缓存记录极热key

 7.部分key的vaue过大，读写加载易超时。hot大key带来的带宽问题。key字段过多db变动频繁，频繁更新缓存。key被淘汰，加载时间长。

（粉丝，长微博）。1.restore？2.大key拆小key。3.尽量不淘汰大key