高并发系统设计知识点

高并发系统设计的通用方法

高并发系统的设计方法可类比治理洪水的思路，主要有三种核心方法：

1. 扩展策略：Scale-up vs Scale-out

Scale-up（纵向扩展）

定义：通过提升单机硬件性能来提高系统并发处理能力
原理：类比"摩尔定律"，追求单机性能的不断提升
优点：实施简单，能用硬件解决的问题直接用硬件解决
适用场景：系统设计初期，并发量较小时

Scale-out（横向扩展）

定义：通过多台低性能机器组成分布式集群来共同抵御高并发流量
原理：类比 CPU 多核技术，增加处理单元数量
优点：可突破单机性能限制，理论上可无限扩展
缺点：引入分布式系统的复杂性问题
- 节点故障时如何保证整体可用性
- 多节点状态同步时如何保证一致性
- 如何实现对使用方无感知的节点增删

2. 缓存策略：提升系统性能

缓存的普遍性

缓存遍布系统设计的各个角落（操作系统、浏览器、数据库、消息队列等）

缓存的性能优势

磁盘寻道时间：约 10ms
CPU 执行指令和内存寻址时间：ns（纳秒）级别
千兆网卡读取数据时间：μs（微秒）级别
核心原理：在计算机体系中，磁盘是最慢的组件，比其他组件慢几个数量级
解决方案：使用内存作为存储介质的缓存可大幅提升性能

缓存的定义

广义缓存：任何能降低响应时间的中间存储都可称为缓存

3. 异步处理：提升系统吞吐量

同步调用的问题

定义：调用方需阻塞等待被调用方法逻辑执行完成
缺点：高并发下容易导致系统性能下降甚至雪崩

异步调用的优势

定义：调用方不需等待方法逻辑执行完成即可返回处理其他逻辑
实现方式：通过回调、事件通知等方式将结果反馈给调用方
典型案例：12306 网站订票系统
- 将请求放入消息队列，快速响应用户
- 释放资源处理更多请求
- 订票请求处理完后再通知用户成功或失败

高并发系统的演进原则

高并发系统设计应遵循循序渐进的原则，具体演进路径如下：

1. 起步阶段：简单优先

设计原则：从最简单的系统设计开始
目标导向：满足当前业务需求和流量
技术选择：选择最熟悉的技术栈

2. 发展阶段：逐步优化

随着流量增加和业务变化，逐步修正架构中的问题点：

核心优化方向

解决单点问题
解决横向扩展问题
替换性能无法满足需求的组件

技术选型原则

优先选择社区成熟且团队熟悉的组件
仅在没有合适解决方案时自研

3. 成熟阶段：架构重构

重构时机：当小修小补无法满足需求时
重构方式：考虑重构或重写

架构分层

什么是分层架构

经典分层架构模式

MVC 架构
- 组成：Model（模型）、View（视图）、Controller（控制器）三层
- 优势：实现了表现和逻辑的解耦
三层架构
- 表现层：展示数据结果和接受用户指令，最靠近用户
- 逻辑层：实现复杂业务逻辑
- 数据访问层：处理和存储之间的交互

分层架构应用实例

OSI 网络七层模型
TCP/IP 四层协议
Linux 文件系统的分层设计

分层架构的优势

1. 简化系统设计

职责分离：让不同的人专注做某一层次的事情
关注点聚焦：只需关注自己负责层的内容，无需了解其他层的细节

2. 高度复用

能力抽取：可以将某一层的通用能力抽取独立，供其他系统使用
效率提升：减少研发周期，提升研发效率

3. 便于横向扩展

针对性扩展：可针对性能瓶颈层单独扩展
成本优化：相比整体系统扩展，付出的代价更小
高并发支撑：支撑高并发的系统通常都是分层的系统

如何做系统分层

1. 明确层次边界

挑战：随着业务复杂度增加，边界可能变得模糊
解决方案：需要清晰定义各层的职责和接口

2. 阿里巴巴推荐的分层架构

从上到下的层次结构：

终端显示层：各端模板渲染并执行显示
开放接口层：封装 Service 层方法为开放接口，进行网关安全控制和流量控制
Web 层：访问控制转发、参数校验、简单业务处理
Service 层：业务逻辑层
Manager 层：通用业务处理层
- 下沉通用能力（缓存和存储交互策略，中间件接入）
- 封装第三方接口调用
DAO 层：数据访问层
外部接口层：第三方平台接口

3. 遵循层次调用规则

相邻依赖：层次之间只能相邻层互相依赖
数据流转：数据只能在相邻的两层之间流转
严格调用：严格遵守层级调用，不允许跨层访问

分层架构的局限性

1. 增加代码复杂度

层次冗余：需要在中间插入多个层次，每个层次可能只是简单的数据传递
修改成本：小需求可能需要修改所有层的代码
调试困难：调试复杂度增加

2. 性能损耗

网络开销：如果每个层次独立部署，层次间通过网络交互会有性能损耗
多跳问题：所谓的"多一跳"问题，是服务化架构性能略差于单体架构的原因

软件设计原则与分层架构的关系

1. 单一职责原则

每一层拥有单一职责，层与层之间边界清晰

2. 迪米特法则

数据交互不能跨层，只能在相邻层之间进行

3. 开闭原则

将抽象层和实现层分离，抽象层不可修改，具体实现可扩展替换

系统设计目标 1：如何提升系统性能

高并发系统设计的三大目标

1. 高性能

定义：反映系统的使用体验
核心指标：响应时间决定用户感受

2. 高可用

定义：表示系统正常服务用户的时间
核心要求：保障服务的持续稳定运行

3. 可扩展性

定义：系统应对峰值流量和快速扩容的能力
核心能力：弹性伸缩和容量规划

性能优化原则

1. 问题导向

避免盲目优化：不能盲目优化，避免增加系统复杂度和浪费开发时间

2. 遵循八二原则

高效优化：用 20%的精力解决 80%的性能问题
重点突破：优先优化主要瓶颈点

3. 数据支撑

量化管理：优化过程中需要量化指标，了解优化效果

4. 持续优化

长期过程：性能优化是一个持续过程，需要不断寻找瓶颈并优化

性能的度量指标

1. 响应时间

系统接口的响应时间是最基本的度量指标，常用统计特征值有：

平均值：所有请求响应时间的平均值
- 特点：敏感度较差
最大值：所有请求中响应时间最长的值
- 特点：过于敏感
分位值：如 90 分位、95 分位、99 分位
- 优势：最适合度量性能
- 原因：排除偶发极慢请求的影响，能够更好地反映整体性能状况

2. 吞吐量

关系：通常与响应时间成倒数关系
示例：
- 响应时间为 1s 时，吞吐量是每秒 1 次
- 响应时间缩短到 10ms，吞吐量上升到每秒 100 次

3. 用户体验标准

从用户体验角度定义的响应时间标准：

200ms：用户感觉不到延迟，如瞬时发生
1s：用户可感受到延迟但可接受
超过 1s：用户有明显等待感，体验变差

健康系统标准：

99 分位响应时间应控制在 200ms 内
99.99% 请求不超过 1s

高并发下的性能优化策略

1. 提高系统的处理核心数

基本原理

目标：增加系统的并行处理能力
理想公式：吞吐量 = 并发进程数 / 响应时间

阿姆达尔定律

描述了并发进程数与响应时间的关系：

公式：加速比 = 1/(1-p+p/s)
- p：可并行部分占比
- s：并行进程数
边界情况：
- 当任务完全并行(p=1)时，加速比等于并行进程数
- 当任务完全串行(p=0)时，加速比为 1，无法加速

拐点模型

并发进程数增加到某个临界点后，系统性能反而下降：

轻压力区：响应时间平稳，吞吐量与并发用户数线性相关
重压力区：系统资源利用率达到极限，吞吐量下降趋势，响应时间略升
拐点区：系统超负荷，吞吐量下降，响应时间大幅上升

2. 减少单次任务响应时间

CPU 密集型系统

特征：处理大量 CPU 运算的系统
优化手段：选用更高效算法，减少运算次数
分析工具：Linux 的 perf、eBPF 等 Profile 工具

IO 密集型系统

特征：系统大部分操作在等待 IO 完成（磁盘 IO 和网络 IO）
常见系统：数据库系统、缓存系统、Web 系统

瓶颈发现方法：

使用 Linux 工具分析网络、磁盘、内存等
通过监控系统分时统计每个步骤耗时

针对性优化：

数据库问题：检查锁表情况、索引设计、JOIN 操作、缓存等
网络问题：优化网络参数、检查超时重传、分析网卡丢包等

系统设计目标 2：系统怎样做到高可用？

可用性的度量

1. MTBF（Mean Time Between Failure）

定义：平均故障间隔时间
含义：代表两次故障的间隔时间，即系统正常运转的平均时间
影响：该值越长，系统稳定性越高

2. MTTR（Mean Time To Repair）

定义：平均故障恢复时间
含义：表示故障平均恢复时间，也可理解为平均故障时间
影响：该值越小，故障对用户的影响越小

3. 可用性计算公式

公式：Availability = MTBF / (MTBF + MTTR)
结果表示：计算结果是一个比例，通常用"几个九"来描述

4. 不同级别的可用性标准

可用性级别	百分比	每年停机时间
一个九	90%	约 36.5 天
两个九	99%	约 3.65 天
三个九	99.9%	约 8.76 小时
四个九	99.99%	约 52.6 分钟
五个九	99.999%	约 5.26 分钟

5. 可用性等级与保障措施

一到两个九：基本人工运维即可满足
三到四个九：需要完善的运维值班体系、故障处理流程、业务变更流程和系统设计考量
五个九以上：需要系统具备容灾和自动恢复能力，靠人工无法达到
业务标准：核心业务系统通常需达到四个九，非核心系统可容忍三个九

高可用系统设计方法

1. 系统设计方面

Failover（故障转移）

对等节点间的故障转移

节点特征：所有节点都承担读写流量且无状态
容错机制：节点间可互为镜像
故障处理：某节点失败时可随机访问另一节点
应用实例：Nginx 配置 Tomcat 节点故障转移

非对等节点间的故障转移

节点架构：涉及主节点和备用节点（热备或冷备）
检测机制：需要故障检测机制，如"心跳"机制 故障切换流程：
长时间无心跳应答时认为主节点故障
通过分布式一致性算法（如 Paxos、Raft）选择新主节点

调用超时控制

风险识别

系统模块间调用最大的风险是延迟而非失败
调用延迟会导致线程阻塞，资源无法释放
大量阻塞请求可能导致系统资源耗尽而崩溃

超时设置策略

设置原则：应设置合理的超时时间
平衡考虑：
- 太短会产生大量超时错误影响用户体验
- 太长则起不到保护作用
建议方案：通过 99%响应时间统计数据来确定超时时间
动态调整：超时时间需要在系统维护过程中不断调整

降级

核心思想

为保证核心服务稳定而牺牲非核心服务的做法

应用实例

发微博时可暂时关闭反垃圾检测服务，确保主体流程稳定

限流

保护机制

通过对并发请求限速来保护系统

实施方式

限制单机每秒处理 1000 次请求，超过部分直接返回错误
虽然损害用户体验，但在极端并发下是必要的短期措施

2. 系统运维方面

灰度发布

发布策略

系统变更不一次性全量推送，而是按比例逐步推进
通常以机器维度进行，如先在 10%机器上变更

验证流程

观察系统性能指标和错误日志，稳定后再全量变更
能在线上流量中观察变更影响，是保障高可用的重要环节

故障演练

演练目的

对系统进行破坏性测试，观察局部故障对整体系统的影响
发现潜在的可用性问题

演练方法

类似"混沌工程"思路，如 Netflix 的 Chaos Monkey 工具
随机关闭线上节点模拟故障，评估影响
建议在与生产环境相同的线下系统进行演练

开发与运维的关注点差异

开发关注点：如何处理故障

关键词：“冗余"和"取舍”
冗余：备用节点、集群替代故障服务
取舍：牺牲部分功能保障主体服务

运维关注点：如何避免故障发生

更注重变更管理和故障演练
两者结合形成完善的高可用体系

平衡考虑

提高系统可用性可能需要牺牲用户体验或系统性能
不同系统对可用性要求不同
核心系统四个九已可满足需求，无需盲目追求更高
某些系统(如配置下发系统)可能追求极致可用性而非性能

系统设计目标 3：如何让系统易于扩展

高可扩展性的意义

突发流量应对

现状：系统通常预留 30%-50%的冗余
挑战：突发事件可能导致流量瞬间增加 2-3 倍

快速扩容能力

应急方案：当架构改造来不及时，最快的应对方式就是堆机器
理想目标：线性扩展，增加 N 倍机器应该支持 N 倍流量

为什么提升扩展性会很复杂

1. 资源争抢的拐点问题

单机系统：过多并行任务会导致性能拐点，系统处理能力不升反降
集群系统：不同层次可能存在瓶颈点制约横向扩展

2. 系统瓶颈的多样性

数据库请求量限制：如数据库无法支持 10 倍于当前的请求量
网络带宽限制：如 30 台机器的前端负载均衡可能超过千兆带宽限制

3. 有状态服务扩展难题

无状态服务：如 Web 服务，易于扩展
有状态服务：如 MySQL 等存储服务，难以扩展，涉及大量数据迁移

4. 需要全局视角

考虑因素：数据库、缓存、依赖的第三方、负载均衡、交换机带宽等
预判能力：需要预判哪个因素会成为系统瓶颈点

高可扩展性的设计思路

1. 存储层的扩展性

存储层拆分主要遵循两个维度：

业务维度拆分

拆分原理

不同业务模块的数据量和访问量差异巨大
针对瓶颈点做针对性拆分

拆分实例

场景：社区系统中，关系数据量大于用户数据，但用户数据访问量大于关系数据
方案：如数据容量是瓶颈，则拆分关系模块数据
结果：拆分后可获得用户库、内容库、评论库、点赞库和关系库

拆分优势

故障隔离：某一库故障不影响其他数据库

数据特征水平拆分

拆分时机

当单一业务数据库容量或并发请求量超过单机限制时需要水平拆分

拆分方法

给用户库增加节点，按算法将用户数据拆分到多个库

注意事项

数据迁移成本：增加节点需要数据迁移，成本高，最好一次性增加足够节点
避免跨库事务：尽量不使用事务，避免二阶段提交的高协调成本

2. 业务层的扩展性

业务层拆分可从三个维度考虑：

业务维度拆分

拆分策略

相同业务的服务拆分为独立业务池

拆分实例

业务池划分：用户池、内容池、关系池、评论池、点赞池、搜索池
依赖关系：每个业务依赖独立数据库资源，不依赖其他业务的数据库

扩展优势

当某业务成为瓶颈，只需扩展该业务池及其上下游依赖

重要性维度拆分

拆分原理

将业务分为核心池和非核心池

拆分实例

核心池：关系池中，关注/取消关注接口
非核心池：拉黑/取消拉黑接口

管理策略

优先保证核心池性能，流量上升时优先扩容核心池
必要时可降级非核心池接口，保证整体稳定性

请求来源维度拆分

拆分依据

根据接入客户端类型不同做业务池拆分

拆分实例

外网池：服务客户端接口
H5 池：服务小程序/H5
内网池：服务内部接口

扩展性与系统复杂度的权衡

系统简单性

未做拆分的系统虽扩展性不强，但足够简单，开发维护投入少

拆分后的挑战

开发复杂度：需求开发可能横跨多个系统和团队
问题排查：故障定位和问题排查更复杂
运维挑战：每个子系统都需要专人负责，对团队是较大挑战

池化技术：减少频繁创建数据库连接的性能损耗

频繁创建数据库连接的性能问题

连接建立过程

数据库连接建立过程耗时明显，主要由两部分组成：

TCP 三次握手：客户端发送 SYN 包，服务端回复 ACK+SYN 包，客户端再回复 ACK 包
MySQL 认证过程：服务端要求认证，客户端发送加密密码，服务端验证并确认

性能对比

传统方式：每次 SQL 执行都建立新连接，1 秒仅能执行约 200 次查询
连接复用：1 秒可执行约 1000 次查询，性能提升 5 倍

数据库连接池工作原理

1. 核心配置参数

最小连接数：连接池维持的最少连接数量
最大连接数：连接池允许的最大连接数量

2. 连接获取流程

如果当前连接数小于最小连接数，创建新连接
如果连接池有空闲连接，直接复用
如果无空闲连接且当前连接数小于最大连接数，创建新连接
如果当前连接数已达最大连接数，等待配置的超时时间
如果等待超时，向用户抛出错误

3. 推荐配置

线上环境：最小连接数约 10，最大连接数约 20-30

连接池的维护问题

连接失效原因

数据库 IP 变更，池中连接仍使用旧 IP
MySQL 的 wait_timeout 参数导致闲置连接被数据库主动关闭

解决方案

定期检测（推荐）：启动线程定期检测连接是否可用（如发送 select 1 命令），移除异常连接
使用前检测（不推荐）：获取连接后先校验可用性，若不可用再获取新连接（引入额外开销，生产环境不推荐）

线程池技术

基本原理

同样基于池化思想，线程池用于减少线程频繁创建、销毁的开销

主要参数

coreThreadCount：核心线程数
maxThreadCount：最大线程数

处理流程

线程数少于 coreThreadCount，创建新线程处理任务
线程数已达 coreThreadCount，任务进入队列，由空闲线程执行
队列已满，继续创建线程直到达到 maxThreadCount
线程数达到 maxThreadCount，新提交任务会被丢弃

线程池使用注意事项

1. JDK 线程池与 IO 密集型任务的不匹配

JDK 特点：ThreadPoolExecutor 优先把任务放入队列，适合 CPU 密集型任务
Web 系统特点：多为 IO 密集型任务，使用 Tomcat 改造的线程池更合适（优先创建线程）

2. 监控队列堆积情况

重要指标：队列任务堆积是重要监控指标，特别是对实时性要求高的任务
实际案例：线程池参数设置过小导致任务长时间未执行

3. 避免使用无界队列

风险识别：无界队列虽不会丢弃任务，但大量堆积会占用大量内存
性能影响：可能触发频繁 Full GC，造成服务不可用

池化技术的本质与应用

1. 核心思想

设计理念：空间换时间
实现方式：
- 预先创建对象减少频繁创建的性能开销
- 统一管理对象降低使用成本

2. 适用场景

对象创建过程耗时或消耗资源大
对象会被频繁创建和销毁

3. 注意事项

池子预热：使用前预先初始化所有对象，避免系统重启后产生慢请求
合理配置：根据经验设置初值，再根据运行情况调整
资源管理：关注空间占用，避免内存泄露或频繁垃圾回收

数据库优化方案 1：查询请求增加时的主从分离

主从读写分离的意义

1. 读多写少的访问模式

系统特点：大部分系统遵循读多写少的模式，读写请求量差距可达几个数量级
典型案例：
- 刷朋友圈请求量远大于发朋友圈
- 商品浏览量远大于下单量

2. 横向扩展策略

扩展方式：通过读写分离可针对读流量单独扩展
设计理念：类似交通管制，将资源优先分配给重要的流量
实际效果：是解决数据库突发读流量问题的有效方法

性能参考

单机 MySQL 在 4 核 8G 机器上约能支撑 500 TPS 和 10000 QPS

主从读写的技术关键点

1. 主从复制原理

复制过程

从库创建 IO 线程，请求主库的 binlog 并写入 relay log
主库创建 log dump 线程发送 binlog 给从库
从库创建 SQL 线程读取 relay log 并在从库中回放

异步复制特点

性能优势：主库写入流程不会等待主从同步完成
一致性风险：极端情况下可能导致主从数据不一致
可接受性：概率低，互联网项目通常可接受

部署模式

一主多从：写入只写主库，读取只读从库
扩展能力：可部署多个从库共同承担读流量
备用功能：从库也可作为备库，避免主库故障导致服务中断
规模限制：通常一个主库最多挂 3-5 个从库（受限于主库资源和网络带宽）

2. 主从延迟问题

主从延迟影响

查询问题：更新数据后立即查询可能查不到最新数据
典型场景：更新主库后，消息队列处理程序在从库查询不到数据

解决方案

数据冗余（推荐）：发送消息时包含完整数据而非仅 ID
- 优点：简单易实现
- 缺点：可能增加消息大小
使用缓存：同步写数据库的同时写入缓存
- 适用：新增场景
- 风险：更新场景可能导致数据不一致
查询主库：特殊场景直接查主库
- 限制：慎用，避免主库压力过大

监控与排查

关键指标：从库落后时间是重要监控指标
正常水平：正常时延迟应在毫秒级别
问题排查：诡异的数据查询不到问题可能是主从延迟导致

3. 数据库访问方式

随着主从分离，数据库访问方式变复杂，需要使用中间件解决：

内嵌型中间件

代表产品：淘宝 TDDL、网易 DDB
特点：以代码形式内嵌在应用程序内部
优点：简单易用，无部署成本，适合小团队
缺点：缺乏多语言支持，版本升级困难

代理层方案

代表产品：Cobar、Mycat、Atlas、DBProxy 等
特点：独立部署在服务器上
优点：支持多语言，方便维护升级，适合大中型团队
缺点：跨两次网络，性能有损耗

使用注意事项

深入了解：必须对中间件有足够深入了解
实际案例：切换到 Sharding-JDBC 时因使用姿势不对导致问题
关注要点：需要了解中间件可能的性能瓶颈和功能边界

主从复制的广泛应用

技术普及

Redis 通过主从复制实现读写分离
Elasticsearch 索引分片可复制到多个节点
HDFS 文件会被复制到多个 DataNode

主从复制设计的核心考量

1. 一致性与性能的权衡

强一致性影响：要保证所有从节点写入成功则影响写入性能
性能优先风险：只写主节点立即返回会有数据同步失败风险
互联网选择：互联网项目通常优先考虑性能而非强一致性

2. 主从延迟的监控

关键地位：关键监控指标
问题关联：诡异的数据读取问题通常与此相关

数据库优化方案 2：写入数据量增加时的分库分表

分库分表的基本概念

核心定义

本质：是一种数据分片方式，目的是将数据尽量平均地分配到多个数据库节点或表中

与主从复制的关键区别

主从复制：数据是全量复制到多个节点
分库分表：每个节点只保存部分数据

主要优势

有效减少单个数据库节点和表中的数据量
提升数据查询性能
分散写入请求到多个节点，提升并发写入性能
实现不同业务模块的故障隔离

垂直拆分

基本定义

将数据库的表按业务拆分到多个不同的数据库中

拆分原则

核心思想：专库专用
具体方法：按照业务类型来拆分
耦合原则：将业务耦合度高的表拆分到同一个库中

应用案例

微博系统拆分：
- 用户相关表分到用户库
- 内容相关表分到内容库
- 关系相关表分到关系库

局限性

不能解决某一业务模块数据量暴增问题
当数据量继续增长，还需要进行水平拆分

水平拆分

基本定义

将单一数据表按照某种规则拆分到多个数据库和表中

关注差异

垂直拆分：关注业务相关性
水平拆分：关注数据特点

常见拆分规则

1. 按哈希值拆分

适用场景：实体表（如用户表、内容表）
拆分方法：通常按 ID 字段哈希后取模确定分库分表位置
实例：用户表拆分成 16 库 64 表，先对用户 ID 哈希，对 16 取余确定库，对 64 取余确定表

2. 按区间拆分

拆分依据：通常使用时间字段作为拆分依据
实例：按创建时间将一个月的数据放入一张表
适用场景：列表数据（如订单、内容发布记录等）

注意事项

热点问题：区间拆分可能存在热点问题（最近数据访问频繁）
表准备：使用区间拆分时需提前建立好数据表，避免新时间段没有对应表的问题

分库分表引入的问题及解决方案

分区键问题

问题描述：
- 分库分表后引入了分区键（分库分表键）
- 所有查询都需要带上分区键才能定位数据
- 不带分区键的查询需向所有库表发送命令，性能极差
解决方案：建立映射表，如昵称到 ID 的映射，先查映射再查详细数据

跨库操作问题

问题描述：多表 join 在分库后无法通过单个 SQL 完成
解决方案：在应用层代码中进行数据关联

聚合操作问题

问题描述：count()等聚合函数在分库分表后需要合并结果
解决方案：将计数数据单独存储在一张表或记录在 Redis 中

数据迁移与扩容问题

问题描述：从单库单表迁移到多库多表是复杂且容易出错的过程
解决方案：一次规划到位，如 16 库 64 表通常能满足几年内业务需求

分库分表的最佳实践

实施原则

保守策略：如果性能上没有瓶颈，尽量不做分库分表
一次到位：如果要做，尽量一次规划到位
替代方案：考虑使用支持 auto sharding 的 NoSQL 数据库作为替代方案（如 HBase、MongoDB）

实施建议

深入理解：深入理解原理，明确拆分后带来的问题及解决方案
场景匹配：结合业务场景选择合适的拆分方式
容量规划：评估现有和未来数据量，合理规划拆分粒度
迁移准备：做好数据迁移和验证计划

发号器：保证分库分表后 ID 的全局唯一性

数据库主键的选择

主键选择方式

业务字段主键：使用业务字段作为主键（如手机号、邮箱、身份证号）
生成 ID 主键：使用生成的唯一 ID 作为主键

业务字段作为主键的局限性

变更风险：业务字段可能会发生变更（如手机号、邮箱可变）
场景限制：某些业务场景缺乏合适的业务字段（如评论表）
维护成本：业务字段变更会导致外键关联表全部变更，工作量巨大

自增 ID 的局限性

范围限制：分库分表后自增 ID 只能保证单库唯一，不能保证全局唯一
数据风险：可能导致跨库存在相同 ID 的情况，引起数据混乱

UUID 方案及其局限性

UUID 优点

独立性强：不依赖于第三方系统，性能和可用性好
应用广泛：可用于生成请求 ID 等场景 UUID 作为数据库主键的缺点
有序性缺失：不是单调递增，缺乏有序性
性能问题：在 B+树索引中性能较差（无序 ID 导致频繁的数据移动）
业务含义：不具备业务含义，难以从 ID 反推业务信息
空间占用：占用空间较大（32 位 16 进制字符串）

基于 Snowflake 算法的发号器

Snowflake 算法原理

设计思路：将 64 位二进制数字分成多个部分，每部分具有特定含义
标准结构：1 位符号位 + 41 位时间戳 + 10 位机器 ID + 12 位序列号

Snowflake 生成的 ID 特点

全局唯一：不同机器、不同时间生成的 ID 不会重复
单调递增：按时间顺序递增，有序 ID 提升数据库写入性能
业务含义：可从 ID 反解出时间、机房、机器等信息
高性能：单实例单 CPU 可达到每秒 2 万次生成速度

Snowflake 算法的变种

可根据业务需求调整各部分占用的位数：

时间戳位：41 位时间戳可支持 69 年（基于自定义起始时间）
机器 ID 位：可细分为 IDC 标识和机器标识
业务标识位：可增加业务 ID 字段区分不同业务
序列号位：控制每毫秒可生成的 ID 数量

发号器的部署方式

嵌入式部署

部署方式：将算法嵌入到业务代码中，分布在业务服务器上
优点：无需跨网络调用，性能更好
缺点：需要更多机器 ID 位数，难以保证机器 ID 唯一性
解决方案：引入 ZooKeeper 等组件保证机器 ID 唯一

独立服务部署

部署方式：作为独立服务部署，业务通过网络调用获取 ID
优点：节省机器 ID 位数，配置简单
缺点：增加网络调用开销
部署模式：通常采用主备方式部署，可达到每秒 2 万 QPS

Snowflake 算法的潜在问题及解决方案

系统时钟依赖问题

问题描述：依赖系统时间戳，时钟回拨可能导致生成重复 ID
解决方案：检测到时钟不准时，暂时拒绝发号直到时钟恢复正确

分库分表不均匀问题

问题描述：低 QPS 场景下，序列号末位可能固定，导致分库分表数据不均匀
解决方案：
- 时间戳记录到秒而非毫秒级别
- 序列号起始值随机化，避免固定模式

其他发号器方案

业界其他方案

基于数据库的发号器：如美团、滴滴提出的方案
微信 seqsvr：微信的序列号发生器
百度 UidGenerator：百度开源的分布式 ID 生成器

NoSQL：高并发场景下与关系型数据库的互补

NoSQL 的概念与分类

NoSQL 定义

不同于传统关系型数据库的数据库系统统称，通常不使用 SQL 作为查询语言

NoSQL 的主要分类

KV 存储：如 Redis、LevelDB，具有极高的读写性能
列式存储：如 HBase、Cassandra，以列为单位存储，适合离线数据统计
文档型数据库：如 MongoDB、CouchDB，特点是 Schema Free，字段可灵活扩展

NoSQL 的应用场景

弥补传统数据库在性能方面不足
简化数据库变更操作，无需修改已有数据结构
适合处理大数据量的场景

提升写入性能的 NoSQL 设计

传统关系型数据库写入性能瓶颈

磁盘随机 IO 开销：B+树索引导致插入和更新时需要寻道
页分裂问题：数据插入导致页分裂时会移动大量数据

LSM 树（Log-Structured Merge Tree）存储引擎

应用范围：多种 NoSQL 数据库（HBase、LevelDB 等）采用的方案
核心原理：牺牲部分读性能换取更高的写入性能

数据处理流程：

数据先写入 MemTable 内存结构（有序存储）
同时写入 WAL（Write Ahead Log）防止数据丢失
MemTable 达到一定规模后刷新到 SSTable（Sorted String Table）文件
多个 SSTable 定期合并减少文件数量

优势：将随机 IO 变成顺序 IO，大幅提高写入性能

特定场景下的 NoSQL 应用

全文搜索场景

关系型数据库全文搜索的局限性：

索引限制：LIKE 查询在前模糊匹配时无法使用索引（如name LIKE '%电冰箱'）
性能问题：全表扫描性能极差

Elasticsearch 等基于倒排索引的 NoSQL 解决方案：

倒排索引原理：将文本分词后建立词与记录 ID 的映射关系
搜索能力：支持高效的全文搜索和复杂的搜索表达式
分布式能力：提供分布式搜索能力，解决传统数据库难以解决的问题

提升系统扩展性的 NoSQL 设计

关系型数据库扩展的挑战

再次拆分：分库分表后数据增长快速时需要进一步拆分
迁移复杂：数据迁移复杂，容易出错

MongoDB 等 NoSQL 数据库的扩展性优势

Replica（副本集）：

功能类似：类似主从分离，保证数据多副本存在
读写分离：主节点处理写请求，从节点分担读请求
故障恢复：主节点故障时自动选举新主节点

Shard（分片）：

功能类似：类似分库分表，但自动化程度高
组成部分：存储数据的 Shard Server、存储元信息的 Config Server、负责路由的 Route Server

负载均衡：

自动检测：自动检测分片之间数据不均衡情况
自动平衡：启动 Balancer 进程重新分配数据
自动扩展：添加新节点时自动迁移数据，减少人工干预

NoSQL 使用的注意事项

深入理解要求

选型原则：选型时必须对 NoSQL 实现原理有深入了解
运维能力：需要具备足够的运维能力，应对可能出现的问题
避免盲目：仅使用表面 API 而缺乏深入理解可能导致线上问题难以解决
合理选择：NoSQL 作为关系型数据库的补充，需要结合业务场景灵活使用

缓存系统：动态数据查询加速与使用策略

缓存的基本概念

缓存定义

基本定义：缓存是一种存储数据的组件，目的是让对数据的请求更快地返回
技术定位：位于速度相差较大的两种硬件之间，用于协调数据传输速度差异的结构
设计思路：空间换时间的性能优化手段，广泛应用于多种场景

硬件延迟对比

内存寻址：约 100ns
磁盘查找：约 10ms
性能差异：两者性能差异达 10 万倍量级

缓存与缓冲区的区别

缓存：用于提高低速设备访问速度或减少复杂计算的开销
缓冲区：临时存储数据的区域，弥补高速设备和低速设备通信时的速度差

缓存的分类

静态缓存

应用场景：用于缓存不经常变化的静态数据，如门户网站文章内容
实现方式：生成 Velocity 模板或静态 HTML 文件
适用时期：Web 1.0 时期的内容管理系统，新浪、网易等门户网站
性能优势：减少对应用服务器和数据库的压力，提供极高的性能

分布式缓存

应用场景：用于缓存动态数据，如 Memcached、Redis
技术特点：性能强劲，可通过分布式方案组成集群突破单机限制
架构地位：在整体架构中承担着重要角色

本地热点缓存

部署方式：部署在应用服务器的代码中，阻挡热点查询
实现技术：HashMap、Guava Cache、Ehcache 等
性能特点：不需要跨网络调用，速度极快
适用场景：极端热点数据查询，如明星微博热门话题

缓存的不足

适用场景限制

适合读多写少且数据具有热点属性的业务

系统复杂度影响

引入缓存组件导致系统架构更复杂

数据一致性风险

更新数据库成功但更新缓存失败时会导致脏数据

资源限制

内存作为存储介质并非无限，需评估数据存储量级

运维成本

需对缓存组件有了解，故障排查更复杂

缓存读写策略

1. Cache Aside（旁路缓存）策略

核心思想

以数据库中的数据为准，缓存中的数据按需加载

读策略

先读缓存，缓存命中则直接返回
缓存未命中则查询数据库
查到数据后写入缓存并返回

写策略

先更新数据库
再删除缓存（不是更新缓存）

优缺点

优点：实现简单，适用于大多数场景
缺点：写入频繁时缓存命中率可能较低

2. Read/Write Through（读穿/写穿）策略

核心思想

用户只与缓存交互，由缓存组件负责与数据库通信

读策略

缓存命中直接返回
缓存未命中则由缓存组件从数据库加载

写策略

更新缓存数据
由缓存组件同步更新到数据库

适用场景

本地缓存如 Guava Cache 的 Loading Cache
需要缓存组件支持与数据库通信

3. Write Back（写回）策略

核心思想

写入时只写入缓存并标记为"脏"，只有再次使用时才写入后端存储

写策略

只写入缓存，标记为"脏"
异步批量写入后端存储

适用场景

操作系统的 Page Cache
日志的异步刷盘
消息队列的异步写入磁盘

优缺点

优点：性能极高，避免了直接写磁盘的随机写问题
缺点：缓存掉电可能导致数据丢失

缓存高可用设计

1. Redis 单点问题解决方案

Redis Sentinel（哨兵）模式

架构组成：主从服务器+哨兵集群
哨兵职责：监控 Redis 服务、主库故障转移、配置中心、客户端通知

工作原理：

定期发送 PING 命令检测 Redis 实例是否存活
主观下线：单个哨兵认为实例不可用
客观下线：多数哨兵认为实例不可用
自动选择新主库并通知客户端

Redis Cluster（集群）模式

架构特点：无中心化，多主多从，数据分片存储
分片原理：将数据库分为 16384 个槽位，每个主节点负责一部分槽位
命令路由：客户端通过计算键的槽位确定目标节点
故障转移：由从节点接管主节点的槽位
适用场景：需要大容量数据存储，单机 Redis 无法满足需求

2. 缓存可用性提升技术

客户端缓存

实现方式：缓存 SDK 实现一个本地缓存，减轻服务端压力
技术选择：使用 Guava Cache 等本地缓存组件
性能优势：降低网络开销，提升响应速度

多级缓存

架构设计：构建"本地缓存 → 分布式缓存 → 数据库"的多级缓存架构
性能优势：减轻 Redis 集群压力，提升整体性能
关键挑战：多级缓存数据一致性保障

热点数据处理

缓存预热：系统上线前将热点数据提前载入缓存
缓存降级：缓存失效时，降级直接返回默认值而不查询数据库
防止缓存雪崩：给过期时间添加随机值，避免同时过期

缓存穿透、击穿与雪崩

缓存穿透

定义：请求查询一个必定不存在的数据，导致请求直接落到数据库
危害：可能导致数据库压力过大而宕机

解决方案：

接口校验：接口层增加校验，过滤不合理请求
缓存空值：对不存在的数据也进行缓存
布隆过滤器：快速判断数据是否可能存在

缓存击穿

定义：热点 key 在某个时间点过期，大量请求直接落到数据库

解决方案：

互斥锁：保证同一时间只有一个线程查询数据库
热点数据永不过期：通过后台异步更新保持数据最新

缓存雪崩

定义：大量缓存在同一时间过期或缓存服务宕机

解决方案：

过期时间随机化：过期时间添加随机值，避免同时过期
高可用集群：构建高可用的缓存集群
熔断降级：暂停非核心服务
隔离机制：避免级联失败

CDN 加速静态资源

CDN 原理

定义：内容分发网络，在用户与源站之间增加 Cache 层
核心技术：缓存、回源、智能调度

工作流程：

用户请求首先到达最近的 CDN 边缘节点
边缘节点检查资源是否缓存
未缓存则回源获取并缓存
已缓存则直接返回

CDN 架构组成

中心节点：负责全局负载均衡和资源调度
边缘节点：分布于全国各地，直接面向用户请求
源站：存储原始资源的服务器

CDN 适用资源

静态资源：CSS、JavaScript、图片、视频等
动态资源：较少变化的动态资源，如 API 结果等

CDN 优化技术

智能 DNS 调度：将用户请求导向最近的边缘节点
预热与刷新：主动将热门资源推送到边缘节点
回源优化：减少回源请求，提高缓存命中率

消息队列在高并发系统中的应用

消息队列的本质

核心概念

基本定义：消息队列是一个暂时存储数据的容器
功能作用：是平衡低速系统和高速系统处理任务时间差的工具
形象比喻：可以看作一种缓冲机制，类似古代臣子在午门等待皇帝依次召见的场景

队列的普遍性

Java 线程池中用队列暂存待处理任务
操作系统中断的下半部分使用工作队列实现延后执行
RPC 框架将网络请求写入队列后启动工作线程处理
队列是系统设计中常见的组件

消息队列在秒杀系统中的作用

1. 削峰填谷（主要作用）

基本原理

将秒杀请求暂存在消息队列中，快速响应用户"结果计算中"
后台启动有限个队列处理程序消费消息，控制数据库并发请求数量

实现效果

请求可在消息队列中短暂堆积，当库存耗尽后堆积请求可被丢弃
通过消息队列削平短暂的流量高峰，实现流量整形
用户对秒杀结果的短暂延迟有一定容忍度

配置策略

根据商品数量、请求处理时间和期望总处理时间决定队列处理程序数量

2. 异步处理

设计思路

通过异步处理简化业务流程，提升系统性能
区分主要业务逻辑（生成订单、扣减库存）和次要业务逻辑（发放优惠券、增加积分）

实现方式

将次要业务逻辑放入另一个队列异步处理，缩短主要流程处理时间
需要明确同步流程和异步流程的边界

性能优势

使用异步处理可以提升系统整体吞吐量

3. 系统解耦

解耦目标

降低业务系统与其他系统（如数据分析系统）的直接耦合度

直接调用的问题

一个系统故障影响整体可用性
接口参数变更导致多系统联动变更

解决方案

采用发布-订阅模式，将数据发送到消息队列，各系统根据需求订阅处理
提升系统整体的鲁棒性

消息队列引入的新挑战

1. 系统复杂度上升

复杂度体现

同步流程和异步流程边界划分问题
消息丢失和重复消费问题
请求延迟如何减少
消息接收顺序对业务流程的影响
消息处理失败后的补偿机制

2. 需要考虑的关键问题

核心问题

如何处理消息的丢失和重复（消息投递的可靠性）
如何降低消息的延迟（性能优化）
如何保证消息仅被消费一次（幂等性）

消息投递：如何保证消息仅被消费一次

消息丢失的三个场景

1. 消息生产过程丢失

问题描述：生产者和消息队列之间的网络可能出现抖动导致消息丢失
解决方案：实施消息重传机制，发送超时后重新发送消息（2-3 次）
潜在问题：可能导致消息重复，需要解决重复消费问题

2. 消息队列中丢失

问题场景：以 Kafka 为例，消息存储于本地磁盘，先写入 OS 的 Page Cache 再异步刷盘
丢失原因：若机器掉电或异常重启，未刷盘的消息将丢失

解决方案：

集群部署：多副本备份机制（Leader-Follower 架构）
配置优化：配置acks=all，确保消息写入 Leader 和所有 ISR 副本后才返回成功
性能平衡：避免频繁同步刷盘，以平衡性能和可靠性

权衡建议：

消息绝对不能丢失：使用集群模式，配置全 ISR 确认
可接受部分丢失：不必部署集群或配置较少的副本确认

3. 消息消费过程丢失

消费流程：接收消息 → 处理消息 → 更新消费进度
丢失风险：在接收或处理消息环节发生异常，若提前更新消费进度会导致消息丢失
解决方案：先处理消息，确认完成后再更新消费进度
潜在问题：可能导致消息被重复消费

保证消息只被消费一次的核心思想

现实认知

完全避免消息重复几乎不可能

实际解决方案

保证消息处理的幂等性，即消费多次和消费一次结果相同

什么是幂等性

幂等性定义

多次执行同一操作与执行一次操作，最终结果相同

幂等性示例

幂等操作：将库存设置为固定值，多次执行结果相同
非幂等操作：每次将库存减 1，多次执行会导致不同结果

本质理解

同一事件无论执行多少次，产生的结果都与执行一次相同

实现消息处理幂等性的方法

生产端幂等性保证

技术支持：Kafka 0.11 版本和 Pulsar 提供 producer idempotency 特性
实现机制：
- 为每个生产者分配唯一 ID，每条消息也有唯一 ID
- 服务端存储<生产者 ID，最后消息 ID>映射，自动丢弃重复消息

消费端幂等性保证（通用层面）

基本思路：为每条消息生成全局唯一 ID
实现步骤：
1. 处理消息后将 ID 存入数据库
2. 处理新消息前先查询 ID 是否存在，存在则放弃消费

处理逻辑：

if (消息ID已存在) {
  返回; // 已处理过，直接返回
} else {
  处理消息;
  保存消息ID; // 标记为已处理
}

进阶方案：引入事务机制确保消息处理和 ID 存储的原子性

消费端幂等性保证（业务层面）

乐观锁机制：
- 数据增加版本号字段
- 生产消息时查询并附带当前版本号
- 消费时执行条件更新：UPDATE user SET amount=amount+20, version=version+1 WHERE userId=1 AND version=1
- 重复消费时版本号不匹配，SQL 执行失败，保证幂等性

方案设计的取舍原则

核心平衡

性能、复杂度与可靠性的平衡 业务场景差异化处理
不同业务场景的差异化处理
日志处理等场景可接受少量消息丢失，换取更高性能和更简单实现
财务、订单等核心业务需要保证消息不丢失和幂等处理
根据业务场景选择合适的消息队列配置和幂等性保证方式

消息队列：如何降低消息队列系统中消息的延迟

消息延迟的监控方法

基于消息堆积的监控

基本原理：消息堆积数 = 生产消息总数 - 当前消费进度
存储位置：在 Kafka 中，消费进度存储位置随版本不同：
- 0.9 版本之前：存储在 ZooKeeper 中
- 0.9 版本之后：存储在专门的 topic __consumer_offsets中

使用 Kafka 内置工具监控

监控命令：kafka-consumer-groups.sh 命令查看消费堆积情况：

./bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group test-consumer-group

命令输出信息：

TOPIC、PARTITION：话题名和分区名
CURRENT-OFFSET：当前消费进度
LOG-END-OFFSET：生产消息总数
LAG：消息堆积数（LOG-END-OFFSET 减去 CURRENT-OFFSET）

使用 JMX 监控

数据暴露：Kafka 通过 JMX 暴露消息堆积数据
系统集成：可通过代码获取并输出到监控系统
推荐方案：推荐使用此方法实现系统化监控

生成监控消息法

监控消息设计：定义特殊的监控消息，包含生成时间戳
工作流程：
1. 监控程序定时发送监控消息到队列
2. 业务处理程序遇到此消息直接丢弃
3. 监控消费程序收到后与生成时间比较，延迟超过阈值报警
优点：直观反映实际消费延迟时间
推荐监控组合：
- 基础监控：结合 JMX 数据监控堆积量
- 延迟监控：使用监控消息法监控实际延迟时间
- 综合评估：从数据量和时间两个维度评估系统性能

减少消息延迟的方法

消费端优化策略

性能优化：
- 优化消费代码提升单线程处理性能
- 增加消费者数量（受限于队列实现机制）
Kafka 分区特性：
- 限制：一个分区只能被一个消费者消费（避免消费进度同步问题）
- 影响：分区数量决定消费并行度上限
- 解决：增加 Topic 分区数可提高并行消费能力

消费并行度提升策略

多线程处理：
- 创建线程池处理接收到的消息
- 将串行消费改为并行消费
- 单次请求批量拉取多条消息，分配给多线程处理

避免消费线程空转

问题描述：队列无新消息时持续轮询会导致 CPU 使用率飙升
解决方案：
- 拉取不到消息时等待一段时间再尝试
- 建议等待时间：10ms-100ms
- 递增等待策略：首次 10ms，依次增加到上限（如 100ms）
- 恢复机制：拉取到消息后恢复最短等待时间

消息队列性能优化

存储介质优化

本地磁盘存储：替代数据库存储
Page Cache 利用：利用操作系统 Page Cache 提升读取速度
顺序读取优势：消息顺序读取特性使磁盘读取性能接近内存
性能提升：本地存储可提升 QPS 一个数量级

零拷贝技术

传统拷贝流程（四次数据拷贝）：
1. 磁盘 → 内核缓冲区
2. 内核缓冲区 → 用户缓冲区
3. 用户缓冲区 → Socket 缓冲区
4. Socket 缓冲区 → 网卡缓冲区
Sendfile 优化：
- 内核缓冲区数据直接拷贝到 Socket 缓冲区
- 省略用户缓冲区环节，减少一次拷贝
- Java 支持：FileChannel.transferTo() 方法

消息延迟问题的重要性

影响范围

用户体验：消息处理延迟直接影响用户体验
系统稳定性：任何使用队列的组件都要警惕堆积问题
故障风险：系统故障常源于队列堆积导致资源耗尽

应对策略

监控机制：实时监控队列状态
预警机制：设置合理的预警阈值
保护策略：线程池满时丢弃请求等保护措施

分布式服务架构

系统架构：何时需要进行服务化拆分

一体化架构的适用场景

适用时期：项目初创阶段适合采用一体化架构

核心优势

开发简单：代码和项目集中式管理
运维成本低：只需维护一个工程
问题排查便捷：只需关注单个应用进程，目标明确

一体化架构的痛点

技术层面瓶颈

数据库连接数问题：
- 一体化架构下所有应用服务器直连数据库
- 随着应用服务器扩容，数据库连接数急剧增加
- 不仅支撑外网流量，还要支撑内网调用和队列处理
- 连接数接近上限，成为系统稳定性的隐患

研发效率瓶颈

沟通成本指数增长：团队规模增长导致沟通成本呈指数级增长（n(n-1)/2）
协作困难：
- 多团队共同维护一套代码，配合困难
- 功能服务重复开发，代码冲突频繁
耦合问题：
- 功能之间耦合严重，小改动可能影响整体功能
- 需要进行全面回归测试，延长交付时间
稳定性风险：模块互相依赖，单点错误影响整体系统稳定性

运维成本增加

构建时间延长：代码量增加导致构建时间从分钟级延长到十几分钟
部署不灵活：任何小修改都需要构建整个项目
变更复杂：上线变更过程不够灵活

微服务化拆分的决策因素

关键考量点（QPS 并非决定性因素）

资源扩展性问题：系统资源出现扩展性问题，特别是数据库连接数瓶颈
研发效率下降：大团队共同维护代码导致研发效率下降
运维成本上升：系统部署和运维成本上升

微服务化拆分的实施策略

按业务做横向拆分

业务模块独立：将用户、内容、互动等相关逻辑独立部署为单独服务
连接数控制：控制直连数据库的服务数量，有效降低数据库连接数
可扩展性提升：提高系统可扩展性

下沉公共服务

功能抽取：将与业务无关的公用功能（如地理位置服务）抽取成独立服务
重用性提升：避免代码重复实现，提高重用性
服务调用：各业务模块通过服务调用获取功能

微服务拆分的收益

服务管理优势

职责明确：服务功能内聚，维护职责明确
测试简化：新功能只需测试自身服务
故障隔离：问题隔离，可通过服务熔断、降级减少连锁影响

性能和扩展性提升

构建加速：各服务代码量减少，构建速度提升
扩展性增强：系统整体扩展性提高

微服务架构：系统架构改造原则与挑战

微服务拆分原则

高内聚低耦合原则

职责单一：每个服务只完成自己职责内的任务
边界清晰：不同服务之间职责边界清晰
逻辑内聚：避免服务间逻辑判断交叉（如内容服务判断用户认证状态）
业务封装：确保业务逻辑内聚在负责的服务中

合理控制服务粒度

渐进细化：初期可粗略拆分，后期再逐渐细化
避免过度拆分：避免过度拆分导致"一方法一服务"
成本考量：
- 服务过多会增加运维成本
- 跨网络调用增加会影响性能
拆分示例：先将用户关系相关逻辑统一为用户关系服务，后续再将黑名单等功能拆分为独立服务

渐进式拆分策略

业务连续性：在维持产品功能迭代的同时完成服务拆分
避免全盘重构：避免停止业务开发全盘重构（可能错失市场机会）
拆分顺序建议：
1. 优先剥离边界清晰的独立服务（如短信服务、地理位置服务）
2. 当存在依赖关系时，优先拆分被依赖的服务
3. 梳理服务依赖链，按照依赖顺序拆分（如用户 → 内容 → 互动）

服务接口设计具备可扩展性

变更风险：接口变更可能导致调用方出错
设计建议：
- 接口参数类型推荐使用封装类
- 增加参数时无需变更接口签名，只需在类中添加字段

微服务化引入的挑战

服务调用性能问题

性能劣化：进程内方法调用变为跨进程网络调用，响应时间增加
解决方案：
- 选择高效的服务调用框架
- 引入服务注册中心管理服务地址和生命周期
- 实现服务健康状态检测

服务依赖链故障传播

依赖复杂性：服务间错综复杂的依赖关系
故障传播：
- 被依赖服务性能问题会导致依赖服务线程池耗尽
- 故障会沿依赖网络向上蔓延，最终导致系统整体故障
解决方案：引入服务治理体系，实现熔断、降级、限流和超时控制

分布式问题定位困难

解决方案：
- 引入分布式追踪工具（追踪单一慢请求中的性能瓶颈）
- 建立细致的服务端监控报表（关注宏观性能表现）
- 结合两者排查问题

团队结构与微服务架构的关系

康威定律的影响

核心观点：系统设计反映了组织的沟通结构
架构映射：
- 一体化架构对应职能型团队结构（开发、DBA、运维、测试分离）
- 微服务架构需要业务导向的团队结构（每个服务对应一个自治小团队）

团队组织优化

团队构成：小团队内包含开发、测试、运维和 DBA，降低沟通成本
规模建议：团队规模建议遵循"两个披萨"理论（6-8 人为宜）

过渡策略

渐进式微服务化

适用场景：对于人员不多、尚未准备好全面微服务化的团队
工程层面拆分：
- 可先进行工程层面的拆分（而非部署层面）
- 按业务边界将代码拆分到不同子工程
- 子工程间通过包依赖方式协作

收益

构建优化：减少打包时间
代码质量：实现代码层面的高内聚低耦合

RPC 框架设计：10 万 QPS 下的毫秒级服务调用

RPC 基础认知

RPC 概念和发展

基本定义

RPC：Remote Procedure Call（远程过程调用），通过网络调用另一台计算机上部署服务的技术
核心价值：封装网络调用细节，让远程服务调用如同本地服务调用一样简单
历史背景：RPC 并非互联网时代产物，而是一种封装网络调用细节的通用规范

传统 RPC 技术及局限性

Java RMI

优势：Java 原生远程调用框架，J2EE 时代 EJB 的实现基础
局限性：
- 使用 JRMP 协议限制跨语言通信
- Java 原生序列化效率差，字节数组空间大

Web Service

优势：HTTP+SOAP 协议支持跨语言跨平台
局限性：使用 XML 封装数据，数据包大，性能较差

服务化后的性能影响

网络调用增加

调用次数增长：一体化架构的 3 次网络请求变为服务化架构的 6 次网络请求
延迟累积效应：服务拆分粒度越细，网络调用越多，延迟越长
权衡考量：为提升系统扩展性而在性能上付出的代价

RPC 调用流程和优化方向

标准 RPC 调用流程

完整调用链路

客户端序列化：将类名、方法名、参数名、参数值序列化成二进制流
网络传输：客户端通过网络发送二进制流给服务端
服务端反序列化：解析二进制流得到调用信息
动态代理调用：通过反射调用对应方法获得返回值
结果序列化：服务端将返回值序列化后通过网络发送
客户端反序列化：获得最终调用结果

性能优化方向

主要优化维度

网络传输优化：选择高性能 I/O 模型，调优网络参数
序列化优化：选择高效的序列化方式，减少数据传输量

网络传输性能优化

I/O 模型选择

I/O 处理的两个阶段

等待资源阶段：等待网络数据可用（阻塞 vs 非阻塞）
使用资源阶段：数据拷贝到应用程序缓冲区（同步 vs 异步）

五种 I/O 模型对比

同步阻塞 I/O：站在灶台边等水烧开然后倒水
同步非阻塞 I/O：看电视但时不时检查水是否烧开
同步多路 I/O 复用：同时烧多壶水，哪壶开了先倒哪壶（推荐使用）
信号驱动 I/O：给水壶加报警器，水开了自动通知
异步 I/O：智能水壶，水烧好后自动倒水

推荐选择：多路 I/O 复用（Linux 的 select、epoll；Java 的 Netty 框架）

网络参数调优

tcp_nodelay 参数优化

问题根源：Nagle 算法与 DelayedACK 配合导致 40ms 延迟
Nagle 算法：小数据包累积到 MSS 或收到 ACK 才发送，避免带宽浪费
DelayedACK：延迟 ACK 发送以合并多个 ACK，默认超时 40ms
解决方案：开启 tcp_nodelay 禁用 Nagle 算法，适用于强网络交互场景

其他关键参数

接收缓冲区和发送缓冲区大小
客户端连接请求缓冲队列大小（back log）

序列化方式选择

序列化评估维度

性能考量

时间开销：序列化和反序列化速度
空间开销：序列化后二进制串大小，影响传输带宽

功能特性

跨语言支持：是否支持多语言解析，适应公司多语言技术栈
扩展性：对象字段变更时的协议兼容性

主要序列化方案对比

JSON

优势：简单易用，人类可读，相比 XML 性能更好
适用场景：性能要求不高，传输数据量不大的场景

Thrift

特点：Facebook 开源的高性能序列化协议，也是轻量级 RPC 框架
优势：空间和时间性能都很高，提供配套 RPC 框架
缺点：需要 IDL 文件，使用不便
适用场景：性能要求高且需要一体化解决方案

Protobuf

特点：谷歌开源的序列化协议
优势：空间和时间性能都很高
缺点：需要 IDL 文件，使用不便
适用场景：缓存等存储场景，用 Protobuf 替换 JSON 节省空间

选择建议

按性能要求分类

性能要求不高：使用 JSON
性能要求高：选择 Thrift 或 Protobuf
需要一体化方案：优先考虑 Thrift
存储场景优化：考虑用 Protobuf 替换 JSON

高并发 RPC 设计要点

核心性能优化策略

技术选择

选择多路 I/O 复用模型
开启 tcp_nodelay 等关键网络参数
根据业务需求选择合适的序列化协议

学习和实践建议

深入学习方向

研读成熟 RPC 框架源码（如 Dubbo、Motan）
理解 RPC 抽象和 SPI 扩展点设计
掌握网络编程关键考虑点
具备系统设计思路和方向感

注册中心：分布式系统寻址解决方案

服务发现的演进需求

传统静态配置方式的局限性

早期解决方案：将服务端地址配置在客户端代码或配置文件中（如 Nginx 配置）

主要问题

扩容困难：紧急扩容时需要修改客户端配置并重启所有客户端进程，操作时间长
故障恢复缓慢：服务器故障时无法快速修复和自动恢复，需要手动修改配置重启
发布风险：RPC 服务端上线时无法提前摘除流量，重启时会造成慢请求甚至请求失败

注册中心解决方案

主流选择：ZooKeeper、ETCD、Nacos、Eureka 等

基本功能

集中存储：提供服务地址的集中存储
变更推送：当存储内容发生变化时，将变更推送给客户端

服务注册与发现流程

完整服务发现过程

标准流程

客户端连接：客户端与注册中心建立连接，声明感兴趣的服务组
服务注册：服务端向注册中心注册服务信息
信息同步：注册中心将最新服务注册信息通知给客户端
服务调用：客户端获得服务端地址后发起调用请求

核心价值

管理优化

透明化管理：服务节点增减对客户端透明，无需重启客户端
优雅关闭：服务退出时先从注册中心删除，观察无流量后再停止服务
动态扩缩容：支持快速服务扩容和故障节点摘除

服务状态管理策略

主动探测模式

实现方式：RPC 服务开放统一端口，注册中心定期探测（如 30 秒间隔）

判断标准：端口可用则服务正常，否则从服务列表删除

存在问题

端口冲突：混合部署环境中端口冲突导致 RPC 服务启动失败
探测成本高：大量服务实例时探测成本高，故障发现延迟长

心跳模式（推荐）

实现机制

时间记录：注册中心记录每个服务节点的最近续约时间
心跳发送：RPC 服务节点按固定间隔（如 30 秒）发送心跳包
状态检查：注册中心更新节点续约时间，定期检测超时节点（如 90 秒阈值）

核心优势：适用范围更广，避免端口冲突问题

注册中心高可用保护策略

防过度摘除机制

问题案例：混合云部署中专线带宽满导致主从同步延迟，云端注册中心误删所有节点

保护策略

阈值控制：设置摘除节点比例阈值（如 40%）
风险控制：超过阈值时停止摘除并发送报警
技术实现：Eureka 采用类似策略，ZooKeeper/ETCD 可在客户端实现保护逻辑

通知风暴问题

问题根源：变更一个节点会产生大量推送消息（100 调用者 ×100 节点=10000 条通知）

解决方案

规模控制：控制单个注册中心管理的服务集群规模，监控峰值带宽
负载分担：扩容注册中心节点分担负载
使用规范：规范使用方式，变更单节点时只通知相关变更信息
保护策略：自建注册中心可加入保护策略，限制通知消息量阈值

服务治理体系概述

服务治理定义

本质：多个服务节点组成集群时的复杂问题管理

城市道路比喻：

集群=微型城市，服务=道路，流量=车辆
新建/关闭街道=服务注册发现
道路监控=服务监控
拥堵调度=熔断引流
链路排查=分布式追踪
交通疏导=负载均衡策略

核心组成要素

治理体系构成

服务注册与发现
服务监控
熔断与流量调度
分布式链路追踪
负载均衡策略

注册中心设计要点总结

核心价值

业务支撑

支持动态扩缩容和故障快速恢复
实现服务优雅关闭
为服务治理体系提供基础支撑

关键技术点

设计考虑

心跳机制进行服务状态检测
保护策略避免节点过度摘除
通知风暴控制保证系统稳定性
在整体架构中位置关键，设计不容忽视

分布式 Trace：慢请求排查解决方案

一体化架构中的慢请求排查

基础排查思路

简单方案：打印每个步骤的耗时，比较找出延迟最高的步骤

并发问题：多个请求并行处理，日志相互穿插难以区分

解决方案：引入 requestId 标记同一请求的所有日志

RequestId 实现机制

技术实现

生成方式：程序入口处生成 UUID 作为 requestId
传递方式：使用 ThreadLocal 存储在线程上下文中
日志格式：每行日志增加 requestId 前缀方便查询
查询优化：通过 requestId 串联单次请求所有步骤耗时

切面编程优化

解决问题：避免每次问题都需要增加日志、重启服务

实现原理：对跨网络调用（数据库、缓存、第三方服务）做切面拦截

AOP 类型对比

动态代理：Spring AOP，运行期生成代理对象，性能较差但灵活性好
选择建议：追踪日志优先考虑静态代理减少性能影响

日志量控制策略

性能挑战：QPS 10000 时可能产生每秒十几万条日志

控制方案

采样方案：只打印部分请求日志（如 requestId%10==0 采样 10%）
集中存储：日志发送到消息队列，由消息处理程序写入 Elasticsearch
查询优化：避免登录多台服务器搜索日志，支持 requestId 集中查询

分布式 Trace 实现方案

分布式环境挑战

核心问题

日志分散：单次请求跨越多个 RPC 服务，日志分布在多个服务器
调用关系复杂：仅依靠 requestId 无法表达清楚服务间调用关系
解决思路：采用 traceId + spanId 两个维度记录调用关系

TraceId + SpanId 设计

概念定义

TraceId：等同于 requestId，标识单次完整请求
SpanId：记录每一次 RPC 调用，表示调用层级关系

示例说明

用户请求 A 服务：traceId=100, spanId=1
A 调用 B 服务：traceId=100, spanId=1.1（上级 spanId 为 1，调用次序为 1）
A 调用 C 服务：traceId=100, spanId=1.2（上级 spanId 为 1，调用次序为 2）
B 调用 D 服务：traceId=100, spanId=1.1.1
B 调用 E 服务：traceId=100, spanId=1.1.2

SpanId 传递机制

完整传递流程

发起调用：A 服务从线程上下文获取当前 traceId 和 spanId，生成本次 RPC 调用的 spanId
请求传输：将 spanId 和 traceId 序列化后装配到请求体中发送给服务方
接收处理：服务方 B 从请求体反序列化出 spanId 和 traceId，设置到线程上下文
响应记录：服务 B 执行完成前计算执行时间，连同 span 信息发送给消息队列

数据汇总和存储

数据来源：RPC 服务响应时间 + 切面拦截的数据库/缓存/HTTP 调用时间

存储链路：消息队列汇总 → 处理程序 → Elasticsearch 存储

查询方式：通过 traceId 查询完整调用链，通过 spanId 还原调用关系

分布式 Trace 性能优化

性能影响控制

主要开销：磁盘 I/O 和网络 I/O 增加

优化策略

自研组件：必须提供开关，方便线上随时关闭日志打印

实现要点总结

核心要素

代码无侵入：使用切面编程解决
性能低损耗：采用静态代理和日志采样
日志串联：使用 requestId 串起日志呈现完整问题场景
客户端整合：requestId 可从客户端生成并传递，整合客户端日志体系

分布式追踪系统价值

核心能力

系统功能

跨进程调用链展示
服务依赖关系分析
性能优化数据支持
问题排查数据基础

技术本质

技术特点

整合性技术：不是新技术，而是已有技术的整合
实现简单：实现并不复杂，但价值显著
微服务必备：微服务化过程中的必选项
部署时机：应在微服务化完成前尽快部署

方案选择

技术选型

开源方案：Zipkin、Jaeger 等
自研方案：基于团队技术栈定制
部署建议：微服务化完成前尽快让其发挥价值

负载均衡：系统横向扩展能力提升

负载均衡基础概念

负载均衡定义与价值

核心作用：将访问请求均衡地分配到多个处理节点上

系统价值

性能提升：减少单个处理节点请求量，提升整体系统性能
扩容透明性：作为流量入口屏蔽服务节点部署细节，实现无感知扩容
系统地位：高并发系统设计三大通用方法之一（缓存、异步、横向扩展）

应用场景示例

典型应用

数据库读扩展：通过 DNS 服务器将查询请求分配到多个从库
Web 服务扩展：Nginx 承接 HTTP 请求分发到多个业务服务器
微服务架构：负载均衡服务器作为流量入口实现服务节点间流量分发

负载均衡服务器分类

代理类负载均衡服务

部署特点

部署方式：单独服务方式部署，所有请求先经过负载均衡服务
工作原理：选择合适服务节点后，由负载均衡服务调用该节点实现流量分发

LVS 和 Nginx 对比

LVS 特点

工作层级：工作在 OSI 网络模型第四层（传输层）
性能优势：
- 请求包转发后客户端与后端服务直接建立连接
- 响应包不经过 LVS 服务器，性能更高，承载更高并发
功能限制：
- 无法针对 URL 做细致请求分发
- 缺乏后端服务存活检测机制

Nginx 特点

工作层级：工作在 OSI 网络模型第七层（应用层）
性能表现：性能比 LVS 差但可承担每秒几万次请求
功能优势：
- 配置更加灵活，可感知后端服务是否出现问题
- 支持基于 URL 的细维度请求分发

LVS + Nginx 组合部署

架构设计：入口处部署 LVS 分发流量到多个 Nginx，再由 Nginx 分发到应用服务器

分工策略

LVS 职责：承担大流量请求分发
Nginx 职责：做细维度请求分发
QPS 建议：十万 QPS 以内可考虑仅使用 Nginx，减少系统维护成本

客户端负载均衡服务

部署特点

部署方式：内嵌在 RPC 客户端中，与客户端应用部署在同一进程
工作原理：提供多种节点选择策略，为客户端提供最佳可用服务端节点

应用优势

微服务适用性：适合微服务架构，结合注册中心获取服务节点列表
协议支持：支持 RPC 协议，弥补 LVS 和 Nginx 在微服务场景的局限性

负载均衡策略

静态策略

轮询策略（RoundRobin, RR）

使用广泛：最广泛使用的策略
工作原理：按照服务列表顺序请求下一个后端服务节点
优缺点：
- 优点：请求尽量平均分配到所有服务节点
- 缺点：未考虑服务节点具体配置情况

加权轮询策略

配置权重：给节点配置权重值（如 8 核 8G 机器权重为 2）
流量分配：根据权重分配流量，发挥高配置节点性能优势
解决问题：解决轮询策略无法区分节点性能差异的问题

其他静态策略

Nginx：ip_hash、url_hash 算法
LVS：按请求源地址和目的地址做 hash
Dubbo：随机选取策略、一致性 hash 策略

动态策略（推荐）

核心思想：根据后端服务实际运行状态选择节点

选择原则：优先选择负载最小、资源最空闲的服务

典型实现

Dubbo LeastActive 策略：选择活跃连接数最少的服务
Ribbon WeightedResponseTimeRule：基于响应时间计算权重分配节点

核心优势：最大化使用服务器空闲资源，获得更高服务调用性能

节点故障检测机制

微服务架构中的故障检测

检测机制

心跳机制：服务节点定期向注册中心发送心跳包
故障感知：注册中心能够知晓服务节点是否故障
节点保障：传递给负载均衡服务的节点确保可用

Nginx 故障检测方案

技术实现

nginx_upstream_check_module 模块：淘宝开源的 Nginx 模块
检测机制：定期探测后端服务指定接口，根据返回状态码判断服务存活
自动摘除：探测不存活次数达到阈值时自动摘除后端服务

配置参数说明

interval：检测间隔时间
rise：连续成功次数阈值（认为服务可用）
fall：连续失败次数阈值（认为服务不可用）
timeout：检测超时时间
default_down：后端服务刚启动时的初始状态

Web 服务优雅启动与关闭

启动过程

初始状态：初始化时 HTTP 状态码设置为 500
资源准备：等待依赖资源初始化完成，避免启动时波动
状态变更：完全初始化后将状态码变更为 200
服务就绪：Nginx 经过两次探测后标记服务为可用

关闭过程

状态变更：先将 HTTP 状态码变更为 500
流量切除：等待 Nginx 探测将服务标记为不可用
停止接收：前端流量停止发往该服务节点
优雅关闭：等待正在处理的请求全部完成后再重启服务

核心原则：秉承"先切流量后重启"原则，减少节点重启对系统影响

负载均衡最佳实践

策略选择建议

优先级排序

首选动态策略：保证请求发送到性能最优节点
备选轮询策略：无合适动态策略时选择轮询让请求平均分配
权重配置：根据服务器配置差异合理设置权重值

架构部署建议

按并发规模分类

高并发场景：LVS + Nginx 双层负载均衡架构
中等并发场景：十万 QPS 以内可考虑仅使用 Nginx
微服务场景：优先选择客户端负载均衡结合注册中心

运维管理要点

关键管理项

健康检查：合理配置健康检查参数和接口
状态码管理：可通过配置中心管理状态码，避免重启服务
优雅升级：遵循标准的服务启动关闭流程
监控告警：建立完善的负载均衡服务监控体系

API 网关：系统门面统一管控

API 网关基础概念

定义与本质

核心特征

架构模式：不是开源组件，而是一种架构模式
核心功能：将服务共有功能整合在一起，独立部署为单独一层
治理价值：解决服务治理问题，作为系统边界统一管控出入流量
业务背景：解决多服务重复功能代码冗余问题，支持多语言技术栈

API 网关分类

按部署位置分类

入口网关：部署在负载均衡服务器和应用服务器之间
出口网关：部署在应用服务器和第三方系统之间

入口网关功能特性

统一接入与协议转换

接入能力

统一地址：为客户端提供统一的接入地址
动态路由：将用户请求动态路由到不同业务服务
协议转换：处理 HTTP、RPC、Web Service 等多种协议转换
细节屏蔽：对客户端屏蔽服务部署地址和协议细节

服务治理策略植入

治理功能

熔断降级：服务熔断和降级策略实现
流量控制：流量限制和分流策略
请求路由：基于规则的智能路由策略

统一认证与授权

多元认证支持

多端认证：手机 APP 使用 OAuth 协议认证
Web 认证：HTML5 端和 Web 端使用 Cookie 认证
内部认证：内部服务使用自研 Token 认证
认证统一：应用服务无需了解认证细节

安全防护与访问控制

安全机制

黑白名单：基于设备 ID、用户 IP、用户 ID 等维度的访问控制

日志记录与链路追踪

监控功能

访问日志：记录 HTTP 请求访问日志
RequestId 生成：为分布式追踪系统生成请求标识
监控数据：提供统一的监控数据收集入口

出口网关功能特性

第三方服务统一管控

管控能力

统一出口：为调用第三方系统提供统一出口
认证授权：对外部 API 调用做统一认证授权
审计访问控制：统一的审计和访问控制机制
典型应用：第三方账户登录、第三方支付服务等

API 网关实现关键点

性能优化

性能重要性：承担客户端所有流量，性能影响巨大

I/O 模型选择：I/O 模型是性能提升关键

Zuul 性能演进

Zuul 1.0：同步阻塞 I/O 模型，servlet 架构
Zuul 2.0：I/O 多路复用模型，netty server + netty client，性能提升 20%

扩展性设计

设计需求

热插拔需求：支持动态增加和移除逻辑处理
责任链模式：每个操作定义为 filter，用责任链串联

Zuul filter 分类

Pre routing filter：路由前过滤器
Routing filter：路由过滤器
After routing filter：路由后过滤器

动态组织：按顺序插入 filter chain，运行时按顺序执行

线程隔离与保护

问题场景：商品服务故障导致调用线程阻塞，影响其他服务

解决思路

服务级隔离：针对不同服务采用不同线程池
接口级保护：线程池内部针对不同服务/接口设置使用配额

保护机制

配额机制：限制单个服务最多可使用的线程数量，防止故障传播
组合使用：服务级线程池 + 池内接口配额，双重保护

主流开源 API 网关

Kong

技术特点

技术架构：在 Nginx 中运行的 Lua 程序
性能优势：得益于 Nginx 性能，在开源 API 网关中性能最好
运维优势：大中型公司 Nginx 运维能力强，把控力好

Zuul

集成优势

生态集成：Spring Cloud 全家桶成员，可无缝集成其他组件

版本特点

Zuul1：同步阻塞模型，性能不高效但代码简单易懂
Zuul2：推出时间不长，可能存在未知问题

适用场景：Java 技术栈团队，系统量级不高的场景

Tyk

技术特点

技术栈：Go 语言实现的轻量级 API 网关
插件生态：丰富的插件资源
适用场景：Go 语言技术栈团队

电商系统 API 网关改造方案

原有 Web 层分析

现有功能

数据聚合：聚合商品信息、用户信息、店铺信息、用户评论等多个服务数据
协议转换：HTTP 请求转换为 RPC 请求
流量控制：前端流量限制、设备 ID 黑名单等

改造策略

入口网关功能迁移

功能迁移：将协议转换、限流、黑白名单挪到 API 网关处理

数据聚合处理方案

方案一：流量网关 + 业务网关双层架构
方案二：原子服务层 + 聚合服务层（推荐）
选择理由：接口数据聚合是业务操作，放在贴近业务的服务层更合适

出口网关应用

第三方服务管控

第三方支付：将数据加密、签名操作放在出口网关
服务简化：支付服务只需调用出口网关统一支付接口
统一管理：第三方服务调用的统一出口管控

API 网关最佳实践

架构设计原则

核心设计要素

性能优先：使用多路 I/O 复用模型和线程池并发处理
扩展性保障：责任链模式支持热插拔
高可用设计：线程池隔离和保护机制
功能分层：入口网关处理通用功能，服务层处理业务聚合

实施改造建议

改造策略

渐进改造：从 Web 层逐步抽取功能到 API 网关
技术选型：根据团队技术栈选择合适的开源方案
性能监控：建立完善的网关性能监控体系

应用价值

核心价值

功能复用：服务治理功能独立实现复用
调用便捷：为 API 调用提供便捷性
性能可控：使用成熟开源组件性能损耗可接受
系统门面：微服务系统复杂时的统一门面解决方案

多机房部署：跨地域分布式系统设计

多机房部署基础概念

定义与目标

基本定义：在不同 IDC 机房中部署多套服务，共享同一份业务数据，都可承接用户流量

核心目标

容灾目标：当某机房出现网络故障、火灾甚至自然灾害时，可将流量切换到其他机房
系统连续性：保证系统不间断持续运行的能力
现实需求：解决单一机房部署时系统可用性受制于机房可用性的问题

业务驱动场景

典型风险场景

机房网络设备割接：网络中断导致服务不可用
机房规范整顿：如 2016 年北京联通整顿 40 多个 IDC 机房，脉脉宕机 15 小时，A 站宕机超 48 小时
自然灾害风险：地震、洪水等不可抗力因素
设备故障风险：机房掉电、网络设备故障等

多机房部署的核心挑战

数据传输延迟问题

关键影响因素：机房间距离直接影响网络延迟

延迟基准数据

同城双机房：北京同地专线延迟 1ms~3ms
国内异地机房：延迟 50ms 以内
- 北京-天津：<10ms
- 北京-上海：接近 30ms
- 北京-广州：达 50ms
跨国机房：100ms~200ms 左右（如国内访问美国西海岸）

性能影响分析

接口响应要求：需控制在 200ms 以内

可接受场景

轻量服务调用：几次第三方 HTTP/RPC 服务调用，增加几毫秒延迟可接受
数据库写入：几次数据库写入，增加几毫秒到十几毫秒可接受

不可接受场景

频繁读取：十几次到几十次缓存和数据库读取，增加几十到上百毫秒延迟不可接受

数据访问策略挑战

数据访问方案

跨机房直接读取：B 机房应用直接读取 A 机房从库
本地从库同步：在 B 机房部署从库，跨机房同步主库数据

同城双活部署方案

适用场景与限制

容灾能力

容灾级别：机房级别容灾，无法做到城市级别容灾
风险概率：机房网络故障、掉电概率远大于城市级自然灾害
实用性：大部分系统做到同城双活已足够
延迟优势：1ms~3ms 延迟对跨机房调用容忍度较高

核心设计原则

设计策略

避免跨机房调用：尽量避免跨机房的服务调用和数据访问
本地优先策略：数据读取和服务调用优先在本机房进行
合理容忍写入：允许有跨机房数据写入，但控制在可接受范围

具体实施方案

数据库部署策略

主库配置：主库部署在一个机房（如 A 机房）
写入策略：A、B 两机房都写入 A 机房主库
从库配置：A、B 机房各部署一个从库，通过主从复制同步数据
读取策略：查询请求读取本机房从库
故障处理：故障时通过主从切换将 B 机房从库提升为主库

缓存部署策略

双机房部署：两个机房都部署缓存
读取策略：查询优先读取本机房缓存
穿透处理：缓存 miss 时穿透到本机房从库加载数据
一致性保证：数据更新时更新双机房缓存保证一致性

RPC 服务注册策略

服务组隔离：不同机房 RPC 服务注册不同服务组
订阅策略：RPC 客户端(Web 服务)只订阅同机房服务组
调用优化：实现 RPC 调用尽量在本机房内进行

依赖服务管理

内部服务依赖：如审核、搜索等服务也需双机房部署

调用策略：优先调用本机房的依赖服务

延迟控制：降低整体调用链路延迟

异地多活部署方案

应用场景与挑战

适用条件

业务规模要求：流量达到京东、淘宝级别才需考虑
容灾级别：城市级别容灾，应对重大自然灾害 距离选择：主机房北京，异地机房选择上海、广州等距离较远位置

核心设计原则

设计策略

避免同步调用：避免跨机房同步的数据写入和读取
异步数据同步：采用异步方式将数据从一个机房同步到另一个机房
本地写入策略：保证只写本机房的数据存储服务
用户分片策略：对用户进行分片，保证读写在同一机房

数据同步方案

存储系统主从复制

部署策略：MySQL、Redis 等在一个机房部署主库，异地机房部署从库
同步方式：通过主从复制实现数据同步

消息队列同步

异步写入：一个机房产生写入请求后写消息到消息队列
消费执行：另一个机房应用消费消息后执行业务逻辑写入存储

组合使用策略

消息方式：同步缓存数据、HBase 数据等
主从复制：同步 MySQL、Redis 等数据

用户分片与数据访问

分片策略

分片依据：按用户 ID、地域等属性进行分片
读写一致性：保证用户读取自己数据时访问数据主库所在机房

数据访问优化

跨机房数据读取：优先保证本机房服务调用，可接受读取跨机房从库数据的延迟
数据延迟处理：跨机房数据传输存在延迟，通过用户分片最小化影响

多机房部署最佳实践

方案选择策略

选择原则

业务发展阶段：依据系统量级和可用性要求进行选择
实施优先级：能不做则尽量不做，同城双活已能满足大部分需求
复杂度权衡：异地多活实现过于复杂，轻易不要尝试
架构演进：架构需要依据实际需求不断迭代发展

延迟数据应用

设计考虑

设计基础：机房间延迟数据是架构设计的重要基础
性能优化：尽量避免数据延迟对接口响应时间的影响
调用策略：合理规划跨机房调用的频次和场景
监控告警：建立完善的跨机房调用监控体系

实施注意事项

配置要点

读写分离配置：异地机房配置主库为主机房主库，从库为本机房从库
主从延迟处理：通过主动写缓存解决主从延迟问题
缓存部署策略：各机房创建独立缓存库，或建立主从同步机制
注册中心部署：可部署在单机房，或双机房独立部署
数据完整性：保证两个机房都有完整的数据和服务副本

云服务环境适配

云服务策略

小公司策略：没有自建机房的公司可通过云服务可用区实现类似架构
成本控制：根据实际业务需求选择合适的多机房策略

服务端监控：给系统加上眼睛

监控系统的重要性

背景问题

被动运维困境

被动发现问题：只能在用户投诉后才发现系统问题

常见运维问题

数据库问题：数据库主从延迟变长，导致业务功能异常
性能问题：接口响应时间变长，用户看到空白页面
系统错误：系统出现大量错误，影响用户正常使用
监控盲区：基础监控（CPU、内存、磁盘、网络）无法覆盖业务层面问题

监控体系价值

核心价值

主动发现问题：在用户感知之前发现和定位问题
提升系统稳定性：关乎系统的稳定性和可用性
减少故障风险：提高对系统运维的掌控力

监控指标选择

四个黄金信号（Four Golden Signals）

来源：谷歌提出的分布式系统监控经验总结

核心指标

延迟（Latency）
- 请求的响应时间
- 接口响应时间
- 访问数据库和缓存的响应时间
通信量（Traffic）
- 吞吐量，单位时间内的请求量大小
- 访问第三方服务的请求量
- 访问消息队列的请求量
错误（Errors）
- 显式错误：Web 服务出现 4xx 和 5xx 响应码
- 隐式错误：响应码 200 但发生业务相关错误
  - 数组越界异常
  - 空指针异常等业务异常
饱和度（Saturation）
- 服务或资源到达上限的程度（资源利用率）
- CPU 使用率、内存使用率、磁盘使用率
- 缓存数据库的连接数

RED 指标体系

简化版监控指标：四个黄金信号的简化版本

R - Request rate：请求量
E - Error：错误
D - Duration：响应时间
特点：缺少饱和度指标，适合作为简化版通用监控指标

组件特殊监控指标

组件特有指标：不同组件有独特的监控指标

数据库：主从延迟数据
消息队列：堆积情况
缓存：命中率
基础资源：CPU、内存、网络、磁盘等基础指标

数据指标采集方式

Agent 采集方式

基本原理

部署方式：在数据源服务器上部署自研或开源 Agent
工作原理：通过数据源提供的接口获取数据，发送给监控系统

Memcached 监控示例

通过 stats 命令获取统计信息：

cmd_get：计算查询 QPS
cmd_set：计算写入 QPS
get_hits：计算命中率（get_hits/cmd_get）
curr_connections：当前连接数
bytes：当前内存占用量
evictions：被剔除的 item 数量（过大表示容量不足或 Slab Class 分配问题）

JMX 监控方式

适用于 Java 语言开发的中间件或组件：

监控 Kafka 队列堆积数
监控 JVM 内存信息和 GC 相关信息
获取统计或监控信息

代码埋点方式

与 Agent 对比

区别：Agent 收集服务端信息，埋点从客户端角度描述组件和服务性能

实现方式

面向切面编程（AOP）方式
直接计算：在资源客户端直接计算调用耗时、调用量、慢请求数

埋点优化策略

问题识别：缓存、数据库请求量高（单机每秒万次），直接发送会导致监控服务器不堪重负
解决方案：先做汇总再发送
- 每隔 10 秒汇总同一资源的请求量总和
- 计算响应时间分位值、错误数等
- 大大减少发往监控服务器的请求量

日志采集方式

重要日志源

Web 服务器日志：Tomcat 访问日志、Nginx 访问日志 常用采集工具
Apache Flume
Fluentd
Filebeat（推荐使用）

监控数据处理和存储

数据流处理架构

处理流程

数据采集 → 消息队列 → 并行处理 → 存储展示

消息队列缓冲

核心作用

削峰填谷：防止大量监控数据冲击监控服务
必要性：承接高频次的监控数据写入

双路径处理模式

路径一：原始数据查询

处理流程：消息队列 → 数据写入 Elasticsearch → Kibana 展示
用途：原始数据查询和问题详细分析

路径二：聚合数据分析

处理中间件：Spark、Storm 等流式处理工具
处理内容：
- 解析数据格式（特别是日志格式）
- 提取请求量、响应时间、请求 URL 等数据
- 对数据做聚合运算
- 计算同一 URL 的请求量、响应时间分位值、非 200 请求量等

时间序列数据库存储

数据特点：带有时间标签，按时间递增

常用时序数据库

InfluxDB
OpenTSDB
Graphite

核心优势：对带时间标签数据做更有效存储

数据展示

展示方案

展示工具：Grafana 连接时序数据库
功能：将监控数据绘制成报表，呈现给开发和运维团队

监控报表体系

访问趋势报表

数据来源：Web 服务器和应用服务器访问日志

展示内容

整体指标：服务整体访问量、响应时间情况
错误统计：错误数量
性能指标：带宽等信息

性能报表

数据来源：资源和依赖服务的埋点数据

展示内容

访问统计：被埋点资源的访问量
性能指标：响应时间情况

核心作用：反映资源整体运行情况，定位具体问题资源或服务

资源报表

数据来源：Agent 采集的资源运行情况数据

展示内容

连接统计：连接数变化情况
缓存指标：缓存命中率
运行指标：资源具体运行指标

核心作用：进一步分析问题根源，找到解决方案

监控体系三层分析模式

问题定位流程

访问趋势报表：发现整体问题
性能报表：定位问题资源
资源报表：分析问题根本原因

实施建议

核心要点

监控要素

三种通用指标：耗时、请求量、错误数
三种采集方式：Agent、埋点、日志
三个报表体系：访问趋势、性能分析、资源监控

投入与完善

建设策略

重视程度：监控是发现和排查问题的重要工具
持续投入：需要足够精力不断完善监控系统
运维价值：提高系统运维掌控力，降低故障风险

应用性能管理：如何监控用户体验

用户体验监控的重要性

服务端监控的局限性

视角差异问题

服务端监控：关注系统资源和性能指标
用户体验：关注页面加载速度、操作响应时间、功能可用性
现实问题：服务端一切正常，用户端可能仍有问题

网络因素影响

CDN 问题：CDN 节点故障导致静态资源加载缓慢
网络差异：用户网络环境差异影响访问体验
运营商问题：跨网络运营商访问质量不稳定
兼容性问题：浏览器兼容性问题
性能瓶颈：前端性能瓶颈（如大量 DOM 操作）

真实案例分析

案例：电商系统商品详情页访问缓慢

服务端监控结果：API 响应时间正常，数据库查询时间在合理范围
用户反馈：页面加载超过 10 秒，严重影响购买体验
根因分析：商品图片 CDN 节点故障，图片加载失败导致页面渲染阻塞
解决方案：切换备用 CDN 节点，优化图片加载策略

APM 体系架构设计

核心组件

前端监控组件

数据采集：通过 SDK 采集用户行为数据
性能指标：页面加载时间、资源加载时间、用户操作响应时间
错误监控：JavaScript 错误、资源加载失败、API 调用异常

移动端监控组件

性能监控：应用启动时间、页面切换时间、网络请求耗时
崩溃监控：应用崩溃率、崩溃堆栈信息
设备信息：设备型号、操作系统版本、网络类型

服务端监控组件

链路追踪：分布式调用链监控
业务指标：业务成功率、关键业务流程监控
基础设施：服务器资源、中间件性能

数据采集与处理流程

数据上报策略

批量上报：减少网络请求次数，提高上报效率
异步上报：避免影响用户正常使用
采样上报：控制数据量，降低服务端处理压力
断点续传：网络异常时本地缓存，恢复后继续上报

数据处理机制

实时处理：处理紧急告警和实时监控指标
批量处理：处理历史数据分析和报表生成
数据清洗：过滤无效数据、去重、格式标准化

关键性能指标体系

Web 前端性能指标

页面加载性能指标

DNS 解析时间：域名解析耗时
TCP 连接时间：建立网络连接耗时
首字节时间 (TTFB)：服务器响应第一个字节的时间
DOM 解析时间：解析 DOM 结构耗时
资源加载时间：CSS、JavaScript、图片等资源下载耗时
页面渲染时间：浏览器完成页面渲染的总时间
页面完全加载时间：页面所有资源加载完成时间

核心 Web 指标（Core Web Vitals）

LCP (Largest Contentful Paint)：最大内容绘制时间，衡量加载性能
FID (First Input Delay)：首次输入延迟，衡量交互性
CLS (Cumulative Layout Shift)：累积布局偏移，衡量视觉稳定性

用户体验指标

首屏渲染时间：用户看到第一屏内容的时间
可交互时间：页面可以响应用户操作的时间
白屏时间：用户看到页面有内容显示的时间

移动端性能指标

应用启动性能

冷启动时间：应用从完全关闭到可用的时间
热启动时间：应用从后台切换到前台的时间
内存占用：应用运行时的内存使用情况

网络性能指标

请求成功率：网络请求的成功比例
请求响应时间：API 调用的平均响应时间
网络错误率：网络请求失败的比例

业务性能指标

关键业务流程监控

注册转化率：访问注册页面到成功注册的转化率
支付成功率：发起支付到支付成功的比例
搜索成功率：搜索请求返回有效结果的比例

用户行为指标

页面停留时间：用户在特定页面的停留时长
跳出率：只访问一个页面就离开的用户比例
用户流失点：用户在业务流程中离开的环节

错误监控与告警机制

错误监控类型

前端错误监控

JavaScript 运行时错误
Promise 未捕获异常
资源加载失败
网络请求异常

移动端崩溃监控

Android：Java 崩溃、Native 崩溃、ANR 监控
iOS：Mach 异常、Unix 信号、NSException

智能告警策略

多维度告警规则

页面加载时间异常：平均加载时间超过阈值
JavaScript 错误率过高：错误率超过设定比例
API 调用失败率异常：接口失败率超标

告警收敛与抑制

时间窗口收敛：相同类型告警在时间窗口内只发送一次
频次限制：防止告警风暴，限制告警发送频率
分级处理：根据告警级别采用不同的通知方式

性能分析与优化

性能瓶颈定位

瀑布图分析
- 资源加载时序：分析关键资源的加载顺序和耗时
- 阻塞资源识别：找出阻塞页面渲染的关键资源
- 优化建议生成：基于分析结果给出具体优化建议
用户会话回放
- 操作轨迹记录：记录用户的点击、滚动、输入等操作
- 性能问题重现：回放用户遇到性能问题时的完整操作过程
- 问题根因分析：结合性能数据和用户行为定位问题根源

优化策略实施

前端性能优化
- 资源优化：压缩图片、合并 CSS/JS 文件、启用 Gzip
- 缓存策略：合理设置浏览器缓存和 CDN 缓存
- 懒加载：对非关键资源实施懒加载策略
后端性能优化
- API 响应时间优化：数据库查询优化、缓存策略调整
- 服务容量规划：基于监控数据进行容量评估和扩容规划
- 限流和降级：在高并发情况下保障核心功能可用

APM 系统实施要点

技术实现考虑

数据采集性能影响
- 异步采集：避免阻塞主业务逻辑
- 采样策略：在数据完整性和性能之间平衡
- 客户端缓存：本地缓存机制减少网络开销
数据安全与隐私
- 敏感数据过滤：避免采集用户敏感信息
- 数据加密传输：保障数据传输安全
- 用户授权机制：遵守数据保护法规要求

团队协作机制

跨团队协作
- 前端团队：负责前端监控 SDK 集成和前端性能优化
- 后端团队：负责 API 性能监控和服务端优化
- 运维团队：负责基础设施监控和容量管理
- 产品团队：定义关键业务指标和用户体验标准
持续改进流程
- 定期性能回顾：周期性分析性能数据和优化效果
- 问题复盘机制：对重大性能问题进行深度复盘
- 最佳实践分享：在团队内部分享性能优化经验

第 26 章压力测试：如何设计全链路压测平台

压力测试的必要性

传统容量评估的局限性

在没有压力测试的情况下，系统容量评估往往依赖理论计算或经验估算：

理论计算的不准确性
- 单服务理论值偏差：单个服务的理论承载能力与实际表现存在差异
- 多服务协作影响：调用链路中的多服务协作会降低整体性能
- 理论实际差距：实际测试结果通常远低于理论值
经验估算的风险
- 线性推演缺陷：基于历史数据的线性推演缺乏准确性
- 复杂性忽略：忽略系统复杂性和相互依赖关系
- 瓶颈预测不准：无法准确预测系统瓶颈点

压力测试的核心价值

真实容量验证
- 生产环境模拟：在接近生产环境的条件下测试系统真实承载能力
- 差异发现：发现理论计算与实际表现的差异
- 数据支撑：为容量规划提供可靠数据支撑
瓶颈点识别
- 精确定位：定位系统性能瓶颈的具体位置
- 资源限制分析：识别关键资源的限制因素
- 优化指导：指导针对性的性能优化
稳定性验证
- 高负载测试：验证系统在高负载下的稳定性
- 恢复能力测试：测试系统的自动恢复能力
- 问题发现：发现潜在的内存泄漏等问题

业务场景驱动的测试需求

典型案例：电商大促活动

业务背景：双 11 等大促活动流量是平时的 10-20 倍
测试目标：验证系统能否承受预期峰值流量
测试范围：从用户访问到订单完成的完整业务链路
期望结果：确保关键业务功能在高并发下正常运行

全链路压测架构设计

压测平台整体架构

压测平台的核心架构包含以下几个层次：

压测控制台层：提供测试场景配置和监控界面
压测引擎层：分布式执行压测任务
数据隔离层：确保测试数据与生产数据隔离
任务调度层：协调压测任务的分配和执行
监控收集层：实时收集和分析性能数据
被测系统层：接受压测流量的目标系统

核心组件详解

压测控制台
- 测试场景配置：通过可视化界面配置测试脚本的关键参数，包括并发用户数量、测试持续时间、业务流程步骤等，支持多种复杂场景的自定义设置
- 执行计划管理：提供灵活的测试执行策略，支持定时自动执行、分阶段逐步加压、以及根据实际业务需求制定个性化的压测计划
- 实时监控界面：在测试执行过程中实时展示系统性能指标，包括响应时间、吞吐量、错误率等关键数据的动态变化趋势
压测引擎集群
- 分布式执行：通过多个压测节点协同工作，实现大规模并发用户的模拟，确保压测能力能够满足真实业务峰值流量的验证需求
- 协议支持：兼容多种网络通信协议，能够对 HTTP 接口、RPC 服务调用、数据库连接等不同类型的系统组件进行全面的性能测试
- 动态扩缩容：根据当前测试规模的需要，自动增加或减少压测引擎节点数量，既保证测试效果又避免资源浪费
数据隔离层
- 测试数据准备：智能化地生成符合业务特征的测试数据，或者从生产环境安全地导入脱敏后的真实数据用于测试
- 数据隔离策略：通过技术手段确保测试过程中产生的数据与生产环境完全隔离，避免测试活动对线上业务造成任何影响
- 数据清理机制：在测试完成后自动识别并清理所有测试产生的临时数据，保持系统环境的整洁

技术架构实现

分布式压测引擎
- 任务分配机制：智能算法将大型压测任务科学地分解并分配到集群中的各个引擎节点，确保负载均衡的同时最大化测试效率
- 并发执行控制：采用高效的异步编程模型和协程技术，在单个节点上实现成千上万个虚拟用户的并发模拟，突破传统线程模型的性能瓶颈
- 性能指标收集：在测试执行过程中实时记录每个请求的详细性能数据，包括响应时间分布、错误类型统计、网络延迟等关键指标
- 执行流程控制：精确控制压测请求的发送频率和时序，管理虚拟用户的完整生命周期，确保测试场景的真实性和可重复性
- 结果汇总统计：将分布在各个节点的测试结果进行实时汇总和统计分析，生成综合性的性能评估报告
实时监控数据收集
- 多维度监控：同时关注系统层面的基础设施指标、应用层面的业务逻辑指标、以及用户层面的体验指标，构建全方位的监控体系
- 定时采集机制：按照预设的时间间隔持续收集各类性能数据，确保监控数据的完整性和时效性
- 时序数据存储：采用专门的时序数据库来存储大量的监控时间序列数据，支持高效的查询和分析操作
实时监控系统
- 指标类型涵盖：
  - 系统层面：服务器的 CPU 使用率、内存占用情况、磁盘 IO 性能、网络带宽利用率等基础资源指标
  - 应用层面：每秒查询次数(QPS)、请求响应时间、错误率、并发连接数等应用性能指标
  - 业务层面：与具体业务逻辑相关的关键指标和用户自定义的业务监控指标

测试数据管理策略

数据隔离方案

影子库模式
- 实现原理：为每个生产数据库创建对应的影子库
- 数据同步：定期从生产库同步数据到影子库
- 路由策略：通过标识区分生产流量和测试流量
- 隔离机制：基于线程上下文或请求标识进行数据源路由
- 适用场景：对数据隔离要求极高的核心业务系统
影子表模式
- 表结构复制：在同一数据库中创建带前缀的影子表
- SQL 改写：动态改写 SQL 语句访问对应的影子表
- 优势：减少数据库实例数量，降低维护成本
- 技术实现：通过代理或拦截器实现 SQL 语句的动态路由
数据标记模式
- 标记字段：在原表中增加标记字段区分测试数据
- 查询过滤：在查询条件中自动添加标记字段过滤
- 适用场景：数据量较小、隔离要求不高的场景
- 注意事项：需要确保所有查询都正确添加过滤条件

测试数据准备

数据生成策略
- 批量数据生成：提高数据创建效率，减少数据库交互次数
- 随机数据算法：生成符合业务特征的随机数据
- 数据标记机制：明确标识测试数据，便于后续清理
- 并行生成优化：利用多线程提高大量数据生成速度
- 内存管理：分批处理避免内存溢出
数据关联性维护
- 主外键关系：确保测试数据间的引用关系正确
- 业务逻辑一致性：生成的数据符合业务规则约束
- 数据分布特征：模拟真实数据的分布特征
- 关联数据同步：确保相关联的测试数据保持一致性

压测场景设计

业务场景建模

用户行为路径分析
- 场景权重分配：根据真实业务流量分布设计场景权重
- 用户行为步骤：模拟完整的用户操作流程
- 思考时间设置：在操作步骤间设置合理的等待时间
- 参数化设计：使用变量和随机数据模拟真实用户行为
- 典型场景包括：
  - 浏览商品场景（占总流量 40%）：首页访问 → 商品搜索 → 详情查看
  - 购买商品场景（占总流量 20%）：用户登录 → 加购物车 → 订单结算 → 支付
  - 用户管理场景：注册、登录、个人信息管理等
负载模式设计
- 稳定负载测试：持续稳定的并发用户数
- 阶梯负载测试：逐步增加并发用户数
- 峰值负载测试：模拟突发流量场景
- 疲劳强度测试：长时间稳定负载验证系统稳定性

压测策略实施

分层压测方法
- 第一层：单接口压测
  - 针对单个 API 接口进行独立测试
  - 快速识别接口级别的性能瓶颈
  - 验证接口的承载能力和响应时间
- 第二层：核心链路压测
  - 测试关键业务流程的完整链路
  - 验证服务间协作的性能表现
  - 发现链路中的薄弱环节
- 第三层：全链路压测
  - 模拟真实业务场景的混合压测
  - 验证系统整体承载能力
  - 评估系统在复杂场景下的稳定性
容量评估方法
- 响应时间基准：99%请求响应时间 < 500ms
- 错误率阈值：系统错误率 < 0.1%
- 资源利用率：CPU 使用率 < 70%，内存使用率 < 80%
- 业务指标：关键业务功能成功率 > 99.9%

性能监控与分析

多维度性能监控

应用层监控
- 响应时间监控：记录各个接口的响应时间分布
- 请求量统计：监控系统的 QPS 变化趋势
- 错误率跟踪：实时统计各类错误的发生情况
- 事件驱动监控：基于请求完成事件进行指标收集
- 标签分类：按 URI、方法、状态码等维度进行分类统计
基础设施监控
- 服务器资源：CPU、内存、磁盘、网络使用率
- 数据库性能：连接数、查询响应时间、锁等待时间
- 缓存性能：命中率、响应时间、内存使用情况
- 消息队列：消息堆积量、处理速度、错误率

性能瓶颈分析

瓶颈识别方法
- 响应时间分析：识别响应时间超过阈值的慢接口
- 错误率分析：找出错误率过高的问题接口
- 资源使用分析：监控 CPU、内存等资源的使用情况
- 自动化识别：通过脚本自动分析测试结果
- 分类统计：按不同维度对性能问题进行分类
- 建议生成：针对不同类型的问题提供相应的优化建议
优化建议生成
- 自动化分析：基于监控数据自动识别性能问题
- 优化建议：针对发现的问题提供具体的优化建议
- 优先级排序：根据影响程度对优化项进行优先级排序
- 问题归类：将性能问题按类型进行归类和整理
- 解决方案库：建立常见问题的解决方案知识库

压测平台最佳实践

实施策略

渐进式压测
- 从小到大：从单接口测试逐步扩展到全链路测试
- 从简到繁：从简单场景逐步增加复杂度
- 持续优化：基于测试结果持续优化和改进
自动化集成
- CI/CD 集成：将压测集成到持续集成流程中
- 自动触发：代码发布前自动执行性能回归测试
- 结果反馈：自动生成测试报告并反馈给开发团队

组织保障

团队协作机制
- 性能测试团队：负责压测平台建设和测试执行
- 开发团队：配合进行性能问题排查和优化
- 运维团队：提供基础设施支持和监控数据
- 业务团队：提供业务场景和验收标准
持续改进文化
- 定期回顾：定期回顾压测结果和系统性能表现
- 知识分享：在团队内分享性能优化经验和最佳实践
- 工具改进：持续改进压测工具和方法

第 27 章配置管理：如何管理成千上万的配置项

配置管理的挑战

传统配置管理的痛点

在系统规模不断扩大的过程中，配置管理面临越来越多的挑战：

配置项数量爆炸式增长
- 微服务配置独立：微服务架构下，每个服务都有独立的配置文件
- 多环境配置倍增：多环境部署（开发、测试、预发布、生产）成倍增加配置项
- 第三方集成复杂：第三方服务集成带来的配置复杂性
配置变更风险高
- 错误影响服务：配置错误可能导致服务不可用
- 缺乏变更机制：缺乏变更审批和回滚机制
- 配置漂移问题：配置漂移问题难以发现和纠正
多环境一致性难以保证
- 手工维护出错：手工维护多环境配置容易出错
- 环境差异难排查：环境间配置差异导致的 bug 难以排查
- 新环境搭建低效：新环境搭建效率低下

实际案例分析

案例：电商系统配置管理混乱导致的线上事故

背景：双 11 大促前夕，运维人员调整数据库连接池配置
问题：在多个配置文件中修改，遗漏了一个关键服务的配置
影响：该服务在高并发下连接池耗尽，导致订单服务不可用 2 小时
损失：直接经济损失超过千万元
教训：急需建立统一的配置管理平台

配置中心架构设计

整体架构设计

┌─────────────────┐    ┌─────────────────┐    ┌─────────────────┐
│   配置管理界面   │    │    配置存储     │    │   客户端 SDK    │
│  Config Portal  │────│  Config Store   │────│  Client SDK     │
└─────────────────┘    └─────────────────┘    └─────────────────┘
         │                        │                        │
         ▼                        ▼                        ▼
┌─────────────────┐    ┌─────────────────┐    ┌─────────────────┐
│   权限管理系统   │    │   版本控制系统   │    │   应用服务集群   │
│  Permission Mgmt │    │  Version Control │    │ Application Cluster│
└─────────────────┘    └─────────────────┘    └─────────────────┘

核心组件设计

配置存储层 配置数据模型的核心设计包含了配置管理的所有关键信息。每个配置项都有唯一标识符，明确所属的应用名称和运行环境（开发、测试、生产）。配置项以键值对形式存储，支持字符串、整数、布尔值、JSON 等多种数据类型。系统还记录了配置的详细描述、创建和更新时间、操作人员信息、版本号以及是否需要加密等重要属性，确保配置管理的完整性和可追溯性。
配置服务接口 配置服务提供了 RESTful API 接口来处理配置的读取和更新操作。获取配置的接口支持根据应用名称和环境来查询相应的配置项，还可以指定版本号来获取特定版本的配置。更新配置的接口在执行操作前会进行权限验证，确保只有授权用户才能修改配置。成功更新配置后，系统会自动向所有相关的客户端发送变更通知，实现配置的实时同步。
客户端 SDK 设计 客户端 SDK 是应用程序与配置中心交互的核心组件。它在应用启动时自动从配置中心拉取最新配置并缓存到本地，同时启动长轮询机制来监听配置变更。SDK 提供了便捷的 API 方法来获取不同类型的配置值，包括字符串、整数、布尔值等，每个方法都支持设置默认值以提高系统的健壮性。当配置发生变更时，SDK 能够自动刷新本地缓存，确保应用始终使用最新的配置信息。为了提高可靠性，SDK 还实现了定期轮询机制作为长轮询的补充，即使网络出现短暂异常也能及时获取配置更新。

配置热更新机制

推拉结合的更新策略

长轮询机制实现 配置变更通知服务采用了长轮询技术来实现实时的配置推送。当客户端请求配置更新时，服务端首先检查是否有立即可用的配置变更，如果有则立即返回。如果没有，服务端会将请求加入等待队列，设置合理的超时时间（通常 30 秒）。当配置确实发生变更时，服务端会主动向所有等待的客户端推送变更事件，包含变更的具体内容和时间戳。这种机制既避免了频繁轮询造成的资源浪费，又确保了配置变更能够及时传达到所有相关的应用实例。
配置变更监听器 配置变更监听器是客户端处理配置更新的核心组件。当收到配置变更事件时，监听器会遍历所有变更项并逐一处理。对于 Spring 应用，监听器会动态更新 Spring Environment 中的属性源，将新配置添加到最高优先级，确保应用能立即使用新配置。同时，监听器还会刷新那些使用@Value 注解绑定的配置字段，并通过 Spring 的事件机制通知其他相关组件，实现配置变更的级联处理。

灰度发布机制

分批次配置发布 灰度发布服务提供了配置变更的渐进式发布能力。系统首先获取目标应用的所有实例列表，然后根据设定的灰度比例计算每批次需要更新的实例数量。发布过程采用分批次进行，每个批次完成后都会设置观察期，在此期间系统会密切监控已更新实例的健康状况和关键业务指标。只有当当前批次的所有检查都通过时，才会继续下一批次的发布。如果在任何阶段发现异常，系统会立即触发回滚机制，确保配置变更的安全性。这种机制有效降低了配置变更对线上服务的风险，特别适用于对稳定性要求极高的生产环境。

配置安全与权限管理

敏感配置加密

配置加密机制 配置加密服务专门用于保护敏感配置信息的安全。系统能够自动识别敏感配置项（如包含 password、secret、token、key 等关键字的配置），并对其进行加密处理。加密采用了双重保护机制：首先使用 AES 算法对配置值进行对称加密，然后使用 RSA 算法对 AES 密钥进行非对称加密。这种设计既保证了加密的性能，又确保了密钥的安全性。在解密时，系统先用 RSA 私钥解密得到 AES 密钥，再用 AES 密钥解密配置值。整个过程对应用透明，应用程序获取到的始终是明文配置值。
权限控制体系 权限控制系统建立了细粒度的访问控制机制，包含用户权限数据模型和权限验证服务。权限数据模型记录了用户对特定应用和环境的访问权限，包括读取、写入、管理员等不同级别。权限验证服务实现了分层的权限检查逻辑：首先检查用户是否具有系统管理员权限，然后检查应用级权限，最后检查环境级权限。权限授予操作会同时记录操作时间、授权人员等信息，并通过审计日志服务记录所有权限变更操作，确保权限管理的可追溯性。

33.5 配置审计与版本管理

配置变更审计

变更记录跟踪
配置变更审计系统通过详细的日志记录来跟踪所有配置变更操作。变更记录数据模型包含了变更的完整上下文信息：应用名称、环境、配置键名、变更前后的值、变更类型（新增、修改、删除）、操作人员、变更时间、变更原因以及审批状态等。配置审计服务在执行配置更新时会自动创建变更记录，首先获取当前配置值作为对比基准，然后根据业务规则判断是否需要审批流程。对于需要审批的变更，系统会将状态设置为待审批并发送审批通知；对于无需审批的变更，则直接执行配置更新操作。
配置版本管理
配置版本管理服务提供了配置快照和回滚功能。创建快照时，系统会获取指定应用和环境的所有当前配置，并将其打包成一个版本快照，包含应用名称、环境标识、版本标签、快照创建时间和所有配置项信息。配置回滚功能允许将配置恢复到任意历史快照版本，系统首先根据快照 ID 获取目标版本的配置数据，然后获取当前配置进行对比分析，计算出需要变更的配置差异。最后通过配置审计服务批量应用这些变更，确保回滚操作的安全性和可追溯性。

33.6 配置中心最佳实践

配置管理规范

配置命名规范
推荐采用层次化的配置命名结构，以便于管理和维护。数据库相关配置应包含连接信息如 URL、用户名、密码，以及连接池配置如最小和最大连接数。缓存配置包含 Redis 服务器地址、端口和超时设置。业务配置定义具体的业务参数，如订单超时时间和最大重试次数。配置值中可以使用环境变量引用，提高配置的灵活性和安全性。
环境配置策略
环境特定配置策略通过 Spring Profile 机制实现不同环境的配置隔离。系统定义通用配置供所有环境共享，如应用名称等基础信息。同时为不同环境定义专用的配置 Bean，开发环境使用内存数据库 H2 便于开发调试，生产环境使用真实的数据库连接配置。这种策略确保了配置的环境适应性，同时避免了环境间的配置冲突。

性能优化策略

配置缓存机制
配置缓存组件使用本地缓存来提高配置访问性能。缓存系统设置了合理的容量限制（最多缓存 10000 个配置项）和过期策略（写入后 5 分钟过期，1 分钟后自动刷新）。当获取配置时，系统首先尝试从缓存中读取，如果缓存未命中或访问失败，则会降级到备用的配置获取方式。缓存的自动加载机制会在后台异步地从配置中心加载最新配置，确保缓存数据的时效性。
降级保护机制
配置服务降级保护机制确保在配置中心不可用时系统仍能正常运行。服务采用多层降级策略：首先尝试从配置中心获取最新配置，如果失败则降级到本地缓存获取配置值，如果本地缓存也没有相应配置，最后使用预设的默认值。整个降级过程对调用方透明，保证了配置服务的高可用性。同时系统会记录降级事件的日志，便于运维人员及时发现和处理配置中心的问题。

降级和熔断：如何屏蔽非核心系统故障影响

34.1 服务降级与熔断的必要性

分布式系统的脆弱性

在微服务架构中，系统由众多服务组成，服务间存在复杂的调用关系。这种架构虽然提供了良好的扩展性和可维护性，但也带来了新的挑战：

故障传播效应
- 单个服务的故障可能导致整个系统不可用
- 调用链越长，出现故障的概率越高
- 资源竞争导致的雪崩效应
实际案例分析 案例：电商系统推荐服务故障导致整站崩溃
- 背景：双 11 期间，商品推荐服务因为机器学习模型更新失败导致响应缓慢
- 影响链路：商品详情页 → 推荐服务 → 整个详情页不可用 → 用户无法浏览商品
- 损失：在最关键的流量高峰期，整站不可用 30 分钟
- 根本问题：缺乏对非核心服务的降级机制

服务分级策略

为了有效进行降级和熔断，首先需要对系统中的服务进行分级：

核心服务
- 用户登录验证：系统基础认证功能
- 商品信息查询：核心业务数据查询
- 订单创建和支付：关键交易流程
- 库存扣减：核心业务逻辑
重要服务
- 用户个人信息：用户基础数据管理
- 订单历史查询：历史交易记录
- 商品搜索：商品发现功能
一般服务
- 商品推荐：个性化推荐功能
- 用户行为分析：数据分析服务
- 评论系统：用户互动功能
边缘服务
- 广告展示：营销推广功能
- 统计分析：数据统计服务
- 日志收集：系统监控功能

服务降级机制设计

降级策略分类

功能降级 商品推荐服务实现了多层次的功能降级策略。正常情况下，系统使用机器学习推荐服务提供个性化推荐，通过熔断器来监控服务健康状态。当机器学习服务出现异常时，系统会捕获熔断器开启异常，自动降级到简单推荐服务，提供基于商品热度的通用推荐。如果简单推荐服务也不可用，系统会进一步降级到默认推荐，返回预设的热门商品列表，确保推荐功能始终可用，只是推荐质量会有所下降。
页面降级 商品详情页控制器实现了分层的页面降级策略。核心的商品基础信息被定义为必须成功加载的内容，如果获取失败会直接抛出异常。用户评论被归类为重要但可降级的内容，当评论服务不可用时，页面会显示空的评论列表并提示用户"评论暂时无法显示"。商品推荐则被视为完全可降级的内容，当推荐服务失败时，系统不会向页面模型添加推荐数据，前端页面会自动隐藏推荐模块。这种策略确保了页面的核心功能始终可用，同时优雅地处理非核心功能的异常情况。
数据降级 用户档案服务采用了数据层面的降级策略。基础用户信息作为核心数据必须成功获取，而用户行为数据则可以降级处理。当用户行为服务不可用时，系统首先尝试从 Redis 缓存中获取历史的用户行为数据，如果缓存中也没有相关数据，则使用默认的用户行为数据。这种多层数据降级机制确保了用户档案服务的稳定性，即使在部分依赖服务不可用的情况下，仍能返回基本可用的用户档案信息。

自动降级机制

基于响应时间的自动降级 自动降级管理器通过定期监控服务性能指标来实现智能降级决策。系统维护了服务性能指标映射表和降级状态记录，每 10 秒执行一次健康检查。降级触发条件包括：平均响应时间超过 5 秒、错误率超过 10%、或超时率超过 5%。当检测到服务性能恶化时，系统会自动触发降级流程，更新降级状态、发送告警通知、记录降级日志，并通过配置中心通知所有客户端节点。当服务性能恢复正常时，系统也会自动解除降级状态，实现降级和恢复的全自动化管理。

熔断器模式实现

熔断器状态机

熔断器实现了一个三状态的状态机模式，包括关闭、开启和半开启三种状态。关闭状态下熔断器允许正常调用；开启状态下拒绝所有调用；半开启状态下进行试探性调用来判断服务是否恢复。

熔断器的核心执行逻辑如下：当处于开启状态时，首先检查是否已经过了超时窗口期，如果是则转入半开启状态并重置成功计数器，否则直接抛出熔断器开启异常。执行业务逻辑时，如果成功则调用成功处理方法，失败则调用失败处理方法。

成功处理逻辑：在半开启状态下记录成功次数，当连续成功次数达到阈值时恢复到关闭状态并重置失败计数器；在关闭状态下直接重置失败计数器。

失败处理逻辑：记录失败次数和失败时间，在半开启状态下一旦失败立即回到开启状态；在关闭状态下当失败次数达到阈值时转入开启状态。这种设计确保了系统能够自动识别服务故障并进行保护，同时能够在服务恢复时自动解除保护。

集成 Hystrix 实现熔断

商品服务客户端通过 Hystrix 框架实现了完整的熔断保护机制。主要方法配置了熔断参数：执行超时时间 3 秒、请求量阈值 20 个、错误率阈值 50%、熔断窗口期 10 秒。当服务调用出现问题时，系统会自动调用降级方法。

降级处理逻辑采用多层策略：首先尝试从缓存中获取商品信息，如果缓存中有数据则直接返回；如果缓存也没有，则返回包含错误提示信息的默认商品对象，告知用户"商品信息暂时无法获取，请稍后重试"，并将商品可用状态设为 false。

熔断器状态检测功能能够识别熔断器是否处于开启状态，当检测到熔断器开启时，系统会记录熔断事件到监控系统，同时发送告警通知运维人员，然后调用标准的降级方法返回默认数据。这种机制确保了在服务不可用时用户仍能获得基本的响应，避免了请求超时和页面崩溃。

流量控制与限流

令牌桶算法实现

令牌桶限流器实现了经典的令牌桶算法来控制请求流量。算法核心包含桶容量、令牌生成速率、当前令牌数量和上次填充时间等关键参数。

令牌获取机制：系统提供了单令牌和多令牌获取方法，每次获取前都会先刷新令牌桶。刷新过程计算从上次刷新到现在的时间差，根据令牌生成速率计算应该添加的令牌数量，将新令牌加入桶中但不超过桶的最大容量。如果桶中有足够的令牌，则扣除相应数量的令牌并返回成功；否则返回失败。

这种算法的优势在于允许短时间的突发流量（利用桶中积累的令牌），同时长期来看能够严格控制平均流量不超过设定的速率。算法实现了线程安全的同步机制，确保在高并发环境下的正确性。

分布式限流实现

分布式限流器通过 Redis 和 Lua 脚本实现了跨多个应用实例的统一限流控制。系统使用 Lua 脚本来保证限流操作的原子性，避免并发访问时的数据竞争问题。

Lua 脚本的核心逻辑如下：首先从 Redis 中获取指定键的令牌桶状态（当前令牌数和上次刷新时间），如果不存在则使用默认值。然后获取当前时间，计算与上次刷新的时间差，根据时间差和令牌补充速率计算应该添加的令牌数量，更新令牌桶中的令牌数量但不超过桶容量。如果桶中有足够的令牌，则扣除一个令牌并更新 Redis 中的状态，同时设置键的过期时间，返回成功标识；否则只更新状态，返回失败标识。

系统提供了便捷的用户级和 API 级限流方法。用户级限流使用"rate_limit:user:{userId}“格式的键，通常设置为每分钟允许的最大请求数。API 级限流使用"rate_limit:api:{apiPath}“格式的键，通常设置为每秒允许的最大请求数。这种设计可以灵活应对不同场景的限流需求。

多维度限流策略

多维度限流器实现了分层次的流量控制策略，通过多个维度的限流规则来全方位保护系统。限流检查按照优先级顺序进行：

全局限流是第一道防线，防止系统整体过载，设置为每秒 10000 个请求的上限。如果全局流量超限，直接拒绝请求并记录告警日志。
API 级别限流针对特定接口进行保护，防止某个接口被过度调用，通常设置为每秒 1000 个请求。这可以防止热点接口拖垮整个系统。
用户级别限流防止单个用户的异常行为影响其他用户，通常设置为每分钟 100 个请求。系统从请求头中提取用户 ID 进行识别。
IP 级别限流是最后一道防线，主要防御恶意攻击和爬虫行为，设置为每分钟 200 个请求。系统会智能解析真实客户端 IP，优先从 X-Forwarded-For 头部获取，如果没有则使用直连 IP。

只有通过所有层次的限流检查，请求才能被放行继续处理。这种多维度限流策略可以有效应对各种异常流量场景，确保系统的稳定性和公平性。

34.5 监控与告警

降级熔断监控

降级监控服务负责记录和分析系统的降级熔断事件，为运维决策提供数据支持。

降级事件记录功能包含多个维度的监控：首先在指标注册表中记录降级计数器和降级持续时间计时器，按服务名称和降级类型进行分类统计。对于高优先级服务的降级，系统会立即发送紧急告警，确保运维人员能够第一时间收到通知。同时更新服务健康状态为"降级"状态，供监控大盘展示。

熔断器状态监控专门跟踪熔断器的状态变化。系统会在指标注册表中创建状态量表来记录当前熔断器状态。当熔断器从非开启状态转为开启状态时，发送高级别告警通知相关人员服务暂时不可用；当熔断器从开启状态恢复到关闭状态时，发送信息级通知告知服务已恢复正常。

定期报告生成功能每分钟统计一次各服务的降级情况。系统计算各服务的降级率，当某个服务的降级率超过 10%时，发送中等级别的告警，提醒运维人员关注该服务的稳定性问题。这种定期统计有助于发现系统中的潜在问题和趋势。

限流监控大盘

限流监控控制器提供了 REST API 接口来查询限流统计数据和系统降级状态，为运维团队提供可视化的监控大盘。

限流统计接口实现了 API 和用户两个维度的限流数据汇总。系统遍历指标注册表中以"rate_limit.api"开头的计数器，提取出对应的 API 路径，获取被拒绝的请求数量和总请求数量，计算出拒绝率。最终返回包含 API 指标、用户指标和时间戳的统计报告，为分析系统流量特征和限流效果提供数据支持。

降级监控大盘接口汇总了系统的整体降级状况。它收集所有服务的状态信息、各服务的降级次数统计、最近的降级事件列表等关键信息。返回的监控大盘数据包括服务状态列表、降级计数统计、最近事件记录、服务总数和当前处于降级状态的服务数量。这个接口为运维人员提供了系统健康状况的全局视图，便于快速识别和处理问题。

34.6 最佳实践与实施建议

实施策略

渐进式实施
系统采用分阶段的渐进式实施策略来逐步建立完善的降级熔断机制。
第一阶段专注于建立服务分级体系。通过服务层级注册表，将系统中的所有服务按照业务重要性分为四个等级：核心服务包括用户服务、订单服务、支付服务等关键业务功能；重要服务包括商品服务、库存服务等核心支撑功能；一般服务包括推荐服务、评论服务等增值功能；边缘服务包括分析服务、营销服务等辅助功能。这种分级为后续的降级策略制定提供了基础框架。
第二阶段实施基础降级机制。系统通过事件监听器监听服务降级事件，根据服务等级采用不同的降级策略：核心服务不允许降级，而是启用备用服务来保证可用性；重要服务启用缓存降级，使用历史数据保证基本功能；一般服务使用简化逻辑，提供基础版本的功能；边缘服务可以直接停用，不影响核心业务流程。这种差异化的降级策略确保了系统在故障时能够优先保证核心功能的可用性。
团队培训与文档
- 制定降级手册和操作指南
- 定期进行故障演练
- 建立应急响应流程
- 培训开发和运维团队

关键成功因素

监控体系完善
- 建立全面的服务监控
- 设置合理的告警阈值
- 实时监控降级和熔断状态
自动化程度高
- 自动降级决策
- 自动恢复机制
- 自动化测试验证
业务理解深入
- 准确识别核心业务流程
- 合理设置降级策略
- 平衡用户体验和系统稳定性

高并发系统设计的通用方法#

1. 扩展策略：Scale-up vs Scale-out#

2. 缓存策略：提升系统性能#

3. 异步处理：提升系统吞吐量#

高并发系统的演进原则#

1. 起步阶段：简单优先#

2. 发展阶段：逐步优化#

3. 成熟阶段：架构重构#

架构分层#

什么是分层架构#

分层架构的优势#

如何做系统分层#

分层架构的局限性#

软件设计原则与分层架构的关系#

系统设计目标 1：如何提升系统性能#

高并发系统设计的三大目标#

性能优化原则#

性能的度量指标#

高并发下的性能优化策略#

1. 提高系统的处理核心数#

2. 减少单次任务响应时间#

系统设计目标 2：系统怎样做到高可用？#

可用性的度量#

高可用系统设计方法#

1. 系统设计方面#

Failover（故障转移）#

调用超时控制#

降级#

限流#

2. 系统运维方面#

灰度发布#

故障演练#

开发与运维的关注点差异#

系统设计目标 3：如何让系统易于扩展#

高可扩展性的意义#

为什么提升扩展性会很复杂#

高可扩展性的设计思路#

1. 存储层的扩展性#

业务维度拆分#

数据特征水平拆分#

2. 业务层的扩展性#

业务维度拆分#

重要性维度拆分#

请求来源维度拆分#

扩展性与系统复杂度的权衡#

池化技术：减少频繁创建数据库连接的性能损耗#

频繁创建数据库连接的性能问题#

数据库连接池工作原理#

连接池的维护问题#

线程池技术#

线程池使用注意事项#

池化技术的本质与应用#

数据库优化方案 1：查询请求增加时的主从分离#

主从读写分离的意义#

主从读写的技术关键点#

1. 主从复制原理#

2. 主从延迟问题#

3. 数据库访问方式#

主从复制的广泛应用#

主从复制设计的核心考量#

数据库优化方案 2：写入数据量增加时的分库分表#

分库分表的基本概念#

垂直拆分#

水平拆分#

分库分表引入的问题及解决方案#

分库分表的最佳实践#

发号器：保证分库分表后 ID 的全局唯一性#

数据库主键的选择#

UUID 方案及其局限性#

基于 Snowflake 算法的发号器#

发号器的部署方式#

Snowflake 算法的潜在问题及解决方案#

其他发号器方案#

NoSQL：高并发场景下与关系型数据库的互补#

NoSQL 的概念与分类#

提升写入性能的 NoSQL 设计#

特定场景下的 NoSQL 应用#

提升系统扩展性的 NoSQL 设计#

NoSQL 使用的注意事项#

缓存系统：动态数据查询加速与使用策略#

高并发系统设计的通用方法

1. 扩展策略：Scale-up vs Scale-out

2. 缓存策略：提升系统性能

3. 异步处理：提升系统吞吐量

高并发系统的演进原则

1. 起步阶段：简单优先

2. 发展阶段：逐步优化

3. 成熟阶段：架构重构

架构分层

什么是分层架构

分层架构的优势

如何做系统分层

分层架构的局限性

软件设计原则与分层架构的关系

系统设计目标 1：如何提升系统性能

高并发系统设计的三大目标

性能优化原则

性能的度量指标

高并发下的性能优化策略

1. 提高系统的处理核心数

2. 减少单次任务响应时间

系统设计目标 2：系统怎样做到高可用？

可用性的度量

高可用系统设计方法

1. 系统设计方面

Failover（故障转移）

调用超时控制

降级

限流

2. 系统运维方面

灰度发布

故障演练

开发与运维的关注点差异

系统设计目标 3：如何让系统易于扩展

高可扩展性的意义

为什么提升扩展性会很复杂

高可扩展性的设计思路

1. 存储层的扩展性

业务维度拆分

数据特征水平拆分

2. 业务层的扩展性

业务维度拆分

重要性维度拆分

请求来源维度拆分

扩展性与系统复杂度的权衡

池化技术：减少频繁创建数据库连接的性能损耗

频繁创建数据库连接的性能问题

数据库连接池工作原理

连接池的维护问题

线程池技术

线程池使用注意事项

池化技术的本质与应用

数据库优化方案 1：查询请求增加时的主从分离

主从读写分离的意义

主从读写的技术关键点

1. 主从复制原理

2. 主从延迟问题

3. 数据库访问方式

主从复制的广泛应用

主从复制设计的核心考量

数据库优化方案 2：写入数据量增加时的分库分表

分库分表的基本概念

垂直拆分

水平拆分

分库分表引入的问题及解决方案

分库分表的最佳实践

发号器：保证分库分表后 ID 的全局唯一性

数据库主键的选择

UUID 方案及其局限性

基于 Snowflake 算法的发号器

发号器的部署方式

Snowflake 算法的潜在问题及解决方案

其他发号器方案

NoSQL：高并发场景下与关系型数据库的互补

NoSQL 的概念与分类

提升写入性能的 NoSQL 设计

特定场景下的 NoSQL 应用

提升系统扩展性的 NoSQL 设计

NoSQL 使用的注意事项

缓存系统：动态数据查询加速与使用策略