以秒杀为例的分布式知识点概览

发表于 分类于 阅读次数： 本文字数： 2.5k 阅读时长 ≈ 2 分钟

分布式、秒杀、节点、Redis 核心内容汇总

一、分布式系统基础

1. 定义与核心逻辑

  • 由多台独立计算机（节点）通过网络协同工作，对外呈现 “单一系统” 形态，核心是解决单机性能、容量、可靠性瓶颈，适用于高并发（如秒杀）、大规模数据处理场景。
  • 核心设计原则：服务拆分（垂直 / 水平）、负载均衡、异步化、数据一致性保障，避免单点故障和资源浪费。

2. 核心优势

  • 高可用性：多节点冗余部署，某节点故障时其他节点接管（如秒杀服务集群），避免系统宕机。
  • 水平扩展性：通过增加节点数量提升并发能力（如秒杀服务从 10 节点扩至 100 节点），突破单机性能上限。
  • 高性能：任务拆分 + 并行处理（如数据分片到多节点），配合负载均衡（Nginx/K8s）均匀分配请求，降低单节点压力。
  • 故障隔离：独立服务集群（如秒杀、支付、地址服务）各自部署，某服务故障不影响整体（如支付服务卡顿不影响秒杀库存扣减）。

二、秒杀场景核心设计

1. 秒杀请求处理流程（核心：同步核心 + 异步后续）

（1）同步核心流程（毫秒级响应，确保准确性）

  • 请求路由：用户秒杀请求通过负载均衡（Nginx/K8s）分配到单个秒杀服务节点（非拆分请求），避免跨节点协调开销。
  • 核心校验（必同步完成）：
    1. 资格校验：判断用户是否登录、是否重复秒杀；
    2. 库存扣减：调用 Redis 集群（原子命令decr）扣减库存，库存不足则立即返回 “秒杀失败”，不进入后续流程；
    3. 生成订单快照：暂存订单核心信息（订单号、商品 ID、用户 ID）到内存 / 缓存，避免直接写数据库。
  • 返回初步结果：库存扣减成功则返回 “秒杀成功，请等待支付”，失败则返回 “库存不足”。

（2）异步后续流程（解耦非核心任务，降低延迟）

  • 秒杀节点通过

    消息队列（Kafka/RabbitMQ）

    发送 “待处理订单” 消息，触发独立服务处理细分任务（非拆分请求，而是调用独立服务）：

    1. 地址服务集群：校验用户收货地址有效性（独立节点处理，如节点 P）；
    2. 支付服务集群：生成支付单、调用第三方支付接口（独立节点处理，如节点 X）；

  • 后续失败处理：若地址校验 / 支付单生成失败，仅单独提示用户（如 “补充有效地址”），不影响 “秒杀成功” 结果（库存已扣减，用户已获资格）。

2. 秒杀任务拆分与服务分工

  • 拆分逻辑：按 “业务模块垂直拆分”，而非 “单个请求数据拆分”（避免跨节点协调开销）：
    • 秒杀服务集群：处理库存扣减、订单快照（核心节点，如 A/B/C）；
    • 支付服务集群：处理支付单生成、支付状态同步（独立节点，如 X/Y/Z）；
    • 地址服务集群：处理地址校验、配送范围判断（独立节点，如 P/Q/R）；
  • 核心原则：单个请求的核心流程（库存扣减）由一个秒杀节点完成，后续任务由独立服务节点处理，实现 “解耦、独立扩展、故障隔离”。

三、节点相关概念

1. 节点定义

  • 分布式系统中的逻辑处理单元，对应一个 “进程 / 容器”（如 Docker 容器、服务进程），具备独立接收、处理任务及协同能力，而非硬件本身。
  • 核心作用：参与分布式协同（如秒杀节点处理请求、支付节点处理支付），是分布式服务的 “最小执行单元”。

2. 节点与服务器的关系（非一对一）

服务器是 “物理 / 硬件载体”（如物理机、云 ECS），节点是 “逻辑单元”，对应关系由资源需求决定：

（1）一台服务器 → 多个节点（主流场景，轻量服务）

  • 适用场景：节点资源需求低（如秒杀服务、地址服务），一台服务器硬件资源（如 4 核 8GB）可支撑多个节点；
  • 举例：一台云服务器运行 2 个秒杀节点（1 核 2GB / 个）+1 个地址节点（1 核 2GB）+1 个日志节点（1 核 2GB）；
  • 优势：提升硬件利用率，降低集群成本。

（2）一台服务器 → 一个节点（特殊场景，资源密集服务）

  • 适用场景：节点需独占资源（如 Redis 主节点、MySQL 主库），避免资源竞争；
  • 举例：秒杀库存 Redis 节点（需 64GB 内存）独占一台服务器，MySQL 主库（需稳定 IO）独占一台服务器；
  • 优势：性能稳定，故障隔离性强（单个节点崩溃不影响其他）。

3. 节点在秒杀中的角色分工

  • 秒杀服务节点：处理库存扣减、订单快照（核心节点，如 A）；
  • 支付服务节点：处理支付单生成、第三方接口调用（如 X）；
  • 地址服务节点：处理地址校验（如 P）；
  • Redis 节点：存储实时库存，支撑高并发扣减（分片部署，避免单点）；
  • MySQL 节点：存储最终库存、订单数据，确保持久化（独立部署，避免高并发冲击）。

四、Redis 在秒杀与库存管理中的应用

1. Redis 的核心作用（高并发读写支撑）

  • 实时库存存储：秒杀前将 MySQL 中的 “可售库存” 同步到 Redis（库存预热），支撑每秒数万次的库存读取 / 扣减；
  • 原子性库存扣减：通过decr（递减）、incr（回滚）等原子命令，避免并发超卖（如 1000 个库存不会被 1001 个用户抢到）；
  • 临时数据缓存：存储秒杀订单快照、用户秒杀资格，避免直接读写 MySQL（降低延迟，保护数据库）。

2. Redis 与 MySQL 的协同（缺一不可）

（1）为何不能只存 Redis？

  • Redis 虽高性能，但存在数据丢失风险：
    • RDB（定时快照）：快照后宕机，期间的库存扣减数据丢失；
    • AOF（日志追加）：默认每秒刷盘，宕机可能丢失几秒数据；
  • 丢失会导致 “库存回滚”，引发重复售卖或用户已秒杀成功却无货。

（2）为何不能只存 MySQL？

  • MySQL 是磁盘数据库，单表每秒仅支持千级库存更新（行锁竞争严重），无法支撑秒杀的数万 QPS，会直接导致数据库崩溃。

（3）协同流程

  1. 库存预热：秒杀前，将 MySQLproduct_stock表的 “可售库存” 同步到 Redis；
  2. 高并发扣减：秒杀时，Redis 处理所有库存读写，原子扣减；
  3. 异步同步：Redis 扣减成功后，通过消息队列异步同步到 MySQL（更新available_stock和used_stock）；
  4. 异常恢复：Redis 宕机重启后，从 MySQL 读取最新库存，恢复 Redis 数据，确保一致性。

3. Redis 的部署要求

  • 分片集群：库存数据按商品 ID 哈希分片（如 10 个 Redis 节点，商品 ID%10 分配分片），避免单 Redis 节点压力过大；
  • 主从备份：每个 Redis 分片部署主从节点，主节点故障时从节点切换，保证 Redis 高可用。