企业官网建设流程全解析

1. 项目背景与总体架构设计

1.1 业务规模与核心挑战

先把这个项目的背景讲清楚。这是一个电商平台的模拟大促秒杀项目，商品数量 20 万，预约用户规模 100 万，目标峰值对外宣称百万 QPS。乍一听“百万 QPS”挺吓人，但经历过几次大促的人都知道，真正落到后端写链路的高并发请求通常远低于这个数，关键在于怎么在各个入口把流量削平、过滤、分流，而不是让所有请求都打穿到数据库。

秒杀场景下最头疼的其实是三个问题：第一，瞬时流量极高，开始抢购的那几秒是最高峰，如果所有用户同时点按钮，请求洪峰能把任何单机服务冲垮；第二，库存扣减必须保证不超卖也不少卖，20 万件商品的库存分散在若干缓存节点和数据库分表里，任何一步出现并发竞态，都会造成资损；第三，前后端都要配合，前端不能重复提交，后端不能重复下单，用户 100 万预约的资格校验还要在秒杀开启瞬间扛住大量读请求。

所以这个项目的设计核心不是“把所有请求都处理完”，而是在“尽量少的关键请求”上做到极致的可靠。换句话说，秒杀系统本质上是一个流量控制工程，而不是一个普通 CRUD 工程。

1.2 分层架构与技术选型

项目的总体架构可以简单划分成四层：接入层、应用层、缓存层、存储层。接入层负责静态资源分发和网络层限流，应用层跑核心业务逻辑，缓存层存放库存和预约资格，存储层最终落库订单和流水。这样的分层能保证每一层都有独立的扩展能力，不至于因为某一层的瓶颈拖垮整条链路。

技术选型方面，应用层用了常用的 Spring Boot 微服务框架，缓存层使用 Redis Cluster，配置中心在 Apollo 和 Nacos 之间做了选型，数据库采用 MySQL 主从加商品分表。为什么不用单机 Redis？20 万商品如果集中在一两个 Redis 节点上，内存和热点会非常集中，秒杀时一个热 Key 就能把单节点 CPU 打满。Redis Cluster 的好处是数据可以按照 slot 分散到多台机器，天然规避单点压力。

存储层看上去简单，但秒杀订单不能直接落到普通业务表，而是先通过消息队列异步落库，再加上分表策略。异步落库可以缩短核心链路响应时间，分表则避免单表数据量过大。整个过程总结下来就是：尽量把流量挡在前面，让真正进入核心链路的请求少而精。

2. 前端交互与预约链路设计

2.1 静态资源托管与 CDN 加速

很多人容易忽略前端在秒杀体系里的重要性。100 万预约用户同时刷秒杀页，如果页面上的商品数据、图片、脚本都从应用服务器出，单靠后端扛是扛不住的。这个项目的做法是：秒杀页面在活动开始前就预生成好静态 HTML，上传到 CDN，用户在客户端请求时直接命中就近的 CDN 节点，应用服务器完全不感知。

页面上的动态数据要尽量少。比如倒计时，通常由一个接口返回活动开始时间，前端拿到时间后本地做倒计时，而不是每秒轮询服务器。商品展示列表做成静态化快照，活动期间不允许运营随意改商品文案，避免页面缓存失效。

静态资源域名和应用接口域名分开也有讲究。静态域名不会携带 Cookie，请求体积小，CDN 命中率高；接口域名单独配置跨域和安全策略，方便排查问题。还有一个细节，静态资源要设置较长的浏览器缓存时间，这样秒杀开始后用户刷新页面时，浏览器本地直接命中，不会产生额外请求。

2.2 预约流程与资格校验

预约功能和普通“报名”不太一样，需要做到两件事：一是记录 100 万用户的预约关系，二是秒杀开启时快速判断某个用户是否有资格。100 万条数据如果在数据库里直接做存在性判断，秒杀瞬间数据库会被读请求打爆。所以预约数据在写库的同时，还要同步写入 Redis。

典型做法是用 Redis 的 Set 数据结构存储预约用户 ID，Key 格式类似reserve:users:{goodsId}。写入的时候利用SADD天然去重的特性，重复预约不会产生脏数据。示例代码如下：

public boolean addReserve(Long userId, Long goodsId) { String key = "reserve:users:" + goodsId; Long rst = stringRedisTemplate.opsForSet().add(key, String.valueOf(userId)); if (rst != null && rst > 0) { // 异步发送预约成功消息，用于后续短信通知和数据库落库 mqSender.send("reserve-topic", userId + "_" + goodsId); return true; } return false; }

100 万用户放进一个 Set 会导致这个 Key 非常大，后续读取和扩容都比较麻烦。实际项目中我把预约用户按照用户 ID 做了取模拆分，比如拆成 128 个分片 Key：reserve:users:{goodsId}:{userId % 128}。这样单 Key 数据量控制在几千左右，秒杀开始后资格校验的压力也被均匀分散到了 Redis 集群的多个 slot 上。

资格校验的接口同样要设置限流。用户进入结算页时会调用checkReserve，后端只做一次SISMEMBER判断，如果用户没有预约直接返回“未预约”，把大量无效请求挡在业务逻辑之前。这里还要注意，校验接口一定要加上用户维度限流，防止有人拿脚本疯狂遍历用户 ID。

2.3 前端防抖与异步结果通知

秒杀按钮几乎一定会被用户疯狂点击。前端要做两件事：第一，秒杀开始前按钮置灰，开始瞬间恢复；第二，用户点击后按钮立即进入“处理中”状态，短时间内不可重复点击。这听起来很简单，但很多项目都栽在“按钮置灰”只做了前端校验，抓包后仍然可以绕过按钮直接发请求。

所以前端防抖只是用户体验层面的第一道闸门，真正防重复提交还要靠后端。用户每次点击提交请求时，后端会先把用户 ID、商品 ID、活动批次号拼接成一个唯一请求流水号，使用 RedisSETNX加 10 秒过期时间做幂等，同一个用户同一商品在短暂时间内只能创建一个订单流水。这个设计方案非常适合秒杀场景，简单又有效。

秒杀请求提交成功后，不建议给用户同步返回订单结果，因为核心链路还要做库存扣减、资格核销、异步下单等操作，同步等待会导致接口耗时过长。项目里前端提交后返回“已受理”，然后通过轮询或者长连接查询用户维度的订单状态。轮询本身也要注意频率，每次轮询间隔不少于 2 秒，并且有个最大轮询次数，超过次数后提示用户刷新页面。

3. 基于 Redis+Lua 的分布式令牌桶限流

3.1 令牌桶与漏桶的取舍

限流是秒杀系统的灵魂。项目里在网关和应用层都设置了限流，核心算法选择了令牌桶，而不是漏桶。很多初学者会问为什么不直接固定速率放行，因为秒杀场景有一个特殊性：用户点击行为往往集中在开始后的前 10 秒，完全匀速放行会积压大量超时请求，用户体验极差；令牌桶允许一定程度的突发流量，只要桶里还有令牌，短时间内可以放行比平均速率更多的请求，这对业务来说更合理。

漏桶更像是“恒定速率管道”，无论上游多猛，下游都只能以固定速度处理；令牌桶则可以控制“每秒新增多少个令牌”，让系统在突发和稳定之间找到一个平衡点。

当然，这里有一个前提：令牌桶里的令牌数量不是随便拍的。活动商品总量是 20 万，如果我希望订单在 5 分钟内消化完，那么每秒至少要放行 200000 / 300 ≈ 667 个请求；再算上客户端重试、网络抖动等因素，可以设置每秒 1000 个令牌，桶容量 5000。这个参数不能拍脑袋，一定要根据库存总量和预估售卖时长倒推。

3.2 基于 Redis+Lua 的实现

单机限流用 Guava 的 RateLimiter 很容易，但项目是分布式部署，多个应用节点各自限流会导致整体流量不可控，所以必须用 Redis 做一个集中式的令牌桶。实现方式上不建议用先读取再写入的方式，因为并发场景下会产生竞态条件。最稳妥的办法是把令牌桶逻辑写进 Lua 脚本，利用 Redis 单线程执行 Lua 的特性来保证原子性。

下面这段 Lua 脚本就是项目里实际使用的令牌桶核心逻辑：

-- KEYS[1]: 限流 key -- ARGV[1]: 当前时间戳（秒） -- ARGV[2]: 初始令牌数 -- ARGV[3]: 每秒补充令牌数 -- ARGV[4]: 桶容量 local last_time = tonumber(redis.call('HGET', KEYS[1], 'last_time') or ARGV[1]) local tokens = tonumber(redis.call('HGET', KEYS[1], 'tokens') or ARGV[2]) local now = tonumber(ARGV[1]) local rate = tonumber(ARGV[3]) local capacity = tonumber(ARGV[4]) local delta = math.max(0, now - last_time) * rate tokens = math.min(capacity, tokens + delta) if tokens >= 1 then redis.call('HSET', KEYS[1], 'last_time', now) redis.call('HSET', KEYS[1], 'tokens', tokens - 1) return 1 else redis.call('HSET', KEYS[1], 'last_time', now) redis.call('HSET', KEYS[1], 'tokens', tokens) return 0 end

Java 侧调用时，通过 RedisTemplate 执行这段 Lua 脚本：

private static final String RATELIMIT_LUA = "local last_time=tonumber(redis.call('HGET',KEYS[1],'last_time') or ARGV[1]) " + "local tokens=tonumber(redis.call('HGET',KEYS[1],'tokens') or ARGV[2]) " + "local now=tonumber(ARGV[1]) " + "local rate=tonumber(ARGV[3]) " + "local capacity=tonumber(ARGV[4]) " + "local delta=math.max(0,(now-last_time))*rate " + "tokens=math.min(capacity,tokens+delta) " + "if tokens>=1 then " + "redis.call('HSET',KEYS[1],'last_time',now) " + "redis.call('HSET',KEYS[1],'tokens',tokens-1) " + "return 1 " + "else " + "redis.call('HSET',KEYS[1],'last_time',now) " + "redis.call('HSET',KEYS[1],'tokens',tokens) " + "return 0 " + "end"; public boolean tryAcquire(String key, int rate, int capacity) { long now = System.currentTimeMillis() / 1000; DefaultRedisScript<Long> script = new DefaultRedisScript<>(RATELIMIT_LUA, Long.class); List<String> keys = Collections.singletonList(key); Long rst = redisTemplate.execute(script, keys, String.valueOf(now), String.valueOf(capacity), String.valueOf(rate), String.valueOf(capacity)); return rst != null && rst == 1L; }

这里的HGET和HSET选择 Hash 结构，是为了把上次补充时间和当前令牌数放在同一个 Key 下，后续扩容或者排查数据都方便。

还需要特别注意限流 Key 的分布。如果所有请求都打在同一把 Key 上，Redis 实例上仍然会形成一个热点 Key。项目里的做法是按照用户 ID 取模，比如ratelimit:user:{userId % 256}，这样负载相对均匀；对于商品维度，则按照商品 ID 取模分片。

3.3 多级限流与流量调度

限定一个地方还不够。网关层和业务层要做不同粒度的限流。网关层通常配置 IP 维度限流和全局总流量限流，防止某个恶意 IP 发起超大规模请求；业务层则配置用户维度限流和商品维度限流。

举个例子，如果网关层限定全局入口最多 50 万 QPS，但某个商品的热度过高，所有请求都集中在同一个商品上，商品服务的压力依然很大。所以业务层还要针对每个秒杀商品单独配置令牌桶：每个商品每秒最多放行 1000 个请求，超过部分直接返回“活动太火爆”。这两级限流配合起来，既保护了整个系统，也保护了单个商品的数据节点。

多级限流参数必须支持动态调整，这就是配置中心发挥作用的地方。活动开始前运营可以按预估流量设置一个比较保守的值，如果实际流量低于预期，可以动态调高限流阈值；如果流量过于异常，又可以瞬间调低，实现“宽进严出”的弹性控制。

4. 商品分片与 Redis 数据布局

4.1 商品分片策略与一致性哈希

20 万商品全部放在 Redis 里，按商品 ID 作为 Key，单节点内存会非常大，而且部分热销商品的访问频率远高于普通商品。项目在 Redis Cluster 基础上，还在应用层做了一层商品分片逻辑。

最简单的方式是对商品 ID 做取模，例如goodsId % 128，得到分片编号后，把库存、预约、限流等数据都落在对应的分片 Key 上。这样做的本质是把一个大 Key 拆成多个小 Key，避免单个 Key 的访问量过大。

实际操作中，我使用的是带权重的一致性哈希环，而不是简单的取模。原因是有部分商品可能属于重点运营商品，需要占用更多 Redis 节点；另一些冷门商品的访问量较少，可以共享分片。一致性哈希比起取模更容易做节点扩缩容时的数据迁移，当 Redis 集群增加节点时，只需要迁移少量 Key，不会出现大量缓存失效。

代码实现上并不复杂，关键是维护好商品 ID 到分片路由的映射关系。项目里这个映射关系不是写死在代码里的，而是存储在配置中心，后续如果要调整某个商品的分片策略，可以直接动态下发，不需要重启服务。

4.2 库存预加载与热点 Key 拆分

秒杀当天最怕的一件事是 Redis 里没有库存数据，请求穿透到数据库。项目在活动开始前有一个预热任务，定时从数据库把商品库存同步到 Redis，Key 定义为seckill:stock:{goodsId}，Value 为剩余库存数，并设置一个较长的过期时间，防止活动过程中内存不足被清理。

热销商品即便只有一个 Key，仍然会出现单 Key 访问量过于集中的问题。假设一个商品的库存是 1 万件，1 秒内 20 万请求都来抢这一个 Key，Redis 单线程执行命令也会有瓶颈。项目里把这个热点商品的库存拆分成多个子 Key，例如seckill:stock:1024:0、seckill:stock:1024:1，最多拆到 16 个子 Key。扣减库存时用一个 Lua 脚本轮询这些子 Key，找到第一个库存大于 0 的分片执行扣减。这样一个商品的访问负载就被分散到多个 Redis slot 上。

需要提醒的是，库存分片数不能设置得过大，否则每个分片的库存余量是很小数值，容易出现某个分片提前耗尽而另一个分片还有很多库存的情况。实际项目中，我一般把每个分片的库存控制在 500 到 1000 件左右，确保不会被某个分片提前清空。

4.3 预约用户名单与资格缓存

预约数据除了 Set 结构存放用户 ID 外，秒杀开启时还需要一个快速判断用户是否有资格的方式。直接把 100 万用户全部缓存为单个 Key，无论是内存占用还是查询性能都不划算，所以依旧采用分片方式，把用户 ID 分散到 128 个分片中。

秒杀开始时，资格校验接口会变成这样：

public boolean checkReserve(Long userId, Long goodsId) { int shard = (int) (userId % 128); String key = "reserve:users:" + goodsId + ":" + shard; return stringRedisTemplate.opsForSet().isMember(key, String.valueOf(userId)); }

这里还有一个隐藏的优化点：资格校验的结果可以做一层本地缓存，比如用户第一次校验通过后，JVM 本地缓存记录下来，有效期几秒。这样同一个用户短时间内多次请求不会反复访问 Redis，Redis 的读压力会明显降低。

预警名单和黑名单功能也建议做成缓存 Key，黑名单用户的特征就是请求频率极高，一旦命中标记为黑名单，秒杀期间直接返回“账号异常”。这一层可以挡住大部分机器脚本流量。

5. 分布式锁与库存扣减的正确姿势

5.1 分布式锁选型与 Redisson 实践

库存扣减是秒杀系统里最容易出错的地方。很多初学者会直接用数据库的UPDATE stock SET stock = stock - 1 WHERE goods_id = ?，在秒杀场景下这把数据库行锁的竞争会非常严重，系统的吞吐量会被拖垮。所以这个项目的库存扣减没有放在数据库，而是放在 Redis 内存中完成，数据库只是在异步下单时做最终校验。

那分布式锁到底用在哪儿？应用层多节点同时扣减库存时，如果只靠 RedisDECR命令，其实已经能保证原子性，并不需要额外的锁。分布式锁主要用在一些包含多步操作的场景，比如先检查用户资格，再扣减库存，再记录购买记录，这三步如果分成三个命令连续执行，中途可能被其他线程插入，就需要用锁来保证整体原子性。

项目里选用 Redisson 分布式锁，因为它提供看门狗机制，可以自动续期，避免了锁过期后业务还没执行完的尴尬问题。示例代码如下：

RLock lock = redisson.getLock("seckill:lock:" + goodsId); boolean locked = null; try { locked = lock.tryLock(0, 30, TimeUnit.SECONDS); if (!locked) { return "活动太火爆，请稍后再试"; } // 执行资格校验、库存扣减、幂等记录写入 } finally { if (locked && lock.isHeldByCurrentThread()) { lock.unlock(); } }

这里锁的粒度是按商品 ID 维度，不是按用户 ID 维度。如果按用户 ID 加锁，同一商品的大量并发请求会分散在不同锁上，扣库存时依然存在竞争，意义不大；按商品 ID 加锁可以保证同一个商品的扣减流程是串行的，逻辑简单清晰。

5.2 基于 Lua 的原子库存扣减

有了锁之后，还要考虑一个问题：锁只是保证单商品扣减流程串行，但如果你有多个商品分片，锁还会带来额外的等待开销，影响吞吐量。更优的做法是直接把库存扣减设计成一个原子操作，不需要锁也能保证不超卖。

项目里用 Lua 脚本扣减库存：

local stock = tonumber(redis.call('GET', KEYS[1])) if stock == nil then return -1 end if stock <= 0 then return 0 end redis.call('DECR', KEYS[1]) return 1

这段脚本在 Redis 内是原子执行的，同一时刻即使有多个线程并发调用，也不会出现同时扣成负数的情况。扣减成功之后，再发送一条消息到 MQ，由消息消费者去创建订单。

李姐要注意，仅仅扣减 Redis 库存还不够，消费者创建订单时极有可能因为数据库主键冲突、用户重复下单等原因失败。如果失败，必须把 Redis 库存加回来，否则会出现“少卖”的情况。项目里消费者处理流程图是这样的：收到消息 -> 幂等校验 -> 创建订单 -> 成功后通知前端；创建订单失败 -> 发送“库存回补”消息 -> RedisINCR回补库存。

5.3 事务边界与最终一致性

分布式事务在秒杀场景下不能过度依赖强一致。为什么？秒杀链路中的 Redis 库存、数据库订单、用户资格记录分布在多个系统中，如果全部要求强一致，系统的可用性会大打折扣。所以项目采用的是最终一致性方案。

处理流程大致是：

1. 前端提交秒杀请求；
2. 应用层检测资格、扣减 Redis 库存、记录用户幂等标识；
3. 发送 MQ 消息，消息包含用户 ID、商品 ID、幂等 ID；
4. MQ 消费者异步写订单，写入时判断幂等表是否存在该幂等 ID；
5. 如果订单写入失败，通过定时对账任务发现并回补库存。

这里的核心是幂等。消息消费者在写订单前会先查询“幂等记录表”，如果发现同一个幂等 ID 已经处理过，就直接返回成功，避免消息重复消费导致重复下单。

事务边界划在“缓存扣减成功并发送 MQ 成功”这一节点。只要 MQ 消息可靠投递，最终订单一定会创建成功。如果 MQ 发送失败，需要立即回补 Redis 库存，保证数据一致。

6. 配置中心 Apollo 与 Nacos 的应用

6.1 配置中心在秒杀场景的价值

秒杀期间，系统参数随时可能需要调整，最典型的就是限流阈值、活动开关、商品上下架状态。如果每次调整都要修改配置文件并重新发布，会浪费大量时间，大促的分秒必争根本等不起。

配置中心解决了这个问题。把限流速率、活动开关、降级阈值、商品库存配置等全部外置到配置中心，运维调整配置后，应用可以在秒级感知并生效。项目里有几个实际使用的场景：

• 动态调整商品维度的令牌桶速率；
• 紧急下架某个异常商品；
• 开启全局限流降级开关；
• 调整用户资格校验的白名单和黑名单。

比如秒杀开始后，发现某个商品的请求量远超预期，导致该商品分片所在 Redis 节点负载过高，此时可以立即下调该商品的令牌桶速率，或者直接关掉该商品的活动开关，避免风险扩散。

6.2 Apollo 与 Nacos 对比与选择

项目初期在 Apollo 和 Nacos 之间犹豫了一段时间，两个都是业界使用非常广泛的开源中间件。我需要做一个比较准确的对比，而不是简单地说“看团队熟悉度”。

最终这个项目根据已有微服务技术栈选择了 Nacos，因为项目本身已经用 Nacos 做服务注册与发现，如果额外引入 Apollo，相当于多维护一套配置系统，成本会增加。隔离成独立配置中心的做法也很多，但没必要为了“多”而引入更多组件。

6.3 动态开关与预案切换

配置中心的应用代码并不复杂。以 Nacos 为例，Spring Cloud 项目中可以用@RefreshScope标注配置类，当 Nacos 配置变更推送后，应用会自动刷新：

@Component @RefreshScope public class SeckillConfig { @Value("${seckill.limiter.rate:1000}") private int limiterRate; @Value("${seckill.activity.enable:true}") private boolean activityEnable; public int getLimiterRate() { return limiterRate; } public boolean isActivityEnable() { return activityEnable; } }

秒杀请求入口处读取这个配置类，当 activityEnable 为 false 时，直接返回活动已结束，不再处理后续业务。

预案切换是配置中心发挥作用的关键场景。项目里专门准备了几套预案配置：正常、压测、限流收紧、全链路降级等。大促前通过配置中心一次性推送到所有节点，随时可以切换。这一点很重要，因为秒杀当天如果出现异常，往往没有太多时间慢慢排查，一套可预置的降级预案能省下大量救火时间。

7. 常见问题与排查记录

7.1 超卖与少卖问题复盘

项目联调期间出现过一次超卖，原因是扣减 Redis 库存后，订单创建的异步流程并发执行，同一个用户或者多个用户同时通过了库存校验，创建订单时没有再次做数据库库存校验。类似这样的问题，建议在数据库层面加最后一道防线的校验：

UPDATE seckill_stock SET stock = stock - 1 WHERE goods_id = ? AND stock > 0

只有受影响行数为 1，才算扣减成功。数据库库存校验不能完全替代 Redis 扣减，因为数据库的性能扛不住秒杀流量，但它可以作为兜底，防止缓存和数据库不一致时产生超卖。

少卖问题的出现往往是消息丢失。MQ 消费者收到消息后，如果创建订单失败，又没有做库存回补，就会出现数据不一致。排查心得是：一定要建立定时对账任务，定期比较 Redis 剩余库存和数据库售出数量的总和是否等于初始库存。差异数据通过告警系统通知值班工程师处理。

7.2 缓存穿透、击穿与雪崩处理

秒杀项目中 Redis 承担了绝大部分读请求，一旦缓存失效，数据库会瞬间被打垮。项目里针对三种常见风险做了处理：

缓存穿透发生在请求的 Key 在 Redis 和数据库中都不存在的情况。比如用户传了一个不存在的商品 ID，每次都会穿透到数据库。解决方式是缓存空值并设置短过期时间，同时加一层参数校验过略非法商品 ID。

缓存击穿指某个热点 Key 过期瞬间，大量请求同时访问数据库。项目里对热点商品的缓存不设置物理过期时间，而是用逻辑过期时间加上异步刷新，也就是后台任务定期更新缓存，避免集中失效。

缓存雪崩是大面积 Key 同时过期导致的。处理方式是在预热时给 Key 的过期时间加一个随机偏移量，让过期时间分散开，不至于在某一个时间点集体失效。

7.3 血泪经验与建议

大促前压测是真的能发现问题。开始我只压测了单机接口，测出来 QPS 还不错，结果压测集群时发现 Redis 大 Key 成了瓶颈，最后只能紧急拆分并重新预热。所以建议压测时一定要从负载均衡入口整链路压测，而不是只测单个服务节点。

另外，不要迷恋“百万 QPS”这个名词。百万 QPS 是整个网络入口的流量，核心业务真正需要处理的请求可能只有几万甚至几千。设计目标应该放在“如何优雅地拒绝大多数请求”上，把系统变成了一个精准的“过滤器”，而不是一个无所不能的处理器。

还有一个经验是监控要提前做好。Redis 的命中率、线程池队列积压数量、MQ 消费延迟、接口 TP99 耗时，这些指标在大促期间必须一目了然。项目上线后，我专门做了一套大屏监控，把核心指标汇总展示，高峰期能节省大量排查时间。秒杀系统的成败往往不取决于某一个亮点技术，而在于所有环节是否滴水不漏。