技术探索与实践的一些思考：从一次高并发场景下的系统重构说起

引子：为什么今天要谈技术探索？

去年夏天，我们团队负责的电商营销平台迎来了上线以来的最大挑战——某个促销活动前，用户量在短短几分钟内暴涨了10倍。虽然我们提前做了一些扩容准备，但系统仍然出现了严重的响应延迟、接口超时甚至部分功能不可用。面对这种情况，作为团队的技术负责人，我深刻意识到：单纯依赖经验是不够的，我们需要更系统的思考和更具前瞻性的技术探索。

这篇文章，就想和大家分享那次事件背后的思考过程、技术方案的选型过程，以及我们在实践中踩过的坑和收获的经验。

---

项目背景：一场失败的促销活动

我们团队维护的是公司内部一个基于Java的营销中台系统，主要提供优惠券发放、限时抢购、积分兑换等功能。系统整体架构采用Spring Cloud微服务架构，部署在Kubernetes上，使用MySQL作为主数据库，Redis用于缓存热点数据，消息队列使用的是RabbitMQ。

在那次大促活动中，我们预计流量会有明显增长，提前做了以下准备：

• 将商品详情页静态化
• 提前增加了Redis集群节点数
• 微服务实例数量进行了横向扩展
• 增加了Nginx负载均衡层

然而这些措施并没有阻止问题的发生：用户点击“领取优惠券”按钮后，大量请求直接打到优惠券下发服务，导致该服务线程池耗尽、数据库连接池被打满，进而引发整个系统链路式雪崩。最终活动开始半小时后被迫终止，对公司品牌影响极大。

这让我开始认真反思：我们到底哪里出了问题？是架构设计本身有缺陷，还是容量评估方式不对？有没有更合理的技术解决方案可以避免类似的问题发生？

---

挑战分析：不只是“扛不住流量”的问题

经过复盘，我们发现问题远比表面看到的复杂得多：

1. 系统瓶颈定位困难

虽然监控工具显示TP99达到了3秒以上，但到底是哪个服务或者哪段代码引起的延迟？当时缺乏足够的调用链追踪能力，只能通过日志大致猜测，排查效率很低。

2. 数据一致性难以保障

在多实例并发下单和发券的过程中，出现了一些重复发券的问题。根本原因在于我们对分布式锁的使用不规范，部分业务没有考虑事务边界。

3. 缓存穿透 & 击穿

由于优惠券信息是缓存在Redis中的，当大量用户同时访问一个不存在的优惠券ID（比如刷单行为）时，导致大量请求直接穿透到数据库，进一步加剧了压力。

4. 流量控制机制缺失

尽管我们对服务做了限流降级的设计，但由于未针对具体API进行细粒度配置，导致核心路径没有保护，非关键路径反而被拦下。

这些问题背后其实反映了一个更深层次的问题：我们的技术体系虽然看起来完整，但实际落地的细节把控不足，特别是在高并发场景下的系统稳定性设计上还存在重大漏洞。

---

解决方案：一次渐进式的重构尝试

第一步：完善可观测性

我们引入了SkyWalking作为分布式链路追踪工具，配合Prometheus + Grafana搭建了一套完整的性能监控体系。

小插曲：刚开始接入SkyWalking的时候，因为Agent配置不当，导致应用启动特别慢。整整花了一天时间才解决这个问题。教训就是：任何新工具的引入都需要有一个小范围试点的过程。

通过这套系统，我们终于能清晰地看出每个API的耗时分布、调用路径和潜在瓶颈。例如我们发现某几个优惠券查询接口竟然占用了80%的总耗时，而其中60%的时间消耗在一个无效的冗余SQL上。

第二步：优化缓存策略

为了避免缓存穿透，我们采用了一个简单但有效的策略：

public Coupon getCoupon(String couponId) {
    // 先查缓存
    Coupon coupon = redis.get(couponId);
    if (coupon != null) return coupon;

    // 加一个本地布隆过滤器防止空值穿透
    if (!bloomFilter.contains(couponId)) {
        log.warn("Potential cache penetration detected, couponId: {}", couponId);
        return null;
    }

    // 锁住后查数据库
    String lockKey = "lock:coupon:" + couponId;
    try {
        if (redis.setnx(lockKey, "1", 5)) { 
            coupon = db.query(couponId);
            if (coupon != null) {
                redis.setex(couponId, 300, coupon); // 缓存5分钟
            }
        } else {
            Thread.sleep(50); // 等待其他线程写入
            coupon = redis.get(couponId);
        }
    } finally {
        redis.del(lockKey);
    }
    
    return coupon;
}

这个实现虽然简单，但在我们后续的压力测试中确实起到了显著的效果。

第三步：精细化限流降级

我们之前使用的是整个服务级别的熔断策略，后来升级为按接口维度进行限流和降级管理。例如：

• /coupon/issue 接口设置QPS上限为1000，并启用滑动窗口计数；
• 当达到阈值时自动切换为排队模式，或返回预先设定好的缓存结果；
• 对非关键路径的接口如“分享统计”、“推荐商品”等，在异常情况下直接熔断，保证主流程。

我们采用了Sentinel作为限流组件，它支持多种规则定义方式，并且可以动态推送规则，非常适合我们这种需要快速响应的场景。

第四步：服务拆分与异步处理

最开始，所有的优惠券业务都在同一个微服务中处理。但随着功能增加，模块之间耦合严重，修改一处就可能导致其他功能受影响。

我们决定将核心发券逻辑抽取出来，单独作为一个服务。并在其上下游引入Kafka，实现生产消费分离。

[用户端] --> [Gateway] --> [Coupon Core Service] --> Kafka --> [Coupon Async Worker]

这样做的好处是显而易见的：

• 核心接口响应时间下降了60%
• 发生异常时可重试，提高了容错能力
• 可以灵活扩展Worker数量应对突发流量

---

实施效果与收益总结

经历了这次重构后，我们在后续几次促销活动中表现得非常稳定。以下是具体的对比数据：

指标	改造前	改造后
平均RT	700ms	200ms
错误率	12%	<1%
最大承载QPS	1500	超过5000
系统恢复时间	数小时	分钟级别

更重要的是，我们建立了一套相对完善的应急响应机制和监控体系，可以在第一时间发现问题并做出反应。

---

经验分享：给技术人的几点建议

1. 不要迷信“高可用”的幻觉

很多团队觉得自己用上了微服务、K8s、Redis集群就万事大吉了。实际上，真正的稳定性不是靠堆技术栈，而是靠对业务的深度理解、对风险的预判能力和日常的压测演练。

2. 防御式编程很重要

尤其是在并发高的环境下，很多看似安全的操作，如果没加兜底机制，很容易出事。举个例子，我们在做优惠券库存扣减的时候，最初是先查库存再update，后来改成了：

UPDATE coupons SET stock = stock - 1 WHERE id = 'xxx' AND stock > 0;

这样一条原子SQL语句就解决了并发下的超卖问题。

3. 工具链不是越多越好，适合才是王道

我们一开始也想引入各种炫酷的新技术，比如Service Mesh、Istio、Opentelemetry等。最后发现，对于中型项目而言，轻量级的SkyWalking+Sentinel+Prometheus组合已经足够解决问题，关键是用好它们。

4. 技术方案的选择要有“成本意识”

比如我们曾纠结是否要引入Redis Cluster来替代原来的哨兵机制。权衡之后发现目前的业务场景下，哨兵+连接池已经能满足需求，没必要为了“先进”而去改动。

---

结语：技术探索永远在路上

技术探索从来不是一个孤立的行为，它必须服务于业务目标、团队能力和长期演进方向。在这个过程中，我们要敢于试错、善于总结，也要懂得取舍与克制。

正如那句话所说：“系统稳定性不是一蹴而就的，它是每一次故障后的反思，每一个深夜里的日志分析，每一份代码提交时的责任感。”愿我们都能在不断探索的路上，走得更稳、更远。

如果你也在经历类似的困境，欢迎留言交流，一起成长。