T15 · Backend for Crypto

一个现实问题

一个「我的资产」页面。需求写得很简单：列出用户持有的代币，每种显示余额、当前价格、24 小时涨跌。

你算了一下：假设用户持有 20 种代币。

• 20 次余额查询
• 20 次精度查询（不同代币位数不同）
• 20 次名称与符号查询
• 20 个价格，来自另外一个数据源

80 多次网络请求，从用户的浏览器发出去。

首屏跑了 6 秒。用户以为页面坏了，刷新，又是 80 次。三个用户同时刷新，你的 RPC 配额开始报 429。而此时全站只有三个人在线。

再往下想一层，问题更尴尬：这 80 次请求的结果对所有用户都是一样的。代币的名称、符号、精度是永远不变的；价格是全站共享的；连余额，同一个地址在同一个区块高度上的余额也是确定的。

你让每一个用户，各自重新算了一遍全世界都一样的答案。

这时候「为什么还要后端」就不再是一个哲学问题了。它的答案很具体：因为有一堆事情，链不做，前端做不好，只能后端做。

思想实验

把 RPC 想成一个只有一个窗口的档案馆。

它的性质很特别：

• 只读，而且极其严谨。 你问什么它答什么，一个字不多。它不会帮你汇总，不会帮你排序，不会告诉你「这个地址最近一个月的净流入」。
• 不记得你。 每次问都从头开始，没有会话，没有上下文。
• 有排队。 队伍是全站共用的，一个人问得太频繁，所有人一起等。
• 按次收费。 问得越多越贵。

现在把你的产品需求摆在这个档案馆面前：

「列出这 20 个代币的余额并按美元价值排序」——档案馆不会排序，你得把 20 条都取出来自己排。 「这个地址一收到钱就通知我」——档案馆不会主动找你，你得一遍遍去问。 「这笔提现请求，用户重复点了三次，只执行一次」——档案馆不知道什么叫「一次」，你发三笔它就执行三笔。 「同一个人一分钟最多查十次」——档案馆不认识人。

这四句话，就是后端的四项职责：聚合、轮询与通知、幂等、限流。再加上一项档案馆本身的性质带来的：缓存——同一个问题，答案在一段时间内不会变，不必反复去问。

后端不是来替代链的，是来做链做不了的那部分。 记住这句话的反面同样重要：链能做的那部分，后端不要抢——尤其是「什么是真的」这件事。

你来决定

给上面那个资产页面加一层。你先加哪一层？

观察结果

四个选项不是四选一，而是按顺序叠上去的四层。但它们要解决的其实是同一件事的两面：

看完这张表，有一条边界要立刻立起来：

链是事实来源，后端是投影与节流层。

后端可以缓存、聚合、加工、预计算，但它给出的每一个数字，都必须能回溯到链上的某个高度。一旦你的后端开始产生链上没有的「事实」——比如自己记一份余额然后加加减减——你就有了两份真相，而它们迟早会分叉。T16 会把这条边界变成具体的表结构。

建立模型

后端在链的两侧各有一条路径，它们的失败模式完全不同：

读路径：缓存的三层

缓存键的设计比缓存本身重要。分三类：

第一类是最大的免费午餐。上面那个页面的 80 次请求里，有 40 次是查名称、符号、精度——这些值一辈子都不会变，缓存一次就够了。光这一项就能砍掉一半请求。

第二类是这一章最值得记住的技巧：把区块高度放进缓存键，缓存就永远不会给出过期数据。高度变了，键就变了，自然回源。代价是命中率随高度更新而下降，所以它适合「历史查询」而不适合「查最新」。

还有一个几乎所有人第一版都会漏的东西：单飞。一百个请求同时到达，缓存都没命中，于是一百个请求一起回源——缓存在这一刻完全没起作用，甚至更糟（缓存击穿）。正确做法是同一个键只允许一个请求真的去回源，其余的等它的结果。

写路径：幂等的三个层次

用户重复点击、网络重发、队列重投、客户端重试——重复请求不是异常，是常态。而链上操作一旦重复，就是真金白银的损失。

幂等要在三个层次上同时成立，缺一层就会漏：

第一层  请求幂等：同一个幂等键，只产生一个任务
        实现：唯一索引 + 插入冲突即返回原结果

第二层  任务幂等：同一个任务被消费多次，只执行一次副作用
        实现：任务状态机 + 状态转移用条件更新，不用读后写

第三层  链上幂等：同一个业务操作，最多只有一笔交易上链
        实现：把幂等键与 nonce 绑定，一个键固定占用一个 nonce

第三层是最容易被忽略、代价最大的一层。 后端只发了一次，不等于链上只有一笔——如果你的 worker 崩溃重启后重新构造了交易，用的是新的 nonce，那么两笔交易都会上链，两笔都会成功。

反过来，如果一个幂等键固定绑死一个 nonce，重复构造出来的交易会因为 nonce 相同而互相顶替，链上最多只有一笔。这是从链的规则里拿到的一层免费保险。

请求幂等的表结构（SQL 是稳定的，这里可以写死）：

create table submissions (
  idempotency_key text        primary key,
  request_digest  text        not null,       -- 请求体的哈希，用来识别「同键不同内容」
  status          text        not null,       -- queued | broadcast | confirmed | failed
  nonce           bigint,                     -- 分配之后固定不变
  tx_hash         text,
  result          jsonb,
  created_at      timestamptz not null default now(),
  updated_at      timestamptz not null default now()
);

写入用一条语句解决，不要「先查再插」：

insert into submissions (idempotency_key, request_digest, status)
values ($1, $2, 'queued')
on conflict (idempotency_key) do nothing
returning idempotency_key;

• 返回了一行：这是新请求，继续入队。
• 返回零行：这是重复请求，去把原记录读出来返回给客户端。
• 读出来发现 request_digest 不一样：同一个键被用在了不同的请求上，返回冲突错误——这通常意味着客户端的键生成有 bug，不要默默接受。

「先 SELECT 看看有没有，没有再 INSERT」是错的。 两个并发请求会同时查到「没有」，然后同时插入。唯一索引是唯一可靠的那道锁。

限流要有两套

对外和对内是两件不同的事，很多人只做了一半：

• 对下游（你的用户）：按用户、按地址、按 IP 限流，防滥用。超限返回 429 并带上重试时间。
• 对上游（RPC 配额）：你自己的出口也要限，否则一次流量尖峰会把当天的配额打光，然后全站不可用。

上游限流的正确姿势不是丢弃，是排队加超时：请求进队列等待令牌，等不到就快速失败并返回缓存里的旧值——给一个稍旧的答案，好过给一个错误页。

它叫什么

动手

AI Lab

第一步：
为一个会发起链上交易的后端接口设计幂等方案。要求覆盖：
- 幂等键由谁生成、格式、有效期
- 存储结构与并发下的正确性保证
- 重复请求时返回什么
- 同一个键配不同请求体时怎么办
- 任务失败后的重试与终态判定
给出具体的表结构和 SQL。

第二步：
现在假设这个接口的 worker 在「交易已广播、回执未返回」时崩溃并重启。
重启后它读到这条记录，应该做什么？
如果它重新构造并发送了一笔交易，链上会发生什么？
我应该怎样保证「一次业务请求最多只有一笔交易上链」？

真实案例

改一个变量

带走的问题

本章自测