1. 分布式锁与分布式 ID 特训指南（极简源码速成版）

本指南专为快速吃透 分布式集群下的秒卖超卖预防、Redisson 锁在哨兵集群下的高并发失效自愈 以及 SaaS 餐饮系统海量订单全局唯一 ID 设计 等核心场景中的考点而设计。杜绝大段铺垫，采用 Why - What - How - Deep 四步直达底层算法与共识协议，帮助您在面试中反客为主，化被动为主动。

---

🚀 核心概念极简拆解

• 分布式锁 (Distributed Lock)
  • Why：传统的 JVM 锁（如 ReentrantLock、synchronized）只能锁定单台服务器的 JVM 内存。当系统采用多实例分布式集群部署时，单机锁无法限制跨物理节点的并发抢占，极易导致超卖和数据大面积损坏。
  • What/How：跨越多个物理独立节点，依靠全局共享的第三方中间件（如 Redis, ZooKeeper）在网络环境下协调共享资源排他性访问的全局加锁机制。
• 红锁 (Redlock)
  • Why：普通的 Redis 主从/哨兵集群存在异步复制带来的主从切换锁失效缺陷。需要一种能容忍单点宕机、保证强一致安全的 Redis 加锁算法。
  • What/Deep：客户端在 5 个完全独立的 Redis 节点上并行尝试加锁，只有在过半数（3个以上）节点加锁成功，且耗时小于锁有效时间时，才认为加锁成功。由于网络开销高昂且存在时钟回拨隐患，大厂生产中极少真正采用。
• 临时顺序节点 (EPHEMERAL_SEQUENTIAL)
  • Why：ZooKeeper 锁如果只使用普通的临时节点，当锁被释放时，成百上千个等待锁的客户端会被同时唤醒并疯狂抢锁，这会产生高昂的系统开销并瞬间冲垮 ZK 服务器（即**“羊群效应”**）。
  • What/Deep：ZK 分布式锁的精髓。每个尝试抢锁的客户端在 ZK 的锁节点下，创建具有单调递增编号的临时节点。客户端仅去监听排在自己前一位的那个节点。这彻底扼杀了羊群效应，实现了有序、轻量排队。
• 时钟回拨 (Clock Backwards)
  • Why：雪花算法（Snowflake）生成的 64 位唯一 ID，其前 41 位强依赖系统毫秒时间戳。如果服务器因为 NTP 网络自动校时或其他原因导致系统时钟发生倒退，雪花发号器会瞬间产生与过去完全重复的 ID，引发严重的物理主键冲突崩溃。
  • What/Deep：强依赖时间戳的分布式算法的致命死穴。大厂必须在发号器底层注入完备的时钟回拨自愈防线（如自旋等待、备用机器 ID 物理切分）。

---

🚀 AP 与 CP 分布式锁架构骨架

在面试中陈述分布式锁，您可以通过下方的精美对比图，快速向面试官展示 Redis 分布式锁的异步 AP 特性（高吞吐，存在极低概率丢失）以及 ZooKeeper 的强一致性 CP 特性（利用临时顺序节点排队监听）：

graph TD
    classDef redisStyle fill:#ffebee,stroke:#c62828,stroke-width:2px;
    classDef zkStyle fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px;

    subgraph Redis 分布式锁模型 (AP 属性 - 侧重高吞吐)
        Client1[客户端 A] -->|1. SETNX 加锁成功| Master[Redis 主库]:::redisStyle
        Master -.->|2. 异步同步延迟期间 Master 宕机| Slave[Redis 从库]:::redisStyle
        Client2[客户端 B] -->|3. 从库升级为新主 / 丢失 Key / 成功抢锁| Slave
    end

    subgraph ZooKeeper 分布式锁模型 (CP 属性 - 侧重强一致)
        ClientA[客户端 A] -->|1. 创建最小临时顺序节点 lock_001| ZK1[ZK 节点 1]:::zkStyle
        ClientB[客户端 B] -->|2. 创建节点 lock_002 / Watch 监听 lock_001| ZK1
        ClientC[客户端 C] -->|3. 创建节点 lock_003 / Watch 监听 lock_002| ZK1
    end

---

🎯 第一优先级核心考点详解

一、 Redis 分布式锁失效与学术界红锁 Redlock 经典大辩论 (Why-What-How-Deep)

• Why（主从/哨兵模式下的分布式锁为什么会失效？）
  • 痛点：为了高可用，Redis 部署了主从或哨兵集群。由于 Redis 主从复制是异步进行的：
    1. 线程 A 尝试在 Master 节点上写入锁 Key 并成功加锁。
    2. 在 Master 还没来得及将这行 Key 异步同步给 Slave 的一瞬间，Master 突然发生物理宕机。
    3. 哨兵将 Slave 提升为新 Master。由于新 Master 内存中根本没有这行 Key，线程 B 尝试加锁时会轻松成功。
  • 👉 后果：同一瞬间，线程 A 和线程 B 同时持有了同一把分布式锁，分布式锁宣告瞬间瘫痪。
• What（红锁 Redlock 算法能解决吗？）
  • Redlock 机制：客户端在 5 个完全独立的 Redis Master 节点上并行加锁，过半数（$\ge 3$ 个）成功且总耗时未超期才算加锁成功。这消除了单主节点同步延迟隐患。
• How（业务层终极容错与 Redlock 的弃用准则）
  • 简历实战引用：在我们的秒杀设计中，我们承认 Redis 锁的 AP 属性，大厂普遍禁用 Redlock。我们通过“Redis 锁防重复提交（截杀 99.9% 流量）”+“数据库乐观锁原子条件更新与唯一约束（死守最后 0.1% 防线）”实现了兼顾吞吐与安全的终极架构。👉 点击跳转简历场景一
• Deep（深水区：Martin Kleppmann 对 Redlock 的经典死锁质问）
  • 分布式系统泰斗 Martin Kleppmann（《设计数据密集型应用》作者）曾发表长文，从学术和工程双重维度对 Redlock 进行了彻底的否定，引发了与 Redis 作者 Antirez 的经典大辩论。其核心论点如下：
    1. GC STW（Stop-The-World）导致的锁越界失效：
       • 假设客户端 A 并行向 5 个 Redis 节点发起了加锁请求，并在其中 3 个节点上加锁成功。
       • 就在客户端 A 刚准备执行业务逻辑的一瞬间，其 JVM 突然触发了严重的 Full GC，线程陷入长时间的 STW 挂起（假设挂起了 40 秒，而锁的生存期 TTL 仅为 30 秒）。
       • 由于 STW 期间客户端 A 无法向 Redis 发送续租心跳，30 秒到期后，Redis 节点自动将锁删除。
       • 此时，客户端 B 并行加锁，成功获得了锁，并开始执行写业务。
       • 40 秒后，客户端 A 结束 GC 恢复运行，它误以为自己依然安全持有锁，也继续执行写业务。
       • 👉 后果：A 和 B 在没有并发锁保护下同时写入数据，引发致命脏写。
    2. 系统时钟漂移 (Clock Drift) 引发的崩盘：
       • 红锁的加锁时效性极度依赖各个 Redis 服务器节点的本地物理时钟。如果其中一台 Redis 服务器因为 NTP 自动对时，导致系统时间突然向未来**“跳跃”了数秒**。这会导致锁在这台节点上瞬间被提前过期清除，破坏了“过半数锁成功”的共识基础。
    • 👉 大厂共识：Redlock 将一次网络 I/O 放大 5 倍，吞吐急剧恶化，且理论上依然无法防范 GC STW。因此大厂生产环境全面禁用 Redlock，首选轻量单节点 Redis 锁配合数据库强拦截。

---

二、 ZooKeeper 分布式锁与羊群效应 (Herd Effect) 剿灭 (Why-What-How-Deep)

• Why（为什么 ZooKeeper 锁能够完美防范锁失效与死锁？）
  • 痛点：Redis 锁存在异步复制导致的锁失效；且如果持有锁的客户端服务器突然挂机崩溃，若不设合理的 TTL 就会发生死锁，而设了 TTL 又有提前释放的风险。
  • 解决：ZooKeeper 引入强一致的 ZAB 协议（CP 属性），并利用临时节点实现自动物理释放。
• What（临时顺序节点加锁机制）
  • ZK 分布式锁在指定的锁节点（如 /lock）下，为每个尝试抢锁的客户端创建一个 临时顺序节点（EPHEMERAL_SEQUENTIAL）（如 /lock/seq_00001, /lock/seq_00002）。
• How（如何防范严重的羊群效应 Herd Effect？）
  • 羊群效应痛点：如果所有未抢到锁的客户端都去监听最小的那个节点（锁持有者）。当锁被释放、节点被删除的一瞬间，ZK 会向成百上千个等待客户端同时发送 Watch 事件通知。这会导致上千个客户端在一瞬间同时被唤醒，疯狂发起获取锁请求，这会让 ZK 服务器的 CPU 与网络带宽瞬间过载并瘫痪。
  • 大厂级自愈解法：排队排他监听机制。
    1. 每个客户端在创建完自己的临时顺序节点后，通过 getChildren() 获取 /lock 下的所有子节点。
    2. 判定是否为最小：如果自己创建的节点编号是所有子节点中最小的，则判定抢锁成功。
    3. 精确监听：如果自己不是最小的，客户端只去注册监听排在自己前一位的那个节点（如 seq_00003 仅去 Watch seq_00002，而绝对不去 Watch seq_00001）。
    4. 当 seq_00001 释放锁并删除节点后，ZK 只会定向唤醒 seq_00002；当 seq_00002 释放时，只会唤醒 seq_00003。这彻底消灭了羊群效应，实现了极其优雅、有序的锁排队。
• Deep（深入源码：Session 心跳超时与临时节点的自动删除死锁防线）
  • ZK 锁无死锁的物理底座：
    • ZK 锁之所以不需要设计复杂的看门狗续租机制，是因为其节点被声明为 EPHEMERAL 临时节点。
    • 客户端在建立连接后，会与 ZK 服务端维持一个底层的 TCP 长连接 Session 会话心跳。
    • 当持有锁的客户端服务器发生物理宕机、JVM 崩溃或网线断开时，心跳骤然停止。ZK 服务端在检测到该 Session 超时（默认由参数 tickTime * 2 控制）的一瞬间，会自动在物理内存中将该客户端对应的临时顺序节点彻底抹去删除。
    • 这一删除动作会立刻向排在它后面的下一个节点发送 Watch 事件。新节点在毫秒级无感接管锁，全程完全不需要设计任何超时时间，且绝对不会发生无尽死锁，完美体现了 CP 系统的强安全保障。

---

三、 雪花算法（Snowflake）二进制移位设计与时钟回拨生产自愈 (Why-What-How-Deep)

• Why（为什么分库分表下绝对禁用 MySQL 自增 ID 或 UUID？）
  • 痛点：如果数据库在分库分表下使用自增主键，不同库之间的主键范围会重叠，导致数据物理冲突，合并对账灾难；且自增 ID 会泄露公司敏感的日交易增量。UUID 虽唯一，但它是 36 字节的无序字符串，作为 B+ 树主键会导致严重的页分裂和物理空间碎片，写入性能雪崩。
  • 解决：使用全局唯一、时间递增、对 B+ 树极其友好的雪花算法 ID。
• What（雪花算法 64 位 Long 的二进制拼接公式）

  0 (1位符号) | 41位时间戳 (毫秒差值) | 5位数据中心ID | 5位工作机器ID | 12位序列号 (单毫秒自增)

  • 移位拼接公式：

    id = ((timestamp - twepoch) << 22) | (datacenterId << 17) | (workerId << 12) | sequence;

• How（时钟回拨防线的自愈实现）
  • 简历实战引用：在我们的餐饮 SaaS 订单号生成中，我们设计了包含自旋与 maxTimestamp 内存拉平的自愈发号器。👉 点击跳转发号器源码实现
• Deep（深入算法：大厂生产级时钟回拨三道防线设计）
  • 面对 NTP 自动对时造成的时钟回拨，单单写死 timestamp < lastTimestamp 抛出异常会让线上发号器直接停摆。大厂在生产中必须部署以下三道自愈防护层：
    1. 轻微回拨（$\le 5$ms）之“强制自旋”：
       • 当检测到时钟回拨差值在 5 毫秒以内时，发号器不报错，而是强行让当前调用线程进行自旋挂起等待（如 wait(offset * 2)），直到物理时钟追赶上上一次的发号时间，再顺畅发号。
    2. 严重回拨之“maxTimestamp 内存拉平”：
       • 发号器在内存中持续维护并保存该实例所达到的历史最大时间戳 maxTimestamp。
       • 一旦发生严重时钟回拨，发号器强制将当前时间戳直接拉平并重置为 maxTimestamp。虽然此时系统时间处于“过去”，但发号器依然假装在 maxTimestamp 这个“未来”毫秒内执行 12 位序列号的递增发号。因为时间戳不重复，ID 绝不会冲突。
    3. 终极防御之“动态 Backup 备用机器 ID 切换”：
       • 在初始化时，我们利用 ZooKeeper 为每台发号器物理机器分配两个相邻的工作机器 ID：workerId（如 5）和 backupWorkerId（如 6，作为备用）。
       • 当发生无法自愈的严重时钟回拨时，算法自动将 workerId 瞬间切换为备用机器 ID 6。
       • 物理机理：由于机器 ID 发生了物理改变，即使当前的时间戳与过去的某个时间段完全重叠，由于 workerId 字段的二进制位发生了改变，生成的 64 位 Long 型 ID 依然是绝对唯一的，从数学物理结构上彻底封杀了冲突可能，保障了发号器的 100% 可用性。

---

四、 分布式 ID 号段模式与美团 Leaf 方案的双 Buffer 异步装载 (Why-What-How-Deep)

• Why（为什么雪花算法会存在“趋势递增”而非“绝对单调递增”？）
  • 痛点：雪花算法由于包含工作机器 ID 位，不同机器的物理时间戳存在微秒级差异。如果分库分表需要索引页利用极致，或者想让主键实现纯正的、绝对单调递增，雪花算法依然是不完美的。
  • 解决：采用号段模式（如美团 Leaf 方案）。
• What（号段模式核心思想）
  • 不再每次都请求数据库去获取单个 ID。而是每次去数据库里申请并批量加载一个“号段”（例如：max_id 从 1000 变到 2000，当前号段为 [1000, 2000]）。在内存中利用 AtomicLong 的自增直接发号，速度提升上百倍。
• How（消除慢 SQL 引起的响应时间波峰停顿）
  • 普通号段缺陷：当内存中的当前号段（Buffer1）被全部消耗完毕的一瞬间，当前请求的线程会被迫进行同步阻塞，等待去数据库更新并加载下一个号段。这会导致该请求出现明显的响应延迟卡顿。
  • 双 Buffer 异步装载：Leaf 在内存中维护两个号段缓冲区：Buffer1（正在使用）和 Buffer2（备用）。
• Deep（深入内核：双 Buffer 10% 阈值的动态加载机理）
  • 10% 异步激活机制：
    • 当业务高频消耗 Buffer1 时，发号器会持续检测其消耗比例：

      消耗比例 = (当前已发号数) / (号段总步长 step)

    • 一旦当前 Buffer1 的号段消耗比例达到了 10% 这一特定阈值点时，发号器不会等到 100% 才被动触发。它会立即以异步的方式，向后台线程池提交一个加载任务。
    • 后台异步线程去 MySQL 中执行 UPDATE 更新，并将下一个新号段（如 [2001, 3000]）的数据提前拉取下来，写入备用的 Buffer2 中。
  • 无缝指针切换：
    • 当 Buffer1 被 100% 消耗耗尽的那一瞬间，发号器执行极轻量的 指针无缝切换，将当前发号指针直接指向早已加载完毕的 Buffer2。
    • 原先的 Buffer1 变为空闲的备用缓冲区，等待下一次 10% 阈值触发。
    • 这一设计将耗时的慢 SQL 磁盘与网络 I/O 动作完全转化为后台异步线程的悄悄处理，对前台业务实现了完美的 $O(1)$ 内存级发号性能，彻底消除了发号响应时间的任何波峰停顿！

---

🎯 场景亮点深度关联与对线场景 (Why-What-How)

场景一：Redis 哨兵/主从集群下【主从同步延迟导致分布式锁瞬间失效灾难】

面试官切入点：

“我看到你的秒杀系统用了 Redisson 分布式锁进行单实例加锁。如果你的 Redis 部署在哨兵模式或主从集群下，一旦发生 Master 节点宕机、主从切换，分布式锁是如何失效的？你听说过红锁 (Redlock) 吗？为什么工业界极少有人真正使用它？你是如何进行业务容错设计的？”

回答思路 (Why-What-How 拆解)：

• Why：由于 Redis 主从同步是异步的。当 Master 加锁成功而未同步到 Slave 时 Master 宕机，新晋 Master 会因为丢失该 Key 导致并发线程二次成功抢锁，分布式锁瞬间失效。红锁算法太重且无法防范 GC STW。
• What/How： 我们拒绝使用学术派的 Redlock，承认单实例 Redis 锁的 AP 属性。我们通过将 Redisson 单实例锁作为第一流量闸口（拦截 99.9% 流量），配合 MySQL 的排他写锁（写写冲突序列化）与唯一索引强排重 作为最终的底盘保障。
• Deep（Redisson 可重入加锁与解锁 Lua 脚本全集）：
  • 我们自研了防重提与减库存机制，Redisson 底层依托复杂的 Hash 数据结构实现可重入与看门狗续期：

    // 1. Redisson 抢占与可重入底层 Lua 脚本
    // KEYS[1] = 锁的 Key 名称 ("lock:voucher:seckill")
    // ARGV[1] = 锁的租约生存期 (默认 30000ms)
    // ARGV[2] = 锁拥有者的唯一线程标识 ("UUID:threadId")
    String lockLua = 
        "if (redis.call('exists', KEYS[1]) == 0) then " + // 1. 锁不存在：加锁
        "  redis.call('hset', KEYS[1], ARGV[2], 1); " + // 写入 Hash, field=线程ID, value=1(重入次数)
        "  redis.call('pexpire', KEYS[1], ARGV[1]); " + // 设置生存时间
        "  return nil; " +
        "end; " +
        "if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then " + // 2. 锁已存在且是自己：可重入自增
        "  redis.call('hincrby', KEYS[1], ARGV[2], 1); " + // 计数器+1
        "  redis.call('pexpire', KEYS[1], ARGV[1]); " + // 重新续租
        "  return nil; " +
        "end; " +
        "return redis.call('pttl', KEYS[1]);"; // 3. 抢锁失败：返回锁的剩余过期毫秒值

  • 在解锁时，Redisson 利用 Lua 保证计数器递减并在归零时原子删除广播：

    // 2. Redisson 释放可重入锁 Lua 脚本
    // KEYS[1] = 锁的 Key
    // KEYS[2] = 解锁广播通道 ("redisson_lock__channel:lock:voucher:seckill")
    // ARGV[1] = 解锁发布的消息值 (0L)
    // ARGV[2] = 锁的租约生存期 (30000ms)
    // ARGV[3] = 锁持有者的唯一线程标识 ("UUID:threadId")
    String unlockLua = 
        "if (redis.call('hexists', KEYS[1], ARGV[3]) == 0) then " + // 非持有者尝试解锁，直接拒绝
        "  return nil;" +
        "end; " +
        "local counter = redis.call('hincrby', KEYS[1], ARGV[3], -1); " + // 重入计数器自减 1
        "if (counter > 0) then " + // 重入次数依然大于 0，说明仍然持有锁
        "  redis.call('pexpire', KEYS[1], ARGV[2]); " + // 继续保留锁并刷新生存期
        "  return 0; " +
        "else " + // 次数归零，说明锁已完全释放
        "  redis.call('del', KEYS[1]); " + // 原子删除锁 Key
        "  redis.call('publish', KEYS[2], ARGV[1]); " + // 向广播通道发送解锁消息唤醒阻塞线程
        "  return 1; " +
        "end; " +
        "return nil;";

  • 在极端的主从切换失效下，并发请求穿透至数据库。我们通过在 SQL 中设计严格的 CAS 条件更新：UPDATE voucher_stock SET stock = stock - 1 WHERE voucher_id = 100 AND stock > 0。由于 MySQL 的行级排他锁（X 锁）对并发写操作执行了强制的串行化排队，后到达的线程即使绕过了失效的 Redis 锁，也会因为 stock 归零更新返回 affectedRows == 0 而被拦截失败，从而在 AP 系统的极致性能加持下，死守住数据一致性防线！

---

场景二：SaaS 餐饮海量订单生成与【雪花算法时钟回拨生产级硬核解法】

面试官切入点：

“在苍穹外卖 SaaS 系统中，创建订单时为什么不能使用 MySQL 自增主键？如果选择雪花算法 (Snowflake)，请问其底层位结构是怎样的？在 NTP 网络对时服务导致‘时钟回拨（时钟往回走）’的极端生产场景下，雪花算法会发生什么？你是如何应对这一痛点的？”

回答思路 (Why-What-How 拆解)：

• Why：在 SaaS 多租户模式下，分库分表是必然的架构。使用自增 ID 会导致主键冲突，且直接暴露每日订单量等商业机密。雪花算法生成的 Long 型 ID，由于其二进制结构中时间戳高位，天然保证了全局唯一且对 B+ 树极其友好。
• What/How： 雪花算法通过 1位符号位、41位时间戳、5位数据中心ID、5位工作机器ID及12位序列号拼接而成。
• Deep（支持自旋与时间拉平的时钟回拨自愈发号器）：
  • 为了彻底消灭时钟回拨对线上业务的摧毁性打击，我们对发号器进行了源码级重构，引入了自旋与 maxTimestamp 历史时间拉平的自愈防线：

    // 具备时钟回拨自愈容错能力的 SnowflakeIdWorker
    public class SnowflakeIdWorker {
        private long lastTimestamp = -1L;
        private long maxTimestamp = -1L; // 核心设计：记录历史最大时间戳
        private long sequence = 0L;
        // 其余参数省略...
    
        public synchronized long nextId() {
            long timestamp = timeGen();
    
            // 核心拦截：检测当前时钟是否发生回拨
            if (timestamp < lastTimestamp) {
                long offset = lastTimestamp - timestamp;
                if (offset <= 5) {
                    // 1. 轻微回拨（小于 5ms）：当前线程自旋阻塞，强行等待时间赶上
                    try {
                        wait(offset << 1); // 挂起两倍的回拨时间
                        timestamp = timeGen();
                        if (timestamp < lastTimestamp) {
                            throw new RuntimeException("时钟依然在回拨中，拒绝发号");
                        }
                    } catch (InterruptedException e) {
                        throw new RuntimeException(e);
                    }
                } else {
                    // 2. 严重回拨（大于 5ms）：强制拉平至内存记录的历史最大时间戳，杜绝主键重复
                    if (maxTimestamp > 0) {
                        timestamp = maxTimestamp; // 用历史最大时间作为基准，强制自增序列号发号
                    } else {
                        throw new RuntimeException("系统时间严重回拨且无备份，发号器停摆");
                    }
                }
            }
    
            if (lastTimestamp == timestamp) {
                sequence = (sequence + 1) & 4095;
                if (sequence == 0) {
                    timestamp = tilNextMillis(lastTimestamp);
                }
            } else {
                sequence = 0L;
            }
    
            lastTimestamp = timestamp;
            maxTimestamp = Math.max(maxTimestamp, timestamp); // 持续更新并向未来推进最大时间戳
    
            return ((timestamp - twepoch) << 22) |
                   (datacenterId << 17) |
                   (workerId << 12) |
                   sequence;
        }
        // 其余底层方法省略...
    }

  • 配合我们在 ZK 注册中心为机器节点动态分配的 backupWorkerId 应急机器 ID 自动切分机制，从二进制源头上彻底封锁了 ID 冲突可能，保证了餐饮 SaaS 每日数十万量级订单号的安全、连续、单调递增产出！

---

📝 第三优先级：避坑与实战常识

• UUID 为什么绝对不适合作为 B+ 树的聚簇索引主键？
  • 成因剖析：很多项目建表默认使用 UUID 字符串。但在 InnoDB 引擎中，数据页物理行排列是强依赖主键的。UUID 是 36 字节的完全无序随机字符串：
    1. 物理页分裂 (Page Split)：每次插入一条新记录，其 UUID 值的大小是随机的。这会导致新纪录被强行“插队”塞入到树中间已经写满的 16KB 数据页中，频繁引发物理行的大幅拷贝搬运与页分裂。
    2. 索引空间虚胖：UUID 占用 36 字节，比普通的 8 字节 Long 型主键大出数倍。这不仅让非叶子节点单页容纳的索引键暴跌（大幅降低扇出度，增加 B+ 树高度），还让所有的辅助非聚簇索引（叶子节点存主键）的体积极速膨胀，白白耗尽堆内存。
  • 大厂规范：高并发海量表必须全部使用 Long 型自增或雪花算法有序 ID，保证行数据只往末尾页顺序追加追加，彻底扼杀页分裂！