高并发架构设计模板

目录

 一、高并发简介 

二、高并发框架设计经验

        2.1 基础设施层

        2.2 服务端架构层

        架构分层

        业务分割

        分布式

        数据集群

        缓存设计

        消息队列流量削峰

        服务治理

         2.3 服务应用层

---

 一、高并发简介 

        高并发（High Concurrency）是指特定时间段内系统能够同时处理大量请求或链接的能力，并且能够迅速给出响应。比如秒杀场景、人气超高的网红或明星进行直播时，直播间一下涌入大量的观众。

        高并发系统的设计目标是确保用户访问量激增的情况下，系统仍能保持稳定运行，避免服务延迟或中断。衡量高并发系统性能的指标主要包括：

1. 响应时间：系统对单一请求做出反应的所需的时间。
2. 吞吐量：系统在单位时间内能够处理的请求数。
3. 每秒查询数：指QPS，衡量系统每秒种处理查询请求的数量。
4. 并发用户数：系统能够同时支撑正常使用系统功能的用户数量。

        现在的互联网产品都要考虑高并发，尤其是 C 端业务，一般情况下，用户的访问量都是很大的。下面就来谈谈高并发架构设计的经验。

二、高并发框架设计经验

        高并发框架设计主要从三大层面建设和分析。

• 基础设施层
• 服务端架构层
• 服务应用层

        下面分别展开介绍下这三层的含义。

        2.1 基础设施层

        基础设施层一般包含了服务器、IDC或多云部署、负载均衡、网络设备等。目前部署服务都通过容器的方式，而容器的底层能力建立在K8s基础之上，服务本身的部署管理已经有了成熟的设施帮我们实现，具体部署服务时可以采用：

1. 多IDC部署，比如服务同时部署在北京和上海。
2. 多云部署，多云部署可以让企业跨多个云提供商分配工作负载，利用各云平台的负载均衡服务，可以更灵活地管理和分散高并发流量。如果某个云平台遇到性能瓶颈或故障，可以迅速将流量转移到其他健康的云环境，确保服务连续性和高可用性。不同的云提供厂商还提供了丰富的弹性计算资源，可以根据流量进行动态扩缩容，以应对高并发。
3. CDN 加速，通过在多个地理位置部署服务，利用 CDN 和其他加速技术，减少网络延迟，提升用户体验。
4. 负载均衡，使用高性能的负载均衡器(如Nginx)来分配进入的流量至多个后端服务器，确保没有单点过载，提高系统整体的处理能力。
5. 监控预警，建立全面的监控体系，包括性能监控、日志分析、异常报警等，及时发现问题并处理。

        2.2 服务端架构层

        基础设施层由运维团队维护和提供保障，作为开发人员可能不必过多的关注基础设施层，公司内都有统一的标准。但是服务端架构层确实我们需要重点关注的。

        架构分层

        首先对服务进行拆分，拆分出核心链路上的服务作为底层服务，然后再抽象出一个应用层对外提供服务。

        将系统在横向维度上切分成几个部分，每一层的功能职责要足够单一，然后通过上层对下层的依赖和调度组成一个完整的系统。

        将系统划分成多层后，每层专注于特定的功能，是系统结构清晰易于理解，可以进行相对独立的测试。降低耦合度增加扩展性，而且可以进行隔离部署，提高系统的稳定性，保证了服务的性能。

        业务分割

        在纵向方面对业务进行切分，将一块相对复杂的业务分割成不同的模块单元，对应的是模块的划分，通过合理的模块划分，使得每个模块都能可以满足 高内聚低耦合 的设计要求，这样不同的模块可以分布式部署，也能提高并发处理能力和功能扩展。

        分布式

        将分割后的业务服务进行分布式部署，独立的缓存、独立的数据库、独立的应用服务器等。这样可以针对性的进行部署和扩展，当有突发流量时，可以结合云服务的动态扩容的特点，对服务进行扩容，以提高系统应对高并发的能力。

        数据集群

        可以针对数据层单独做一些处理，比如主从分离、读写分离、分库分表，或者采用分布式数据库等等。

        互联网系统大多都是读多写少，因此读写分离可以帮助主库抗量。一般我们都是一主多从的架构，可以抗量，也可以保证数据不丢。

        现在比较流行的分布式数据库 NewSQL 可以替代分库分表，如 TiDB，将数据保存在多台 TiKV 中进行统一管理。

        缓存设计

        缓存的最大作用是可以提升系统性能，保护后端存储不被大流量打垮，增加系统的伸缩性。缓存的设计，需要分多个思路并行。

        首先要考虑的是，必须在数据库之上，增加一层分布式缓存，比如Redis。这里需要考虑一下缓存和数据库一致性的问题。

        其次需要考虑的是多级缓存架构。分几级缓存设计，同时设计热点缓存架构。在分布式缓存之上，还可以加一个本地缓存，来缓存最热的数据；采用多个分布式缓存来搭建多级缓存。

        消息队列流量削峰

        针对流量突峰，仅仅有缓存来抗量可能还不够，还需要使用消息队列来削峰。使用消息队列后，可以将同步处理的请求改为 通过消费 MQ 消息来异步消费，这样可以大大减少系统处理的压力，增加系统的并发量。常用的消息队列比如 kafka。

        服务治理

        在微服务中要对服务进行超时、限流、熔断、降级等处理，避免出现雪崩效应，导致整个系统不可用。

         2.3 服务应用层

        对于单机的处理，如果想提高并发处理能力，可以采用多线程，现在的处理器都是多核处理器，采用多线程可以充分利用多核的优势，提高处理能力。对于可以异步的地方进行异步处理，比如采用线程池等方式，避免让某一个请求长时间等待，提交请求后即可返回，实现快速处理，提高系统吞吐量。

        对一些热点数据进行预热，比如秒杀场景，将商品信息等热点数据提前放入缓存中做好准备，避免从DB 查询影响整体的性能。

        你对高并发处理还有什么经验？欢迎留言讨论。

往期经典推荐

手把手教你实现服务高可用性-CSDN博客

TiDB高手进阶：揭秘自增ID热点现象与高级调优技巧-CSDN博客

Maven核心概念全解析-CSDN博客

如何熟悉一个陌生的业务系统-CSDN博客

微服务拆分：打造高性能、高扩展的未来架构-CSDN博客