高并发系统设计：一个技术负责人的实战分享

大家好，我是林涛，目前在一家中型互联网公司担任技术团队负责人。今天想和大家一起聊聊“高并发系统设计”这个话题。

为什么会写这篇文章呢？其实是因为最近我们上线了一个新的活动推广系统，承载量远超预期，从一开始的日常几十 QPS 瞬间暴涨到上万级别的请求量，整个后端架构经历了一次洗礼。在这个过程中，我和团队遇到了很多棘手的问题，也积累了不少宝贵的经验。

这次项目让我深刻体会到，高并发不仅仅是性能调优的问题，更是一场对整体系统架构、开发流程、运维能力的综合考验。希望通过这篇实战总结，能够给正在或即将面临类似问题的同学一些参考和启发。

一、项目背景与挑战

事情要从去年年底说起。我们公司计划推出一个新的用户拉新活动，目标是在短时间内吸引大量新注册用户，同时带动老用户的活跃度。按照市场部门的测算，这个活动预计会在上线后的前30分钟内吸引超过100万用户的访问，峰值QPS会达到5000以上。

我们的现有系统原本是为日均几十万UV设计的，主要使用的是Spring Boot+MySQL+Redis的经典组合。这种体量的流量冲击对于我们来说，可以说是一个前所未有的挑战。如果不做优化和调整，直接上线的话，系统很可能会在第一波流量高峰时崩溃。

最开始我带着团队做了评估，发现几个关键点：

• MySQL数据库扛不住这么高的并发读写压力；
• 单节点部署的服务容易成为瓶颈；
• 缓存没有针对热点数据进行预热和隔离；
• 没有熔断降级机制，一旦某个服务出问题，整个链路都会挂掉；
• 日志收集和监控体系不够完善，出了问题难以快速定位。

那怎么办？只能硬着头皮上，一边开发功能，一边重构系统。

二、技术方案选型与架构升级

面对这个局面，我们决定围绕以下几个方向进行架构改造：

1. 负载均衡 + 多节点部署

为了提升系统的横向扩展能力，我们在原有Nginx的基础上引入了Kubernetes进行容器化管理，并配合阿里云SLB（Server Load Balancer）实现负载分发。服务本身改成了无状态设计，Session信息全部通过Redis存储。

# 示例：Kubernetes deployment配置片段
apiVersion: apps/v1
kind: Deployment
metadata:
  name: activity-service
spec:
  replicas: 8
  selector:
    matchLabels:
      app: activity-service
  template:
    metadata:
      labels:
        app: activity-service
    spec:
      containers:
        - name: app
          image: registry.example.com/activity:latest
          ports:
            - containerPort: 8080
          resources:
            requests:
              memory: "2Gi"
              cpu: "500m"
            limits:
              memory: "4Gi"
              cpu: "2000m"

小插曲：刚开始上线的时候因为replicas数量设置太低，导致第一次压测还没到预期QPS就撑不住了，后来我们结合JVM内存和CPU利用率逐步调整，最终找到了合适的节点数和资源配额。

2. 数据库优化与分库分表

我们之前的所有业务数据都放在一个MySQL实例里，单机容量早已接近临界值。为了应对新活动的写入压力，我们把活动相关的表单独抽取出来，使用ShardingSphere实现了水平分库分表。

这里有个细节值得一提：我们并没有一开始就盲目地拆分成多个库，而是先根据ID哈希分成了4个物理表，后续根据测试结果动态扩容到了8张表。这样既能缓解压力，又不会造成不必要的复杂性。

-- 分表策略：按user_id模4取值，分别插入t_activity_log_0~t_activity_log_3
CREATE TABLE t_activity_log_0 (
    id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
    user_id BIGINT UNSIGNED NOT NULL,
    action VARCHAR(64),
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
    PRIMARY KEY (id)
) ENGINE=InnoDB;

另外，我们也做了批量写入优化，把用户行为记录通过队列缓冲后定时提交，减少了每次请求的数据库IO操作。

3. Redis缓存与本地缓存结合使用

我们采用了两级缓存结构：应用节点本地用Caffeine作为一级缓存，热点数据更新通过Redis Pub/Sub广播通知清空；Redis则用来做共享缓存层，存放频繁读取的数据如用户积分、优惠券等。

// 示例：使用Caffeine做本地缓存
Cache<String, ActivityConfig> localCache = Caffeine.newBuilder()
    .maximumSize(1000)
    .expireAfterWrite(5, TimeUnit.MINUTES)
    .build();
    
public ActivityConfig getActivityConfig(String key) {
    return localCache.getIfPresent(key);
}

Redis方面我们设置了不同的Key失效策略，并对异常情况加了重试机制和默认值兜底。

4. 异步处理与消息队列解耦

对于不强求实时性的操作，比如签到奖励发放、积分统计等，我们都抽离成异步任务，通过RocketMQ进行事件驱动。

这样做有几个好处：

• 减少主线程阻塞时间，提高吞吐量；
• 提升系统容错能力，即使消费失败也可以重试；
• 更灵活的任务编排能力。

// 示例：发送MQ消息
Message msg = new Message("ACTIVITY_TOPIC", "*".getBytes(), UUID.randomUUID().toString().getBytes());
SendResult sendResult = rocketMQTemplate.getProducer().send(msg);

消费者端我们做了幂等控制，避免重复处理，比如检查是否已经发放过奖励，或者更新状态前加版本号校验。

5. 限流 & 熔断 & 降级机制落地

为了避免突发流量击垮系统，我们引入了Sentinel来做全局限流控制，设置了一些关键接口的QPS阈值，比如注册接口每秒最多允许1000次请求，超过之后触发限流拒绝。

同时结合Hystrix做了熔断机制，当某个依赖服务出现故障时，及时切断调用链条，防止雪崩效应。

// Sentinel资源定义示例
@SentinelResource(value = "activity-register", blockHandler = "handleBlock")
public void register(ActivityRegisterDTO dto) {
    // 正常逻辑处理
}

public void handleBlock(BlockException ex) {
    log.warn("触发限流，当前请求被拒绝");
    throw new BusinessException("当前注册人数过多，请稍后再试");
}

在实际压测中，我们模拟了下游服务不可用的情况，验证了熔断策略的有效性，确实能在极端情况下保护主流程正常运行。

三、踩过的坑和解决方法

说实话，在整个项目的推进过程中，我们碰到了不少坑，有些甚至让我们一度怀疑人生。下面我来分享几个印象比较深的点，希望能帮大家避雷。

1. JVM参数不合理引发FGC问题

在灰度环境测试期间，我们观察到系统经常出现Full GC，响应延迟飙得很高。分析日志发现JVM的Old区频繁GC，于是我们去看了JVM启动参数——结果发现Xms和Xmx设置得太小了，而且GC回收器也没有指定。

解决方案：

• 把堆内存从默认的1G提升到4G；
• 使用G1垃圾回收器；
• 设置合理的Metaspace大小。

调整完之后，FGC频率下降了90%以上，响应时间也明显变稳定了。

2. MySQL自增主键冲突问题

我们在做分表时采用的是Snowflake生成的Long类型ID，但是在某些场景下依然需要使用MySQL自增主键。这个时候我们误以为只要分表就可以解决问题，结果在两个表中出现了相同的自增ID，导致后续查询数据时发生混乱。

后来我们改成了每个分表的自增起始值不同，比如第一个表从1开始递增，第二个表从10亿开始递增。

ALTER TABLE t_activity_log_0 AUTO_INCREMENT = 1000000000;

虽然这只是个小技巧，但在实际生产环境中还是非常有效的。

3. Redis大Key问题

还有一个特别常见的问题是，我们早期把用户积分数据全部存在一个Hash中，比如user:{userId}:points。当用户参与活动较多时，这个Hash的field可能多达几千个，导致单个Key的体积过大。

这个问题在一次压测中暴露出来——Redis占用的内存突增，连接数剧增，性能严重下降。后来我们改成了将每个积分记录独立存储，并加上TTL，才解决了这个问题。

4. 服务发布引发的抖动

上线初期，我们使用Kubernetes滚动更新方式发布新版本，但是有时候会出现部分Pod刚启动就被调用，导致初始化未完成就报错的问题。

解决方案是在Spring Boot中增加了健康检查接口，并在Kubernetes中设置了readinessProbe，只有当应用真正准备好才会加入可用实例池。

readinessProbe:
  httpGet:
    path: /actuator/health
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5

四、上线后的效果总结

经过将近一个月的紧张开发、优化和压测，我们最终成功支撑住了活动第一天的高峰期。整个系统表现如下：

指标	上线前	峰值数据
最大QPS	300	6723
平均响应时间	150ms	< 80ms
接口成功率	95%	99.8%
故障次数	每天2-3次	0次
服务器资源使用率	CPU平均40%，内存70%	CPU平均65%，内存75%

最关键的是，在流量高峰期间系统始终处于可控状态，没有任何核心接口出现超时或错误。这是我们最欣慰的结果之一。

五、几点经验分享与建议

回顾整个过程，我想给各位同行朋友一些实用建议：

1. 架构设计要尽早考虑可扩展性

不要等到系统快崩了再去做优化。在前期设计时就应该预留弹性空间，比如模块划分清晰、接口抽象合理、支持平滑扩容等。这些看似“过度设计”的做法，在后期往往会节省大量成本。

2. 不要迷信单一技术方案

比如你可能会觉得“分库分表就能解决一切”，但其实在某些场景下增加缓存或异步处理往往更简单高效。技术方案要结合具体业务场景来看，适合的才是最好的。

3. 监控和报警体系必须完善

这次我们提前接入了Prometheus + Grafana + AlertManager整套监控体系，实时看板和预警机制帮助我们第一时间发现问题。上线当天如果没这些工具，估计我们早就懵圈了。

4. 测试一定要做真刀真枪的压测

不能只靠单元测试或局部模拟，最好能找专业的压力测试团队，用真实数据、真实网络环境跑一遍，不然很多边界问题根本发现不了。

5. 别忽视运维层面的优化

比如Linux内核参数调优（文件句柄数、TCP设置）、JVM参数配置、慢SQL优化、索引添加等等。这些看似琐碎的东西，在高压环境下都是致命的关键点。

六、结语

高并发从来不是一件容易的事，但它也不是遥不可及的技术难题。只要你愿意从基础做起，一步一个脚印地优化、打磨，大多数系统都可以扛得住高并发的压力。

这篇文章只是我在工作中的一次小小实践总结，不代表所有情况都适用。如果你有更好的思路或者实战经验，欢迎留言交流。技术这条路本就是一场漫长的修行，我们一起加油！

最后，感谢你的耐心阅读。希望未来的某一天，当你在值班室看着监控面板稳如泰山时，也能像我现在一样，露出一丝欣慰的笑容。😊