济南做网站公司有哪些,阳朔到桂林高铁,开源网站 做镜像 如何做,在线公司网站查询1. 如果系统的 QPS 突然提升 10 倍该怎么设计#xff1f;
1.1 硬件的扩展微服务的拆分
如果所有的业务包括交易系统、会员信息、库存、商品等等都夹杂在一起#xff0c;当流量一旦起来之后#xff0c;单体架构的问题就暴露出来了#xff0c;机器挂了所有的业务就全部无法…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 远程调用验证协议
