网站建设后台怎么修改小制作小发明视频教程

网站建设后台怎么修改,小制作小发明视频教程,wordpress 随机页面,idea做网站目录 前言 1.止血保命#xff08;保可用#xff09; 1.1 快速限流 1.1.1 可以参考我之前写的文章 1.2 降级熔断 1.3 紧急扩容 1.4 消息队列#xff0c;流量削锋 2.冷静分析#xff1a;为什么#xff1f;暴增的流量是否合理#xff1f; 3. 设计阶段#xff1a;健…目录前言1.止血保命保可用1.1 快速限流1.1.1 可以参考我之前写的文章1.2 降级熔断1.3 紧急扩容1.4 消息队列流量削锋2.冷静分析为什么暴增的流量是否合理3. 设计阶段健壮设计增强系统身体素质3.1 分而治之横向扩展3.2 微服务拆分系统拆分3.3 分库分表3.4 池化技术3.5 使用缓存3.6 异步4.压力测试测试系统抗压能力5. 最后前言字节面试场景题假设你负责的业务系统流量突增比如QPS暴增100倍你要怎么处理有些伙伴一听完题目就不假思索回答那就加机器呀、扩容什么的。当然这个不能算错但是你只得其中一小点的分数肯定不及格的。作为一名优秀的后端开发程序员我们应当从多个维度去思考这个问题尽可能回答完整、正确。紧急响应阶段快速止血冷静分析为什么暴增的流量合理嘛健壮设计增强系统身体素质压力测试测试系统抗压能力1.止血保命保可用如果我们负责的系统突发流量洪峰来了超过系统的承载能力为了保护我们的系统需要快速止血!1.1 快速限流我们可以采取限流方案。其实就是保护系统控制单位时间内请求的处理数量。什么是限流在计算机网络中限流就是控制网络接口发送或接收请求的速率它可防止DoS攻击和限制Web爬虫。限流也称流量控制。是指系统在面临高并发或者大流量请求的情况下限制新的请求对系统的访问从而保证系统的稳定性。​可以使用Guava的RateLimiter单机版限流也可以使用Redis分布式限流还可以使用阿里开源组件sentinel限流。还可以通过令牌桶、漏桶算法限制请求速率丢弃超出阈值的请求避免系统过载。令牌桶算法系统以固定速率向桶中添加令牌请求需获取令牌才能被处理。若桶空则触发限流。漏桶算法请求像水一样流入漏桶桶以恒定速率出水处理请求。桶满则溢出触发限流。核心动作开启网关层限流如 Nginx、Spring Cloud Gateway、阿里 Sentinel对非核心接口如统计、历史查询直接返回 “服务繁忙”核心接口下单、支付、登录设置 “当前容量 1.5 倍” 的限流阈值如平时 QPS 1000临时设 1500超出部分返回降级提示如 “当前访问人数过多请稍后重试”。数据库限流通过 MySQL 的max_connections限制连接数避免连接耗尽对慢查询如关联查询、无索引 SQL临时 kill释放数据库资源。1.1.1 可以参考我之前写的文章深刻理解限流和降级GUAVA 实现限流1.2 降级熔断熔断是为了快速失败、防止雪崩降级是为了舍车保帅、保障核心。熔断当依赖的下游服务持续失败时主动“断开”调用避免资源浪费和故障扩散。降级在系统资源紧张或非核心服务不可用时主动“牺牲”次要功能保障核心业务正常运行。维度熔断Circuit Breaker降级Degradation出发点应对依赖服务故障应对系统资源不足或非核心功能失效触发原因下游服务错误率 阈值如 10 秒内失败率 50%响应超时如超过 2 秒异常抛出频率过高系统过载CPU 90%、线程池满、内存不足熔断发生后作为 fallback 的兜底逻辑人工干预大促前手动关闭推荐、评论等非核心模块视角调用方视角保护自己全局视角资源调度是否需要 fallback是必须提供降级逻辑是本身就是一种 fallback主动性被动由故障触发可主动如大促预案或被动关系熔断通常会触发降级降级不一定由熔断引起作用防止因一个服务故障拖垮整个调用链如支付服务挂了导致订单服务线程池耗尽给故障服务留出恢复时间快速失败Fail Fast提升用户体验保证核心链路如登录、下单、支付始终可用提升系统整体吞吐量和稳定性实现“有损服务”而非“完全不可用”比如分布式调用链路A-B-C....下图所示如果服务C出现问题比如是因为慢SQL导致调用缓慢那将导致B也会延迟从而A也会延迟。堵住的A请求会消耗占用系统的线程、IO、CPU等资源。当请求A的服务越来越多占用计算机的资源也越来越多最终会导致系统瓶颈出现造成其他的请求同样不可用最后导致业务系统崩溃。因此面对突发激增100倍的流量我们可以采取熔断降级。熔断对非核心服务如推荐、评论启用熔断机制如Hystrix快速失败以释放资源优先保障核心链路如支付、下单。服务降级关闭非关键功能如数据分析、日志记录返回兜底数据如缓存中的默认商品信息降低后端压力。1.3 紧急扩容如果是突发的流量高峰除了降级、限流保证系统不跨我们还可以采用这两种方案保证系统尽可能服务用户请求核心动作应用层扩容通过容器化平台K8s、阿里 ACK对核心服务订单、支付执行 “水平扩容”直接将实例数翻倍如从 3 台扩到 6 台同时调整线程池参数如核心线程数从 20 扩到 50队列容量从 1000 扩到 5000。缓存扩容Redis 集群临时增加从节点如从 2 个从节点扩到 4 个分担读压力开启 Redis 缓存预热提前加载核心商品、用户数据到缓存避免缓存穿透。数据库扩容临时提升数据库连接数max_connections从 1000 调到 2000开启读写分离所有读请求路由到从库主库仅承担写操作。1.4 消息队列流量削锋削峰Peak Shaving在流量洪峰到来时不直接冲击后端服务而是将请求暂存到消息队列中。填谷Valley Filling在系统空闲时段如夜间继续处理队列中积压的消息充分利用资源。高并发场景痛点秒杀、抢购、热点事件等场景下瞬时 QPS 可达数十万甚至百万。后端服务如数据库、订单系统处理能力有限可能仅支持 1000 QPS。若直接处理会导致数据库连接池耗尽CPU/内存飙升 → OOM 崩溃线程阻塞 → 整个服务雪崩核心动作消息队列削峰将核心写操作下单、支付回调接入 MQ如 RocketMQ、Kafka改为异步处理如用户下单后先返回 “下单中”MQ 异步同步订单到数据库MQ 设置足够大的队列容量如 10 万级避免队列满溢。​假设你的应用系统每秒最多可以处理2k个请求每秒却有5k的请求过来可以引入消息队列应用系统每秒从消息队列拉2k请求处理得了。2.冷静分析为什么暴增的流量是否合理问清楚流量暴增是“好事”还是“坏事”可能原因应对措施正常促销如双11检查是否在预案范围内确认压测指标是否达标观察是否仅特定接口突增代码Bug如死循环、重复调用查日志、链路追踪SkyWalking/Zipkin快速回滚或热修复恶意攻击CC/DDoSIP限流、加入黑名单WAF防护结合风控系统拦截异常行为3. 设计阶段健壮设计增强系统身体素质回到设计阶段我们如何避免这些突发的流量倍增呢分析瓶颈点3.1 分而治之横向扩展如果你只部署一个应用只部署一台服务器那抗住的流量请求是非常有限的。并且单体的应用有单点的风险如果它挂了那服务就不可用了。因此设计一个高并发系统我们可以分而治之横向扩展。也就是说采用分布式部署的方式部署多台服务器把流量分流开让每个服务器都承担一部分的并发和流量提升整体系统的并发能力。3.2 微服务拆分系统拆分要提高系统的吞吐提高系统的处理并发请求的能力。除了采用分布式部署的方式外还可以做微服务拆分这样就可以达到分摊请求流量的目的提高了并发能力。所谓的微服务拆分其实就是把一个单体的应用按功能单一性拆分为多个服务模块。比如一个电商系统拆分为用户系统、订单系统、商品系统等等。3.3 分库分表当业务量暴增的话MySQL单机磁盘容量会撑爆。并且我们知道数据库连接数是有限的。在高并发的场景下大量请求访问数据库MySQL单机是扛不住的高并发流量倍增场景下会出现too many connections报错。因此应对流量激增的场景需要考虑拆分为多个数据库来抗住高并发的毒打。而假如你的单表数据量非常大存储和查询的性能就会遇到瓶颈了如果你做了很多优化之后还是无法提升效率的时候就需要考虑做分表了。一般千万级别数据量就需要分表每个表的数据量少一点提升SQL查询性能。3.4 池化技术在高并发的场景下数据库连接数可能成为瓶颈因为连接数是有限的。我们的请求调用数据库时都会先获取数据库的连接然后依靠这个连接来查询数据搞完收工最后关闭连接释放资源。如果我们不用数据库连接池的话每次执行SQL都要创建连接和销毁连接这就会导致每个查询请求都变得更慢了相应的系统处理用户请求的能力就降低了。因此需要使用池化技术即数据库连接池、HTTP 连接池、Redis 连接池等等。使用数据库连接池可以避免每次查询都新建连接减少不必要的资源开销通过复用连接池提高系统处理高并发请求的能力。3.5 使用缓存无论是操作系统浏览器还是一些复杂的中间件你都可以看到缓存的影子。我们使用缓存主要是提升系统接口的性能这样流量激增的高并发场景你的系统就可以支持更多的用户同时访问。常用的缓存包括Redis缓存JVM本地缓存memcached等等。就拿Redis来说它单机就能轻轻松松应对几万的并发你读场景的业务可以用缓存来抗高并发。3.6 异步回忆一下什么是同步什么是异步呢以方法调用为例它代表调用方要阻塞等待被调用方法中的逻辑执行完成。这种方式下当被调用方法响应时间较长时会造成调用方长久的阻塞在高并发下会造成整体系统性能下降甚至发生雪崩。异步调用恰恰相反调用方不需要等待方法逻辑执行完成就可以返回执行其他的逻辑在被调用方法执行完毕后再通过回调、事件通知等方式将结果反馈给调用方。因此设计一个应对激增流量的高并发系统需要在恰当的场景使用异步。如何使用异步呢后端可以借用消息队列实现。比如在海量秒杀请求过来时先放到消息队列中快速响应用户告诉用户请求正在处理中这样就可以释放资源来处理更多的请求。秒杀请求处理完后通知用户秒杀抢购成功或者失败。4.压力测试测试系统抗压能力上线前必须做全链路压测如 JMeter Chaos Engineering。明确系统瓶颈是 CPUDB网络GC5. 最后假设你负责的业务系统流量突增100倍。我们可以通过限流、熔断降级、扩容、流量削峰等手段快速给系统止血。快速止血我们止血后我们快速定位问题分析是bug还是恶意攻击还是正常促销引起的。分析伤口原因我们通过横向扩展、服务拆分、分库分表、池化技术、缓存、异步、压测等手段增强系统身体素质。