老系统
DB
完善缓存
宕机
delete【key:123456 】
client
使用Redis做缓存的缓存穿透和雪崩
业务
key：123456 v：update123
1kw并发
查询返回值为null
返回给业务系统
redis
键值策略控制器
雪崩！
2：后台提前刷新缓存，时间比较久
一：新系统直接迁移，且老系统用户基数过大，大量数据请求落在数据库上或新项目上线活动比较火爆
二：查询了数据库不存在的数据，且每次条件不一样，导致数据库缓存key(sql语句) value(数据集)失效，所有的请求落在数据库上
逐步切量，转移
策略服务器
业务服务
新系统
业务数据更新模块
insert【key:123456，v:123】
问题二，三：1：如果是仿造数据进行攻击，则通过第一层过滤，数据key值通过指定加密方式保护2：如果是每次访问的都是真数据或者仿造者破解了key值生成策略， 则通过第二层缓存处理3：数据更新则采用数据更新模块处理新数据的更新问题4：导致的问题就是redis中会存贮非常多的值为空的键值，通过设置合适的过期时间 来平均redis和数据库的压力
数据库
网关
短期内几乎全量的数据落到数据库上、
99%未命中
查询返回值为null也缓存到redis
1%命中缓存
三：黑客攻击，同第2条
重启
问题一：前提：异地容灾，redis集群不在同一个机房1：新老系统切换，采用逐步切量的方式进行，防止直接切换导致大量的负载
key：123456 v：null expires
读取，写入io飙升导致运行缓慢，直至宕机
前提：redis集群可复用或在同一个机房3：优先考虑同一个redis集群(无需做其他处理)，或者同一机房的服务（采用管道复制）
正则，取模，匹配转发...
校验不合规的请求数据
