优化网站平台设计软件的软件

优化网站平台,设计软件的软件,百度app下载安装官方免费版,公司免费招聘网站在前面的文章中#xff0c;我们聊了分布式锁、聊了持久化#xff0c;这些都是在讲“怎么用好 Redis”。但今天我们要聊一个更底层、更残酷的话题#xff1a;资源限制与系统脆弱性。Redis 再快#xff0c;它也是基于内存的。内存是昂贵的资源#xff0c;不可能无限扩容。同…在前面的文章中我们聊了分布式锁、聊了持久化这些都是在讲“怎么用好 Redis”。但今天我们要聊一个更底层、更残酷的话题资源限制与系统脆弱性。Redis 再快它也是基于内存的。内存是昂贵的资源不可能无限扩容。同时Redis 作为数据库的挡箭牌一旦它出了问题数据库瞬间就会面临灭顶之灾。今天这篇我们就来把 Redis 的内存淘汰策略和缓存击穿/穿透/雪崩彻底讲透。一、 内存满了怎么办内存淘汰策略Redis 的性能虽然强悍但它不是黑洞。在生产环境中我们通常会在配置文件中设置maxmemory来限制 Redis 的最大内存使用量。那么问题来了当数据量存满了新数据又要塞进来Redis 该扔掉谁Redis 提供了 8 种策略看起来眼花缭乱。其实作为博主我建议你不要死记硬背而是从“范围”和“算法”两个维度去理解。1. 维度一你要对谁下手筛选范围Redis 并不总是对所有数据都“赶尽杀绝”它把数据分为了两类圈子圈子一Volatile临时工区 - 仅针对设置了 TTL 的 Key含义Redis 只会从设置了过期时间的 Key 中进行淘汰。场景这非常适合“混合存储”场景。比如你的 Redis 里既存了必须持久化的重要配置没设 TTL又存了大量的临时缓存设了 TTL。当内存不足时Redis 会很懂事地只清理那些本来就会过期的缓存绝对不会碰你的重要数据。圈子二Allkeys全员区 - 针对所有 Key含义不管你设没设过期时间一视同仁大家都在被淘汰的范围内。场景这是“纯缓存”模式的最佳选择。因为作为缓存只要内存满了没用的数据就该腾位置不需要保留任何特权阶级。2. 维度二你要怎么挑筛选算法LRU (Least Recently Used)淘汰最久没被使用过的。逻辑你虽然进来的早但最近 3 个月都没人查过你留着浪费资源请你走人。LFU (Least Frequently Used)淘汰使用频率最低的。逻辑虽然你刚才被访问了一次但你是这一年来唯一的访问说明你不够热请你走人。Random随机。闭着眼瞎选一个删掉。TTL剩余寿命最短。既然你马上就要过期了不如我提前送你一程仅适用于 Volatile 范围。3. 策略大盘点与选型建议将上述两个维度组合再加上默认策略就构成了 8 种策略策略名筛选范围淘汰规则博主推荐场景noeviction-不删除直接报错(默认配置)适用于数据绝不能丢的场景需配合完善的扩容监控。volatile-lru有TTL的最久未用适用于Redis 既做缓存又做存储的混合场景。volatile-lfu有TTL的最少频率同上。volatile-random有TTL的随机删除极其少用。volatile-ttl有TTL的即将过期哪怕没过期只要快到了就删不如 LRU 智能。allkeys-lru所有Key最久未用最常用适用于通用的缓存场景保留热点数据。allkeys-lfu所有Key最少频率适用于有些生僻数据很久才被访问一次的场景。allkeys-random所有Key随机删除极其少用。说明绝大多数业务场景直接闭眼选allkeys-lru。因为缓存的本质就是“把热的数据留下”LRU 是最符合这个直觉的算法。二、 缓存的三大“天坑”击穿、穿透、雪崩Redis 就像一道堤坝挡在脆弱的 MySQL 数据库前面。如果这道堤坝出了问题洪水高并发请求就会直接冲垮数据库。我们按照问题的**“刁钻程度”**由点到面来分析。1. 缓存击穿 (Cache Breakdown) —— “单点爆破”简单来说就是热点key过期的瞬间大量请求达到了DB。这是最常见但也最需要技术含量的场景。现象某个 超级热点 Key比如微博热搜、秒杀商品并发量极高。在它 TTL 过期的一瞬间几万个请求同时发现 Redis 没数据同时冲向数据库去构建缓存。结果 数据库瞬间被打死。解决方案针对这个问题我们有两种截然不同的思路。方案 A互斥锁 (Consistency First)既然大家都要去查数据库那就排队思路只允许一个线程去查询数据库并重建缓存其他线程阻塞等待。流程线程 1 发现缓存没数据。线程 1 获取分布式锁Mutex Lock。线程 1 去查库、写缓存、释放锁。线程 2、3、4 在获取锁失败后阻塞等待或者休眠一会再重试Double Check。优点数据一致性高。缺点性能有损耗大家都在等那一个人。方案 B永不过期 逻辑过期 (Availability First)就好像他本应该过期的但是我留下了他用来保护数据库反正我先返回给你然后更新重置缓存这个方案牺牲了一点点数据一致性换取了极致的性能。这也是很多高并发系统的首选。核心思路Redis 层面Key不设置 TTL所以物理上它永远不会过期除非被淘汰。业务层面我们在 Value 的内容里多存一个属性expireTime逻辑过期时间。具体实现流程查询缓存请求命中缓存后读取 Value。判断过期检查 Value 里的expireTime字段看是否已过期。未过期直接返回数据结束。已过期获取锁尝试获取互斥锁。开启异步线程如果获取锁成功说明我是“被选中”的那个人。我立马开启一个独立的异步线程去查询数据库、更新缓存重置expireTime、释放锁。返回旧值无论是获取锁成功的当前线程还是获取锁失败的其他线程都不用等直接把手里这份“已经过期”的旧数据返回给用户。说明这种方案非常巧妙。它实际上是“悄悄地在后台更新”。用户在更新完成前的几百毫秒内虽然看到的是旧数据但系统响应速度极快没有任何阻塞。2. 缓存穿透 (Cache Penetration) —— “打在了空气上”关键在⼀个透字透过去了即数据在 Redis 缓存和数据库中都不存在这样缓存永远 不会生效请求都会打到数据库。说白了没得给你缓存的机会如果说击穿是“热点失效”那穿透就是“恶意攻击”。现象请求想要的数据Redis 里没有数据库里也没有。这样 Redis 就成了摆设请求每次都直通数据库。这通常是代码 bug 或者黑客恶意攻击一直请求 ID-1 的数据。解决方案缓存空对象数据库查不到我也在 Redis 存一个null并设个短一点的过期时间。下次你再来查 -1Redis 直接告诉你“是空”别烦数据库。布隆过滤器 (Bloom Filter)在访问 Redis 之前加一道屏障。布隆过滤器能高效地判断“这个 ID 是否存在”。如果布隆说不存在直接打回连 Redis 都不用查。布隆过滤器原理分析如果说缓存空值是被动防御那布隆过滤器就是主动拦截。核心原理 底层是一个巨大的BitMap (位图)N 个哈希函数。存入时经过 N 次 Hash 计算将对应位置的比特位全部置为1。查询时同样的 N 次 Hash 计算去查看对应位置。判定规则铁律只要有一位是 0说明该 Key绝对不存在。 -直接拦截无需查库。如果全都是 1说明该 Key可能存在存在极低概率是别的 Key 凑出来的 Hash 冲突。 -放行。3. 缓存雪崩 (Cache Avalanche) —— “全线崩塌”同⼀时间⼤量key过期导致查询全打到数据库上最后一种情况是规模最大的灾难。现象大量的 Key 在同一时间集体过期或者 Redis 节点直接宕机。这导致此刻所有的请求全部涌向数据库数据库瞬间压力过大而崩溃。解决方案打散过期时间在设置 TTL 时不要设成固定的 1 小时而是TTL 随机数1-5分钟。让 Key 排队过期不要挤在一起。高可用架构利用 Redis Sentinel 或 Cluster保证 Redis 挂了一个节点其他的能立马顶上。服务降级当缓存和数据库都扛不住时直接返回默认值或错误提示保住系统不崩。总结Redis 的学习不能只停留在命令的使用上。内存淘汰是为了让 Redis 永远只留最有价值的数据。击穿/穿透/雪崩的防御是为了让 Redis 在面对流量洪峰和异常情况时依然能稳稳地守护身后的数据库。掌握了这些你才算真正具备了驾驭大规模 Redis 集群的能力。下一篇我们将深入 Redis 的集群架构敬请期待