高并发系统的艺术:如何在流量洪峰中游刃有余
01 前言
理解,首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板,当获取到模板后进行模板加载,加载阶段会将产物转换为视图树的结构,转换完成后将通过表达式引擎解析表达式并取得正确的值,通过事件解析引擎解析用户自定义事件并完成事件的绑定,完成解析赋值以及事件绑定后进行视图的渲染,最终将我们经常会说互联网“三高”,那什么是三高呢?我们常说的三高,高并发、高可用、高性能,这些技术是构建现代互联网应用程序所必需的。对于京东618备战来说,所有的中台系统服务,无疑都是围绕着三高来展开的。而对于京东庞大的客户群体,高并发的要求尤为重要。用户对在线服务的需求和期望不断提高,系统的并发处理能力成为衡量其性能和用户体验的关键指标之一。高并发系统不仅仅是大型互联网企业的专利,对于任何希望在市场中占据一席之地的公司来说,能够处理大量并发请求的能力都是至关重要的。
高并发系统的设计和实现是一个复杂且多层次的过程,涉及到硬件资源的合理利用、系统架构的精心设计、并发控制技术的应用以及性能调优等多个方面。无论是电商平台在大促期间应对突发流量,还是社交媒体在热点事件发生时的流量激增,抑或是金融系统在交易高峰期的平稳运行,都需要一个高效、稳定、可扩展的高并发系统作为支撑。接下来我通过一张思维导图展开我的分享,帮大家梳理一下一个高并发系统所需要考虑的技术点。
02 单机维度
理解,首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板,当获取到模板后进行模板加载,加载阶段会将产物转换为视图树的结构,转换完成后将通过表达式引擎解析表达式并取得正确的值,通过事件解析引擎解析用户自定义事件并完成事件的绑定,完成解析赋值以及事件绑定后进行视图的渲染,最终将
01
前言
理解,首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板,当获取到模板后进行模板加载,加载阶段会将产物转换为视图树的结构,转换完成后将通过表达式引擎解析表达式并取得正确的值,通过事件解析引擎解析用户自定义事件并完成事件的绑定,完成解析赋值以及事件绑定后进行视图的渲染,最终将
我们经常会说互联网“三高”,那什么是三高呢?我们常说的三高,高并发、高可用、高性能,这些技术是构建现代互联网应用程序所必需的。对于京东618备战来说,所有的中台系统服务,无疑都是围绕着三高来展开的。而对于京东庞大的客户群体,高并发的要求尤为重要。用户对在线服务的需求和期望不断提高,系统的并发处理能力成为衡量其性能和用户体验的关键指标之一。高并发系统不仅仅是大型互联网企业的专利,对于任何希望在市场中占据一席之地的公司来说,能够处理大量并发请求的能力都是至关重要的。
高并发系统的设计和实现是一个复杂且多层次的过程,涉及到硬件资源的合理利用、系统架构的精心设计、并发控制技术的应用以及性能调优等多个方面。无论是电商平台在大促期间应对突发流量,还是社交媒体在热点事件发生时的流量激增,抑或是金融系统在交易高峰期的平稳运行,都需要一个高效、稳定、可扩展的高并发系统作为支撑。接下来我通过一张思维导图展开我的分享,帮大家梳理一下一个高并发系统所需要考虑的技术点。
02
单机维度
理解,首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板,当获取到模板后进行模板加载,加载阶段会将产物转换为视图树的结构,转换完成后将通过表达式引擎解析表达式并取得正确的值,通过事件解析引擎解析用户自定义事件并完成事件的绑定,完成解析赋值以及事件绑定后进行视图的渲染,最终将
在单机维度上, 我们一般分为硬件维度和代码维度两个方向考虑。硬件维度比较简单,就是提升单机的硬件性能和网络带宽。而代码维度,则是在高并发系统架构设计时,最容易被大家忽视的,尤其是现在大量的互联网架构师脱离一线研发并进化成PPT架构师的今天,单机维度基本不在考量范围。
但不积跬步无以至千里,有的时候单机接口的的性能优化,会带来很高的经济成本价值。在代码维度,我这里重点介绍一种情况,关于多线程和异步方法。
2.1 多线程和异步方法的误区
关于多线程和异步方法的概念,我在面试候选人的时候,发现很多人对此都有误区。在此,我先详细的一下他俩的概念:
多线程:多线程是指在一个进程中可以同时运行多个线程,每个线程执行不同的任务。Java通过java.lang.Thread类和java.util.concurrent包提供了多线程编程的支持。多线程的主要目的是为了充分利用CPU资源,提高程序的执行效率。
异步方法:异步方法是指在调用某个方法时,不需要等待该方法执行完成即可继续执行后续代码。Java通过CompletableFuture和异步回调机制提供了异步编程的支持。异步方法的主要目的是为了提高系统的响应能力和资源利用率。
2.2 多线程能够解决高并发场景么
当大家了解了多线程和异步方法的概念后,那么我们就可以认真思考一下,多线程一定能提升系统的并发能力么?
我的结论是:多线程可以提升不分服务的并发能力,但并不能显著提高性能。
首先我们先了解,Tomcat的Servlet机制是基于多线程实现的,而如果你在单次请求中在此开辟线程池进行多线程处理,在一定的并发情况下,你可能只是改善了单次请求的TP99,但无法有效提升系统的并发能力。因为多线程的性能提升与CPU核心数密切相关。如果系统只有一个CPU核心,那么多个线程只能在该核心上轮流执行,无法实现真正的并行处理。而我们的宿主机一般也就是8C或者16C,在面单机上千的QPS请求时,多线程只会增加CPU上下文切换的负担。
举个简单并且常见的例子,批量下单接口。我们常见的做法就是在批量下单接口中开辟线程池,然后建个多个下单在线程池中并行处理。这样做的结果是,在请求量低的情况下,效果还是可以的,单次请求的QPS也会很低,但如果单机面临每秒上千次的下单请求,这种实现方式就会出现问题。最直观的观察,可以通过TP99的监控曲线发现,就是请求量跟TP99呈现严重的正相关性。
而真正有效的提升下单接口的并发能力,是通过异步方式实现。但异步方式又会增加系统的设计复杂度,比如下单失败,回调设计和数据一致性设计等等,也在考量范围之内,这里就不详细展开说明。
2.3 小结
03
多机维度
理解,首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板,当获取到模板后进行模板加载,加载阶段会将产物转换为视图树的结构,转换完成后将通过表达式引擎解析表达式并取得正确的值,通过事件解析引擎解析用户自定义事件并完成事件的绑定,完成解析赋值以及事件绑定后进行视图的渲染,最终将
对系统的另一个拆分角度,叫做垂直拆分,也就是我们常见的分布式系统。比如按照领域划分,我们将一个大的单体服务,拆分成不同的子领域系统,然后每个子领域系统单独承担各自的流量,而不会相互影响。还比如说长江的CQRS设计架构,翻译过来是指令查询分离的设计方式,通过查询和指令服务拆分,来讲高并发的查询场景单独拆分出来进行设计。既然采用了分布式的微服务架构,那么分布式系统的一些常见痛点也是高并发要考虑的,比如熔断,降级,限流,超时等设计,这些本身是为了增强分布式系统的鲁棒性,从而简介的增强系统的高并发承载能力。关于微服务架构,在此处不再赘述,有兴趣的同学可以看我的另一篇文章:《【实践篇】教你玩转微服务--基于DDD的微服务架构落地实践之路》(https://developer.jdcloud.com/article/2899?mid=30)
04 垂直维度
理解,首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板,当获取到模板后进行模板加载,加载阶段会将产物转换为视图树的结构,转换完成后将通过表达式引擎解析表达式并取得正确的值,通过事件解析引擎解析用户自定义事件并完成事件的绑定,完成解析赋值以及事件绑定后进行视图的渲染,最终将
所谓垂直维度,是区分于单机维度和多机维度的,垂直的意思是针对一个业务系统在系统层级的垂直划分,包括业务应用和数据库。要知道,很多高并发场景,不管是写场景还是读场景,当数据库维度出现瓶颈,扩容就不想业务应用服务那么简单了,所以要区分来说。
05
理论和实战兼得
理解,首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板,当获取到模板后进行模板加载,加载阶段会将产物转换为视图树的结构,转换完成后将通过表达式引擎解析表达式并取得正确的值,通过事件解析引擎解析用户自定义事件并完成事件的绑定,完成解析赋值以及事件绑定后进行视图的渲染,最终将
5.1 小试牛刀
如下图所示,我们把读请求进行缓存,每次库存校验时,我们引入redis缓存,读请求通过缓存,增加接口性能,然后库存扣减时,在进行缓存同步。
5.2 循序渐进
流程如下:
5.3 大显身手
有了以上的思路,我们就可以开始构建我们的架构方案了。接下来,我先把架构图贴出来:
如果最初把所有库存全部平均到每个partition中,当有多个大库存扣减打到一个partition上时,会造成该partition上出现库存被消耗光,而失去后续提供库存扣减能力。为了解决这个问题,我在partition中采取的是动态库存注入和子域隔离的方案。具体方案如下图:
1.调度器中有一个注册表,会记录 Partition的key值,外部服务获取partition key是需要通过调度器获取,调度器会记录每个partition的库存余量和partition和子域信息。
2.当partition无法再获取预占库存,且库存耗尽时,调度器会从注册表中摘除该partition信息。
第一.当每个partition中的明细数据条数超过设定阈值,会自动触发一次MQ消息。
假设当前商品的库存值为10000件,当前partition触发一次预占库存任务,领取400件, 然后假设此时收到MQ库存消费更新消息,更新30件。随后partition又触发一次预占库存任务,零陵区了100件。库存变化如下图所示:
通过这次的案例分析,我们其实是通过方法论结合实际业务场景的方式出发,设计了我们的系统架构。剥离业务场景,其实本质就是通过缓存和异步流程来实现系统的高并发,同时让系统具备拥有水平扩展的能力。但这个方法论在与实际业务结合时,还是会有很多很多需要思考和细化的点,比如分布式思想的使用,比如预占库存的逻辑设计等等。
06
总结
理解,首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板,当获取到模板后进行模板加载,加载阶段会将产物转换为视图树的结构,转换完成后将通过表达式引擎解析表达式并取得正确的值,通过事件解析引擎解析用户自定义事件并完成事件的绑定,完成解析赋值以及事件绑定后进行视图的渲染,最终将
除此之外,也要考虑到数据一致性和事务管理,配合合理的监控和自动化运维,保证及时出现系统资源紧张和崩溃时,可以快速反应和解决问题。