一、分布式系统
简介
系统中的多个模块被部署于不同服务器之上，即可以将该系统称为分布式系统。如Web服务器与数据库分别工作在不同的服务器上，或者多台Web服务器被分别部署在不同服务器上。
演进
--从单体到微服务
分布式系统的本质，就是通过引入更多的硬件资源，解决单机无法承载的业务压力。其演进过程与业务发展密切相关：业务是核心驱动力，技术则是为业务提供支撑的手段
1. 初始阶段：单机架构
结构：应用程序与数据库服务器部署在同一台主机上。
特征：开发简单，部署方便。
局限：无法应对高并发，一旦主机宕机，整个业务立即瘫痪。
2. 纵向扩展：数据库与应用分离
结构：将应用程序和数据库服务器分别部署在不同的独立主机上。
提升：初步利用了多台主机的硬件资源，缓解了单台服务器在 CPU 和磁盘 I/O 上的竞争压力。
3. 高可用起步：引入负载均衡与应用集群
核心操作 ：应用服务器由单点变为集群 ，并在前端引入负载均衡器。
作用：负载均衡器将请求均匀分发给集群中的各个应用服务器。
关键价值 ：提高了系统可用性。当集群中某个主机宕机时，其他主机仍能继续提供服务，业务不中断。
4. 读写压力分担：数据库主从结构
结构 ：设置一个主节点（Master）负责写数据 ，多个从节点（Slave）负责读数据。
同步机制：主节点需要实时将修改后的数据同步给从节点。
目的：通过"读写分离"，大幅提升数据库在面对大量查询请求时的处理效率。
5. 性能飞跃：引入缓存（冷热数据分离）
角色 ：通常由 Redis 在分布式系统中扮演缓存角色。
原理：根据"二八原则"（80% 的请求集中在 20% 的热点数据上），将热点数据存入内存缓存中。
新挑战 ：引入缓存后，需要额外处理数据库与缓存之间的数据一致性问题。
6. 存储瓶颈突破：分库分表
操作：通过分库分表，将海量数据分散存储在不同的数据库和表里。
价值：进一步扩展了系统的存储空间和单表的查询性能，解决了单物理库的容量上限。
7. 终极形态：微服务架构
核心思想：从业务功能角度，对应用服务器进行深层次拆分。
操作 ：将原本臃肿的应用拆分成多个功能单一、逻辑简单、体积更小的服务节点。
意义：微服务架构彻底解决了大型项目中的开发效率与系统扩展性问题，使各业务模块可以独立演进。
分布式系统的演变不是一蹴而就的，而是业务规模与技术边界不断博弈的结果。其核心逻辑始终围绕着：如何利用更多的硬件，去解决更复杂的人与业务的问题。
二、中间件
和业务无关的服务(功能更通用的服务)
1.数据库
2.缓存(redis---热数据暂存---数据库和缓存数据库一致性问题
3.消息队列
... ...
三、衡量指标
可用性：系统整体可用的时间/总的时间（4个9即系统可以提供99.99%的可用性）
响应时长：衡量服务器的性能，指用户完成输入到系统给出用户反应的时长，越小越好
吞吐：衡量服务器的性能，考察单位时间段内，系统可以成功处理的请求的数量
并发：衡量服务器的性能，指系统同一时刻支持的请求最高量
四、主从集群
集群：被部署于多台服务器上的、为了实现特定目标的一个/组特定的组件，整个整体被称为集群。比如多个MySQL工作在不同服务器上，共同提供数据库服务目标，可以被称为一组数据库集群。
---主节点 (Master)负责处理写操作，并将数据同步给从节点;
---从节点 (Slave)：负责处理读操作，接收并执行来自主节点的数据同步命令
【服务器与数据库布局的演进如下】
【多机房，一个机房有多个服务器，多个服务器共享（缓存+主写+从读数据库）】
五、分片集群
数据量大到单台服务器的内存无法装下时，将数据分散存储在多个不同的 Redis 节点上，每个节点只负责一部分数据
【分库】
分库： 将原本存储在一个 逻辑数据库中的数据，分散存储到多个独立的数据库服务器
垂直分库：按照业务维度进行拆分。例如将"用户"、"商品"、"交易"相关的表分别存放在不同的数据库服务器中
【分表】
分表：是指在同一个数据库（或跨库）中，将一张大表拆分成多张物理小表
水平分表：最常见的形式。将一张巨型表按照某种规则（如按时间范围）拆分为表 1、表 2 等。例如，一个巨大的用户表可以被拆分成 128 个子表分布在不同主机上
六、微服务架构
微服务 是一种架构风格，它将一个大型的单一应用程序拆分为一组小型、松散耦合的服务
【主要特征】
单一职责： 每个服务只专注做好一件事（例如：用户服务只负责管理用户信息，订单服务只处理订单逻辑）。
自治性： 每个微服务都可以由不同的团队开发，使用不同的编程语言（如 Java, Go, Python），并拥有独立的数据库（防止数据耦合）。
独立部署： 修改某个功能时，只需重新部署对应的微服务，而不需要重启整个庞大的系统。
去中心化治理： 不强求统一的技术栈，团队可以根据业务场景选择最合适的工具。
【问题缺点】
运维复杂度显著增加：需要管理成百上千个服务的部署、监控、日志收集和治理工作。这通常要求具备成熟的容器化（如 Docker/K8s）和 CI/CD 能力。
分布式系统的复杂性：
服务间通信：服务需要通过网络（消息队列等）进行通信，这会带来额外的网络延迟和不确定性。
分布式事务：在跨多个服务时，保证数据的一致性变得非常困难。
测试与调试难度：由于服务间存在复杂的调用链路，定位 bug 往往需要借助分布式链路追踪系统。
资源消耗：每个微服务通常都有自己的运行环境（如 JVM）和数据库，这可能导致内存和存储资源的占用比单体架构更高。
【核心组件】
服务注册与发现： 动态记录各个服务的 IP 和端口。
API 网关： 系统的单一入口，负责请求路由、负载均衡、认证和限流。
配置中心： 集中管理所有服务的配置文件。
容错与熔断： 防止某个服务故障引发系统雪崩。
链路追踪： 监控一个请求在各个服务之间的调用路径
