企业官网建设流程全解析

大促期间，接到运维电话说返利系统告警，延迟队列积压了几十万条消息，下游结算系统被请求打满，接口响应从50ms一路飙到3秒以上。这几乎是每个做电商返利系统的人都会遇到的场景：用户下单只是个开始，后续的返利计算、金额校验、佣金结算全在一条链路上，任何一个环节被流量冲垮，都会直接导致用户返利延迟，甚至出现重复返利、金额错算这类资金级事故。

这篇博文就是围绕这套实战经验展开的，核心就是标题里的三把刀：分布式锁、限流、削峰。分布式锁解决“同一笔返利不能重复处理”的幂等性问题，限流解决“下游系统不能被瞬间冲垮”的保护性问题，削峰解决“流量瞬时尖峰”的缓冲性问题。适合正在负责返利、积分、佣金这类资金敏感系统的后端开发，以及准备应对大促流量冲击的架构师。三块内容都是可以直接落地复用的，不是概念科普。

1. 项目背景与需求拆解

1.1 返利系统面临的真实挑战

返利系统的核心业务逻辑其实不复杂：用户下单后，系统根据订单金额、商品类目、会员等级计算返利金额，再走审核、入账、提现流程。但“不复杂”三个字只说对了一半，真正复杂的是资金类系统对准确性的要求——返利多算一分钱，对账时就要查半天；用户对同一笔订单的返利查询请求刷了三次，系统就得保证只处理一次。

我之前负责的那个系统，平时日订单量几十万，返利服务扛得住，但一到平台级大促，单量直接翻二十倍。问题就集中在这几个地方：第一，返利计算入口被大量重复请求打穿，用户手动触发、订单状态变更回调、MQ重试消息，同一个订单可能同时来多个请求；第二，Redis缓存大面积击穿和过期，导致流量直接透传到数据库；第三，下游结算系统的吞吐上限很低，返利服务一旦放开跑，瞬间就把对方压垮。

这些问题的共同点在于：单机时代加锁、加队列、限速的做法在分布式环境下全部失效了。你不能在A机器上锁住一个订单，阻止B机器处理它；你也不能指望本机的内存队列把流量削平，因为流量分散在多台机器上，每台看到的都只是局部流量。所以需要一套跨节点的协同机制，而这就是分布式锁、限流、削峰存在的意义。

1.2 高并发场景下的三大核心需求

把问题拆开看，高并发场景对返利系统的要求无非是三条：

一是幂等性。同一个订单的返利请求，无论来一次还是来十次，最终返利结果必须完全一致。注意这不是简单的“去重”，而是要保证状态流转的正确性：请求A正在处理中，请求B也到了，B应该等待或者直接返回处理中，而不是两台机器同时处理同一个订单，各算各的，最后产生两条返利记录。

二是保护性。返利系统作为中间链路，上游是订单系统、下游是结算和支付系统。上游可以承受高并发，下游未必能。如果不做限流，一旦返利请求洪峰涌向下游，下游的数据库连接池、线程池会全部耗尽，触发雪崩效应。

三是缓冲性。大促的流量曲线不是平的，而是断崖式的尖峰。系统设计容量如果是每秒一千单，而大促峰值是每秒五千单，最直接的解法不是把容量扩到五千，因为这会造成巨大浪费，更合理的做法是让峰值流量先排队缓冲，再用相对平缓的速率处理。

分布式锁主打幂等性，限流主打保护性，削峰主打缓冲性，三个工具组合起来，正好覆盖这三个核心需求。

2. 整体方案设计：锁、限流、削峰如何协同工作

2.1 三大利器的职责边界与分工

很多人容易把分布式锁、限流、削峰混为一谈，觉得都是控制流量、防止并发的手段，但实际上它们解决的是完全不同层面上的问题。

分布式锁解决的是“并发冲突”问题。它的本质是互斥，同一个订单只能有一个线程在处理，其他线程必须等。当两个请求同时到达，锁能保证执行顺序是确定的，而不是并行的。这在返利系统里非常重要，因为处理同一个订单的返利计算涉及多个步骤：查订单、算金额、写返利记录、更新状态，这些步骤如果并发执行，很容易出现脏读、重复写。

限流解决的是“负载超载”问题。它的本质是拒绝，当瞬时请求量超过系统预设阈值时，多余的请求直接返回失败或排队等待。限流不关心请求是否冲突，只关心总流量是否超过下游能承受的范围。

削峰解决的是“流量不均”问题。它的本质是转移，把高并发时段的流量平移到低峰时段处理。削峰可以看作是一个更高级的缓冲机制，它不拒绝请求，而是把请求暂时存起来，慢慢处理。

在实际架构里的协作关系是：请求先经过限流层，过滤掉明显超出处理能力的流量；然后进入业务层，分布式锁保证同一个订单不会并发处理；业务层处理后产生返利事件，发给消息队列，由消费者异步消费——这一步就是削峰，把同步的瞬时压力转换成异步的持续压力。

这三层是串联关系，每一层都在做减法：限流减少进入的请求量，锁减少并发处理的重叠度，削峰减少下游的瞬时压力。

2.2 整体调用链路的架构编排

以我负责的系统为例，完整的调用链是这样编排的：

用户下单后，订单系统发送消息到返利服务的入口，同时用户端也会主动发起返利查询请求。返利服务入口先做参数校验，然后进入限流层。限流层的设计不是一刀切，而是针对不同的接口做分级处理：返利计算接口限流阈值最高，因为它是核心链路不能轻易拒绝；返利查询接口阈值次之，可以稍微放宽；下游状态回调接口阈值最低，因为外部系统间隔性调用，这边需要严格保护自己不被打垮。

通过限流层后，请求进入业务处理层。此时用分布式锁锁住订单ID维度，保证同一订单的并发请求串行执行。锁的粒度只到订单级别，不锁用户、不锁商品，这样不同订单的操作完全不受影响，最大化并发度。

业务处理成功后，生成返利事件发送到消息队列。这一步是关键转折：从同步调用变成异步投递，返利服务这边只需要保证消息成功写入MQ，不需要等待下游消费完成就可以返回。消息队列成了削峰的核心缓冲区，消费者根据自己的处理能力消费消息，下游结算系统看到的流量是平滑的，而不是脉冲式的。

这个链路里有一个容易被忽略的细节：如果消费端已经做了幂等，为什么还需要在业务入口加分布式锁？答案是幂等侧重“结果不重复”，锁侧重“过程不并发”。消费端的幂等保证消息重复消费时不产生重复数据，但无法保证两个线程同时执行的时候状态判断是准确的——A线程查到订单状态是待处理，B线程也查到是待处理，两个同时往下走，结果就错了。只有锁能保证这种check-then-act的操作是原子性的。

3. 分布式锁：保证返利幂等性的核心机制

3.1 什么情况下锁会出现误判

做分布式锁之前，我先理清了一个问题：什么样的锁方案在返利系统里是不能用的？答案是纯Redis的SETNX加过期时间。原因有两个：

一是锁的持有者可能执行太长而锁先过期。假设业务处理时间是10秒，锁过期时间设了5秒，那么A线程刚处理到一半，锁就没了，B线程过来拿到锁也开始处理，于是两个线程同时操作同一笔订单，幂等性彻底失效。

二是锁的释放存在误删风险。A线程处理完后执行DEL命令释放锁，但此时锁已经因为超时被自动释放了，B线程拿到了锁，A线程的DEL把B线程的锁给删了。结果C线程也拿到了锁，相当于锁形同虚设。

这两个问题的根源是同一个：锁的生命周期无法与业务执行生命周期对齐。要解决这个问题，要么把过期时间设得非常大，大到任何业务都不会超过，但这意味着一旦持有锁的机器宕机，锁要被白白占用很久——这条路线不可取。

比较成熟的方案是用Redisson这类带看门狗机制的锁，或者用ZooKeeper的临时顺序节点。我在生产环境选择了前者，原因后面会讲。

3.2 主流分布式锁方案选型对比

当时我梳理了几个候选方案，做个了对比：Redis SETNX自研、Redisson看门狗锁、ZooKeeper临时顺序节点、数据库乐观锁。

Redis SETNX自研的问题上面说了：锁续期、锁释放、锁重入全都要自己实现，绕过坑的复杂度堪比重新造一个组件。当然如果系统里只有最简单的防重复场景，可以用，但返利系统的业务复杂度太高。

Redisson的看门狗机制解决了锁续期的问题：加锁时默认30秒租约，后台守护线程每10秒检查一次，如果锁还在，就自动续期到30秒，业务跑多久锁就续多久。宕机守护线程停止，锁最多30秒后自动释放，不会无限占用。这正是分布式锁在业务场景下最需要的“我不会锁死你，但也别让我手上的锁被抢走”的能力。

ZooKeeper方案在锁可靠性上更强，因为ZK是CP模型，不存在Redis主从切换丢锁的问题。但代价是性能：秒级锁加解锁操作在高频场景下，ZK的吞吐量远不如Redis。返利系统的锁操作频率极高，每个订单都要加锁，ZK扛不住。

数据库乐观锁的逻辑是update where status=待处理，利用数据库的行锁和条件更新保证原子性。这个方案实际上很可靠，但对数据库的压力大，频繁update会产生大量行锁竞争和死锁检测开销，还会把业务状态和锁状态耦合在一起。

最终选型：锁的核心是Redis+Redisson。原因好记：性能够、续期稳定、代码侵入小。再配合数据库的乐观锁兜底，双保险。

3.3 Redisson分布式锁在返利场景的落地代码

直接展示核心实现代码。先引入依赖：

<dependency> <groupId>org.redisson</groupId> <artifactId>redisson</artifactId> <version>3.17.0</version> </dependency>

初始化Redisson客户端：

@Configuration public class RedissonConfig { @Bean public RedissonClient redissonClient() { Config config = new Config(); config.useSingleServer().setAddress("redis://xxx:6379"); return Redisson.create(config); } }

返利计算入口的锁处理：

@Service public class RebateService { @Resource private RedissonClient redissonClient; public void processRebate(String orderId) { // 锁的粒度：订单维度的KEY，不同订单天然隔离 String lockKey = "rebate:lock:" + orderId; RLock lock = redissonClient.getLock(lockKey); // 等待时间3秒，租约时间-1表示开启看门狗自动续期 boolean locked = false; try { locked = lock.tryLock(3, -1, TimeUnit.SECONDS); if (!locked) { // 获取锁失败，说明同一订单正在处理中，直接返回 log.warn("获取分布式锁失败，订单正在处理中, orderId={}", orderId); throw new RebateProcessingException("该订单返利正在处理中"); } // 业务处理逻辑：查订单、计算返利、写库 doRebate(orderId); } finally { // 释放锁，注意判断持有状态，避免释放他人持有的锁 if (locked) { lock.unlock(); } } } }

几个关键点我说下为什么这样写：

tryLock(3, -1, TimeUnit.SECONDS)的参数含义——第一个参数3是获取锁的等待时间，如果订单正在被其他线程处理，当前线程最多等3秒；第二个参数-1是租约时间，-1表示不固定，交给看门狗自动续期。这里有个细节：tryLock方法只有设置了leaseTime为-1时看门狗才生效，如果你传了一个具体的租约时间，看门狗就不会工作了。

在业务代码里，还有一个容易被忽视的问题：回复处理失败时锁要不要释放？我的处理方式是在finally里统一释放，但释放前要判断是否真的持有了锁。如果业务抛了异常，一样要释放锁，否则锁会一直持有到看门狗到期，白白阻塞同一订单的其他请求。

还有一点：加锁之后要先查一次业务状态再往下走。我在真实需求里遇到过，锁拿到了，结果发现这个订单已经在十分钟前被另一个请求处理完了，白白浪费一次锁。所以规范的流程是：加锁 -> 查状态 -> 判断是否已处理 -> 再算返利。

4. 限流：保护下游系统的防洪闸

4.1 为什么需要限流以及限流算法对比

限流这件事，很多人第一反应是“限流就是拒绝用户请求”，这种理解太片面。限流的意义不在于拒绝，而在于保护。当流量超过下游处理上限时，与其让整个链路雪崩，不如牺牲一部分请求，保住整体可用性。

返利系统中的限流主要有两个场景：一是保护下游结算系统，它的接口吞吐有限，返利服务直接调用它时，需要限制调用速率；二是保护自身数据库和缓存，防止大促时的读放大打垮Redis和MySQL。

限流算法我做过一轮对比：

计数器算法：固定时间窗口内计数，超过阈值就拒绝。实现最简单，但问题很明显：如果时间窗口是1秒，前900毫秒只来了10个请求，最后100毫秒来了900个请求，这1秒内放过了超过阈值的流量，存在窗口边界“突刺”。

滑动窗口算法：把时间窗口细分成多个小格子，每次请求都移除窗口外的记录，统计窗口内的记录数。解决了计数器算法的“突刺”问题，但需要存储每个请求的时间戳，内存开销较大。

令牌桶算法：以固定速率往桶里放令牌，请求来了必须取到令牌才能通过，桶内可以积累令牌应对突发流量。适合允许一定突发量的场景。Guava的RateLimiter就是这种实现。

漏桶算法：请求以任意速率进入桶，以固定速率流出桶，超过桶容量的请求被丢弃。它的特点是输出速率恒定，非常适合保护下游系统。限制性也很明显：无法应对突发流量，即使下游能扛住，也始终是匀速处理。

在返利系统的限流场景里，我最终选了滑动窗口算法而非令牌桶，原因后面说。

4.2 为什么选Redis + Lua做分布式滑动窗口限流

限流有一个先决条件：必须是分布式限流。单机限流（比如Guava的RateLimiter）在单机时代够用，但现在返利服务是三节点、五节点部署，每台机器单独限流1000QPS，整体就是5000QPS，远超预期，失去了限流的意义。

所以限流必须基于共享存储。Redis是现成的选择，但关键问题是如何在Redis里做原子的滑动窗口操作。

典型的滑动窗口实现是这样的：用Redis的ZSet，每个请求时间戳作为score，请求标识作为member。每次来请求就执行：把当前时间戳加入ZSet，移除窗口起点之前的所有成员，然后统计ZSet里剩余成员数量，判断是否超过阈值。这个操作有三个命令，不是原子的，并发下会出错。

解决方式是Lua脚本。Redis是单线程执行Lua脚本，脚本整个执行期间不会被其他命令插入，天然原子。我写的Lua脚本核心逻辑如下：

local key = KEYS[1] -- 限流的key，比如 rebate:limit:settle:20250120 local windowMs = tonumber(ARGV[1]) -- 时间窗口大小，单位毫秒 local threshold = tonumber(ARGV[2]) -- 窗口内最大请求数 local currentTime = tonumber(ARGV[3]) -- 当前时间戳，毫秒 local field = ARGV[4] -- 请求唯一标识，用UUID -- 移除窗口之外的过期记录 redis.call('ZREMRANGEBYSCORE', key, 0, currentTime - windowMs) -- 加入当前请求 redis.call('ZADD', key, currentTime, field) -- 统计当前窗口内的请求数 local count = redis.call('ZCARD', key) -- 设置key的过期时间为窗口大小，防止长期占用内存 redis.call('PEXPIRE', key, windowMs) if count > threshold then return 0 -- 限流，拒绝 else return 1 -- 放行 end

调用代码：

private static final String SLIDING_WINDOW_LUA = "local key = KEYS[1] " + "local windowMs = tonumber(ARGV[1]) " + "local threshold = tonumber(ARGV[2]) " + "local currentTime = tonumber(ARGV[3]) " + "local field = ARGV[4] " + "redis.call('ZREMRANGEBYSCORE', key, 0, currentTime - windowMs) " + "redis.call('ZADD', key, currentTime, field) " + "redis.call('PEXPIRE', key, windowMs) " + "local count = redis.call('ZCARD', key) " + "if count > threshold then return 0 else return 1 end"; public boolean tryAcquire(String key, int windowMs, int threshold) { Long result = redisTemplate.execute( new DefaultRedisScript<>(SLIDING_WINDOW_LUA, Long.class), Collections.singletonList(key), String.valueOf(windowMs), String.valueOf(threshold), String.valueOf(System.currentTimeMillis()), UUID.randomUUID().toString() ); return result != null && result == 1L; }

这个方案的巧妙之处在于：把判断、加记录、清过期放在一个原子操作里完成。不需要在业务代码里加锁，不需要处理并发竞争，Redis单线程天然保证了同一时刻只有一个请求在执行这段逻辑。

4.3 限流参数如何设定才科学

限流参数是绝大多数人容易拍脑袋的地方。我见过有人把限流阈值设成1000QPS，理由是“我们系统设计容量是1000QPS”，但这个数并没有经过验证。

我的建议是先压测，后配参。把下游结算系统的每秒最大处理能力压出来，比如极限是500QPS。那么返利服务对结算接口的限流阈值只能设成500的百分之八十，即400QPS。为什么留余量？因为压测是理想情况，线上还有网络抖动、GC停顿、机器降频等各种因素，而且大促期间下游系统本身也扛着其他调用方的流量。

再一个细节是限流key的设计。用单一key做全局限流会出现热点问题，Redis单实例处理某个key的QPS有上限。我的做法是给key加上时间分片和桶号：比如按分钟维度拆分，再加一个随机桶号，把压力分散到多个key上。限流判断的时候，先用客户端hash选桶，再走Lua——相当于把全局限流变成分片限流。

总结一下限流参数设定的核心经验：

• 绝对不能把限流阈值设成系统压测峰值的满值，留20%的余量是底线。
• 限流不只是QPS限制，还要限制并发数、连接数，全方位保护。
• 限流触发后的降级策略很重要：拒绝请求直接返回错误，还是进入等待队列，不同场景不同选择。返利计算接口可以等待，结算回调接口必须快速失败。

5. 削峰：消息队列做流量缓冲层

5.1 削峰的架构本质：同步转异步的时机选择

削峰这件事的原理一句话就能说清楚：把同步处理改成异步处理，让请求先落在消息队列里，消费者按自己的节奏处理。

但“什么时候该削峰”这个判断很关键。我见过有团队一上来就把所有返利请求全部扔进MQ，结果发生问题排查起来特别痛苦。我的经验是：像用户下单后主动触发返利计算这类非实时强感知的请求，应该走MQ异步；而像返利状态查询这类需要立即返回结果的接口，绝不能走MQ，必须是同步查询。

在时序上，返利削峰的完整流程是这样的：

用户下单成功 -> 订单服务发送“订单完成”事件到Kafka -> 返利服务消费该事件 -> 根据订单号查订单明细 -> 计算返利金额 -> 生成返利记录 -> 同步调用结算系统

其中前面走MQ的部分就是削峰：大促时每秒几千个订单完成事件涌入Kafka，返利消费者不需要立即处理完所有事件，只要保证最终能消费掉就可以。这里消费者的处理速率就是“削平后的水位线”。

有个细节：这个流程里，订单服务发消息到MQ的速度很快，几乎没有瓶颈，真正会积压的是消费者。所以削峰设计要围绕消费者的吞吐量来匹配。如果消费者的最大处理速度是每秒300单，而高峰期每秒进来1000单，那么消费者天然形成一个漏斗，把流量削平到300的节奏。

5.2 Kafka消费者参数调优的实操细节

在返利系统里，用的是Kafka作为消息中间件。选Kafka的原因很简单：吞吐量高、水平扩展容易、社区生态成熟。实际操作中有几个参数直接影响削峰效果。

第一个是max.poll.records。默认值是500，意味着一次拉取最多处理500条消息。处理完这500条后如果超过max.poll.interval.ms，消费者会被判定为死亡，触发rebalance。返利计算的单条耗时如果在20ms上下，500条就是10秒，很容易超时触发rebalance。我把这个参数调小到100，宁可多拉几次，也不让单批处理时间过长。

第二个是enable.auto.commit。默认是true自动提交offset，但我建议设成false手动提交。为什么？自动提交的时机无法掌控，如果业务逻辑处理完500条消息、但offset还没来得及提交的时候消费者挂了，这批消息会被重复消费。手动提交可以让你在确认业务处理完成后才提交offset，配合分布式锁，重复消费也不会有副作用。

关键还是消费幂等。我给返利消费逻辑设计了这样的幂等策略：

public void consumeRebateEvent(String orderId) { // 先查库：返利表有记录说明已处理过 RebateRecord record = rebateMapper.selectByOrderId(orderId); if (record != null) { log.info("订单返利已处理, 跳过消费, orderId={}", orderId); return; } // 从Redis缓存查询处理状态，快速判断，减少数据库查询 String status = redisTemplate.opsForValue().get("rebate:status:" + orderId); if ("FINISHED".equals(status)) { return; } // 加分布式锁防止并发处理同一订单 RLock lock = redissonClient.getLock("rebate:lock:" + orderId); boolean locked = false; try { locked = lock.tryLock(3, -1, TimeUnit.SECONDS); if (!locked) { // 没拿到锁说明正在处理，直接return，等待下次重试 return; } // 双重检查：拿到锁后再次查库，防止拿到锁前已被处理 record = rebateMapper.selectByOrderId(orderId); if (record != null) { return; } // 执行业务逻辑 calculateAndSaveRebate(orderId); // 处理成功后写Redis状态 redisTemplate.opsForValue().set("rebate:status:" + orderId, "FINISHED", Duration.ofHours(1)); } finally { if (locked) { lock.unlock(); } } }

看清楚这个逻辑：先查库，再查缓存，再拿分布式锁，拿到锁后二次查库。这个四次检查的过程，每一层都在处理不同的问题。查库是最终兜底，缓存是快速路径，分布式锁是并发拦截，二次查库是防止“查了旧状态，等锁拿到时状态已变化”的竞态条件。

很多人实现幂等只做到“查一下有没有记录”，没有做分布式锁，也没有做双重检查，结果遇到并发场景照样出问题。这是我踩过坑之后总结出来的完整幂等姿势。

5.3 消息积压的监控与快速恢复手段

削峰方案再完善，也挡不住消费者处理速度严重下降的极端情况。比如下游结算系统挂了，消费者处理失败率飙升，大量消息堆积在Kafka里，lag持续上涨。这种情况必须有明确的监控与恢复预案。

监控方面，我用Prometheus接Kafka的JMX指标，重点看kafka_consumergroup_lag。设置了两个阈值：lag超过5万发告警通知，超过10万触发应急流程。注意lag的作用不只是发现问题，它也是削峰效果的直接度量——lag太大说明削峰堵住了，太小说明消息队列可能没啥流量。

恢复预案我能给出的实操建议是：临时扩容消费者实例。Kafka的消费并发能力与分区数强相关，一个消费者实例最多同时消费一个分区内的消息。如果你只有6个分区，扩到100个消费者实例也没用。所以在设计初期就要把topic分区数规划好，至少按日常峰值流量的三倍来设置分区数。我系统中的返利topic设了24个分区，日常峰值流量下每个分区处理的压力并不大，有充足扩容空间。

另外一个容易被忽略的恢复手段是消费者端的“降级消费”。当发现下游结算系统压力过大、处理失败率升高时，与其无脑重试，不如在消费者里加一个降级开关：暂停调用下游，把返利记录先保存到本地表，状态置为待结算，等下游恢复后再启动对账程序批量补偿。这个方案能极大减轻下游压力，同时保证数据不丢。

6. 线上问题与排查经验实录

6.1 问题一：分布式锁“看起来生效”但重复返利依旧发生

有一段时间线上还是出现了同一订单被处理两次的情况。看日志发现两个线程确实都进入了业务方法，都拿到了锁。查了半天才定位到问题：Redisson的看门狗机制只在tryLock传leaseTime为-1时生效，但我在部分代码路径里忘了走tryLock，直接用lock()方法，又懒得传leaseTime，结果默认leaseTime是30秒。业务处理中有个外部接口调用，最慢可以到40秒，超过30秒锁就自动释放了。两个线程就是在这10秒窗口里同时处理的。

解决方式是：统一走tryLock并显式传-1让看门狗生效。同时我在业务方法里加了一个数据库层面的兜底——对返利记录表加了订单号唯一索引，即使分布式锁被绕过，数据库也会拒绝第二条重复记录。这是分布式锁在资金场景下的重要指导原则：锁可以有漏洞，但数据库的约束不能有漏洞。

6.2 问题二：大促期间限流误伤了正常用户的花费

有一次大促，限流阈值设的是根据压测结果计算的400QPS，但上线后发现这个阈值不够——因为压测只模拟了结算接口调用，忽略了下游系统还有其他服务在调用。结果大促刚开始，限流就触发了，返利服务大量请求被拒绝，用户纷纷反馈返利金额看不到。

排查时先看了监控：返利服务的调用量是350QPS左右，低于400的阈值，被拒比例却高达三成。后来发现限流key设计错了，所有节点的限流都集中在一个Redis key上，但这个key又做了分钟级的窗口计数，导致限流的粒度太粗，某些秒级的突发流量触发了窗口内的限额。

修正方案有两个：一是把限流key细化到秒级窗口，二是把阈值按系统侧重新压测。更重要的是加了一个“放行策略”：当用户之前在正常阈值内的请求被误限之后，通过降级接口自动放行核心用户（比如高等级会员）的返利请求。处理之后，误伤率从30%降到了1%以下。

6.3 问题三：消息消费端积压导致返利延迟

大促期间日报警：返利消息lag从几千涨到几十万。排查发现消费端没有明显异常，但单个消息的处理时间异常变长，从平均20ms涨到了200ms。最终定位到是数据库连接池配置太小，消费者线程一多就把连接池打满，所有SQL都在等连接，处理速度自然雪崩。

修复方式是调整数据库连接池最大连接数，同时给消费逻辑加了批量操作，把原来单条插入返利记录改成batch insert，一次插50条，把数据库的交互次数降了一个数量级。调整之后lag在半小内恢复正常。

这个问题的启示是：削峰方案里的消费者吞吐量，不只是消费者代码本身的速度，还受数据库连接池、下游接口响应时间等多重因素制约。做压测时要把整条链路都压进去，不能只压业务方法。

6.4 高频问题速查表

写在最后

返利系统的高并发解决方案，说到底是三句话：用分布式锁保准确，用限流保稳定，用削峰保平滑。三者的关系不是孤立的，而是层层嵌套——限流挡在最前面，锁保障业务执行的幂等性，削峰把压力转移到消费者可控处理的节奏里。

我个人亲测下来最值钱的一条经验是：不要依赖单一手段解决所有问题。分布式锁可能会过期，限流阈值可能会设错，MQ消息可能会积压，所以每一层都要有兜底方案。数据库唯一索引兜底幂等，降级开关兜底限流误伤，死信队列兜底消费失败。高并发系统不怕复杂，怕的是每个环节都只有一层保护，一旦穿透就是事故。

最后再分享个调试小技巧：在本地上模拟高并发时，不用完全复制线上的Redis和Kafka，可以用嵌入式Redis和内存版Kafka跑通整个链路，把限流的Lua脚本、Redisson的锁行为、消息消费的幂等逻辑都验证一遍。但记住，生产环境还是要做一次压测，因为真正的风险藏在Redis连接池、Kafka分区数、数据库连接池这些本地环境看不出来的资源约束里。