Redis领域中服务端高并发分布式架构的发展轨迹

未分类 11小时前程序员胖胖胖虎阿

4 0 0

文章标题：

Redis领域中服务端高并发分布式架构的演进历程

文章内容：

📃个人主页： _island1314 ___

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

生活不会总是顺遂，前行之路也不会始终平坦，如何面对挫折影响人生走向 – 《人民日报》

🔥 目录

- 一、引言
- 二、架构变革
- - 1. 单机架构
- 2. 应用数据分离架构
- 3. 应用服务集群架构
- 4. 读写分离/主从分离架构
- 5. 引入缓存--冷热分离架构
- 6. 垂直分库
- 7. 微服务架构
- 三、总结

一、引言

本文以“电子商务”应用为例，阐述从百级到千万级并发情形下服务端的架构演变过程。目的是协助读者构建对架构演变的整体认识，以便深入学习后续知识。

常见概念

应用（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）与并发（Concurrent） ：单位时间内处理的请求数量与同时支持的最大请求数量。

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

二、架构变革

1. 单机架构

适用场景 ：仅有一台服务器，该服务器承担所有工作。

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

如上为单机架构，其特点是仅有一台服务器，该服务器可处理所有工作。

假设这是一个电商网站，应用服务即所写的服务器程序，比如前面提到的C++的httplib程序，此HTTP服务器可与MySQL数据库服务结合，MySQL本质是客户端 - 服务器结构程序，其本体是MySQL服务器，负责数据存储与组织。

多数项目采用此类典型单机架构，单机架构的优势在于简单，且当下计算机硬件发达，单主机也能有较高性能，支撑较大并发与数据存储。但实际业务发展到一定程度，单主机难以处理，因单主机硬件资源有限，包括CPU、内存、硬盘、网络等，处理请求时会消耗资源，同一时刻请求多会致硬件资源不足。

若遇服务器资源不足情况，有两种处理方式：
1. 扩容：简单直接，增加硬件资源，如加大内存、添加内存条等，但单主机扩展硬件资源有限，受主板扩展能力限制，扩展到极限仍不足则需引入多台主机（此时系统可称分布式系统，复杂度大增）；
2. 优化：需专业知识优化数据，通过性能测试找出问题模块，需较高水平。

补充说明 ：

当下大部分公司采用单机架构，选择缘由 ：初期需精干技术团队快速将业务系统推向市场检验，能迅速响应变化需求。且前期用户访问量少，对性能、安全等要求不高，系统架构简单，无需专业运维团队，故单机架构适用。

再者，当下计算机硬件发展迅猛，单主机性能亦高，可支撑极高并发与数据存储；

若业务进一步增长，用户量和数据量达单主机难应付程度，需投入更多主机，增加硬件资源。

2. 应用数据分离架构

基于此引出应用服务器与存储服务器分离的架构模式。

适用场景 ：系统访问量增加，硬件资源接近极限。

架构描述 ：应用服务与数据库服务分离部署，应用服务通过网络访问数据库。

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

应用服务器 ：包含诸多业务，需消耗CPU和内存资源。

数据库服务器 ：需更大磁盘空间、更快数据访问速度，可搭配SSD硬盘等。

相较单机架构，分离应用服务器和数据库服务器可获更高性价比。

3. 应用服务集群架构

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

应用服务器较吃CPU和内存，若资源耗尽则无法满足需求，有以下方案可选：
1. 垂直扩展（Scale Up）：购置更高性能服务器，成本高且提升有限；
2. 水平扩展（Scale Out）：增加应用服务器数量，成本相对较低，提升空间大，但系统复杂性增加，需丰富经验；
3. 引入组件：负载均衡（Nginx、HAProxy、LVS、F5等）。

负载均衡
：为解决用户流量向哪台应用服务器分发问题，需专门系统组件进行流量分发。实际中负载均衡不仅工作于应用层，还可能在其他网络层。流量调度算法多样，常见有：
1. 轮询（Round-Robin） ：公平将请求分发给不同服务器；
2. 加权轮询（Weight-Round-Robin） ：按权重分配请求；
3. 一致哈希算法 ：确保同一用户请求分发到同一服务器。

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

看似是两个应用服务器，实际可能是多个，用户请求先达负载均衡器或网关服务器，再被分配到各应用服务器，诞生多种分配算法。例如1w个请求经分配后，各服务器分担5k。

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

但此方式并非万无一失，负载均衡器也可能承受不住大请求，需引入更多负载均衡器，即多机房引入，然机房增多致机器增多，出现问题概率大增。

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

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

随业务增长，可动态扩张服务器缓解压力，但数据压力达系统承载上限时，单纯扩展数据库服务器不现实，存数据一致性问题。

例如不同机器数据不同危险，遂诞生主从分离架构。

应用：保留一主数据库写入，其他为从数据库读取，从库数据来自主库同步，维护与主库一致数据；
优点：分担数据库压力，写请求交主库，读请求分散到从库。因系统中读写请求多不成比例（读多写少），读请求由从库分担后，数据库压力减小；
问题：主库到从库数据同步有时延成本，暂不深讨；
解决方案 ：主库写入，从库读取，通过数据同步保一致性；
相关软件 ：数据库中间件（MyCat、TDDL、Amoeba、Cobar等）。

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

随访问量增加，发现业务中部分数据读取频率远高于其他数据，称热点数据，对应冷数据（二八原则）。

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

如上，新增缓存服务器，存小部分热点数据，缓存虽快但空间小。

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

6. 垂直分库

随业务数据量增大，单库存储吃力，按业务分数据存储，即分库分表。

简言之，原一数据库服务器有多个数据库，现引入多数据库服务器，各存部分数据库，表过大时拆分表。

例子：
* 评论数据按商品ID hash，路由到对应表存储；
* 支付记录按小时建表，每小时表再拆分，用用户ID或记录编号路由数据。

只要实时操作表数据量小，请求均匀分发到多服务器小表，数据库可水平扩展提性能。

前文提及的Mycat支持大表拆分访问控制；
此做法增数据库运维难度，对DBA要求高；
数据库达此结构可称分布式数据库。

但这是逻辑数据库整体，不同组成部分由不同组件实现：
1. 分库分表管理和请求分发由Mycat实现；
2. SQL解析由单机数据库实现；
3. 读写分离可能由网关和消息队列实现；
4. 查询结果汇总可能由数据库接口层实现等。

注意：此架构属MPP（大规模并行处理）架构一类实现。

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

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

7. 微服务架构

前期应用服务器中一服务器做很多业务，代码复杂，遂有微服务概念，将复杂服务器拆解为功能单一的小服务器。

例如人员增加、业务发展，将业务分给不同开发团队维护，各团队独立实现微服务，相互隔离数据访问。可利用Gateway、消息总线等技术实现调用关联，将用户管理、安全管理、数据采集等业务提成公共服务。

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

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

微服务的好处

微服务本质解决“人”的问题：应用服务器复杂需更多人维护，人多需管理，拆分为微服务利于人员组织分配；
便于功能复用；
可对不同服务不同部署。

引入微服务的代价：
（1）系统性能下降（要保性能需更多机器硬件资源→投入）
* 拆出更多服务，功能间依赖网络通信，网络通信速度可能慢于硬盘，幸硬件技术发展，网卡有万兆网卡，读写速度超硬盘。
（2）系统复杂度提高，可用性受影响
* 服务器增多，出现问题概率增大；
* 需一系列手段保系统可用性（更丰富监控报警及运维人员）。