成品网站app开发网站高质量外链

成品网站app开发,网站高质量外链,东纺服装人才网,北京论坛建站模板写在开头#xff1a; 上周跟一个想跳槽腾讯的朋友吃饭#xff0c;他一脸郁闷。 三面的时候#xff0c;面试官问了他一个经典的场景题#xff1a;“双十一大促#xff0c;某个爆款商品预计每秒有 100 万请求#xff08;QPS#xff09;#xff0c;库存只有 100 个。请设…写在开头上周跟一个想跳槽腾讯的朋友吃饭他一脸郁闷。 三面的时候面试官问了他一个经典的场景题“双十一大促某个爆款商品预计每秒有 100 万请求QPS库存只有 100 个。请设计一个限流方案。”朋友自信满满地抛出了“Redis 分布式限流”方案 “用 Redis 的INCR或者Lua脚本做令牌桶每秒发 100 个令牌抢不到的直接返回失败。”面试官听完冷笑了一声“100 万 QPS 全部打到 Redis 上你知道 Redis 单节点的极限吞吐是多少吗哪怕是集群针对同一个 Key商品ID的热点操作你怎么分片还没等扣库存你的 Redis 网卡就被限流请求打爆了。”朋友当场死机。这就是典型的“工具思维”害死人。在海量流量面前Redis 不是银弹它甚至可能是瓶颈本身。今天咱们把这个“漏斗式限流”拆透告诉你为什么真正的秒杀系统绝不敢把第一次限流放在 Redis 这一层。一、 认清现实Redis 扛不住 100 万 QPS 的“询问”先算笔账。100 万 QPS指的是“用户点击抢购”的请求量。 如果你让这 100 万个请求都去访问 Redis哪怕只是读一下令牌这叫“热点 Key 问题”。Redis 再强单节点处理Lua脚本或简单命令的极限通常在 8-10 万 QPS 左右。 要把 100 万 QPS 扛下来你得搞多大的 Redis 集群 而且因为是同一个商品Key 是seckill:sku:1001根据哈希算法这些请求全部会打到同一个 Redis 分片上。结局Redis 单节点 CPU 100%整个缓存集群卡死继而拖垮依赖缓存的订单、用户信息服务。全站崩溃。结论在真正的秒杀场景千万别让所有流量都触达 Redis。二、 核心架构漏斗模型The Funnel秒杀限流的核心心法是“层层削减把流量拦在最外层”。 就像一个漏斗100 万请求进来最后到底层数据库的只能是两位数。第 0 层客户端/前端限流让请求发不出来这是最容易被忽略但效果最立竿见影的一层。 如果 100 万用户同时点按钮前端不做控制这 100 万个 HTTP 请求瞬间发起光是建立 TCP 连接握手的开销和带宽成本就能把机房入口堵死。按钮控制活动开始前置灰点击一次后强制置灰几秒防止手速快的用户 1 秒点 10 次。随机丢弃在极度火爆的场景下前端 JS/App 本地可以直接Math.random()。如果是 100 万人抢 100 个货前端直接丢弃 90% 的请求直接弹窗“哎呀人太多了”只有 10% 的幸运儿能真的发起 HTTP 请求。错峰神器引入验证码滑动、计算题。让用户花 3-5 秒去答题把原本集中在 1 秒内的 100 万并发拉平到 5-10 秒内瞬间削峰。第 1 层Nginx/网关限流拦住 90% 的流量这是服务端的“门神”。利用Nginx LuaOpenResty在流量到达 Java 应用服务器之前直接把它掐断。手段limit_req_zone或者自定义 Lua 脚本。逻辑针对 IP 限流或者粗粒度的总流控。效果前端放行过来的 10 万请求在这里再丢弃一部分非法或溢出的请求。为什么在这里做因为 Nginx 是 C 写的处理静态规则的性能是 Java 的几十倍。让 Nginx 返回 503成本极低。第 2 层单机限流Java 进程内限流这是保护微服务不崩盘的关键。 剩下的请求穿透了 Nginx到达了你的 Java 微服务Tomcat/Netty。这时候千万别急着调 Redis先用 JVM 内部的锁如Guava RateLimiter或Sentinel再拦一道。逻辑假设你有 100 台机器后端总共想放行 5000 个请求。那么每台机器设置单机阈值 50 QPS。优势完全内存操作无网络开销。比调 Redis 快 1000 倍。效果经过这一层只有 5000 个请求能通过。第 3 层分布式限流Redis 最终一致性只有那 5000 个“幸运儿”才有资格去请求 Redis 做精准的库存校验和令牌扣减。 这时候Redis 面临的压力只有 5000 QPS简直是挠痒痒完全 hold 得住。三、 算法选择别只会说“令牌桶”面试官如果问“用什么算法” 别光背“令牌桶Token Bucket”和“漏桶Leaky Bucket”的定义要结合业务体验说。漏桶算法Leaky Bucket特点出水速率恒定。即使瞬间来了 1 万个请求它也按每秒 10 个慢慢处理多的直接扔。缺点太死板。秒杀场景用户就想要“快”你让他排队慢吞吞地处理体验极差。令牌桶算法Token Bucket特点以恒定速率存入令牌允许突发流量只要桶里有存货。秒杀首选它允许系统在刚开始的一瞬间处理一波高峰符合秒杀“瞬时爆发”的特征。四、 最后的“防杠”指南高阶避坑这一块是专门留给 P8/P9 面试官的“投名状”。当你说完上面的漏斗模型对方可能会挑战你杠点 1“单机限流导致流量不均怎么办”挑战“你用 Nginx 轮询但如果某台机器处理得慢堆积了请求而另一台机器很空闲单机限流Guava会不会导致整体通过量不足”回击“你说得对单机限流确实有‘总体精度误差’。但在秒杀场景下系统存活 精准控制。 我们宁可少卖出几个最后靠 Redis 兜底也不能让单台机器被流量打死。而且通过 Nginx 的Least Connections策略可以尽量保证流量均匀。”杠点 2“Redis 还是热点 Key 怎么办”挑战“就算只有 5000 QPS 打到 Redis如果这 5000 个都是写操作扣库存Redis 的单线程依然可能响应不过来。”回击“对于极致热点我们会采用‘本地售罄标记Local Stock Flag’策略。 我们不在 Java 内存里做库存分片容易导致数据倾斜而是做一个‘售罄标记’。Redis 扣减库存成功 - 返回成功。Redis 返回库存为 0 - 所有应用服务器同步在本地内存比如AtomicBoolean soldOut true做标记可以通过 MQ 广播或 ZooKeeper 监听甚至简单的短 TTL 本地缓存。关键点后续请求在 JVM 层检查到soldOut true直接返回失败连 Redis 都不用访问。这样Redis 只需要处理库存卖完之前的那一点点流量后续的无效流量全被 JVM 挡住了。”杠点 3“如果有羊毛党用脚本刷接口怎么办”回击“限流解决的是‘流量’问题解决不了‘人性’问题。 防刷必须在限流之前通过WAFWeb防火墙、风控系统、黑名单、复杂验证码来解决。单纯靠技术限流是拦不住模拟正常请求的机器人的。”总结一下下次面试被问到“秒杀限流”千万别上来就写 Lua 脚本。请按这个剧本走否定单层架构直接怼回去100 万 QPS 打 Redis 肯定死。抛出漏斗模型 客户端随机丢弃/置灰 - NginxIP限流/鉴权 - 单机限流Guava保命 - Redis处理最后 1%。防御性补充提出“本地售罄标记”解决热点 Key 问题承认单机限流的误差是为了“保命”做的取舍。做秒杀系统不是为了让所有人都买到东西而是为了在流量洪峰下保证系统能 “有尊严地活着”。https://mp.weixin.qq.com/s/myYTZ_YAT0Wl7dHhfIGgGg