【Redis#1】服务端高并发分布式结构的演进

一、前言

本文以“电子商务”应用为例，介绍从一百个到千万级并发情况下服务端的架构演进过程。目的：帮助读者建立对架构演进的整体认知，便于深入学习后续知识

常见概念

1. 应用（Application）/ 系统（System）：完成一系列服务的程序或程序群。
2. 模块（Module）/ 组件（Component）：负责特定功能的内聚单元。
3. 分布式（Distributed）：系统组件部署在不同服务器上，通过网络通信协作。（物理上）
4. 集群（Cluster）：多个组件部署在多台服务器上，共同实现特定目标。（逻辑上）
5. 主（Master）/ 从（Slave）：集群中承担主要或辅助职责的组件。例如: 一个写，多个同步读的模式
6. 中间件（Middleware）：不同应用程序间通信的桥梁。与业务无关的更通用的服务（如：sql,cache,消息队列…）

评价指标

• 可用性（Availability）：系统正常提供服务/一年总时长 的时间比例。

例如：平时我们常说的4个9即系统可以提供99.99%的可用性，5个9是99.999%的可用性，以此类推。我们平时只是用高可用（High Availability, HA）这个非量化目标简要表达我们系统的追求。

• 响应时长（Response Time RT）：用户输入到系统响应的时间。
• 吞吐（Throughput）vs 并发（Concurrent）：单位时间内处理的请求数量 vs 同时支持的最大请求数量。

响应时长 和 吞吐 并发 都是衡量服务器性能的标准

二、架构演进

1. 单机架构

适用场景：只有一台服务器，这个服务器负责所有的工作

image-20250529134148281

• 相关软件：Web服务器（Tomcat、Netty、Nginx、Apache等）、数据库（MySQL、Oracle、PostgreSQL、SQL Server等）

如上所示就是一个单机架构，对于单价架构来说，就是只有一台服务器，这个服务器可以负责处理所有的工作

我们假设这是一个电商网站，那么这个应用服务其实就是我们写的一个服务器程序，比如说有前面写的一个 C++ 的 httplib 这样的程序，而这样的 HTTP 服务器是可以和 MySQL 数据库的服务进行结合起来的，那么对于 MySQL 来说，它本质上其实是一个客户端服务端结构的程序，本体上是一个 MySQL 的服务器，这个服务器来负责进行数据的存储和组织的部分

而在大多的项目中，其实使用的就是这种比较典型的单机架构，单机架构的特点其实就是简单，并且由于现在计算机的硬件已经发达到了一定的程度，所以哪怕只有一个主机，其实已经是可以有比较高的性能了，可以支持比较大的并发和数据的存储

但是事实上，当业务到达一定程度的时候，其实一个主机已经很难进行处理了，那么就需要用到的是主机，其实本质上是硬件资源

一个主机上的硬件资源是有限的

这句话其实很好理解，因为在一台主机上，它的硬件资源包括但不限于有 CPU ，内存，硬盘，网络等等，当服务器收到请求的时候，其实都是需要消耗这些资源的，在同一时刻，如果处理的请求比较多，那么就会造成此时的某个硬件资源就不够用

如果我们真的遇到了这样服务器不够用的场景，该怎么处理？

1. 开源：简单粗暴，增加更多的硬件资源，，比如说可以引入更大的内存，或者新加一些内存条等，但是这样的设计也是有问题的，一个主机上能增加的硬件资源也有限，取决于主板的扩展能力，一台主机扩展到极限还不够就只能引入多台主机（此时从某种意义来说，如果一旦引入了多台主机，就可以把系统称之为就是一个 分布式系统，但是引入分布式此时系统的复杂程度就会大大提高）
2. 节流：需要用到一些专业知识来对于数据进行优化，需要对于性能测试来看到底是哪个模块出现了问题，这一般需要比较高的水平

补充说明：

现在大部分公司都是这种单机架构，选择原因：初期需要利用精干的技术团队，快速将业务系统投入市场进行检验，并且可以迅速响应变化要求。但好在前期用户访问量很少，没有对我们的性能、安全等提出很高的要求，而且系统架构简单，无需专业的运维团队，所以选择单机架构是合适的

• 还有就是现在计算机硬件发展速度很快，就算只有一台主机，这台主机的性能也是很高的，可以支持非常高的并发 & 数据存储
• 如果业务进一步增长，用户量和数据量增长到一台主机难以应付，就需要投入更多主机，引入更多硬件资源

2. 应用数据分离架构

因此我们就引出了下面这种架构体系模式，可以把应用服务器和存储服务器分开

• 适用场景：系统访问量增加，硬件资源接近极限
• 架构描述：应用服务和数据库服务分离部署，应用服务通过网络访问数据库

image-20250601141603379

• 和之前架构的主要区别在于将数据库服务独立部署在同一个数据中心的其他服务器上，应用服务通过网络访问数据

应用服务器：对于应用服务器来说，里面可能包含有很多的业务，这些业务都会需要进行 CPU 和内存的资源

数据库服务器：对于这种服务器来说，它就需要更大的磁盘空间，更快的数据访问速度，因此可以搭配有对应的 SSD 硬盘等

• 相比于单机架构，此时把这两个服务器进行分离，就可以到达一个更高的性价比

3. 应用服务集群架构

适用场景：单台应用服务器无法满足需求。–引入负载均衡

应用服务器通常来说比较吃 CPU 和内存，那么如果 CPU 和内存都被吃掉了，那此时应用服务器就无法满足要求了，那此时怎么办？

有如下几种方案选择：

1. 垂直扩展（Scale Up）：购买更高性能的服务器，成本高且提升有限
2. 水平扩展（Scale Out）：增加应用服务器数量，成本相对较低，提升空间大。但是会给系统带来更多的复杂性，需要丰富经验
3. 引入组件：负载均衡（Nginx、HAProxy、LVS、F5等）

负载均衡：为了解决用户流量向哪台应用服务器分发的问题，需要一个专门的系统组件做流量分发。实际中负载均衡不仅仅指的是工作在应用层的，甚至可能是其他的网络层之中。同时流量调度算法也有很多种，这里简单介绍几种较为常见的:

1. Round-Robin：公平地将请求分发给不同服务器
2. Weight-Round-Robin：按权重分配请求
3. 一致哈希散列算法：确保同一用户的请求分发到同一服务器

负载均衡具体的设计模式如下所示：

image-20250601142301872

看起来是两个应用服务器，实际上也可能是多个应用服务器，而对于应用服务器来说，用户的请求实际上会优先到达负载均衡器或者是网关服务器，之后会被分配到每一个应用服务器，所以这也就使得会诞生很多种不同的算法，来进行合适的分配。比如：假设现在有 1w 个请求，经过分配后就可以让每一个服务器去分担 5k

负载均衡相关软件：Nginx、HAProxy、LVS、F5 等

但是上面这样就可以解决问题了吗？

• 其实也是不一定的，因为负载均衡器也可能会无法承受一个比较大的请求，此时就需要引入更多的负载均衡器，也就是我们俗称的引入多个机房，让多个机房共同来进行分配
• 但这其实并不是一件好事，因为风险总是和收益并存的，只是单纯这样的设计并不会有比较大的风险，但是随着机房的增多，机器的增多，这就意味着出现问题的概率就会大大增加，此时就会导致出现问题

4. 读写分离 / 主从分离架构

适用场景：数据库成为系统瓶颈

随着业务的增长，可以动态扩张服务器来进行压力的缓解，但是实际上，数据的压力会到达一个系统承载能力的上限，此时如果一味地去扩展数据库的服务器是不现实的，因为存在 数据一致性 的问题。

例如对于同样的数据，如果在不同的机器上是不同的数据，那这必然是一件非常危险的事，所以就诞生了下面的模式 ----- 主从分离架构

image-20250601143830532

• 运用：我们采用的解决办法是这样的，保留一个主要的数据库作为写入数据库，其他的数据库作为从属数据库。从库的所有数据全部来自主库的数据，经过同步后，从库可以维护着与主库一致的数据
• 优点：分担数据库的压力，将写数据请求全部交给主库处理，但读请求分散到各个从库中。由于大部分的系统中，读写请求都是不成比例的（读多写少），所以只要将读请求由各个从库分担之后，数据库的压力就没有那么大了
• 问题：当然这个过程不是无代价的，主库到从库的数据同步其实是有时间成本的，但这个问题我们暂时不做进一步探讨
• 解决方案：保留一个主数据库用于写入，其他从数据库用于读取，通过数据同步保持一致性
• 相关软件：数据库中间件（MyCat、TDDL、Amoeba、Cobar等）

5. 引入缓存 – 冷热分离架构

随着访问量继续增加，发现业务中⼀些数据的读取频率远大于其他数据的读取频率。我们把这部 分数据称为热点数据，与之相对应的是冷数据（二八原则）

• 适用场景：读取频率高的热点数据增加。读取频率高的热点数据增加。

image-20250601145021455

如上所示，在原来的基础上新增一个缓存服务器，这个缓存服务器就会帮助数据库服务器进行负重前行，而在缓存服务器当中其实存放的只是一小部分的热点数据，也就是会频繁访问到的数据，缓存虽然快，但不是没有代价的，那就是它很小，这也就解释了不会有完美的解决方案，只是会有不同的优化场景

• 解决方案：使用本地缓存和分布式缓存（Memcached、Redis）减少数据库压力
• 面临问题：缓存一致性、缓存穿透/击穿、缓存雪崩、热点数据集中失效等

6. 垂直分库

随着业务的数据量增大，大量数据存储在同一个库中已经显得有些力不从心了，所以可以按照业务，将数据分别存储。所以下面引入的这个模式架构体系，就是叫做 分库分表

简单来说，就是本来一个数据库服务器，这个数据库服务器上有多个数据库，现在就可以引入多个数据库服务器，让每一个数据库服务器去存储一个或者一部分数据库，甚至说，当一个表特别大的时候，也可以对于表进行拆分

例子如下：

• 针对评论数据，可按照商品ID进行hash，路由到对应的表中存储
• 针对支付记录，可按照小时创建表，每个小时表继续拆分为小表，使用用户ID或记录编号来路由数据

只要实时操作的表数据量足够小，请求能够均匀地分发到多台服务器上的小表，数据库就能通过水平扩展的方式来提高性能。

• 其中前面提到的Mycat也支持在大表拆分为小表情况下的访问控制
• 这种做法显著增加了数据库运维的难度，对DBA的要求较高
• 数据库设计到这种结构时，已经可以称为分布式数据库

但是这只是⼀个逻辑的数据库整体，数据库里不同的组成部分是由不同的组件单独来实现的

1. 如分库分表的管理和请求分发，由Mycat实现
2. SQL的解析由单机的数据库实现
3. 读写分离可 能由网关和消息队列来实现
4. 查询结果的汇总可能由数据库接口层来实现等等

注意：这种架构其实是MPP （大规模并行处理）架构的⼀类实现

适用场景：数据量增大，单库难以支撑

image-20250601145648083

• 解决方案：按业务将数据分库存储，使用Mycat等工具管理分库分表
• 相关软件：分布式数据库（Greenplum、TiDB、Postgresql XC、HAWQ等）

7. 微服务架构

在之前的应用服务器当中，一个服务器中可能做了很多的业务，这就会导致一个服务器的代码会变的非常的复杂，为了解决这样的问题，就可以使用一个微服务的概念，把一个复杂的服务器拆解为更多的，功能更加单一的更小的服务器

• 比如：随着人员增加，业务发展，我们将业务分给不同的开发团队去维护，每个团队独立实现自己的微服务，然后互相之间对数据的直接访问进行隔离。可以利用 Gateway、消息总线等技术，实现相互之间的调用关联。甚至可以把一些类似用户管理、安全管理、数据采集等业务提成公共服务

适用场景：业务复杂度增加，团队扩大。

image-20250601145955647

• 解决方案：将业务拆分为独立的微服务，通过Gateway、消息总线等技术实现服务间的调用。
• 公共服务：安全中心、监控预警中心等。

微服务的好处

• 微服务本质上是在解决"人" 的问题：当应用服务器复杂了势必就需要更多的人来维护了，当人多了，就需要配套的管理,把这些人组织好按照功能，拆分成多组微服务,就可以有利于上述人员的组织结构的分配了
• 使用微服务，可以更方便于功能的复用
• 可以给不同的服务进行不同的部署

引入微服务,解决了人的问题,付出的代价?

（1）系统的性能下降 （要想保证性能不下降太多,只能引入更多的机器,更多的硬件资源 =>充钱）

• 拆出来更多的服务，多个功能之间要更依赖网络通信.
• 网络通信的速度很可能是比硬盘还慢的!!!
• 幸运的是，硬件技术的发展,
• 网卡现在有 万兆 网卡.读写速度已经能过超过硬盘读写了~

（2）系统复杂程度提高,可用性收到影响

• 服务器更多了,出现问题的概率就更大了
• 这就需要一系列的手段,来保证系统的可用性 (更丰富的监控报警，以及配套的运维人员)

三、总结

① 单机架构 (应用程序+数据库服务器)

② 数据库和应用分离：应用程序和数据库服务器分别放到不同主机上部署了

③ 引入负载均衡, 应用服务器 =>集群 通过负载均衡器,把请求比较均匀的分发给集群中的每个应用服务器当集群中的某个主机挂了，其他的主机仍然可以承担服务 提高了整个系统的可用性~~

④ 引入读写分离,数据库主从结构，一个数据库节点作为主节点,其他N个数据库节点作为从节点。

• 主节点负责写数据,从节点负责读数据
• 主节点需要把修改过的数据同步给从节点

上述四点，都是为了 高效的处理更多的数据

⑤ 引入缓存，冷热数据分离

• Redis 在一个分布式系统中,通常就扮演着缓存这样的角色
• 引入的问题:数据库和缓存的数据一致性问题

⑥ 引入分库分表,数据库能够进一步扩展存储空间

⑦ 引入微服务,从业务上进一步拆分应用服务器，从业务功能的角度，把应用服务器，拆分成更多的功能更单一、更简单、更小的服务器

上述这样的几个演化的步骤, 只是一个粗略的过程.

• 实际上一个商业项目, 真实的演化过程, 都是和他的业务发展密切相关的.
• 业务是更重要的, 技术是给业务提供支持的.

所谓的分布式系统, 就是想办法引入更多的硬件资源!!