高并发系统架构设计全链路指南

📌 第一章：架构优化

核心目标：提升系统 高并发 & 高可用能力，优化架构，提高吞吐量。

---

1.1 微服务高可用优化

解决问题：微服务可能存在 单点故障、扩展性差、调用效率低 等问题。

---

📍1.1.1 服务无状态化

📌 目的：让服务实例可以 随时扩缩容、快速恢复，避免单点故障。

🚨 可能的问题

现象	影响
本地存储 Session，导致用户粘连某个实例	实例挂掉后，用户重新登录
订单等业务逻辑依赖本地缓存	容器扩缩时数据丢失
静态文件（Excel/图片）存本地	实例销毁后文件丢失

✅ 解决方案

1. 去掉本地 Session，使用 Redis / JWT 认证
2. 去掉本地缓存，使用 Redis + 本地 LRU 缓存
3. 对象存储代替本地存储，如 OSS / MinIO

💡 代码示例

方案 1：使用 Redis 共享 Session

@Configuration
@EnableRedisHttpSession(maxInactiveIntervalInSeconds = 1800)
public class RedisSessionConfig {}

方案 2：JWT 代替 Session

String token = Jwts.builder().setSubject(userId).setExpiration(new Date(System.currentTimeMillis() + 86400000)).signWith(SignatureAlgorithm.HS512, SECRET_KEY).compact();

📌 流程图

[用户请求] -> [Nginx 负载均衡] -> [多个服务实例] -> [Redis 存储会话]

---

📍1.1.2 负载均衡（Nginx + Spring Cloud Gateway）

📌 目的：优化请求调度，提高吞吐能力。

✅ 解决方案

1. Nginx + 负载均衡（RR / LeastConn / IP Hash）
2. Spring Cloud Gateway 提供 API 网关能力
3. 长连接（HTTP2 / WebSocket）减少 TCP 开销
4. 请求压缩（gzip / brotli）提高传输效率

📌 Nginx 负载均衡示例

upstream backend {least_conn;server service1:8080;server service2:8080;
}
server {listen 80;location /api/ {proxy_pass http://backend;}
}

📌 Spring Cloud Gateway 配置

spring:cloud:gateway:routes:- id: user-serviceuri: lb://USER-SERVICEpredicates:- Path=/user/**

---

📍1.1.3 服务间调用优化（gRPC / HTTP2）

📌 目的：降低服务间延迟，提高 QPS。

✅ 解决方案

方案	优势
gRPC 替换 Feign	减少数据包开销，速度提升 7~10 倍
HTTP2 复用连接	减少 TCP 建立消耗
批量请求合并	减少网络请求次数

💡 gRPC 代码示例

Server 端

public class UserServiceImpl extends UserServiceGrpc.UserServiceImplBase {@Overridepublic void getUser(UserRequest request, StreamObserver<UserResponse> responseObserver) {UserResponse response = UserResponse.newBuilder().setName("张三").build();responseObserver.onNext(response);responseObserver.onCompleted();}
}

Client 端

ManagedChannel channel = ManagedChannelBuilder.forAddress("localhost", 50051).usePlaintext().build();
UserServiceGrpc.UserServiceBlockingStub stub = UserServiceGrpc.newBlockingStub(channel);
UserResponse response = stub.getUser(UserRequest.newBuilder().setUserId("123").build());

---

1.2 异步化 & 事件驱动架构

📌 解决问题：系统 同步阻塞，订单高并发压力大，需要 异步化 提高吞吐。

---

📍1.2.1 任务异步化（线程池、MQ）

📌 目的：避免业务阻塞，提升并发处理能力。

✅ 解决方案

场景	方案
下单扣库存	MQ 异步处理
批量任务	线程池执行
延迟任务	Redis / MQ 处理

💡 代码示例

线程池优化

@Bean
public Executor taskExecutor() {ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();executor.setCorePoolSize(10);executor.setMaxPoolSize(50);executor.setQueueCapacity(100);executor.initialize();return executor;
}

RocketMQ 异步下单

@RocketMQMessageListener(topic = "order", consumerGroup = "order-group")
public class OrderConsumer implements RocketMQListener<String> {@Overridepublic void onMessage(String message) {processOrder(message);}
}

---

📍1.2.2 事件驱动架构（RocketMQ + Kafka）

📌 目的：解耦服务，提高系统扩展能力。

✅ 方案

场景	解决方案
订单创建 -> 库存扣减	事件驱动（MQ）
订单支付 -> 物流发货	事件驱动（MQ）

📌 事件流示意图

[用户下单] -> [订单中心] -> (MQ) -> [库存中心] -> (MQ) -> [物流中心]

---

1.3 分库分表 & 数据分片

📌 解决问题：数据库单点压力大，单表行数过多影响查询效率。

---

📍1.3.1 MySQL 水平/垂直拆分

📌 目的：减少单库压力，提高并发处理能力。

✅ 方案

拆分方式	方案
垂直拆分	拆分订单、用户、支付等
水平拆分	按 用户 ID 取模 分表

📌 分库分表示例

CREATE TABLE order_0 (...) PARTITION BY HASH(user_id) PARTITIONS 4;

---

📍1.3.2 ShardingSphere 代理层优化

📌 目的：屏蔽分库分表复杂性，提高开发效率。

✅ 解决方案

方案	作用
读写分离	让 查询走从库，写入走主库
分库分表	自动路由 SQL

ShardingSphere 配置

sharding:tables:t_order:actual-data-nodes: ds${0..1}.t_order${0..1}key-generator:column: order_idtype: SNOWFLAKE

---

🔚 总结

✅ 微服务高可用：服务无状态化 + 负载均衡 + gRPC
✅ 异步化处理：RocketMQ 异步下单 + 线程池优化
✅ 数据库优化：ShardingSphere 读写分离 + 分库分表