系统设计，建议做好这 10个权衡！_权衡系统复杂性与可扩展性-CSDN博客

本文链接：https://blog.csdn.net/2301_78976656/article/details/140467561

在做系统设计时，有个不成文的规则：一切都是权衡的结果。这篇文章，我们一起来分析系统设计时经常遇到的 10种权衡，帮助你快速地找到系统设计的核心秘密。

可扩展性与性能

可扩展性和性能是软件系统设计和开发中的两个很重要也很容易顾此失彼的指标。

可扩展性

可扩展性（Scalability）是指系统在增加资源（如硬件、带宽、存储等）后，能够处理更大负载（如更多用户、更多数据、更多请求）的能力。一个可扩展的系统能够通过增加资源来提高其处理能力，而不需要进行重大的设计变更。

可扩展性的类型

垂直扩展（Vertical Scalability）：通过增加单个节点的资源（如CPU、内存）来提升性能。
水平扩展（Horizontal Scalability）：通过增加更多的节点（如服务器）来提升性能。

性能

性能（Performance）是指系统在特定条件下完成任务的效率，通常以响应时间、吞吐量和资源利用率等指标来衡量。

衡量指标

响应时间（Response Time）：从请求发出到收到响应所需的时间。
吞吐量（Throughput）：单位时间内系统处理的请求数量。
资源利用率（Resource Utilization）：系统资源（如CPU、内存、网络等）的使用效率。

如何权衡？

在实际应用中，系统设计需要在可扩展性和性能之间找到平衡。例如：

初期阶段：可能更多关注性能，通过优化代码和数据库来提高响应速度。
成长阶段：随着用户和数据量的增加，需要更多关注可扩展性，通过分布式架构和负载均衡来处理更大负载。

延迟与吞吐量

延迟和吞吐量是系统性能评估中的两个重要指标，它们分别衡量系统响应时间和处理能力。

延迟

延迟（Latency）是指请求发出到收到响应所需的时间，通常以毫秒（ms）或微秒（µs）为单位，它反映了系统响应的速度。

text

代码解读

复制代码

延迟 = 网络延迟 + 处理延迟 + 队列延迟

组成部分

网络延迟：数据在网络上传输所需的时间，包括路由、交换等。
处理延迟：服务器处理请求所需的时间，包括CPU处理、I/O操作等。
队列延迟：请求在队列中等待处理的时间。

吞吐量

吞吐量（Throughput）是指单位时间内系统处理的请求数量，通常以每秒请求数（requests per second, RPS）或每秒事务数（transactions per second, TPS）为单位。

影响因素

系统资源：CPU、内存、磁盘和网络带宽等资源的可用性和利用率。
并发处理能力：系统能够同时处理的请求数量。
工作负载类型：不同类型的工作负载对系统资源的需求不同。

如何权衡？

在实际应用中，设计系统时需要根据具体需求在延迟和吞吐量之间找到平衡，以下是一些参考：

实时应用：优先优化延迟，确保快速响应。
批处理系统：优先优化吞吐量，提高处理能力。
混合应用：综合考虑延迟和吞吐量，根据不同场景进行优化。
篇幅限制下面就只能给大家展示小册部分内容了。这份面试笔记包括了：Java面试、Spring、JVM、MyBatis、Redis、MySQL、并发编程、微服务、Linux、Springboot、SpringCloud、MQ、Kafka 面试专题

需要全套面试笔记【点击此处】即可免费获取

SQL 与 NoSQL 数据库

SQL和NoSQL是两种不同类型的数据库管理系统（DBMS），它们在结构、存储、查询语言和适用场景等方面有显著的区别。

SQL数据库

SQL（Structured Query Language）数据库是基于关系模型的数据库管理系统，数据以表格形式存储，表与表之间通过外键建立关系。

特点

结构化数据：数据具有固定的模式（Schema），表的结构在创建时定义。
关系模型：数据通过表格和关系表示，支持复杂的查询和操作。
ACID 特性：支持原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability），确保数据的可靠性和一致性。

常见的 SQL 数据库： MySQL、PostgreSQL、Oracle Database、Microsoft SQL Server。

NoSQL数据库

NoSQL（非关系数据库）数据库是不依赖于关系模型的数据库管理系统，设计上更灵活，适用于大规模分布式数据存储。

特点

灵活的数据模型：支持多种数据模型，如键值对、文档、列族和图形等。
无固定模式：数据没有固定的模式（Schema），可以动态添加字段。
水平扩展：通过增加节点实现水平扩展，适合大规模数据存储和高并发访问。
CAP 定理：在分布式系统中，NoSQL数据库通常遵循CAP定理中的两个特性（一致性、可用性、分区容忍性）。

常见 NoSQL 数据库：MongoDB（文档型）、Redis（键值型）、Cassandra（列族型）、Neo4j（图形型）。

如何权衡？

选择 SQL 还是 NoSQL 数据库，取决于具体的应用需求和场景，以下是一些参考建议：

SQL 数据库：适合需要复杂查询、事务管理和数据一致性要求高的应用。
NoSQL 数据库：适合需要处理大规模数据、高并发访问和灵活数据模型的应用。

另外，在实际项目中，许多系统会同时使用 SQL 和 NoSQL 数据库，以充分利用两者的优势。例如，使用 SQL 数据库管理关键业务数据，使用 NoSQL 数据库处理日志、缓存和实时分析等任务。

一致性与可用性

一致性和可用性是分布式系统设计中的两个关键概念，它们在 CAP 定理（也称为布鲁尔定理）中有着广泛的阐述和使用。

一致性

一致性（Consistency）是指在分布式系统中，所有节点在同一时间具有相同的数据视图，换句话说，当一个数据更新操作完成后，所有后续的读取操作都能看到这个更新结果。

类型

强一致性（Strong Consistency）：所有节点在任何时刻都具有相同的数据视图。一旦数据更新，所有读取操作都会立即返回最新的数据。
最终一致性（Eventual Consistency）：系统保证在没有进一步更新的情况下，所有节点最终会达到一致的状态，但在短时间内可能存在不一致。
因果一致性（Causal Consistency）：如果一个操作影响了另一个操作，系统会保证这些操作按照因果关系的顺序被看到。
读己之写一致性（Read Your Writes Consistency）：一个节点总是能读取到自己写入的数据，即使其他节点可能暂时不一致。

可用性

可用性（Availability）是指系统在任何时刻都能够响应请求，即使某些部分出现故障，系统仍然能够处理请求并返回结果。

关键点

高可用性（High Availability）：系统能够在大多数情况下提供服务，即使部分节点或网络出现故障。
故障恢复（Fault Tolerance）：系统能够在故障发生后迅速恢复并继续提供服务。
冗余设计（Redundancy）：通过增加冗余节点和数据副本，确保系统在部分节点失效时仍能正常运行。

CAP定理

CAP定理指出，在一个分布式系统中，不可能同时满足一致性（Consistency）、可用性（Availability）和分区容忍性（Partition Tolerance）这三个特性，只能同时满足其中的两个。

一致性（C）：所有节点拥有相同的数据视图。
可用性（A）：每个请求都能收到一个（成功或失败的）响应。
分区容忍性（P）：系统能够在网络分区的情况下继续运行。

篇幅限制下面就只能给大家展示小册部分内容了。这份面试笔记包括了：Java面试、Spring、JVM、MyBatis、Redis、MySQL、并发编程、微服务、Linux、Springboot、SpringCloud、MQ、Kafka 面试专题

需要全套面试笔记【点击此处】即可免费获取

如何权衡？

在实际的分布式系统设计中，通常需要在一致性和可用性之间做出权衡：

CP系统：在一致性和分区容忍性之间做出选择，牺牲可用性。例如，分布式数据库中的某些强一致性配置。
AP系统：在可用性和分区容忍性之间做出选择，牺牲一致性。例如，DNS系统和某些NoSQL数据库（如Cassandra）。
CA系统：理论上无法实现，因为无法同时在分布式环境中保证一致性和可用性而不考虑分区容忍性。

以下为实际工作中常采用的权衡方式：

金融系统

一致性优先：金融交易系统通常需要强一致性，确保所有节点的数据视图一致，以防止出现数据不一致的风险。
可用性保障：同时，通过冗余设计和故障恢复机制确保系统的高可用性。

社交媒体

可用性优先：社交媒体平台通常更关注系统的高可用性，确保用户能够随时访问和发布内容。
最终一致性：采用最终一致性模型，允许短时间内的数据不一致，但最终会达到一致状态。

电商平台

混合策略：电商平台可能需要在不同场景下采用不同的策略。例如，订单处理需要强一致性，而商品浏览和推荐可以采用最终一致性。

强一致性与最终一致性

在分布式系统中，一致性是一个关键的设计考虑因素，强一致性和最终一致性是两种不同的一致性模型，它们在数据一致性和系统性能之间做出了不同的权衡。

强一致性

强一致性（Strong Consistency）是指在分布式系统中，每次数据更新后，所有节点立即可见最新的数据。任何读取操作在更新完成后都会返回最新的数据。

特点

同步更新：数据更新需要同步到所有节点，确保所有节点的数据视图一致。
读取最新数据：任何读取操作都会返回最新的数据。
严格的保证：提供严格的一致性保证，适用于需要高数据一致性的应用。

最终一致性

最终一致性（Eventual Consistency）是指在分布式系统中，数据更新后，系统不立即保证所有节点的数据一致，但在没有进一步更新的情况下，所有节点最终会达到一致的状态。

特点

异步更新：数据更新是异步的，允许节点在不同步的情况下处理请求。短暂不一致：在短时间内，节点间的数据可能不一致。最终一致：在没有新的更新操作后，所有节点最终会达到一致的状态

如何权衡？

在实际的分布式系统设计中，根据具体需求选择合适的一致性模型：

金融交易系统：选择强一致性，确保所有交易数据的一致性和准确性。

社交媒体平台：选择最终一致性，提高系统的性能和可用性，允许用户动态数据在短时间内不一致。

电商平台：订单处理采用强一致性，确保订单状态的准确性；商品浏览和推荐采用最终一致性，提升用户体验和系统性能。

批处理与流处理

批处理和流处理是两种常见的数据处理模式，它们在数据处理方式、应用场景和技术实现上有显著的区别。理解这两种处理模式有助于在不同数据处理需求下选择合适的解决方案。

批处理

批处理（Batch Processing）是一种数据处理模式，系统在预定时间或特定条件下对一组数据进行处理。数据在批处理任务开始前已经全部收集完毕，处理过程通常是离线的。

特点

定时处理：数据在预定时间间隔或特定条件下进行处理，如每天、每小时。
离线处理：通常在后台执行，不需要实时响应。
大数据量：适合处理大规模数据集，批量操作可以提高处理效率。

流处理

流处理（Stream Processing）是一种数据处理模式，系统对实时生成的数据流进行连续处理。数据在生成后立即被处理，处理过程通常是在线的。

特点

实时处理：数据在生成后立即被处理，具有低延迟。
在线处理：处理过程是连续的，系统需要实时响应。
事件驱动：以事件为单位进行处理，每个事件独立处理。

如何权衡？

在实际应用中，选择批处理还是流处理，取决于具体的数据处理需求和场景，以下为一些参考建议：

数据仓库和报表生成：选择批处理，定期加载和分析数据，生成业务报表。 实时监控和分析：选择流处理，实时监控系统性能或用户行为，快速响应事件。 混合模式：在某些情况下，可以结合批处理和流处理。例如，实时收集和处理数据流，同时定期进行批量分析和报表生成。

同步处理与异步处理

同步处理和异步处理是两种常见的计算和通信模式，它们在任务执行、资源利用和响应时间等方面有显著的区别。

同步处理

同步处理（Synchronous Processing）是指任务按顺序执行，一个任务在前一个任务完成后才开始执行。在同步通信中，发送方在接收到响应之前会一直等待。

特点

顺序执行：任务按顺序依次执行，后续任务需要等待前一个任务完成。
阻塞等待：调用方在等待响应的过程中会被阻塞，无法执行其他任务。
简单性：逻辑简单，容易理解和实现。

异步处理

异步处理（Asynchronous Processing）是指任务可以并发执行，一个任务不需要等待另一个任务完成。在异步通信中，发送方在发送请求后可以立即继续执行其他任务，不需要等待响应。

特点

并发执行：任务可以并发执行，提高资源利用率。
非阻塞等待：调用方在等待响应的过程中可以继续执行其他任务。

如何权衡？

在实际应用中，根据具体需求选择同步处理或异步处理，或结合使用，以实现最佳的系统性能和用户体验，下面为一些真实业务的权衡建议：

电商平台：

同步处理：订单处理和支付流程中，使用同步处理，确保数据一致性和交易的可靠性。
异步处理：商品推荐、库存更新等操作，使用异步处理，提高系统的响应速度和并发处理能力。 社交媒体平台：
同步处理：用户登录、数据写入等关键操作，使用同步处理，保证数据一致性。
异步处理：消息推送、动态更新等操作，使用异步处理，提升用户体验和系统性能。

有状态架构与无状态架构

有状态架构和无状态架构是两种不同的系统设计模式，它们在状态管理、扩展性、可靠性和适用场景等方面有显著的区别。

有状态架构

有状态架构（Stateful Architecture）是指系统在处理请求时会保留客户端的状态信息。每个请求都依赖之前的请求状态，服务器需要维护会话信息。

特点

状态依赖：每个请求依赖之前的请求状态，服务器需要维护会话信息。
会话管理：服务器需要管理客户端的会话信息，如用户登录状态、购物车内容等。
复杂性高：需要处理状态同步、会话持久化等问题。

无状态架构

无状态架构（Stateless Architecture）是指系统在处理每个请求时不依赖任何之前的请求状态。每个请求都是独立的，服务器不需要保留会话信息。

特点

独立请求：每个请求都是独立的，服务器不需要维护会话信息。
简化管理：服务器不需要管理客户端的会话信息，简化了系统设计。
高扩展性：由于不依赖状态，系统可以轻松实现负载均衡和扩展。

如何权衡

在实际应用中，根据具体需求选择有状态架构或无状态架构，下面为一些真实业务的权衡建议：

电商平台

有状态架构：用户购物车、订单处理等需要维护会话信息。
无状态架构：商品浏览、推荐服务等可以使用无状态架构，提高系统扩展性。

在线游戏

有状态架构：玩家的游戏状态、进度等需要维护会话信息。
无状态架构：游戏的静态资源加载、排行榜查询等可以使用无状态架构。

微服务架构

无状态架构：各个微服务独立运行，不依赖全局状态，易于扩展和维护。

单体架构与微服务架构

单体架构和微服务架构是两种常见的软件系统设计模式，它们在模块化、扩展性、部署和维护等方面有显著的区别。

单体架构

单体架构（Monolithic Architecture）是指将所有功能模块集成到一个单一的、不可分割的应用程序中。所有的业务逻辑、数据访问、用户界面等都在一个代码库中实现，并作为一个整体进行部署。

特点

单一代码库：所有功能模块共享一个代码库，集成到一个应用程序中。
统一部署：整个应用程序作为一个整体进行部署。
紧耦合：各个模块之间紧密耦合，修改一个模块可能会影响其他模块。

微服务架构

微服务架构（Microservices Architecture）是指将应用程序拆分为若干独立的小服务，每个服务负责特定的业务功能。各个服务独立开发、部署和维护，通过轻量级的通信机制（如HTTP、消息队列）进行交互。

特点

独立服务：每个服务独立开发、部署和维护，不同服务可以使用不同的技术栈。
松耦合：各个服务之间松耦合，通过API或消息队列进行通信。
高可用性：服务可以独立扩展和部署，提高系统的可用性和容错性。

如何权衡

在实际应用中，根据具体需求选择单体架构或微服务架构，下面为一些真实业务的权衡建议：

初创项目

单体架构：在初期阶段，使用单体架构快速开发和迭代，验证商业模式和用户需求。

大型应用

微服务架构：在系统规模增大后，逐步拆分为微服务架构，提高系统的扩展性和可维护性。

混合模式

结合使用：在某些情况下，可以结合单体架构和微服务架构。例如，核心业务逻辑使用单体架构，非核心业务逻辑使用微服务架构。

TCP 与 UDP

TCP 和 UDP 是两种常见的传输层协议，它们在可靠性、连接方式、数据传输模式和应用场景等方面有显著的区别。

TCP

TCP（Transmission Control Protocol）是一种面向连接的、可靠的传输层协议，提供数据传输的确认、顺序和错误检测功能。

特点

面向连接：在传输数据前，必须先建立连接（三次握手），传输完毕后需要断开连接（四次挥手）。
可靠传输：通过确认机制（ACK）保证数据包的可靠传输，确保数据包按顺序到达。
流量控制：通过滑动窗口机制进行流量控制，防止发送方发送数据过快导致接收方缓冲区溢出。
拥塞控制：通过拥塞避免和控制机制，避免网络拥塞，提高传输效率。

UDP

UDP（User Datagram Protocol）是一种无连接的、简单的传输层协议，不提供数据传输的确认、顺序和错误检测功能。

特点

无连接：不需要建立和断开连接，数据包独立传输。
不可靠传输：不保证数据包的可靠传输、顺序到达和无重复。
简单快速：没有复杂的确认和重传机制，传输效率高，延迟低。

如何权衡？

在实际应用中，根据具体需求选择 TCP 或 UDP，下面是一些实际场景的参考：

文件传输和网页浏览：选择TCP，确保数据的可靠性和完整性。

实时音视频和在线游戏：选择UDP，确保低延迟和快速响应，允许一定程度的数据丢失。

DNS查询和物联网：选择UDP，数据量小，允许重发请求，传输效率高。

总结

本文分析了系统设计时，最常见的 10个权衡以及它们的特点，通过 10个权衡可以从侧面反映出系统设计时，我们应该考虑的因素，让我们再回顾下这 10个权衡。

可扩展性与性能
延迟与吞吐量
SQL 与 NoSQL 数据库
一致性与可用性
强一致性与最终一致性
批处理与流处理
同步处理与异步处理
有状态架构与无状态架构
单体架构与微服务架构
TCP 与 UDP

在实际应用中，需要根据具体业务，具体需求选择选择合适的权衡，以实现最佳的系统性能和开发效率。一句话：脱离真实业务讲架构都是空谈！