本文转载理解高并发：原理、场景与解决方案 - 知乎
在互联网行业，高并发已成为衡量系统性能的关键指标。无论是电商平台的促销活动、在线教育平台的直播授课，还是IOT物联网的状态同步与远控，高并发场景无处不在。本文来剖析高并发，理解其原理、常见场景以及有效的解决方案。
一、高并发原理：性能指标解析
（一）响应时间（RT）
响应时间（RT）指的是系统对请求做出响应所需要的时长。它直接影响用户体验，比如在电商 APP 中，从点击 “购买” 按钮到看到订单提交成功的提示，这之间的等待时间就是响应时间。
在高并发环境下，RT 越短，用户体验就越好；反之，若 RT 过长，用户可能会失去耐心，导致业务流失。
（二）每秒查询率（QPS）与每秒事务数（TPS）
每秒查询率（QPS）代表系统每秒能够处理的查询数量。
单线程 QPS 的计算公式为：QPS = 1000ms / RT 。在系统线程数未达到最佳值前，QPS 会随着线程数的增加而线性增长，但实际情况中，由于系统资源限制、网络延迟等因素，这种增长很难达到理想的线性状态。
每秒事务数（TPS）和 QPS 紧密相关，一个事务可能包含多个查询操作。因此，TPS 是 QPS 的倍数，倍数范围在 1 到 n 之间。以电商下单为例，一个下单事务可能涉及查询商品库存、验证用户支付信息、更新订单状态等多个查询，此时 TPS 就会大于 QPS。
（三）并发数与吞吐量
并发数是指系统能够同时处理的请求数量。可以将其想象成高速公路的车道数量，车道越多，同时能通过的车辆（请求）也就越多。
系统的吞吐量则与 CPU 消耗、外部接口调用、IO 操作等因素密切相关。如果单个请求对 CPU 的消耗较大，或者外部接口、IO 速度较慢，系统的吞吐能力就会降低；反之，吞吐能力则会提高。
（四）最佳线程数
每个系统都存在一个最佳线程数，这个数值是基于具体实例评估得出的，计算公式为：((线程等待时间 + 线程 cpu 时间) / 线程 cpu 时间) * cpu 数量 。
当系统线程数达到最佳值时，系统性能处于最优状态，QPS 达到峰值。若继续增加线程数，QPS 不会提升，反而响应时间会变长；若持续增加线程数，QPS 甚至会下降。这是因为超过最佳线程数后，会引发资源竞争，导致系统性能下降，瓶颈资源可能是 CPU、内存、锁资源或 IO 资源等。
二、高并发常见场景
（一）业务特性引发的高并发
许多业务场景本身就具有高并发的特性，例如电商平台的秒杀、抢红包活动。在这些活动中，大量用户会在同一时刻发起请求，瞬间产生海量的并发访问。以 “双 11” 零点的抢购活动为例，无数用户同时点击购买按钮，对电商系统的承载能力是巨大的考验。
（二）用户异常操作导致的高并发
当系统出现异常时，部分用户可能会因为焦急而频繁进行操作，如连续点击按钮、多次刷新页面等。这种行为会导致请求量进一步增加，形成恶性循环。例如，当页面加载缓慢时，用户可能会不断刷新，导致更多的请求涌入服务器，加重服务器的负担。
（三）业务接口异常引发的高并发
业务接口异常，如响应时间变慢，会使可用连接数被占满。后续的请求无法及时得到处理，从而导致更多的请求堆积，进一步加剧系统的拥堵。比如，某个商品详情页的接口出现故障，响应时间延长，大量用户的请求被阻塞，最终可能导致整个商品展示系统瘫痪。
（四）恶意攻击引发的高并发
大量的 CC（Challenge Collapsar，挑战黑洞）或 DDOS（Distributed Denial of Service，分布式拒绝服务）攻击是高并发场景的常见诱因。攻击者通过发送海量请求，耗尽系统资源，使正常用户无法访问服务。例如，DDOS 攻击会利用大量僵尸网络向目标服务器发送请求，瞬间打满服务器带宽，使其无法正常提供服务。
三、高并发的解决方案
（一）架构设计层面
- 采用微服务架构，将大型系统拆分成多个独立部署的微服务，每个微服务可以根据自身的负载情况进行水平扩展。
- 无状态设计则方便 K8S 进行弹性伸缩，当系统负载增加时，能够快速增加实例来处理请求；负载降低时，又可以减少实例，提高资源利用率。
2. K8S 中的 Service 与负载均衡：
在 K8S 中，Service 是将一组 Pod 暴露给外界访问的重要机制。由于 Pod 的生命周期短暂且 ID 不固定，Service 承担起了负载均衡的重任。它有多种暴露服务的方式，
- 如 ClusterIP 适用于集群内部通信，通常搭配 Ingress 对外提供服务；
- NodePort 通过在每个选定 Node 的相同端口上公开 Service，可从集群外部访问；
- LoadBalancer 借助云厂商的支持，生成高可用的 IP 地址用于访问；
- ExternalName 则通过返回 CNAME 记录公开 Service。
2.1 ingress controller实现Service 前端的负载均衡
ingress controller是K8S的一个控制器，用于管理和配置入站网络流量的路由规则。它与K8S的ingress资源结合使用，为集群中的服务提供外部访问。
- 向API Service 用post方式提交一个新的service定义
- service得到一个cluster IP，并保存在集群数据库
- 在集群范围内传播service 配置
- 集群DNS服务得知该service的创建，据此创建必要的DNS记录，实现endpoint和Cluster IP映射。
- 完成创建后，其它服务pod就可以基于endpoint访问该service
2.2 Kube - proxy实现Service 内的负载均衡
Kube - proxy 负责维护节点上的网络规则，它的作用是使发往 Service 的流量（通过ClusterIP和端口）负载均衡到正确的后端Pod。Kube - proxy通过管理Endpoints和通过Endpoints Controller实现Service负载均衡功能。
- Endpoints标识一个Service对应所有Pod副本的访问地址，Endpoints Controller负责生成和维护所有Endpoints对象的控制器。
- Endpoints Controller负责监听Service和对应的Pod副本的变化，如果监测到Service被删除，则删除该Service同名的Endpoints对象。如果监测到新的Service被删除或被修改，则根据Servic信息获取相关的Pod列表，然后创建或者更新Service对应的Endppints对象。如果监测到Pod事件，则更新它对应的Service的Endpoints对象(增加、删除或者修改对应的Endpoint条目)。
Kube - proxy 支持 iptables 和 IPVS 两种负载均衡模式，与 iptables 模式相比，IPVS 模式重定向通信延迟更短，同步代理规则时性能更好。Endpoints 标识了 Service 对应所有 Pod 副本的访问地址，Endpoints Controller 负责生成和维护这些 Endpoints 对象，确保服务的正常访问。
在服务前端使用 Nginx 或 OpenResty 进行反向代理，可以对流量进行分发和初步过滤，减轻后端服务的压力。同时，还能在反向代理层进行限流、熔断、鉴权等操作，保障系统的稳定性和安全性。
4. 使用 CDN 加速：
CDN 如今不仅能缓存静态资源，如 HTML、CSS、JS、VIDEO 等，还能缓存动态接口内容。它通过将内容缓存到离用户更近的节点，提高页面加载速度，增加内容冗余以保障服务可用性，节省源站带宽，并能有效抵御 DDOS 攻击。
（二）业务实现层面
- 数据库优化：在数据库方面，减少全表搜索，合理添加索引，使用排序功能，对热点查询数据添加 redis 缓存，提高数据查询效率。同时，根据系统负载调整数据库的最大连接数，避免连接数过多或过少导致的性能问题。
- 请求异步化：通过Kafka/MQ消息队列等方式，将业务请求从同步改为异步，从而实现削峰的作用。
- 业务请求分流：根据业务流量优化微服务设计，避免所有的流量都打到同一个微服务来
- 服务器配置调整：根据实际业务需求，对服务器配置进行优化。例如，对于 1 核 2G 内存的服务器，线程数经验值为 200；4 核 8G 内存的服务器，线程数经验值为 800。如果业务量持续增长，可以考虑升级服务器配置，如更换更好的 CPU、增加内存或扩大网络带宽。
高并发是互联网技术领域的一个重要课题，理解其原理、识别常见场景并掌握有效的解决方案，对于构建稳定、高效的系统至关重要，希望通过本文整理，能更加从容不迫面对高并发挑战。
发表评论