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

IsLand1314~

已于 2025-06-01 16:16:28 修改

阅读量1.9k

点赞数 125

CC 4.0 BY-SA版权

分类专栏： Redis 文章标签： redis 分布式数据库

于 2025-06-01 15:48:10 首次发布

本文链接：https://blog.youkuaiyun.com/island1314/article/details/148366972

Redis 专栏收录该内容

3 篇文章

订阅专栏

在这里插入图片描述

📃个人主页：island1314

⛺️ 欢迎关注：👍点赞 👂🏽留言 😍收藏 💞 💞 💞

生活总是不会一帆风顺，前进的道路也不会永远一马平川，如何面对挫折影响人生走向 – 《人民日报》

🔥 目录

一、前言

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

常见概念

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

评价指标

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

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

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

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

二、架构演进

1. 单机架构

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

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

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

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

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

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

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

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

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

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

补充说明：

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

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

2. 应用数据分离架构

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

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

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

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

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

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

3. 应用服务集群架构

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

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

有如下几种方案选择：

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

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

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

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

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

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

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

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

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

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

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

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

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