当前位置：首页 > news >正文

服务端⾼并发分布式结构演进之路

news 2025/8/4 6:21:56

🍑个人主页：Jupiter. 🚀 所属专栏：Redis 欢迎大家点赞收藏评论😊

在这里插入图片描述

`1. 相关基本概念`

1.1 应⽤（Application）/ 系统（System）

应用是为实现特定任务或业务目标而设计的软件系统，通过单机、客户端-服务器或分布式架构等技术形态，直接向用户或业务场景提供可感知的功能价值（如计算、交易等）。也可以理解为是为了完成⼀整套服务的⼀个程序或者⼀组相互配合的程序群。⽣活例⼦类⽐：为了完成⼀项任务，⽽搭建的由⼀个⼈或者⼀群相互配的⼈组成的团队。

1.2 模块（Module）/ 组件（Component）

当应⽤较复杂时，为了分离职责，将其中具有清晰职责的、内聚性强的部分，抽象出概念，便于理解。⽣活例⼦类⽐：军队中为了进⾏某据点的攻克，将⼈员分为突击⼩组、爆破⼩组、掩护⼩组、通信⼩组等。

1.3 分布式（Distributed）

系统中的多个模块被部署于不同服务器之上，即可以将该系统称为 分布式系统 。如 Web 服务器与数据库分别⼯作在不同的服务器上，或者多台 Web 服务器被分别部署在不同服务器上。跨主机之间的模块之间的通信基本要借助⽹络⽀撑完成。

1.4 集群（Cluster）

部署于多台服务器上的、为了实现特定⽬标的⼀个/组特定的组件，整个整体被称为集群。
⽐如多个 MySQL ⼯作在不同服务器上，共同提供数据库服务⽬标，可以被称为⼀组数据库集群。
分布式 vs 集群 。通常不⽤太严格区分两者的细微概念，细究的话，分布式强调的是物理形态，即⼯作在不同服务器上并且通过⽹络通信配合完成任务；⽽集群更在意逻辑形态，即是否为了完成特定服务⽬标。

1.5 主（Master）/ 从（Slave）

集群中，通常有⼀个程序需要承担更多的职责，被称为主；其他承担附属职责的被称为从。⽐如MySQL 集群中，只有其中⼀台服务器上数据库允许进⾏数据的写⼊（增/删/改），其他数据库的数据修改全部要从这台数据库同步⽽来，则把那台数据库称为主库，其他数据库称为从库。

1.6 中间件（Middleware）

⼀类提供不同应⽤程序 ⽤于相互通信 的软件，即处于不同技术、⼯具和数据库之间的桥梁。⽣活例⼦类⽐：⼀家饭店开始时，会每天去市场挑选买菜，但随着饭店业务量变⼤，成⽴⼀个采购部，由采购部专职于采买业务，称为厨房和菜市场之间的桥梁。

1.7 评价指标（Metric）

可⽤性（Availability）
- 考察单位时间段内，系统可以正常提供服务的概率/期望。例如：年化系统可⽤性 = 系统正常提供服务时⻓ / ⼀年总时⻓。这⾥暗含着⼀个指标，即如何评价系统提供⽆法是否正常，我们就不深⼊了。平时我们常说的 4 个 9 即系统可以提供 99.99% 的可⽤性，5 个 9 是 99.999% 的可⽤性，以此类推。
响应时⻓（Response Time RT）
- 指⽤⼾完成输⼊到系统给出⽤⼾反应的时⻓。通常我们需要衡量的是最⻓响应时⻓、平均响应时⻓和中位数响应时⻓。这个指标原则上是越⼩越好，但很多情况下由于实现的限制，需要根据实际情况具体判断。
吞吐（Throughput）vs 并发（Concurrent）
- 吞吐考察单位时间段内，系统可以成功处理的请求的数量。并发 指系统同⼀时刻⽀持的请求最⾼量。例如⼀条辆⻋道⾼速公路，⼀分钟可以通过 20 辆⻋，则并发是 20，⼀分钟的吞吐量是 20。

`2. 架构演进`

`2.1单机架构`

单机架构（Monolithic Architecture）是指将一个完整的软件系统的所有功能模块、组件和服务集中部署在单一物理或虚拟设备（如一台服务器、一台个人电脑）上运行的架构模式。在前期⽤⼾访问量很少，没有对我们的性能、安全等提出很⾼的要求，⽽且系统架构简单，⽆需专业的运维团队，所以选择单机架构是合适的。
在这里插入图片描述

`2.2应⽤服务集群架构`

当一个软件的用户量增很大时，单台应⽤服务器已经⽆法满⾜需求了。我们的单机应⽤服务器⾸先遇到了瓶颈，摆在我们技术团队⾯前的有两种⽅案：

垂直扩展 / 纵向扩展 Scale Up。通过购买性能更优、价格更⾼的应⽤服务器来应对更多的流量。这种⽅案的优势在于完全不需要对系统软件做任何的调整；但劣势也很明显：硬件性能和价格的增⻓关系是⾮线性的，意味着选择性能 2 倍的硬件可能需要花费超过 4 倍的价格，其次硬件性能提升是有明显上限的。
⽔平扩展 / 横向扩展 Scale Out。通过调整软件架构，增加应⽤层硬件，将⽤⼾流量分担到不同的应⽤层服务器上，来提升系统的承载能⼒。这种⽅案的优势在于成本相对较低，并且提升的上限空间也很⼤。但劣势是带给系统更多的复杂性，需要技术团队有更丰富的经验。

⽔平扩展的⽅案，来解决该问题，但这需要引⼊⼀个新的组件⸺负载均衡：为了解决⽤⼾流量向哪台应⽤服务器分发的问题，需要⼀个专⻔的系统组件做流量分发。实际中负载均衡不仅仅指的是⼯作在应⽤层的，甚⾄可能是其他的⽹络层之中。同时流量调度算法也有很多种，这⾥简单介绍⼏种较为常⻅的：

Round-Robin 轮询算法。即⾮常公平地将请求依次分给不同的应⽤服务器。
Weight-Round-Robin 轮询算法。为不同的服务器（⽐如性能不同）赋予不同的权重（weight），能者多劳。
⼀致哈希散列算法。通过计算⽤⼾的特征值（⽐如 IP 地址）得到哈希值，根据哈希结果做分发，优点是确保来⾃相同⽤⼾的请求总是被分给指定的服务器。

应用服务集群架构是指将 多个独立服务器（节点） 通过网络连接，共同运行相同的应用服务副本，通过负载均衡、故障转移和并行处理等技术，实现系统高可用性、高性能与可扩展性的架构模式。其核心在于通过多节点协同工作，突破单机架构的性能瓶颈，同时保障服务连续性。

在这里插入图片描述

`2.3 读写分离 / 主从分离架构`

把⽤⼾的请求通过负载均衡分发到不同的应⽤服务器之后，可以并⾏处理了，并且可以随着业务的增⻓，可以动态扩张服务器的数量来缓解压⼒。
但是现在的架构⾥，⽆论扩展多少台服务器，这些请求最终都会从数据库读写数据，到⼀定程度之后，数据的压⼒称为系统承载能⼒的瓶颈点。我们可以像扩展应⽤服务器⼀样扩展数据库服务器么？ 答案是否定的，因为数据库服务有其特殊性：如果将数据分散到各台服务器之后，数据的⼀致性将⽆法得到保障。所谓数据的⼀致性，此处是指：针对同⼀个系统，⽆论何时何地，我们都应该看到⼀个始终维持统⼀的数据。

解决办法是：通过主从分离架构实现读写分流，利用读多写少的业务特性横向扩展从库分担读压力，以可控的同步延迟代价换取数据库整体性能提升。保留⼀个主要的数据库作为写⼊数据库，其他的数据库作为从属数据库。从库的所有数据全部来⾃主库的数据，经过同步后，从库可以维护着与主库⼀致的数据。然后为了分担数据库的压⼒，我们可以将写数据请求全部交给主库处理，但读请求分散到各个从库中。由于⼤部分的系统中，读写请求都是不成⽐例的，例如 100 次读 1 次写，所以只要将读请求由各个从库分担之后，数据库的压⼒就没有那么⼤了。当然这个过程不是⽆代价的，主库到从库的数据同步其实是由时间成本的，后面详细讨论。

在这里插入图片描述

`2.4 引⼊缓存⸺冷热分离架构`

随着访问量继续增加，发现业务中⼀些数据的读取频率远⼤于其他数据的读取频率。我们把这部分数据称为 热点数据 ，与之相对应的是冷数据。针对热数据，为了提升其读取的响应时间，可以增加本地缓存，并在外部增加分布式缓存，缓存热⻔商品信息或热⻔商品的 html ⻚⾯等。通过缓存能把绝⼤多数请求在读写数据库前拦截掉，⼤⼤降低数据库压⼒。

其中涉及的技术包括：使⽤memcached作为本地缓存，使⽤ Redis 作为分布式缓存，还会涉及缓存⼀致性、缓存穿透/击穿、缓存雪崩、热点数据集中失效等问题。

在这里插入图片描述

`2.5 垂直分库`

当数据量激增到单机数据库难以支撑时，可以像把大型图书馆的藏书按学科分类存放到不同楼层的分馆（分库），再按作者或书名首字母细分到各个书架（分表）一样，通过业务规则（如商品ID哈希、时间+用户ID）将数据拆分到多台服务器的多个小表上，并用智能导航系统（Mycat等中间件）精准指引读写请求到对应位置，这样既保持了业务对“单一数据库”的使用体验，又通过物理分散实现了性能的横向扩展；不过这种架构如同组建一支交响乐团，需要分片调度、SQL解析、结果合并等多个模块紧密协作，对DBA的分布式系统运维能力要求较高，本质上是利用MPP（大规模并行处理）思想构建的逻辑统一、物理分散的数据库系统。

在这里插入图片描述