![]()
前言
理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将我们经常会说互联网“三高”，那什么是三高呢？我们常说的三高，高并发、高可用、高性能，这些技术是构建现代互联网应用程序所必需的。对于京东618备战来说，所有的中台系统服务，无疑都是围绕着三高来展开的。而对于京东庞大的客户群体，高并发的要求尤为重要。用户对在线服务的需求和期望不断提高，系统的并发处理能力成为衡量其性能和用户体验的关键指标之一。高并发系统不仅仅是大型互联网企业的专利，对于任何希望在市场中占据一席之地的公司来说，能够处理大量并发请求的能力都是至关重要的。
高并发系统的设计和实现是一个复杂且多层次的过程，涉及到硬件资源的合理利用、系统架构的精心设计、并发控制技术的应用以及性能调优等多个方面。无论是电商平台在大促期间应对突发流量，还是社交媒体在热点事件发生时的流量激增，抑或是金融系统在交易高峰期的平稳运行，都需要一个高效、稳定、可扩展的高并发系统作为支撑。接下来我通过一张思维导图展开我的分享，帮大家梳理一下一个高并发系统所需要考虑的技术点。
单机维度
理解，首先 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 小结
多线程和异步方法是Java开发中两种重要的并发处理技术，它们在提高系统性能和响应能力方面各有优势。多线程通过并行处理任务，充分利用CPU资源，适用于CPU密集型任务和需要并行处理的场景。异步方法通过非阻塞I/O操作和异步回调机制，提高系统的响应能力和资源利用率，适用于I/O密集型任务和事件驱动架构。 多机维度
理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将在多机维度考虑系统的高并发性能，应该是大家最长能够想到的场景了，也是架构师们最热衷讨论的点。
首先是对系统的拆分角度来说，第一个是单体应用的水平扩展问题，就是我们所说的负载均衡集群，换成我们经常听到的一个词：扩容。扩容一般针对负载均衡集群进行水平扩展，用于解决单机无法承载高并发的情况，这也是互联网公司解决高并发场景的最常用手段，就比如每次双十一或者618前夕，我们都会成倍的扩容我们的服务实例。对系统的另一个拆分角度，叫做垂直拆分，也就是我们常见的分布式系统。比如按照领域划分，我们将一个大的单体服务，拆分成不同的子领域系统，然后每个子领域系统单独承担各自的流量，而不会相互影响。还比如说长江的CQRS设计架构，翻译过来是指令查询分离的设计方式，通过查询和指令服务拆分，来讲高并发的查询场景单独拆分出来进行设计。既然采用了分布式的微服务架构，那么分布式系统的一些常见痛点也是高并发要考虑的，比如熔断，降级，限流，超时等设计，这些本身是为了增强分布式系统的鲁棒性，从而简介的增强系统的高并发承载能力。关于微服务架构，在此处不再赘述，有兴趣的同学可以看我的另一篇文章:《【实践篇】教你玩转微服务--基于DDD的微服务架构落地实践之路》（https://developer.jdcloud.com/article/2899?mid=30）
垂直维度
理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将所谓垂直维度，是区分于单机维度和多机维度的，垂直的意思是针对一个业务系统在系统层级的垂直划分，包括业务应用和数据库。要知道，很多高并发场景，不管是写场景还是读场景，当数据库维度出现瓶颈，扩容就不想业务应用服务那么简单了，所以要区分来说。
在存储媒介这块其实高并发是不好设计的。比如关系型数据库MySQL, 在进行扩展要比业务应用复杂不少，涉及到的就是数据库的分库分表逻辑。这块可以参考之前我写过的一篇文章：《分而治之--浅谈分库分表及实践之路》（https://developer.jdcloud.com/article/2963?mid=30）。而对于读场景下的高并发请求，还有一种最常见的处理手段，就是异构存储介质，实现读写分离，最常见的就是MySQL关系型数据库负责写，ES这种文档类数据库负责读。而他的技术难点则在于数据的同步和数据一致性上。唯物辩证法中有一个重要概念，就是一切从实际出发，具体问题具体分析。对于高并发系统的构建，虽然有通用的手段和方法论，但没有统一的落地方案，必须根据具体的业务应用场景进行分析和设计。比如你的系统是高并发读还是高并发写，处理思路也是完全不一样的。当然常见的手段和方法论核心包括两点：缓存和异步。但具体到相应的业务，需要仔细思考缓存逻辑怎么设计，异步流程怎么设计，如何保证数据一致性等等。接下来，我也将通过实战场景，对这一理论进行更为直观的解析。 理论和实战兼得
理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将随着互联网业务的不断发展，选择在网上购物的人群不断增加，这种情况下，会衍生出一些促销活动，类似抢购场景或者热销热卖场景，在高峰时段的下单数量会非常大，也意味着对数据库中畅销商品的库存操作十分频繁，需要频繁查库存和更新库存。这属于高读写场景，比起单独的并发读和并发写来说，业务场景更复杂一些。那么这种高并发为了保证库存数据一致性，一般会在数据库更新时进行加锁操作，以保证系统不会发生超卖情况。我们应该如何应对呢？大家可以根据我之前的思维导图，跟随我的思路，一起来看如何解决当前场景下的高并发问题。5.1 小试牛刀
面对库存扣减的场景，我们第一个考虑到是数据一致性问题，因为超卖会对我们的履约和客户信誉造成影响。所以一般情况下，在数据库更新时进行加锁操作，以保证系统不会发生超卖情况。所以更多方案是提高数据库性能方法，比如增加硬件性能，优化乐观锁，提升锁效率，优化SQL性能等。对于一些大型系统，也衍生出一些基于分片的库存方案，通过分库分表增加并发吞吐量。当然那这样不够，因为MySQL数据库的读写的并发上线能力是有限的，我们还是需要再进一步优化我们的方案。这里就要参考之前我写的那篇文章中的思维导论了，这里常见解决方案就是，引入缓存机制。如下图所示，我们把读请求进行缓存，每次库存校验时，我们引入redis缓存，读请求通过缓存，增加接口性能，然后库存扣减时，在进行缓存同步。
但这种方式存在很大问题：所有请求都会在这里等待锁，获取锁有去扣减库存。在并发量不高的情况下可以使用，但是一旦并发量大了就会有大量请求阻塞在这里，导致请求超时，进而整个系统雪崩；而且会频繁的去访问数据库，大量占用数据库资源，所以在并发高的情况下这种方式不适用。同时这个方案还会存在mysq和redis的数据同步不一致的情况，导致高并发情况下，出现超卖。所以这种方案虽然简单，但是无法满足高并发场景，我们必须得pass。5.2 循序渐进
为此，我们可以进行一次优化，通过架构维度进行调整。在这个方案中，我们将库存操作封装成一个单独模块，这个方案的优化点在于，所有库存的查询和扣减都围绕redis进行。当发生库存扣减操作时，会直接更新redis，同时采用异步流程，更新MySQL数据库。这样以来，我们的性能会比直接访问MySQL数据库高效不少，并发能力会有不少提升。流程如下：
![]()
但这个方案依然有缺陷，它的点在于redis的单点性能问题。该方案的最大并发性能取决于redis的单点处理能力。而如果想要进一步提升并发能力，该方案不具备水平扩展能力。那么，这个方案，依然不是我们最优的选择。5.3 大显身手
那么接下来，我们需要考虑的是如何可以实现我们业务系统并发能力的水平扩展能力。当然这里也不是凭空来想，我们可以思考一下，业内成熟的一些中间件是如何实现高并发的，这里我们可以两个我们常见的框架：kafka和elasticsearch。上述我们常见的两个中间件框架，都以可以水平能力扩展著称。那么仔细思考一下他们的技术架构不难发现，他们的核心其实都是采用了一种所谓的分片实现的。那么问题来了，我们的库存扣减，能不能实现分片呢？或者换一个思路思考这个问题：我们的库存逻辑是否可以转化为分布式库存进行存储和扩展呢？有了以上的思路，我们就可以开始构建我们的架构方案了。接下来，我先把架构图贴出来：
在这个架构方案中，是以Redis缓存为实现基础，结合Mysql数据存储，通过一套控制机制，保证库存的分布式管理。在该方案中，有一些特定的业务模块单元需要说明。熟悉kafka的人对partition一定不陌生。在本架构方案之中，该业务架构中的partition的概念是一组基于redis来实现的库存分片，分别存储一部分库存大小。在一个partition中，会存有一定量的预占库存量，当有请求服务进行库存扣减时，只需要选择其中一个partition即可，这样以来，就可以减轻单节点的压力，同时可以基于redis集群的可扩展性，实现partition的水平扩展。分布式系统常见的一个问题就是数据倾斜问题，因为严重的数据倾斜，会让我们分布式方案瞬间瓦解，导致单点承担高并发。那么该方案下的数据倾斜问题如何解决呢？最终，我想到的解决方案类似养宠物狗时买的那种定时投喂仪器，每天通过定时定量投喂，来保证宠物狗不会被饿到或者吃撑。如果最初把所有库存全部平均到每个partition中，当有多个大库存扣减打到一个partition上时，会造成该partition上出现库存被消耗光，而失去后续提供库存扣减能力。为了解决这个问题，我在partition中采取的是动态库存注入和子域隔离的方案。具体方案如下图：
每个partition会有两个子域，调度器中会记录每个partition当前激活的子域，每次库存扣减，会扣减激活的子域中的库存值。而当激活的子域库存值低于设定阈值是，会切换子域，冷却当前子域，激活另一个子域。被冷却的子域会触发任务触发器，实现预占库存的数据同步。子域中会存储一定额度的库存值，不会存储很大的量，这样就可以保证动态的预占库存实现，从而解决库存倾斜的问题。当然为了更好的管理partition，我们需要单独开发一个partition调度器模块，来负责管理管理众多partition资源，那么这个调度器的具体功能包括：1.调度器中有一个注册表，会记录 Partition的key值，外部服务获取partition key是需要通过调度器获取，调度器会记录每个partition的库存余量和partition和子域信息。
2.当partition无法再获取预占库存，且库存耗尽时，调度器会从注册表中摘除该partition信息。
3. 调度器可以采用随机或者轮训的方式获取partition，同时每次也会校验partition剩余库存是否满足业务扣减数量，如果剩余库存小于业务扣减数量，将会跳过该partition节点。第二个核心模块就是更新库存管理了，这块你可以理解为异步流程机制，通过异步化操作，来减轻系统的高并发对数据库的冲击。更新库存会有一个明细表，记录每个partition库存扣减信息，明细表会有一个同步状态，有两种情况可以出发库存同步MQ消息：第一．当每个partition中的明细数据条数超过设定阈值，会自动触发一次MQ消息。
第二．每间隔额定设定时间(默认设置1秒)， 会触发一次当前时间段内每个partition产生的库存扣减明细信息，然后发送一次MQ消息。两中触发方案相互独立，互不影响，通过同步状态和明细ID实现幂等。接下来就是关于库存的底层数据结构设计了。这里会引入一个在电商行业很共识的概念：预占库存。在库存领域层中，库存分为预占库存和库存两个模块，这里面的库存关系实例如下：假设当前商品的库存值为10000件，当前partition触发一次预占库存任务，领取400件， 然后假设此时收到MQ库存消费更新消息，更新30件。随后partition又触发一次预占库存任务，零陵区了100件。库存变化如下图所示：
![]()
每次预占库存任务触发，会从预设库存池中扣减，如果预占库存池清空，则partition就无法在获取预占库存，调度器会将它从注册表中摘除。而每次MQ更新库存消息，会更新实际库存量，同时对预占库存和扣减库存值进行修改，这个操作具有事务性。通过这次的案例分析，我们其实是通过方法论结合实际业务场景的方式出发，设计了我们的系统架构。剥离业务场景，其实本质就是通过缓存和异步流程来实现系统的高并发，同时让系统具备拥有水平扩展的能力。但这个方法论在与实际业务结合时，还是会有很多很多需要思考和细化的点，比如分布式思想的使用，比如预占库存的逻辑设计等等。
总结
理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将再回到文章开篇的那张思维导图，它表达的是当你遇到一个高并发场景时，你需要经历的思考过程。但做好以上这些也并不能说明你的系统一定能承载高并发了。还是那句话，具体问题具体分析。构建高并发系统的核心在于如何高效地处理大量同时发生的请求，保证系统的稳定性、性能和可扩展性。这里涉及到合理的业务架构设计，以及高效的并发编程模型。除此之外，也要考虑到数据一致性和事务管理，配合合理的监控和自动化运维，保证及时出现系统资源紧张和崩溃时，可以快速反应和解决问题。
底层能力：维护用户基础数据、行为数据建模、用户画像分析、精准营销策略的制定▪功能支撑：会员成长体系、等级计算策略、权益体系、营销底层能力支持
▪用户活跃：会员关怀、用户触达、活跃活动、业务线交叉获客、拉新促活
