application.yml 配置

技术探索与实践优化：我在一个高并发项目中的实战经验

---

开篇：为什么写这篇文章？

作为技术团队的负责人，我经常在日常工作中面对各种技术难题。而最让我感慨的是，在解决这些问题的过程中，真正起作用的往往不是“最先进的技术”，而是如何将已有的技术更好地应用到实际业务中。

今天我要分享的，是一次真实项目的经历：我们面对一个突发的高并发访问压力，系统频频崩溃，用户反馈激增。通过这次事件，我和团队从架构调整、代码优化到服务治理，做了一系列技术探索与实践，最终不仅解决了问题，还总结出一套可复用的技术优化方案。

希望这篇文章能给正在面临类似问题的朋友一些启发和参考。

---

项目背景

去年年底，我们接手了一个为电商平台提供商品搜索与推荐服务的后端系统，核心功能包括：

• 实时商品检索
• 搜索词联想建议
• 用户个性化推荐（基于历史行为）
• 商品评分和价格筛选

这个服务原本是基于 Spring Boot + MySQL 构建的传统单体架构，随着平台用户量激增，特别是在“双11”期间，QPS 高达上万，系统频繁出现响应慢、超时甚至崩溃的现象。

我们临危受命，要在两周内完成性能优化，并保障整个促销期的服务稳定性。

---

遇到的挑战

接到任务后，我们立刻对整个系统做了全面分析，发现了几个核心问题：

1. 数据库瓶颈严重

   • 所有查询请求直接打到 MySQL，没有缓存层。
   • 频繁使用 JOIN 和 GROUP BY，导致慢查询频发。
   • 热点数据集中，锁竞争严重。

2. 线程模型不合理

   • 默认 Tomcat 线程池配置不合理，处理慢请求会阻塞其他请求。
   • 同步调用多，缺乏异步化机制。

3. 缺乏限流降级能力

   • 服务之间没有熔断机制，某个接口异常会导致连锁反应。
   • 没有限流策略，恶意爬虫攻击或突发流量容易击垮系统。

4. 监控体系不健全

   • 缺乏统一的 Metrics 收集和告警机制。
   • 日志级别混乱，问题排查困难。

---

我们的技术方案与实现思路

面对这些问题，我们采取了“渐进式重构+局部优化”的策略，重点从以下四个方面入手：

一、引入缓存分层架构（Redis + Caffeine）

为了减轻 MySQL 压力，我们在整体架构中引入两级缓存：

• 本地缓存（Caffeine）：用于存储高频读取、低变更频率的数据，如热门商品的基本信息。
• 分布式缓存（Redis）：用于共享多个节点间的数据，比如用户行为日志、个性化推荐结果等。

// 使用 Caffeine 做本地缓存示例
LoadingCache<String, Product> localCache = Caffeine.newBuilder()
        .maximumSize(10_000)
        .expireAfterWrite(5, TimeUnit.MINUTES)
        .build(key -> fetchProductFromDB(key));


![开发工具界面-1](https://code-guide.oss.shanghai.autogptai.club/common/file/download?name=date2025061301/b02e4655-f4fd-4445-a69c-226838ccf30f.jpg)


Product product = localCache.get(productId);

同时，我们也为 Redis 设置了缓存过期策略和淘汰机制，避免缓存穿透和雪崩问题。

二、异步化 + 线程池隔离

我们将大量非关键路径操作异步化处理，比如记录用户行为日志、推荐计算等，采用 CompletableFuture 异步编程模型：

CompletableFuture.runAsync(() -> {
    // 记录行为日志
    logService.recordUserBehavior(userId, productId, "search");
}, asyncExecutor);  // 使用自定义线程池

并通过线程池隔离不同类型的请求，确保长耗时操作不影响主流程。

三、引入熔断限流组件（Sentinel）

为了防止服务雪崩效应，我们在接口层引入了 Sentinel 进行限流和熔断：

spring:
  cloud:
    sentinel:
      transport:
        dashboard: localhost:8080

通过 Sentinel 控制台设置如下规则：

• QPS 限流：每个接口每秒最多 500 请求，超出拒绝处理。
• 熔断降级：连续错误超过阈值时自动切换备用逻辑或返回默认数据。

四、构建基础监控体系（Prometheus + Grafana）

最后，我们接入了 Prometheus 来收集服务指标（如 QPS、P99 Latency、JVM 内存），并通过 Grafana 展示实时图表，配合 Alertmanager 实现告警推送。

这样我们可以第一时间发现系统异常，及时介入处理。

---

踩坑经验 & 小插曲

在实施过程中，也遇到不少“坑”，这里挑两个印象深刻的给大家讲讲：

1. Redis 缓存雪崩

我们最初设置的所有缓存数据都设置了相同的过期时间（比如1小时）。结果到了整点时刻，大量缓存失效，同时又有很多请求进来重建缓存，MySQL 压力剧增，反而造成了新的抖动。

解决方案： 给缓存加上随机过期时间偏移：

int expireTime = baseExpire + new Random().nextInt(300);  // 增加 0~5 分钟偏移
redisTemplate.expire(key, expireTime, TimeUnit.SECONDS);

2. 异步线程池资源争抢

开始阶段我们没做线程池隔离，所有异步任务共享同一个线程池。结果当推荐计算逻辑变慢，占用了全部线程，连日志记录都无法执行。

解决方案： 为不同类型的任务分配不同的线程池：

@Bean("recommendationExecutor")
@Bean("logRecordExecutor")
public ExecutorService asyncExecutor() {
    return Executors.newFixedThreadPool(10);
}

---

效果总结：优化后的成果

经过这两周的持续优化，系统整体表现有了显著提升：

指标	优化前	优化后
平均响应时间	480ms	120ms
P99 延迟	1200ms	300ms
错误率	6.7%	<0.3%
最大支撑 QPS	~800	>4000

更关键的是，系统在后续的“黑五”、“618”促销中都稳定运行，没有出现重大故障。

---

经验分享：给读者的一些建议

如果你也在经历类似的性能优化项目，以下是我在实践中总结的一些心得和建议：

1. 不要一味追求新技术，先把现有技术用好

   • 很多时候瓶颈并不在于技术栈是否先进，而在于是否合理使用已有工具。
   • 比如 Redis 不光要装，还要懂怎么设置淘汰策略、持久化方式。

2. 监控是第一道防线

   • 没有监控的系统就像盲人开车，出了问题只能靠运气。
   • 提早埋点，尽早发现问题，比事后补救成本低得多。

3. 异步和线程池是高性能的基石

   • 大多数场景下，同步调用并不是必须的。
   • 使用合适的线程池管理并发，避免资源争抢和死锁。

4. 性能优化是个持续过程

   • 不要指望一次性解决所有问题。
   • 在每次上线前后进行压测、观察，持续改进才是王道。

---

结语：真正的技术落地，不只是写代码

写完这篇文章，我不禁回想那段日子——白天压测定位瓶颈，晚上改配置调参数，第二天继续观察。那是一种真实的焦虑，但也是满满的成就感。

在我看来，技术的核心不是炫技，而是解决问题，带来价值。希望这篇文章能帮你在工作中少走弯路，多点效率。

如果你也有关于技术探索和实践优化的故事，欢迎留言交流，我们一起进步！

---

（完）