首页 > 其他分享 >面试场景题系列--(1)如果系统的 QPS 突然提升 10 倍该怎么设计?--xunznux

面试场景题系列--(1)如果系统的 QPS 突然提升 10 倍该怎么设计?--xunznux

时间:2024-07-25 22:26:45浏览次数:18  
标签:10 缓存 服务 -- 数据库 系统 熔断 xunznux 限流

1. 如果系统的 QPS 突然提升 10 倍该怎么设计?

1.1 硬件的扩展+微服务的拆分

如果所有的业务包括交易系统、会员信息、库存、商品等等都夹杂在一起,当流量一旦起来之后,单体架构的问题就暴露出来了,机器挂了所有的业务就全部无法使用了。
在这里插入图片描述

于是,集群架构的架构开始出现,单机无法抗住的压力,最简单的办法就是水平拓展横向扩容。通过负载均衡把压力流量分摊到不同的机器上,暂时是解决了单点导致服务不可用的问题。
在这里插入图片描述
随着业务的发展,在一个项目里维护所有的业务场景使开发和代码维护变得越来越困难,一个简单的需求改动都需要发布整个服务,代码的合并冲突也会变得越来越频繁,同时线上故障出现的可能性越大。微服务的架构模式就诞生了。
在这里插入图片描述
把每个独立的业务拆分开独立部署,开发和维护的成本降低,集群能承受的压力也提高了,再也不会出现一个小小的改动点需要牵一发而动全身了。
以上的点从高并发的角度而言,似乎都可以归类为通过服务拆分和集群物理机器的扩展提高了整体的系统抗压能力,那么,随之拆分而带来的问题也就是高并发系统需要解决的问题。

1.2 高性能 RPC

微服务化的拆分带来的好处和便利性是显而易见的,但是需要考虑各个微服务之间的通信。
传统 HTTP 的通信方式性能首先并不太好,大量的请求头之类无效的信息是对性能的浪费,这时候就需要引入诸如 Dubbo 类的 RPC 框架。
在这里插入图片描述
经测试:Dubbo RPC 的性能,是 Feign RPC 的性能 10 倍(可能是这样)。RPC 框架本身一般都自带负载均衡、熔断降级的机制,可以更好的维护整个系统的高可用性。

1.3 消息队列削峰解耦

MQ 的主要功能:

  • 削峰填谷、解耦。
  • 同步转异步的方式,可以降低微服务之间的耦合。
    例如:对于一些不需要同步执行的接口,可以通过引入消息队列的方式异步执行以提高接口响应时间。在交易完成之后需要扣库存,然后可能需要给会员发放积分,本质上,发积分的动作应该属于履约服务,对实时性的要求也不高,我们只要保证最终一致性也就是能履约成功就行了。 对于这种同类性质的请求就可以走 MQ 异步,也就提高了系统抗压能力了。
    在这里插入图片描述

1.4 三级缓存架构

缓存作为高性能的代表,在某些特殊业务可能承担 90% 以上的热点流量。
对于一些活动比如秒杀这种并发 QPS 可能几十万的场景,引入缓存事先预热可以大幅降低对数据库的压力,10 万的 QPS 对于单机的数据库来说可能就挂了,但是对于如 redis 这样的缓存来说就完全不是问题。

在这里插入图片描述

以秒杀系统举例,活动预热商品信息可以提前缓存提供查询服务,库存数据可以提前缓存,下单流程可以完全走缓存扣减,秒杀结束后再异步写入数据库,数据库承担的压力就小的太多了。

1.5 数据库分库分表

对于整个系统而言,最终所有的流量的查询和写入都落在数据库上,数据库是支撑系统高并发能力的核心。
怎么降低数据库的压力,提升数据库的性能是支撑高并发的基石。主要的方式就是通过读写分离和分库分表来解决这个问题。
对于整个系统而言,流量应该是一个漏斗的形式。比如我们的日活用户DAU有20万,实际可能每天来到提单页的用户只有3万QPS,最终转化到下单支付成功的QPS只有1万。
那么对于系统来说读是大于写的,这时候可以通过读写分离的方式来降低数据库的压力。
读写分离也就相当于数据库集群的方式降低了单节点的压力。而面对数据的急剧增长,原来的单库单表的存储方式已经无法支撑整个业务的发展,这时候就需要对数据库进行分库分表了。
针对微服务而言垂直的分库本身已经是做过的,剩下大部分都是分表的方案了。

1.6 高可用

高可用(High Availability)是指系统在面临高并发、大流量及异常情况时,依然能够保持稳定运行,尽量避免服务中断,确保业务的连续性。高可用性策略包括多种技术手段,例如熔断、限流、降级、预案和核对等。

1.6.1 熔断

熔断(Circuit Breaker)是指当某个服务发生故障或响应时间过长时,自动切断对该服务的调用,防止故障蔓延影响到其他服务或整个系统。熔断器类似于电路中的断路器,通过监控服务的健康状况,当检测到服务出现大量异常或超时时,触发熔断机制。
示例场景:
在电子商务平台中,如果营销服务出现故障或响应时间过长,为避免影响下单主链路,可以使用熔断机制。此时系统暂时停止调用营销服务,确保订单创建流程不受影响。对于因营销服务不可用而导致的积分扣减等操作,可以在服务恢复后通过补偿机制进行补救。

1.6.2 限流

限流(Rate Limiting)是通过限制单位时间内某个服务或接口的访问次数,防止服务在高并发请求下被过载击垮。限流可以根据系统的压测结果,设置合理的阈值,确保系统在高并发场景下依然能够稳定运行。
示例场景:
在秒杀活动中,由于瞬间涌入的大量请求可能导致系统过载,限流机制可以对关键接口进行限制。例如,将秒杀商品的请求限制在每秒1000次以内,超过限制的请求将被拒绝或排队处理,从而保证系统的稳定性。

1.6.3 降级

降级(Fallback)是指在某个服务不可用或性能下降时,自动切换到降级方案,以保证核心功能的正常运行。降级通常与熔断结合使用,熔断触发后进入降级模式,待服务恢复正常后再重新启用。
示例场景:
如果营销服务熔断后,可以立即进入降级模式,即短时间内不再调用营销服务,而是提供一个默认的响应或提示用户稍后再试。当检测到营销服务恢复正常后,再恢复对其调用。

1.6.4 预案

预案(Contingency Plan)是指在系统运行过程中,提前制定的一系列应急处理方案。预案通常在业务高峰期(如促销活动、节假日)生效,通过合理的配置,确保在紧急情况下能够快速做出响应,进行必要的调整。一般来说,就算是有统一配置中心,在业务的高峰期也是不允许做出任何的变更的,但是通过配置合理的预案可以在紧急的时候做一些修改。
示例场景:
在双十一购物节期间,平台可能会遇到流量激增的情况。此时,预案可以包括调整限流阈值、启用备用服务器、临时关闭非核心功能等。通过统一配置中心进行快速配置变更,在不影响业务连续性的前提下应对突发状况。

1.6.5 核对

核对(Verification)是指针对分布式系统中的数据一致性问题,进行定期或实时的校验,确保数据的准确性和完整性。核对通常用于检测和纠正因系统故障、网络攻击等导致的数据异常。
针对各种分布式系统产生的分布式事务一致性或者受到攻击导致的数据异常,非常需要核对平台来做最后的兜底的数据验证。比如下游支付系统和订单系统的金额做核对是否正确,如果受到中间人攻击落库的数据是否保证正确性。
示例场景:
在支付系统中,为确保订单金额的一致性,可以对支付系统和订单系统的数据进行定期核对。如果发现数据不一致,需要及时查找原因并进行修复。核对还可以用于防范中间人攻击,通过验证落库数据的正确性,确保系统安全。

1.7 总结

设计高并发系统,需要从物理硬件层面到软件的架构、代码层面的优化,使用什么中间件来不断提高系统的抗压能力。
但是这个问题本身会带来更多的问题,微服务本身的拆分带来了分布式事务的问题,http、RPC 框架的使用带来了通信效率、路由、容错的问题,MQ 的引入带来了消息丢失、积压、事务消息、顺序消息的问题,缓存的引入又会带来一致性、雪崩、击穿的问题,数据库的读写分离、分库分表又会带来主从同步延迟、分布式 ID、事务一致性的问题,而为了解决这些问题又要不断的加入各种措施熔断、限流、降级、离线核对、预案处理等等来防止和追溯这些问题。

其他内容

之前的文章有对Springboot 启动时Bean的创建与注入这个过程的讲解以及对应的源码解读,感兴趣的可以去看看:
Springboot 启动时Bean的创建与注入(一)-源码解读-xunznux
Springboot 启动时Bean的创建与注入(二)-源码解读-xunznux
Springboot 的Bean生命周期五步、七步、十步详解以及框架源码解读
实现一个自己的OpenFeign 远程调用验证协议

标签:10,缓存,服务,--,数据库,系统,熔断,xunznux,限流
From: https://blog.csdn.net/weixin_44615954/article/details/140648064

相关文章

  • MySQL的查询优化思路
    目录前言解决方案减少查询SQL优化索引优化减少锁避免大事务扩容硬件升级前言一般的系统中,数据库往往都是性能瓶颈。在一个系统中,数据库被使用的频率很高,因为几乎所有的应用程序都需要与数据库交互来读取或写入数据。所以一旦数据库的响应慢,负载突增,则会大大影响系......
  • 11 个接口性能优化技巧(上)【送源码】
    接口性能优化对于从事后端开发的同学来说,肯定再熟悉不过了,因为它是一个跟开发语言无关的公共问题。该问题说简单也简单,说复杂也复杂。有时候,只需加个索引就能解决问题。有时候,需要做代码重构。有时候,需要增加缓存。有时候,需要引入一些中间件,比如mq。有时候,需要需要分库分......
  • 实现一个自己的OpenFeign 远程调用验证协议--Springboot 自定义拦截器验证请求合法性-
    Springboot如何实现一个自定义的拦截器处理系统发出的请求以及接收到的请求(实现一个用于feign远程调用验证的简单协议)文章目录Springboot如何实现一个自定义的拦截器处理系统发出的请求以及接收到的请求(实现一个用于feign远程调用验证的简单协议)**实现Feign拦截器的意......
  • 11 个接口性能优化技巧(下)【送源码】
     7.锁粒度在某些业务场景中,为了防止多个线程并发修改某个共享数据,造成数据异常。为了解决并发场景下,多个线程同时修改数据,造成数据不一致的情况。通常情况下,我们会:加锁。但如果锁加得不好,导致锁的粒度太粗,也会非常影响接口性能。7.1synchronized在java中提供了synchron......
  • Python——异常捕获,传递及其抛出操作
    01.异常的概念1.程序在运行时,如果python解释器遇到一个错误,会停止程序的执行,并且提示一些错误信息,这就是异常。2.程序停止执行并且提示错误信息这个动作,我们通常称之为:抛出(raise)异常。 程序开发时,很难将所有的特殊情况都处理的面面俱到,通过异常捕获可以针对突发事件做......
  • Springboot 的Bean生命周期五步、七步、十步详解以及框架源码解读生命周期-面试热点-x
    文章目录Springboot的Bean生命周期五步、七步、十步详解以及框架源码解读生命周期为什么要知道Bean的生命周期Bean的生命周期之五步堆栈信息:代码验证执行结果为Bean生命周期之七步执行结果Bean生命周期之十步增加的三步测试代码如下:执行结果:Bean的生命周期总结其他......
  • 手动部署?NONONO,动态上传热部署才是王道!!
    近期开发系统过程中遇到的一个需求,系统给定一个接口,用户可以自定义开发该接口的实现,并将实现打成jar包,上传到系统中。系统完成热部署,并切换该接口的实现。定义简单的接口这里以一个简单的计算器功能为例,接口定义比较简单,直接上代码。public interface Calculator {  ......
  • AI外包团队 Unity3D结合AI教育大模型 开发AI教师 AI外教 AI英语教师 AI课堂案例
    自2022年底ChatGPT引爆全球之后,大模型技术便迎来了一段崭新的快速发展期,由其在GPT4.0发布后,AI与教育领域结合产品研发、已成为教育+AI科技竞争的新高地、未来产业的新赛道、经济发展的新引擎和新产品的诞生地。据不完全统计,目前国内已有包括科大讯飞、百度、阿里、华为、网易在......
  • 进制的转换
    任意进制转化成十进制的公式都是系数基数的权次幂相加系数指的是每一位上对应的数字基数就是几进制对应的数字权从右到左依次是01234……1.二进制转十进制(二进制在代码中前面要加上0b)取值为0~1比如说0b1011转成十进制就是120+1*21+022+1*23=11。那么这里还有一个方法就......
  • Java中的日志管理:SLF4J与Logback
    Java中的日志管理:SLF4J与Logback大家好,我是微赚淘客系统3.0的小编,是个冬天不穿秋裤,天冷也要风度的程序猿!本文将介绍如何在Java中使用SLF4J与Logback进行日志管理,帮助您在项目中实现高效的日志记录和管理。一、SLF4J与Logback简介SLF4J(SimpleLoggingFacadeforJava)是一种简单......