T18 · Realtime System

一个现实问题

你的索引器已经很可靠了（T17 那一章的成果），现在要把变化推给用户。你加了一条长连接，索引器每处理完一个区块就把事件推出去。本地测一遍，秒级到达，非常爽。

上线两周后，客诉里开始出现同一类描述，而且很难复现：

• 「我的活动列表少了几笔，刷新一下又有了。」
• 「有一笔一直显示处理中，其实早就成功了。」
• 「界面上的余额和我在浏览器上看到的对不上。」

你去查服务端日志，干干净净：消息都发出去了。 发送函数返回成功，没有异常，没有堆积告警。

然后你注意到这几个用户有一个共同点：他们都在移动网络下，都经历过短暂断线。

这时候问题就清楚了。你的推送是「发出去就忘」的：那一刻谁连着，谁就收到；谁没连着，那条消息就永远消失了。它不是丢在网络上，是丢在你的设计里——因为你从来没有为「他不在」这件事准备过任何东西。

于是真正的问题是：用户掉线 30 秒再回来，中间发生的事，你从哪里补给他？

思想实验

三种把消息送出去的方式。

第一种：电台广播。 你在演播室念，谁开着收音机谁听见。你不在收音机前，那段节目就没了，而且没有任何人知道你错过了什么。

这种方式的特点是：服务端不需要记住任何关于听众的事，成本极低。代价是「送达」完全取决于运气。

第二种：留言板加编号。 每条消息贴在墙上，带一个连续递增的编号。你回来时对管理员说「我看到第 812 号了」，管理员把 813 之后的念给你听。

现在「掉线」这件事从一个不可恢复的事故，变成了一次可以补齐的追赶。代价是有人得保存这面墙，而墙的容量是有限的——旧消息总会被擦掉。

第三种：只喊「有变化了，自己去看」。 不传内容，只传一个信号。听到的人自己去查最新状态。

这一种有一个被低估的优点：丢掉一个信号几乎没有后果，因为下一个信号来的时候会一起刷新。它天然幂等、天然抗丢。它答不了的问题是「中间发生了什么」——只能给你「现在是什么样」。

三种方式指向同一个判断标准：

实时推送要么可重放，要么可收敛。两者都不是，就是在赌网络。

第一种既不可重放也不可收敛，所以它必然会丢。开头那三条客诉，就是这一件事的三种表现。

你来决定

给「链上一有变化就更新界面」这个需求选一种做法。

观察结果

把四种做法按两个不同的指标排一次，你会看到一件很多人没分清的事：

第一列和第二列没有任何关系。这就是这一章最该带走的一句话：

「实时」是一个延迟指标，「不丢」是一个正确性指标，两者由完全不同的机制保证。

绝大多数「实时推送」只做了第一件事。它上线时看起来很好，因为开发和测试都在稳定网络下；它的问题只会出现在用户那里，而且以「偶尔少几条」这种最难排查的形式出现。

还有第二条结论，它把这一章和上一章缝在了一起：

链头的事件是可能被撤回的。已经推给用户的事件，不会自己收回来。

所以推送流里必须有一类「撤销」消息，或者干脆只推已经足够深的事件——也就是 T17 那张待发表里的投递条件。「不丢」和「不假」是两个独立的要求，都要做。

建立模型

三个要素

一个不丢事件的推送系统，只需要三样东西：

游标从哪来：三个候选，两个是错的

时间戳——错。 它不严格单调（同一毫秒内多条）、受时钟调整影响、多实例之间还会漂移。用时间戳做游标，补齐时要么重复要么遗漏。

数据库自增序列——大多数情况下也是错的。 原因很隐蔽：序列号是在插入时取的，提交却不同步。事务 A 拿到 102，事务 B 拿到 103，B 先提交。这时候一个读取者看到了 103，把游标推进到 103——然后 A 才提交，102 就永远不会被任何人读到了。

这个空洞不会报错，只会让某些事件消失。要用它，必须配合「只读取足够旧的记录」或者「单一写入者串行分配」。

链上坐标——对。 (chain_id, block_number, log_index) 这个组合本身就是一个严格单调、全局唯一、跨实例一致、而且重启后还能对得上的游标。它还有一个额外好处：客户端拿着它，可以直接去链上核对。

把三段编码成一个可比较的字符串或者一个大整数，就是你的游标：

cursor = chainId : blockNumber : logIndex
      例：  1 : 00000000020134 : 0007

消息协议：五种消息，缺一不可

不依赖任何具体的库，先把协议本身写清楚：

客户端 → 服务端   subscribe  { topics, cursor }   订阅，带上我看到的位置
服务端 → 客户端   snapshot   { cursor, state }    当前状态快照，可选
服务端 → 客户端   event      { cursor, type, payload }
服务端 → 客户端   revoke     { fromCursor }       这个位置之后的事件作废
服务端 → 客户端   reset      { reason }           你的游标太旧，请重新订阅
双向              ping / pong                      心跳

后面三种是新手最容易漏的：

reset 必须有。 可重放窗口是有限的，客户端离线一小时回来，它的游标可能已经被清理掉了。没有 reset，服务端会静默地不补任何东西，客户端会以为自己已经是最新的——这是一种比掉线更糟的状态，因为它看起来是正常的。

revoke 是重组的出口。 如果你选择推送未确认的事件，就必须有能力告诉客户端「刚才那几条作废」。不想实现它，就只推足够深的事件，把问题交给确认深度。

心跳必须是双向的。 只有客户端发心跳，服务端可以正确判死；只有服务端发，客户端可以正确判死。两边都要有超时判断，否则会出现一方以为连着、另一方早就走了的半开连接。

快照与增量的接缝：这一节是最容易写错的地方

「先取当前状态，再订阅后续变化」听起来天经地义，但它是错的：

错误顺序：
  t0  查询快照（拿到截至 cursor=100 的状态）
  t1  ← 这一瞬间发生了 cursor=101 的事件，没有人在监听
  t2  建立订阅，从此收到 102 及之后

  结果：101 永久丢失，而且没有任何迹象

正确顺序是先订阅、缓冲、再取快照、最后放行：

1. 建立连接并订阅，服务端开始往这个连接的队列里放事件
2. 客户端（或服务端）此时不投递，先把事件缓冲起来
3. 取快照，得到快照对应的 cursor
4. 把缓冲里 cursor 大于快照 cursor 的事件依次放出去，丢弃更早的
5. 之后转入正常投递

这一段顺序写反，是「重连后少几条」这类问题最常见的根因，而且它在本地测试中几乎不可能复现——你需要恰好在那一瞬间有一个事件。

背压：出口永远是降级，不是等待

一个客户端读得比你发得慢（弱网、后台标签页、一个写得不好的客户端）。三种处理方式：

第三种是唯一正确的答案。把它记成一句话：

背压的出口永远是降级，不是等待。

具体做法：每个连接一个有界队列（比如一千条）。队列满时，丢掉这个连接的全部排队事件，给它发一个 reset，让它重新走一遍「订阅、快照、补齐」的流程。

注意不要只丢最老的那几条——那会在客户端造成一个它察觉不到的空洞。要丢就全丢，然后明确告诉它「你需要重来」。

重连：退避要带抖动

客户端断线后立刻重连，失败再立刻重连，会在服务端故障时把它彻底压死。标准做法是指数退避：

第 n 次重试的等待时间 = min(基础间隔 × 2 的 n 次方, 上限) × 随机系数
随机系数取 0.5 到 1.5 之间

那个随机系数不是可有可无的。没有它，一次服务端重启会让所有客户端在同一秒回来，第二次重启又会让它们在同一秒回来——你会得到一个周期性的自我攻击。

交付语义：不要追求服务端的恰好一次

网络层面做不到「恰好一次」。可行的组合是：

服务端：至少一次投递（重连补齐可能重发几条）
客户端：按 cursor 去重（小于等于已见 cursor 的直接丢弃）
合起来：效果上的恰好一次

这和 T15 的幂等、T16 的主键幂等、T17 的断点幂等是同一个套路的第四次出现：不追求「只做一次」，而是保证「做多次和做一次结果相同」。

扇出与多实例

每个连接一个有界发送队列，一张从主题到连接的索引表，事件来了查表投递。这在单实例下很直接。

多实例时会冒出一个诱惑：把事件塞进一个消息中间件，各实例订阅。可以做，但要守住 T16 那条规则：事实只有一份。 中间件是传输通道，不是事实来源——补齐时必须回数据库按游标查，而不是去问中间件要历史。

理由很简单：中间件的保留策略、分区顺序、消费位点，全都是另一套可能出错的状态。让它只负责「快」，让数据库负责「对」。

它叫什么

动手

断线 30 秒后重连收到的事件序列，
必须与全程不断线的对照客户端收到的序列完全一致（数量、顺序、内容）。

select * from outbox
 where chain_id = $1
   and (block_number, log_index) > ($2, $3)   -- 客户端给的游标
   and block_number <= $safeHeight
 order by block_number, log_index
 limit 1000;

- 数量一致吗？
- 顺序一致吗？
- 逐条内容一致吗？
- 重连的那个有没有收到重复的？收到了的话，去重逻辑生效了吗？

- 延迟 500 毫秒
- 丢包 10%
- 带宽限制到很低，逼出背压

AI Lab

第一步：
设计一个链上事件推送的订阅协议，要求断线重连后不丢事件。
列出所有消息类型、字段、以及客户端和服务端各自的状态机。

第二步：
现在逐个回答这些场景，说明你的协议里哪一部分在起作用：
1. 客户端断线 30 秒后重连，中间有 12 条事件。
2. 客户端断线 3 小时后重连，服务端的重放窗口只有 1 小时。
3. 一个客户端读取速度只有推送速度的十分之一，持续 10 分钟。
4. 服务端重启，5 万个客户端同时断开。
5. 客户端在「取快照」和「建立订阅」之间的那一瞬间，正好发生了一条事件。
6. 已经推给客户端的 3 条事件，因为链重组而不再有效。

第三步：
上面六个场景里，哪几个是你的协议目前处理不了的？
对每一个，说明最小的改动是什么，以及这个改动的代价。

真实案例

改一个变量

带走的问题

本章自测