目的：展示一个用于线上景区门票/秒杀场景的多层防护架构，并给出实现与测试要点。

一、总体架构（分层概览）

1. 边缘层（Edge）
   • CDN（内容分发网络）+ DDoS 缓解服务：吸收大流量、缓存静态资源。
   • 公共防护：IP 封锁、Geo 阻断、黑名单/白名单。
2. 网络与接入层
   • WAF（Web Application Firewall）：规则阻断、异常请求识别、自动封禁。
   • 负载均衡（LB）/API Gateway：做流量分发、TLS 终止、接口聚合。
3. 应用层（业务）
   • 认证/会话服务（手机号/实名/第三方）
   • 行为风控与反作弊模块（设备指纹、行为打点、风险评分）
   • CAPTCHA 验证服务（滑块、行为验证码、无感验证）
   • 排队/令牌服务（Queue/Token Issuer）：虚拟排队、限量发放购买凭证
4. 中台与后端层
   • 缓存（Redis/缓存集群）：库存、秒杀凭证、限流计数器
   • 消息队列（Kafka/RabbitMQ/Cloud MQ）：削峰、异步下单、补偿机制
   • 订单服务 / 支付网关：幂等设计、事务补偿
   • 主从/分库分表的关系型数据库：库存强一致性方案（乐观/悲观锁、库存预扣）
5. 观测与响应
   • 日志与审计（集中化日志）
   • 监控与告警（TPS、错误率、热点 IP、异常行为）
   • SOC / 安全运维：人工复核、临时封禁策略

二、典型请求流（用户请求 -> 成功购票）

用户（浏览器/APP）
→ CDN
→ WAF（规则检测 + 指纹/UA/请求速率）
→ API Gateway（签名校验、限流）
→ 验证/排队（需要时触发 CAPTCHA / 进入队列）
→ 获取购买令牌（Token）
→ 下单接口（入列到消息队列）
→ 库存扣减（缓存预扣 + 后台异步落库）
→ 支付
→ 订单确认与回调

三、关键防护点与实现建议

• 限流策略：
  • 多粒度限流（全局/接口/IP/用户/设备），结合漏桶或令牌桶算法。
  • 使用 Redis 实现分布式计数器（带过期）或专用限流网关。
• 验证码与无感验证：
  • 对高风险请求触发挑战；对低风险使用无感验证降低用户摩擦。
  • 使用行为打点（鼠标轨迹、页面停留）做模型判别。
• 设备指纹与风控评分：
  • 聚合浏览器指纹（插件/字体/Canvas 指纹）+ 网络特征（IP、ASN、代理链）+ 历史行为。
  • 对可疑设备施加更严格的限流/挑战/人工校验。
• 签名与防重放：
  • 请求参数签名（短期有效 Token、HMAC），防止直接伪造 API 调用。
  • 对重要接口启用时间戳与一次性 nonce。
• 排队系统设计：
  • 采用“预取令牌”或分配窗口（含随机化）减少同时下单冲突。
  • 将核心下单写入消息队列，后端顺序消费并做库存原子扣减。
• 库存一致性：
  • 缓存预扣 + 后台持久化，或使用 DB 的乐观锁（版本号）/悲观锁（行锁）。
  • 提前考虑超卖补偿流程（退款、补偿库存）。
• WAF 与行为分析：
  • 基于规则 + ML 的混合检测。规则负责拦截已知攻击模式，ML 检测新颖异常。
  • 结合速率、指纹、UA、请求路径等特征做实时打分。

四、合规的测试与验证清单（仅在有授权时执行）

1. 功能性测试：排队、验证码、下单、支付流程完整性。
2. 性能压测：在 STAGE 环境模拟并发（k6 / Locust / JMeter），观察 TPS、95/99P 响应时间、错误率。
3. 并发与竞态测试：库存临界点、消息积压、消费者回退处理。
4. 故障注入：断网、Redis/DB 宕机、队列延迟（验证幂等与补偿）。
5. 安全检测：WAF 误判/漏判率、验证码强度评估、接口签名绕过测试（授权范围内）。
6. 反作弊评估：模拟真实用户行为与自动化脚本比较，验证风控灵敏度与误报率。

五、常见攻防场景（说明性，不提供可实施细节）

• 防御侧会结合多种维度（IP、指纹、行为、速率）进行综合判分与策略执行。
• 合法安全测试应只在授权环境执行，并避免对真实用户与系统造成不可恢复影响。

六、部署与运维建议

• 蓝绿/灰度发布：逐步放量验证防护策略对真实用户的影响。
• 可观察性：为每个关键环节（限流、队列、库存扣减）打埋点并建立 SLO。
• 快速回滚策略：若新策略导致大面积误伤，能在 1 次操作内回退。
• 人工联动流程：当风控触发疑似滥用时，提供人工审核/临时白名单通道。

七、附：快速检查清单（上线前）

• ✅ CDN + WAF 已部署并测试规则效果
• ✅ 限流阈值基于压测结果调整
• ✅ 验证链路（验证码/无感）已覆盖高风险接口
• ✅ 排队/消息队列能承受短时突发峰值
• ✅ 日志与监控已覆盖关键 KPI（TPS、失败率、延时、热点 IP）

现在把焦点放在如何把系统设计成能在 1 秒内售出 1000 张票、同时保证正确性与抗滥用上。下面是按问题域拆开的详尽设计（架构、流程、关键算法、容量估算、测试与运维），包含具体实现建议与注意事项。所有设计假设都会标注，便于你按实际情况调整。

一、总体设计目标（明确需求）

• 目标吞吐：在 1 秒内成功售出 1000 张门票（最终下单并占位，支付可异步完成但要有回滚）。
• 正确性：避免超卖（严格库存一致性或可接受的补偿方案）。
• 公平性：限制单人/单设备抢购上限，降低黄牛和脚本获利。
• 可用性与稳定性：在突发高并发下不中断核心服务。
• 可观测性：实时监控 TPS、错误率、队列长度、热点 IP 等。

二、核心思路（高层）

1. 前端限流+虚拟排队+令牌机制：把瞬时请求削平为可控令牌流，绝大多数请求先进入排队/抽签，由令牌服务分配有限购买资格。
2. Redis 做库存和限流的高性能缓存层（原子操作）：通过 Redis 原子扣减作为首要防超卖手段，数据库做异步持久化与补偿。
3. 消息队列削峰（Kafka/RabbitMQ）：所有“有效下单请求”先入队，后端消费者顺序处理、持久化库存与生成订单。
4. 幂等与回滚：下单到支付设计幂等，支付超时或失败则触发库存回补/释放逻辑。
5. 风控层在边缘：WAF + 行为风控 + CAPTCHA + 设备指纹，阻止脚本/代理/高频 IP 干扰。

三、详细请求处理流程（逐步）

1. 用户发起进入页面 / 点击“立即抢购”。
2. 前端向 排队服务 / 令牌服务 发起请求（通过 API Gateway，带用户会话/签名）。
   • 若为高峰时刻，返回“您已进入排队，预计 X 秒”或抽签成功/失败。
3. 当令牌服务决定发放购买资格时，会下发短期一次性购买 Token（Token 有效期非常短，如 5~10 秒）。
4. 客户带 Token 调用下单接口（下单接口经过 API Gateway 的限流策略）：
   • 下单接口直接在 Redis 执行原子脚本：校验 Token 未被使用 + 对库存 stock > 0 做 stock = stock - 1。
   • 如果 Redis 扣减成功：把下单请求写入消息队列（包含 userId、token、商品 id、时间戳、幂等 id）。
   • 如果 Redis 扣减失败（库存不足或 token 无效），返回失败。
5. 后端消费者（按队列顺序）读取消息：
   • 检查幂等（避免重复消费）→ 写入关系型数据库（订单记录、扣减持久化）→ 标记为“待支付”并通知用户。
6. 支付阶段：用户在有限时间内完成支付；若超时或支付失败，触发异步库存回补（Redis stock = stock + 1，并在 DB 上做相应补偿）。
7. 监控与告警：所有步骤埋点（请求速率、队列长度、失败率、热点 IP），实时可视化。

四、关键实现细节与要点

1) 虚拟排队 / 令牌分配

• 目的：避免瞬间大量有效请求同时打到下单逻辑，保护 Redis/DB。
• 实现方式：
  • 前端先请求 enter_queue，服务端返回一个排队位次或概率（也可做抽签）。
  • 令牌服务按照预设速率（例如每秒发放 1200 个令牌到不同用户，超出即不发），并保证每个用户/设备每天/每场次上限。
• 令牌属性：token = HMAC(secret, userId|eventId|nonce|expiry)，短时有效并记录已发放/已使用状态（可存在 Redis）。

2) Redis 原子扣减（防超卖）

• 把库存放在 Redis（例如 key: stock:event123），用 Lua 脚本保证“校验 token + 扣减 + 记录占位”原子化：
  • 步骤：验证 token 未用 → if stock > 0 then stock-- and record reservation → return success
• 记录占位（reservation）表存在 Redis（或写到队列后由消费者持久化），以便快速查回。
• 为降低 Redis 单点压力，使用 Redis 集群 与分片（sharding）。

3) 消息队列削峰

• 设计为：只把 Redis 扣减成功的请求写入队列，队列有多个分区（partition），但消费者对同一商品/库存分片应保持 顺序性（或用单分区保证顺序），以便一致性处理库存持久化。
• 消费者需要实现幂等检查（基于幂等 id 或 token）。

4) 数据库策略（持久化与一致性）

• DB 写入采用异步持久化模型（先在队列，再消费者写库），或使用“预占 + 最终一致性”：
  • Redis 预扣（实时）→ 消息队列 → DB 写入（最终一致）
• 若需强一致（严格禁止超卖），可采用：分库分表 + 乐观锁 version 或悲观锁（但悲观锁会降低并发）。多数秒杀系统选择 Redis 原子预扣来保证线上表现，然后通过补偿保证一致性。
• 设计补偿流程：若 DB 写入失败，消费者要把对应的 reservation 回滚到 Redis（安全重试策略，或报警人工干预）。

5) 限流与防护（多层）

• 边缘（CDN/WAF）：阻断已知恶意 IP、速率异常者、代理链。
• API Gateway：实现 API 级别的分布式限流（令牌桶 / 漏桶），例如 per-IP / per-user / per-device 限制。
• 应用层：对下单接口做更严格校验（token、指纹、风控）。
• 验证码（CAPTCHA）/无感验证：对可疑请求增加挑战；对低风险用户走无感认证体验。

6) 公平性策略

• 每用户限购：每个用户/身份证每场次最多 N 张。
• 队列白名单：对已认证/已实名用户优先，但要平衡公平性。
• 随机窗口：分散令牌发放时间窗口（比如把令牌发放在 1 秒内的若干毫秒窗口中随机分配），降低同时并发写入峰值。

7) 幂等与支付回滚

• 每笔申请带 idempotency_key，消费者在写订单前检查是否已存在。
• 支付失败后触发回补：先在 DB 标记失败，再把 Redis 库存加回并清除 reservation。

五、容量估算（示例与计算方法）

以下给出一种示例估算方法 —— 关键：所有数字均基于假设，请用你实际的监测数据替换这些假设。

假设：

• 峰值并发请求数（尝试请求）：R_attempt = 100,000 requests/s（假设 10 万请求/秒）。
• 期望成功下单（售出）数：S_success = 1,000 orders / 1 s。
• Redis 每个下单请求平均需要做 ops_per_req = 2 个原子操作（校验 token + 扣减并写 reservation）。

计算：

• Redis 负载 = R_attempt * ops_per_req = 100000 * 2 = 200000 ops/s。
  （即二十万次/秒）。
• 但只有 token 发放后的下单才会触达 Redis 扣减。若令牌策略把可达 Redis 的请求削减到 R_effective = 10,000 req/s，则 Redis 负载 = 10000 * 2 = 20000 ops/s（两万次/秒）。
• 消息队列写入（仅写入扣减成功的请求），成功写入数 ≈ S_success = 1000 msg/s（或写入全部扣减成功的请求，可能略高于 1000，取决于库存）。
• 数据库持久化吞吐需要支持 ~1000 writes/s（持续 1 s 内写入 1000 条订单），实际可短时爆发更高，需做好容量弹性。

机器/实例估算（非常粗略）：

• Redis：若单 Redis 节点平均能处理 100k ops/s（视实例规格而定），则需要 ceil(200000 / 100000) = 2 个节点来处理 200k ops/s（实际建议多节点 + Sentinel/Cluster）。但请基于你选的实例类型及基准压测结果决定节点数。
• API 层/网关：需支持峰值连接数与带宽，使用自动扩容组（ASG）。
• 消息队列（Kafka）：分区数需 >= 消费并发度，吞吐按消息大小估计（1000 msg/s 很小，但写入高并发短时峰值时需要 IO 配置良好）。
• DB：为避免写入延迟，采用写入池 + 主从复制 + 分库分表。

（提醒：不同云/机型/网络环境的单实例吞吐差异大，务必 压测。）

六、压测与验证（必做）

1. 分阶段压测（在非生产或得到授权的环境）：
   • 首先压测 CDN + API Gateway + 排队层（模拟 100k req/s 进入并观察队列和令牌发放）。
   • 然后压测 Redis 原子扣减（在令牌发放后的有效请求率下）。
   • 再压测消息队列到 DB 的消费者速度（确保消费速度 >= 写入速度）。
2. 场景测试：
   • 正常并发、突发流量、网络抖动、单点故障（Redis 宕机、队列堆积）等。
3. 失败注入（Chaos）：
   • 中断 DB 或队列的连接，验证补偿与报警是否触发，验证是否会导致超卖或丢单。
4. 观测指标：
   • TPS（请求/秒）、95/99 响应时间、Redis ops/s、队列长度、错误率、资源利用率（CPU/IO/网络）。

七、反作弊与风控要点

• 设备指纹 + 风险评分：把 UA、Canvas 指纹、IP ASN、请求行为等做聚合评分，超过阈值触发验证码或直接拒绝。
• IP/ASN 限制：对高风险 ASN 实施严格限制（但谨慎，不要误伤共享网络用户）。
• 行为节奏检测：短时间内重复点击、固定时间间隔的请求、同一设备多账户同时请求等可视为脚本行为。
• 人机验证优先级：避免对所有用户强制验证码，采用风险触发机制（无感体验优先）。

八、常见陷阱与注意事项

• 不要把所有逻辑放在数据库事务里（数据库会成为瓶颈）。把高频操作迁移到 Redis/队列中。
• Redis 原子操作需谨慎：Lua 脚本要小且快速，避免阻塞 Redis 主线程太久。
• 务必实现幂等：客户端重试、网络重传都会导致重复请求，必须设计幂等键与检测。
• 超卖补偿流程：即便设计周到，也可能出现极端情况导致异步持久化失败，提前设计退款/补偿流程与人工应急流程。
• 监控与快速回退：任何新策略上线要能在发现误杀或问题时快速回退（蓝绿/灰度发布）。

九、落地清单（实施优先级）

1. 建立排队/令牌服务（先做 POC）+ API Gateway 限流。
2. 将库存迁移到 Redis 并实现 Lua 原子扣减 + reservation 记录。
3. 搭建高性能消息队列并实现消费者写库流程（幂等设计）。
4. 实施支付超时回补与幂等保证。
5. 部署 WAF/行为风控与 CAPTCHA 风险触发。
6. 做分阶段压测 + Chaos 测试。
7. 上线灰度并监控 KPI（TPS、失败率、队列长度、风控误判率）。

如果你愿意，我可以接着做下面任一项（你选其一）：

1. 把上述方案转成实施交付清单（含每项的负责人/估时/验收标准）。
2. 给出 Redis Lua 原子脚本 的示例（用于合法合规的系统实现）。
3. 生成一套 压测脚本草案（基于 k6/Locust 的场景配置），方便你做容量验证。

如何保证公平：限制单人/设备购买数量？

好——下面把“限制单人/单设备抢购上限、降低黄牛和脚本获利”这条拆得非常细：从策略、检测、执行到用户体验与运维，再给出具体的数据结构/键设计和可直接用于防护的原子实现思路（含伪代码 / Redis key 方案），最后列出常见绕过手段与对应缓解措施。全部以防御方向为主，便于你在合规场景下实现公平性保障。

一、设计目标（精确化）

• 每个真实用户在单场次/活动中最多能购买 N 张（N 可配置）。
• 每个设备/浏览器指纹/手机号/身份证 等维度也要有上限，防止一人多号或多设备绕过。
• 在不严重降低正常用户体验前提下，尽量减少脚本/代理/黄牛获利空间。
• 能被审计、回溯并支持人工申诉。

二、总体策略（多维并举）

1. 身份维度限购（强判）：账号ID、手机号、实名/身份证（若法律允许）。
2. 会话/设备维度限购（中等强度）：设备指纹、浏览器指纹、设备ID（APP）。
3. 网络维度限购（弱判但必要）：IP、ASN、代理检测、同一IP下并发限制。
4. 时间/频率控制：冷却期、购买窗口、排队令牌限制。
5. 购买资格策略：实名优先/白名单/抽签/随机分配，防止先到先得被脚本完全垄断。
6. 风控评分与分级处理：高风险触发验证码、限制、人工审核。
7. 支付与资金门槛（可选）：预付定金或支付完成才算最终占位，增大黄牛成本。
8. 多层检测 + 学习：规则检测 + ML 异常行为模型，持续调整策略。

三、具体维度、规则与实现细节

1) 身份维度（最强）

• 规则：每个实名用户（user_id 或身份证号）在活动内最多购买 M 张（例如 M=2）。
• 要求：在购票前必须完成手机号验证 + 实名认证（若合规）。
• 数据存储：关系型 DB + Redis 快速计数（user:limit:{eventId}:{userId}）。
• 优点：限制明确、难以被广泛规避。
• 缺点：需要用户完成实名认证，可能提高门槛并影响转化率。

2) 设备/浏览器指纹（设备绑定）

• 技术：收集 Canvas 指纹、屏幕分辨率、插件/字体、User-Agent、硬件信息（移动端可读设备ID但要合规）。
• 规则：每个指纹限购 P 张（P 接近 M 或更低）。同一指纹对应多个账号则进一步触发风控。
• 存储：fingerprint:limit:{eventId}:{fingerprintHash} 在 Redis 计数与最后活跃时间。
• 实现细节：指纹散列需带 salt；允许指纹失效与学习（在误伤时提供人工申诉）。

3) 网络维度（IP / ASN / 代理）

• 单 IP 并发限流：如 per-IP concurrent 或 per-IP per-second。
• ASN/代理限制：高风险 ASN（云服务商）做更严格检查；代理或 VPN 检测到则触发验证码或拒绝。
• 注意：NAT/运营商场景会导致同一公网 IP 下大量正常用户，需阈值与白名单策略防误伤。

4) 会话与设备绑定（APP）

• 对 APP 使用设备唯一 ID (GAID/IDFA 等或自生设备ID) 绑定购买次数。
• 对 Web 使用基于 cookie + fingerprint 的绑定，必要时要求短信验证绑定该设备。

5) 排队与令牌制（削峰 + 公平）

• 先进入排队/抽签，再分批发放购买 Token（短期、一次性），每个 token 绑定 userId/fingerprint，并记录已使用状态。
• 令牌分发策略可以是：
  • 严格 FIFO（先到先得），或
  • 混合抽签（随机化一部分令牌）以提升公平性，
  • 或对实名用户优先/限额保证。
• 令牌发放日志化，便于回溯。

6) 时间粒度与冷却（防连刷）

• 限制某用户在 T 秒内只能发起 K 次进入队列请求（例如 T=60s, K=3）。
• 下单成功或失败后，对失败者设短期冷却，避免不停刷新造成额外负载与先到优势。

7) 支付/占位设计（降低黄牛收益）

• 选择在支付完成后才真正完成订单（但这会影响支付流程）。可采用：
  • 预占 + 支付窗口：预占库存（例如 10 分钟），用户必须在窗口内完成支付，否则回补库存；
  • 或“先占位后付款”，但设置较短支付窗口和更严格的实名校验。
• 可选：对重复下单且未付款的账号设限制或累积惩罚（例如降低优先级、黑名单）。

四、具体数据结构与 Redis Key 方案（示例）

（下列为防御实现示例，便于在系统中落地）

1. 全局库存（Redis）

• key: event:{eventId}:stock → integer

2. 用户维度限购计数（Redis，活动粒度）

• key: event:{eventId}:user:{userId}:bought → integer，TTL 到活动结束后可自动过期或手动清理

3. 指纹维度计数

• key: event:{eventId}:fp:{fpHash}:bought → integer

4. IP 维度短期计数（用于速率限制）

• key: ip:{ip}:req:{minute} → integer，TTL 65s

5. 令牌记录（防重放）

• key: event:{eventId}:token:{token} → hash { userId, fpHash, used:0/1, expiry }，TTL = token 有效期

6. 幂等 ID（防重复下单）

• key: event:{eventId}:idem:{idempotencyKey} → orderId 或 status，TTL 1 day

五、原子化检验与占位伪代码（伪 Redis Lua 思路）

（目的是确保“用户限购 + 指纹限购 + 全局库存”在单次原子操作里处理，防止竞态）

伪流程（逻辑）：

1. 检查 token 是否存在且未使用（若有 token 流程）。
2. 检查 user_bought < user_limit。
3. 检查 fp_bought < fp_limit。
4. 检查 stock > 0。
5. 如果全部通过，则：
   • stock = stock - 1
   • user_bought = user_bought + 1
   • fp_bought = fp_bought + 1
   • 标记 token 为已用（若使用 token）
   • 返回 success + reservation_id

说明：实际实现用 Lua 脚本在 Redis 中完成，保证原子性；脚本应尽量短小以避免阻塞。

六、风控评分与分级响应（结合规则与 ML）

• 线下建模：用历史购买行为、浏览时长、鼠标轨迹、从何处登录、IP 变化频次等训练一个风险模型，输出 risk_score。
• 分级响应：
  • risk_score < low：正常流程。
  • low <= risk_score < medium：无感验证或短信验证。
  • medium <= risk_score < high：必须过验证码或人工二次认证。
  • risk_score >= high：拒绝或人工审核。
• 实时调整：结合实时指标（同一 IP 并发量、指纹冲突率）调整阈值。

七、可审计日志与申诉机制

• 记录每次发放令牌、每次下单请求的来源（userId、fpHash、IP、UA、时间戳）。
• 在误伤或争议时能回溯并人工解封/补偿。
• 公开活动规则与限购策略，减少投诉与灰色操作。

八、典型阈值建议（可根据实际压测调整）

这些是起点值，用压测与实际流量统计调整。

• 每用户每场次最大购买：M = 2（或根据业务设定）
• 每指纹每场次最大购买：P = 2（当指纹和用户不一致时生效更严格）
• 单 IP 并发请求限流：max_conn_per_ip = 10；req_per_sec_per_ip = 5（视公网 NAT 情况上调）
• 令牌有效期：token_ttl = 5 ~ 10s（短以防重放）
• 排队进入频率：每用户 60s 内最多 K = 3 次请求进入队列
• 支付窗口：pay_window = 5 ~ 10 min（根据是否要确保支付率而定）

九、常见绕过技术与缓解（预测性防护）

1. 多账号 + 多设备（黄牛）
   • 缓解：实名绑定、手机号验证、设备指纹聚合、行为模型识别多账户异常关联（同一指纹/同一IP/时间相近）。
2. 代理/云机刷单
   • 缓解：ASN 阻断/分数惩罚、代理指纹识别、CAPTCHA、限制新账号在短期内的购买优先级。
3. 浏览器自动化（Selenium / Puppeteer）
   • 缓解：行为检测（鼠标轨迹、页面停留时间、指纹差异）、动态 JS 验证、滑块/行为验证码。
4. 分布式并发（大量 IP）
   • 缓解：全链路限流、令牌发放、进一步把关键写路径移到 Redis 原子化处理并入队列削峰。

十、用户体验（UX）与合规建议

• 在追求公平性的同时要顾及正常用户体验：尽量采用风险触发型认证（低风险用户无感通过）。
• 清晰告知“限购规则 / 购买资格 / 申诉渠道”以减少争议。
• 如果启用实名或支付担保，明确隐私与退款政策，遵守当地法律法规。

十一、监控 & 指标（必须）

• 指标：成功下单数/秒、拒绝率、同一指纹失败次数、同一IP并发数、风控触发率、误杀率。
• 告警：当 同一指纹或同一 IP 的失败请求数 超阈值 或 指纹冲突比 畸高 时触发人工审查。

十二、实现建议与交付选项

如果你想，我可以接着提供下面任一项（你选一项）：

1. 把上述“原子化伪代码”转成真实的 Redis Lua 脚本示例（用于合规的实现）。
2. 生成风控评分特征清单与一个简单的规则集（可直接拿去训练/校验）。
3. 给出一份事件审计日志 schema 和范例（便于合规与回溯）。

先进先得的策略

那我给你拆成两个版本对比：

1. 纯先到先得（裸 FCFS）流程

1. 用户发起购票请求。
2. 系统检查库存是否 > 0。
3. 如果有库存 → 立即扣减库存 → 生成订单。
4. 库存耗尽后 → 返回“已售罄”。

特点：

• 实现简单，几乎没有额外调度。
• 1 秒卖完时，成功者几乎都是延迟低、设备快、带脚本的用户。
• 普通用户成功率极低，黄牛垄断概率高。

2. 改造后的 FCFS（真实票务常用）

1. 请求接入层限流
   • CDN / API Gateway 按 IP / 设备限速，防止瞬间洪峰。
2. 进入虚拟排队系统
   • 排队规则：按到达时间排序（FCFS 主体）+ 同时分批放行（削峰）。
3. 风控过滤
   • 设备指纹、IP 信誉、历史行为 → 标记高风险账号。
   • 高风险账号可能被延迟放行或直接拒绝。
4. 分批放票
   • 例如 1000 张票分 4 批，每批 250 张，间隔 3~5 秒释放。
5. 下单令牌机制
   • 每个通过排队的用户先领一个短期有效 Token（几秒钟内有效）。
   • 只有带 Token 的请求才能进入下单环节。
6. 库存扣减（Redis 原子操作 + 数据库持久化）
   • 成功下单 → 进入支付流程。
7. 支付超时回滚
   • 未在指定时间内支付，库存回收重新释放。

特点：

• 表面上看仍是先到先得（排队靠时间先后）。
• 实际上加了多层过滤和批次释放，黄牛脚本优势被大幅削弱。
• 普通用户的成功率和体验提升。