厦门php网站建设,苏州网上商城搭建,南昌网站建设制作,大连软件开发网站建设直接发车#x1f697;
一.雪崩 1.触发原因 A.大量缓存数据在同一时间过期(失效) B.redis故障宕机 上述均导致全部请求去访问数据库#xff0c;导致DB压力骤增#xff0c;严重则导致数据库宕机/系统宕机 2.应对策略
不同触发原因#xff0c;应对策略也不一致
应对A
一.雪崩 1.触发原因 A.大量缓存数据在同一时间过期(失效) B.redis故障宕机 上述均导致全部请求去访问数据库导致DB压力骤增严重则导致数据库宕机/系统宕机 2.应对策略
不同触发原因应对策略也不一致
应对A 1.均匀设置过期时间 给这些key加个随机TTL反正数据别同时过期就行 2.互斥锁 加锁时机发现访问的数据不在Redis中加个互斥锁锁住从数据库读取数据再将数据更新的redis里的这个过程构建缓存构建完成后再释放锁。 若未能拿到锁要么等锁释放后读取缓存要么返回空或默认值。 互斥锁时一定设置【超时时间】防止其他请求一直拿不到锁的情况 3.双KEY策略 相当于给缓存数据做副本 俩KEY-VALUE,key不一致value一致备key设置永不过期TTL -1 当业务线程访问不到【主key】的缓存数据时返回【备Key】的数据有效避免采用互斥锁上述第二点大量线程被锁住后续再通知后台线程重新构建【主key】数据。 4.后台更新缓存 让缓存永不过期业务线程更新缓存的操作交给线程定时任务或者MQ。 虽然设置永不过期但也存在系统内存紧张被淘汰的命运。 第一种方案 后台线程不仅负责定时更新缓存也负责频繁检测缓存是否有效是否被淘汰若失效则需要做数据库到缓存的同步检测间隔不能太久最好毫秒级无论如何有个间隔时间用户体验不咋滴 第二种方案 业务线程若发现缓存失效MQ发个消息来通知后台线程来更新缓存比第一种方案更及时 应对B 1.服务熔断机制 启动【**服务熔断**】机制暂停业务应用对缓存服务的冲击直接返回错误且不再访问数据库侧。影响业务访问影响业务使用 2.请求限流机制 为减少对业务的影响启用【**请求限流**】机制只将少部分请求放过再多的请求直接在入口出直接拒绝等redis恢复且把缓存数据预热后再解除。 二.击穿 应对方案 1.互斥锁 2.热点Key永不过期由后台异步更新缓存当被淘汰时 / 热点数据准备过期时提前通知后台线程更新缓存即重置过期时间 三.穿透 一般出现的两种情况 1.恶意攻击故意访问大量读取不到的业务数据 2.业务误操作将缓存和数据库中的数据都删除了 应对方案 1.非法请求限制 判断参数合理性/参数中是否有非法值若判断出时恶意请求直接响应错误 2.缓存空值/默认值 缓存空置或者默认值若发现有缓存穿透的数据时手动在缓存种存个默认值或空值 3.布隆过滤器 在写入数据库时使用过滤器做个标记。当下次请求过来确认缓存失效后再通过查询布隆过滤器判断数据是否存在若不存在也不去查数据库了 总结
缓存异常产生原因应对方案缓存雪崩大量key同一时间过期1.打散过期时间 2.互斥锁 3.双key策略 4.后台更新缓存定时更新消息通知更新redis故障宕机1.服务熔断 2.请求限流 3.构建redis高可用集群击穿频繁访问过期热点数据1.互斥锁 2.热点数据永不过期穿透访问缓存和数据库种均不存在的数据1.拦截非法请求 2.缓存空置或默认值 3.使用过滤器判断
