NATS JetStream：轻量消息与流存储设计

可视化演示

展示Spark RDD的惰性求值机制：转换操作构建血缘DAG图，行动操作触发执行，节点故障时通过血缘重建分区。

架构定位

回到骑手比喻。NATS 核心就是一个“即时送达、无仓储”的快递网络：生产者和消费者都在线时，消息秒达；一旦有一方不在线，消息立刻蒸发。它的默认语义是 at-most-once——至多送一次，送了就完事，没人签收也不补送。

JetStream 的诞生，本质上是在骑手网络旁边加了一座仓库。它不是一个独立安装的中间件，而是内嵌在 nats-server 程序中的持久化层：消息先落仓（磁盘），再按货架号（序列号）组织，消费者可以随时来取件，哪怕取件人迟到了十分钟，包裹也还好好地躺在架子上。

从架构上看，NATS 提供两条路径：核心路径只在内存中转发消息，追求极低延迟；JetStream 路径把消息写入流存储，并用 Raft 协议在多个节点间复制副本，保证节点崩溃后数据仍在。代价是每条消息多一次落盘与回执的开销，这就是持久化必须支付的成本。

所以选型时先问自己：这笔“快递”能不能丢？能丢，走核心路径；不能丢，就进 JetStream 仓库。架构定位的本质，就是为每一类消息选择正确的仓储方式。

流与消费者

驿站里每个货架都只放同一类包裹，按到达顺序从 1 号位摆到 N 号位——这就是 Stream（流）。分拣员不会每次从头看完整条货架，手里只捏着一张“取件进度卡”，记录自己取到了几号位——这就是 Consumer（消费者）。

在 JetStream 中，Stream 是消息的有序写入日志：每条消息获得一个单调递增的序列号，并长期保存在磁盘上。Consumer 则是独立于 Stream 的读取视角，它维护自己的游标（已确认的交付序号），决定下一次从哪个位置开始读。

Stream 用 subject 过滤器决定什么消息入流，比如只收 orders.* 主题下的订单事件；Consumer 则通过交付策略（deliver policy）选择起点：取最新、取最旧、按序列号回溯或按时间回溯。多个 Consumer 可以挂载在同一个 Stream 上，彼此互不干扰——就像多位分拣员各拿一张进度卡，共享同一排货架，但各自记录各自的进度。

游标就是分拣员手里的卡片。只要卡片没丢，货架再怎么新增包裹，他都能接着上次的位置继续取——这正是“流式消费可回溯”的来源，也是 JetStream 能做事件重放的基础。

投递语义

暴雨天骑手送包裹，你问他送不到怎么办。第一种应答：“我再补送，送到为止，但可能多送一遍”——这是至少一次。第二种应答：“我给每件包裹贴唯一快递单号，你扫码核对，重复件直接拒收”——这是精确一次。

投递语义描述系统对“丢消息”和“重复消息”两种事故的承诺。NATS 核心是至多一次；JetStream 默认提供至少一次：消息只要被写入 Stream 就不会丢，但消费者可能重复收到同一条消息。

JetStream 的至少一次，靠 ACK 加自动重发实现：消费者处理完必须回 ACK，超时未回就重新投递。要逼近精确一次，需要三件套：生产者给消息设置唯一 Nats-Msg-Id（用于去重）、消费者用 AckExplicit 逐条确认、消费业务逻辑保持幂等。注意：跨系统的分布式事务在真实世界里并不存在，业界常说的“精确一次”本质上是“有效一次”。

所以“精确一次”不是魔法，而是“去重 + 幂等 + 确认”三件套的合体。就像驿站不保证暴雨中每件包裹都不淋湿，但保证每张单子都有唯一编号、每笔签收都留底。

ACK 机制

分拣员从货架取走包裹后，要在机器上扫码签收——这就是 ACK。签了，驿站认为这件货处理完毕；迟迟不签，驿站就把包裹重新放回待取区，再次投递。

ACK 是 JetStream 可靠性的核心操作。消费者拉取消息后有两种回应：ACK 表示成功处理；NAK 表示处理失败，要求服务器立即重投。如果消费者在 ack_wait 等待窗口内没有任何回应，服务器也会自动判定超时并重投。

JetStream 的 Consumer 有三种确认策略：AckNone 完全不需要确认，服务器只管推送；AckAll 一次确认到当前游标位置，效率高但粒度粗；AckExplicit 逐条确认，最精确也最稳妥。配合 max_deliver 参数可以限制最大投递次数，超过后消息进入死信队列或直接丢弃，避免一条坏消息无限重试拖垮整条流水线。

把 ack_wait 想象成“骑手等签收的最长耐心”。耐心太短，包裹反复重投浪费运力；耐心太长，一件坏消息就能堵住整条货架。优秀的运维者会按业务处理耗时来调这个参数。

消息去重

驿站每天收到大量长得一模一样的包裹。怎么区分这是两单，还是同一单被重复录入？办法是看唯一快递单号——相同的单号，第二次直接拒收。

JetStream 的去重同样靠“单号”：发布者在消息头里带上 Nats-Msg-Id。Stream 会记住一段时间内见过的所有 ID，新消息的 ID 若已存在，直接丢弃并返回“重复”。

这个“一段时间”叫去重窗口，默认 2 分钟，可通过 Stream 配置调整。窗口期内，同一 ID 的重复消息会被拦截；窗口过后，同样的 ID 会被当作新消息放行。去重窗口不是免费的午餐：窗口越大，服务器内存里需要保留的 ID 集合就越大，内存占用随之上升。

给每条消息贴单号，代价是一点内存；收益是网络重试、客户端重发这些“人工补送”不再造成重复。单据查重，是这座驿站里最划算的投资。

Kafka 对比

Kafka 是城市边缘的巨型物流中心：分拣线（分区）成千上万，承载着全网最重的吞吐，但也需要专门的电力系统（ZooKeeper/KRaft）和一支庞大的运维队伍。JetStream 则是街角的智能驿站：一个二进制文件就能起服务，分拣员按需取件，日常几乎免维护。

选型不是比谁更“高级”，而是比谁更匹配。功能上，Kafka 用分区加消费组实现并行扩展，JetStream 用 Stream 加 Consumer 实现顺序与回溯；Kafka 的生态（连接器、流处理框架）更成熟，JetStream 胜在简单直接。

性能与运维上，JetStream 在每秒百万条消息以下的场景完全够用，端到端延迟更低、部署成本更小；Kafka 在超大规模、跨团队数据平台场景下优势明显。运维上，JetStream 的单二进制开箱即用，Kafka 则需要管理 broker、分区副本和元数据集群，复杂度不在一个量级。

一句话：你的业务需要“全球分仓”就选 Kafka，需要“街角驿站”就选 JetStream。绝大多数微服务团队，其实只需要一座驿站。

集群与容量

一座驿站可能会失火，所以聪明的做法是开三家分店，同一批货在每家库房各存一份——这就是 JetStream 集群的 Raft 复制：三个节点共同保管同一份流数据，任一节点宕机，其余节点照常营业。

JetStream 集群建议至少 3 个节点，Stream 的副本数（replicas）决定冗余度。写入时采用 Raft 多数派确认，过半节点落盘才算成功，因此数据不会因单点故障丢失。容量规划要同时算清存储、内存和网络三本账，避免“货架塞满才发现仓库不够大”。

存储量由消息速率、保留时长和副本数共同决定。主题设计上，推荐用 subject 层级（如 orders.created、orders.paid）代替大量独立 Stream；每条 Stream 可以用最大消息数（MaxMsgs）、最大字节（MaxBytes）或最长保留时间（MaxAge）组合控制生存期限。

容量规划的公式，就是驿站进货的账本：每天进多少货（速率）、留多久（保留）、存几份（副本）。算不清这三项的物流公司，仓库迟早爆仓。

AI 应用场景

Python 演示

import time  class SimStream:    """模拟 JetStream Stream：有序消息日志 + 去重窗口"""     def __init__(self, dedup_window=5):        self.log = []        self.dedup_window = dedup_window        self.seen_ids = {}     def publish(self, msg_id, payload, now):        if msg_id in self.seen_ids:            return "duplicate"        self.seen_ids[msg_id] = now        seq = len(self.log)        self.log.append({"seq": seq, "msg_id": msg_id, "payload": payload})        self._purge(now)        return seq     def _purge(self, now):        for msg_id in list(self.seen_ids):            if now - self.seen_ids[msg_id] > self.dedup_window:                del self.seen_ids[msg_id]  class SimConsumer:    """模拟 JetStream Consumer：游标推进 + ACK + 至少一次重投"""     def __init__(self, stream):        self.stream = stream        self.cursor = 0        self.unacked = {}     def pull(self):        for msg in self.stream.log:            if msg["seq"] >= self.cursor:                if msg["seq"] not in self.unacked:                    self.unacked[msg["seq"]] = 1                    return msg                self.unacked[msg["seq"]] += 1                return msg        return None     def ack(self, seq):        if seq in self.unacked:            del self.unacked[seq]        if seq >= self.cursor:            self.cursor = seq + 1  def run():    stream = SimStream(dedup_window=5)    consumer = SimConsumer(stream)    stream.publish("m1", "hello", 0)    print(stream.publish("m1", "hello-again", 0))    stream.publish("m2", "jetstream", 1)    msg = consumer.pull()    print("投递:", msg["seq"], msg["payload"])    msg = consumer.pull()    print("未ACK重投:", msg["seq"], msg["payload"])    consumer.ack(0)    msg = consumer.pull()    print("ACK后推进:", msg["seq"], msg["payload"])  if __name__ == "__main__":    run()

1. if msg_id in self.seen_ids: return "duplicate"去重窗口内发现相同 ID，直接拒绝。
2. seq = len(self.log)序列号取自当前日志长度，保证单调递增。
3. self._purge(now)每次发布后清理过期 ID，模拟去重窗口滑动。
4. if msg["seq"] >= self.cursor:只读取游标之后的消息。
5. self.unacked[msg["seq"]] += 1未确认消息再次被拉取，重投次数加一。
6. if seq >= self.cursor: self.cursor = seq + 1ACK 后推进游标，对应消费进度卡划格。

常见误区

面试题