4. 事件建模与ID设计

Redis Streams 的每一条消息都拥有一个 Entry ID，默认形如 毫秒时间戳-序号，例如 1717036800000-0。这个 ID 不只是"消息编号"，它同时承担三个职责：作为消息在流中的唯一标识、作为消费者读取与确认的定位游标、作为按时间范围检索（XRANGE）的排序键。因此 ID 设计一旦出错，轻则消息顺序错乱，重则同一业务事件被重复消费或永久丢失。本节围绕业务时间、分区键与幂等三个需求，讨论如何设计一套可落地的 Entry ID 策略。

一、先理解 ID 的生成规则与约束

当生产者使用 XADD stream * field value 时，Redis 会自动生成 ID：取当前服务器毫秒时间戳，若与上一条 ID 的时间戳部分相同，则序号部分自增；若时间戳更大，序号从 0 开始。关键约束是：ID 必须严格递增。如果显式传入的 ID 小于等于流中最大 ID，Redis 会直接报错 ERR The ID specified in XADD is equal or smaller than the target stream top item。

这条约束正是时钟回拨问题的根源。假设节点 A 在 1717036800500 写入了一条消息，随后 NTP 校时把系统时钟拨回到 1717036799000，此时再用 * 自动生成 ID，Redis 会尝试生成一个更小的时间戳，触发上述错误，写入失败。多节点同时向同一 Stream 写入时，各节点本地时钟不一致，也会造成 ID 大小关系与真实业务发生顺序不一致。

二、业务时间与写入时间分离

很多团队直接用 * 让 Redis 取服务器时间，这在单节点、时钟稳定的场景下没问题，但一旦涉及跨机房、批量补数或离线重放，就会暴露问题：写入时间不等于业务发生时间。例如订单在 10:00:00 创建，但因网络延迟 10:00:05 才写入 Redis，用 * 生成的 ID 时间戳是 10:00:05，后续按时间范围查询"10 点整的订单"就会漏掉它。

更稳妥的做法是由生产者显式传入业务时间戳作为 ID 前缀：

# 业务事件发生时间：2024-05-30 10:00:00.000
# 毫秒时间戳 = 1717034400000
XADD orders:stream 1717034400000-0 order_id O1001 amount 299.00

# 同一毫秒内的第二条，序号递增
XADD orders:stream 1717034400000-1 order_id O1002 amount 158.00

这样 ID 的时间戳部分就真实反映业务时间，XRANGE orders:stream 1717034400000 1717034400999 可以精确捞出该秒内的所有订单。代价是生产者必须自己维护"同一毫秒内序号递增"的逻辑，否则会撞上 ID 必须严格递增的约束。

三、分区键与多节点写入的冲突消解

当多个生产者实例同时向同一 Stream 写入时，即使都用业务时间戳，也可能在同一毫秒产生相同 ID。此时有两种思路：

• 序号段编码分区信息：把序号段拆成"分区号 + 分区内序号"。例如 3 位分区号加 3 位序号，1717034400000-001000 表示分区 1 的第 0 条。这样不同分区天然不会冲突，但要求分区号固定且数量可控。
• 按分区拆 Stream：更彻底的方式是每个分区键对应一个独立 Stream，如 orders:stream:shard0、orders:stream:shard1。ID 只需在单个 Stream 内递增，冲突面大幅缩小，消费端按分区并行处理，也便于水平扩展。

选择哪种取决于消费模型：如果下游需要全局有序，单 Stream 加分区号编码更合适；如果下游可以按分区独立处理，拆 Stream 的吞吐和隔离性更好。需要注意的是，拆 Stream 后跨分区的全局顺序不再由 ID 保证，业务上若依赖全局顺序，必须在应用层额外处理。

四、幂等需求：ID 不应承担去重职责

一个常见误区是把 Entry ID 当作幂等键。但 ID 是 Redis 生成的定位标识，同一业务事件因重试可能产生两条不同 ID 的消息，用 ID 去重根本挡不住重复。正确的做法是在消息字段中携带业务幂等键，例如订单号、支付流水号、设备事件序列号：

XADD orders:stream 1717034400000-0 \
  idempotent_key "ORDER:O1001:CREATE" \
  order_id O1001 amount 299.00

消费端在处理前先查幂等表（可用 Redis SET 或数据库唯一索引），若 idempotent_key 已存在则直接 ACK 跳过。这样即使消息重复投递，业务效果也只执行一次。ID 负责"定位与排序"，幂等键负责"去重"，两者职责分离，系统才清晰可控。

五、时钟回拨的工程防护

即便采用业务时间戳，仍需防范时钟回拨。可落地的防护措施包括：

1. 单调时钟兜底：生产者记录上次生成的 ID，新 ID 必须大于它。若业务时间戳回退，则用 上次时间戳 + 序号自增 生成，保证递增性不破坏。
2. NTP 平滑校时：使用 chronyd 的 slew 模式而非 step 模式，让时钟缓慢调整而非瞬间跳变，减少回拨幅度。
3. 写入失败重试：捕获 ERR The ID specified in XADD is equal or smaller 错误后，读取 XINFO STREAM 获取当前最大 ID，在其基础上递增重试，而不是盲目重发。
4. 监控告警：对 ID 生成失败率、节点间时钟偏移设置监控，偏移超过阈值（如 50ms）即告警。

下面给出一个生产者侧 ID 生成器的伪代码示例，体现"业务时间优先、单调兜底、冲突重试"三层逻辑：

last_ms = 0
last_seq = 0

def next_id(business_ms):
    global last_ms, last_seq
    if business_ms > last_ms:
        last_ms = business_ms
        last_seq = 0
    else:
        # 时钟回拨或同毫秒，序号自增
        last_seq += 1
        if last_seq > 999:
            last_ms += 1      # 序号耗尽，借用下一毫秒
            last_seq = 0
    return f"{last_ms}-{last_seq}"

这段逻辑保证了无论业务时间如何抖动，输出的 ID 始终严格递增，同时尽量贴近真实业务时间。序号上限 999 是示例值，实际可按每秒预期消息量调整，例如每秒 10 万条则需要至少 6 位序号。

六、策略选择速查

总结来说，Entry ID 设计的核心是三条线：时间线用业务时间戳保证可检索，顺序线用单调兜底和分区编码保证严格递增，幂等线用独立业务键保证重复投递不产生副作用。三者各司其职，才能在时钟回拨、多节点并发、消息重试等真实工程条件下，让 Stream 既有序又可靠。