Rust 实战：用 buzz 构建高并发 Nostr relay 与 AI agents 通信总线

发布时间：2026/11/3 5:45:16

1. 从 "buzz" 这个词说起：一个被低估的 Rust 实战项目

第一次看到 "buzz" 这个项目标题的时候，我脑子里蹦出来的其实是三个完全不同的方向：一个是消息推送里的 buzz 概念，一个是社交产品里那种"热度"的 buzz，还有一个就是 Nostr 生态里那个用 Rust 写的 relay 实现。结合热搜词里的 Nostr、relay、Rust、AI agents 这几个关键词，基本可以确定我们要聊的是第三类——一个用 Rust 构建的、面向 Nostr 协议的 relay 服务，并且它还在往 AI agents 这个方向做延展。

如果你对 Nostr 还比较陌生，我用一句话解释：它是一个去中心化的社交协议，核心思想是把"身份"和"数据"解耦。你的身份是一对密钥，你的内容（笔记、关注列表、私信）通过事件（event）的形式广播到多个 relay 上，relay 负责存储和转发这些事件。传统社交平台是"一个中心服务器存所有人的数据"，Nostr 是"一堆 relay 各自存一部分，客户端自己聚合"。这个模型听起来简单，但真要做成一个能扛住真实流量的 relay，工程上的坑非常多：并发连接管理、事件去重、订阅过滤、限流、持久化、垃圾内容过滤，每一项都能写一篇长文。

而 "buzz" 这个项目，恰恰是把这些坑都踩了一遍之后，用 Rust 重新做的一个 relay 实现。它为什么值得单独拿出来讲？因为 Rust 在写这类高并发网络服务时，确实有它独特的优势——内存安全、零成本抽象、异步生态成熟（tokio + axum 这套组合现在几乎是标配），而且编译期就能帮你挡掉一大批并发 bug。我自己从 Go 转到 Rust 写网络服务的那段时间，最大的感受就是：以前靠 review 和测试才能发现的 data race，现在编译器直接不让你过。

这篇文章我会围绕 buzz 这个项目，把它的整体设计思路、核心技术点、实操部署流程、以及我在实际跑 relay 过程中踩过的坑，全部拆开讲一遍。不管你是刚学 Rust 想找个真实项目练手，还是已经在做 Nostr 相关开发想了解 relay 内部怎么运转，或者你只是好奇 AI agents 和 Nostr 能怎么结合，这篇应该都能给你一些能直接抄作业的东西。

2. 整体架构设计：为什么用 Rust 写 relay 是合理选择

2.1 relay 的本质是什么，为什么它对性能敏感

先把 relay 的本质说清楚。一个 Nostr relay 干的事情其实就三件：接收客户端发来的 event、根据订阅规则把 event 推给订阅了的客户端、把 event 存下来供后续查询。听起来像是一个带过滤功能的 pub/sub 系统，但它的特殊之处在于：

连接数极高：一个中等规模的 relay 同时维持几千到几万个 WebSocket 连接是常态，每个连接都是一个长连接，不能像 HTTP 那样用完就关。
消息扇出大：一条热门 event 可能被几千个订阅同时命中，需要高效地做匹配和推送。
过滤条件复杂：Nostr 的订阅过滤器支持按作者、按事件类型、按时间范围、按 tag 组合查询，还要支持多条件 OR，匹配逻辑不能太慢。
写入频繁且需要去重：同一条 event 可能从多个客户端重复发来，relay 必须按 event id 去重，否则存储会被迅速撑爆。

这四点叠加起来，对语言和运行时提出了很明确的要求：低延迟、高并发、内存可控、GC 停顿不能有。Rust 没有 GC，异步任务由 tokio 调度，单机扛几万连接在合理配置下是能做到的。这就是为什么现在新写的 relay 越来越多选择 Rust，而不是 Node 或 Python。

2.2 buzz 的技术选型拆解

虽然 buzz 的具体代码结构会随版本演进，但从它公开的设计取向和 Nostr relay 的通用实践来看，它的技术栈基本可以确定是这么一套：

组件	选型	选择理由
异步运行时	tokio	Rust 生态事实标准，多线程调度器成熟，定时器、IO、channel 一应俱全
WebSocket 层	axum + tokio-tungstenite	axum 的 ws 支持足够用，和 tokio 集成自然，路由清晰
序列化	serde + serde_json	Nostr event 是 JSON 格式，serde 是唯一合理选择
存储	SQLite（默认）/ Postgres	轻量部署用 SQLite，规模化用 Postgres，抽象层隔离
密码学	secp256k1 / k256	验证 event 签名，schnorr 签名是 Nostr 的标准
配置	环境变量 + TOML	部署友好，容器化方便

这里我想重点说一下为什么存储层要做抽象。很多新手写 relay 的时候直接硬编码 SQLite，结果一上量就发现单文件数据库在并发写入时锁竞争严重。buzz 这类项目通常会把存储抽象成一个 trait，SQLite 和 Postgres 各实现一份，部署时按规模切换。这个设计决策的价值在于：小规模自部署用 SQLite 零依赖，大规模托管用 Postgres 扛并发，代码不用改。

2.3 AI agents 这个方向意味着什么

热搜词里出现 AI agents 不是偶然的。Nostr 协议天然适合 agent 场景，原因有几个：

第一，身份即密钥。一个 AI agent 可以拥有自己的 Nostr 密钥对，它发的每一条消息都是签名过的，可验证来源，不需要中心化的账号体系。

第二，relay 是天然的通信总线。多个 agent 之间要协作，不需要自己搭消息队列，直接通过 relay 收发 event 就行，订阅过滤器就是天然的路由规则。

第三，事件类型可扩展。Nostr 的 event kind 是一个整数，社区已经定义了几百种 kind，agent 之间完全可以用自定义 kind 来传递结构化指令。

所以 buzz 往 AI agents 方向走，逻辑上是顺的：它不只是一个给人用的社交 relay，还可以作为 agent 之间通信的基础设施。这个延展让项目的想象空间大了很多，也是它区别于普通 relay 实现的地方。

3. 核心细节解析：relay 内部到底在干什么

3.1 event 的生命周期与验证链路

一条 event 从客户端发出到被 relay 接受，中间要过好几道关。我把这条链路完整列一下，这是理解任何 relay 的基础：

WebSocket 帧到达：axum 的 ws handler 收到一个 Text 帧，内容是 JSON 数组，形如["EVENT", {...event...}]。
JSON 解析：serde 把 JSON 反序列化成 Event 结构体。这一步要注意，字段缺失或类型不对要直接拒绝，不能 panic。
结构校验：检查必填字段（id、pubkey、created_at、kind、tags、content、sig）是否齐全，id 是否是 64 位 hex，pubkey 是否是 64 位 hex。
id 校验：event id 是序列化后的[0, pubkey, created_at, kind, tags, content]做 SHA256 得到的。必须重新计算一遍，和客户端给的 id 对比，不一致直接拒。
签名校验：用 pubkey 验证 sig 对 id 的 schnorr 签名。这一步是 CPU 密集的，secp256k1 验签大概几十微秒，高并发下要考虑批量化或缓存。
时间戳校验：created_at 不能太离谱（比如未来时间或太古老的时间），通常允许一定偏差。
去重检查：按 id 查存储，如果已存在，直接返回成功（幂等），不重复写。
策略检查：是否被 ban、内容是否违规、是否超过速率限制。
持久化：写入存储层。
广播：把 event 推给所有匹配的活跃订阅。

这十步里，第 4、5 步是最容易被忽略但最关键的。我见过一些简易 relay 直接信任客户端传来的 id，不重新计算，结果就是攻击者可以伪造 id 让去重逻辑失效，或者用无效签名污染数据库。buzz 这类正经实现一定会做完整校验。

3.2 订阅过滤器的匹配逻辑

Nostr 的订阅过滤器（filter）是一个 JSON 对象，字段包括ids、authors、kinds、since、until、limit，以及任意#<tag>形式的 tag 过滤。一个订阅可以带多个 filter，它们之间是 OR 关系；单个 filter 内部的多个字段是 AND 关系。

举个例子：

["REQ", "sub1", {"authors": ["abc..."], "kinds": [1], "since": 1700000000}, {"kinds": [7], "#e": ["def..."]} ]

这个订阅的意思是：要么是作者 abc 发的 kind 1 笔记且时间在 1700000000 之后，要么是引用了事件 def 的 kind 7 反应。两条规则任意命中一条就要推送。

匹配逻辑的实现要点：

提前编译过滤器：不要每次来 event 都重新解析 JSON，应该在 REQ 到达时就把 filter 解析成内部结构，甚至预计算一些索引。
tag 过滤要小心：#e、#p这类 tag 过滤是最耗时的，因为要遍历 event 的 tags 数组。可以用 HashMap 加速，但要注意一个 tag 名可能对应多个值。
limit 的语义：limit 限制的是"返回的历史事件数量"，不是"未来推送的数量"。很多实现会搞混这一点。

3.3 存储层的设计取舍

存储层是 relay 性能的分水岭。我把它拆成几个关键决策点：

决策一：用什么做索引。最常查的维度是 pubkey、kind、created_at、以及 tag。SQLite 下至少要建这几个索引：

CREATE INDEX idx_events_pubkey ON events(pubkey); CREATE INDEX idx_events_kind ON events(kind); CREATE INDEX idx_events_created_at ON events(created_at); CREATE INDEX idx_events_pubkey_kind ON events(pubkey, kind);

tag 的索引比较麻烦，因为一个 event 有多个 tag。常见做法是单独建一张 tag 表，(event_id, tag_name, tag_value)三列，然后在这三列上建索引。

决策二：要不要做软删除。Nostr 支持删除事件（kind 5），但删除的语义是"请求 relay 删除"，不是强制。实现上通常是标记删除而不是物理删除，保留审计能力。

决策三：过期事件怎么处理。有些 event 带 expiration tag，到期后应该被清理。这需要一个后台任务定期扫描，不能靠查询时过滤，否则表会无限膨胀。

提示：如果你只是自己跑一个小 relay 玩，SQLite 完全够用，但一定要开 WAL 模式（PRAGMA journal_mode=WAL），否则并发读写会互相阻塞，性能差一个数量级。

3.4 连接管理与限流

WebSocket 长连接的管理是另一个重点。每个连接需要维护：

连接本身的读写任务
该连接上所有活跃订阅的列表
该连接的速率统计（用于限流）
心跳状态（ping/pong）

限流这块，我的经验是要分维度做：

维度	限制对象	典型阈值
连接数	单 IP	10-50
事件写入	单连接	10-50 条/秒
订阅数	单连接	20-100
消息大小	单帧	64KB-256KB
请求频率	单 IP	100-500 次/分钟

阈值不是拍脑袋定的，要根据你的机器配置和实际流量调。我一般先用保守值上线，观察一周再放宽。

4. 实操部署：从零把 buzz 跑起来

4.1 环境准备与 Rust 工具链

先把 Rust 环境搭好。如果你还没装，官方推荐用 rustup：

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh source $HOME/.cargo/env rustc --version cargo --version

国内网络环境下，cargo 拉依赖会比较慢，建议配置镜像源。编辑~/.cargo/config.toml：

[source.crates-io] replace-with = 'ustc' [source.ustc] registry = "sparse+https://mirrors.ustc.edu.cn/crates.io-index/"

这个配置能显著加快依赖下载。我实测下来，首次构建一个中等规模的 Rust 项目，配了镜像之后从十几分钟降到两三分钟。

开发环境方面，VS Code 装 rust-analyzer 插件是标配，它能给你实时的类型提示、跳转、重构。如果你习惯 JetBrains 系，CLion 加 Rust 插件也不错，但资源占用高一些。至于"IDEA 未来会不会用 Rust 重写"这种问题，我的看法是短期内不会，但 JetBrains 确实在把越来越多的底层组件用 Rust 重写，比如他们的终端和部分索引逻辑。

4.2 获取源码与依赖构建

假设你已经拿到了 buzz 的源码，进入项目目录后：

cd buzz cargo build --release

这里有几个实操要点：

一定要用--release。debug 构建的 Rust 代码性能可能只有 release 的十分之一，跑 relay 完全不够用。
首次构建会很久。tokio、axum、secp256k1 这些依赖编译起来很费时间，耐心等。
如果编译报错找不到系统库，通常是 secp256k1 需要 C 编译器，装一下build-essential（Debian 系）或xcode-select --install（macOS）。

构建完成后，二进制在target/release/下。

4.3 配置文件详解

buzz 这类 relay 的配置通常通过环境变量或 TOML 文件。我以常见的配置项为例说明每一项的作用：

[server] host = "0.0.0.0" port = 8080 max_connections = 10000 [database] backend = "sqlite" path = "./data/buzz.db" max_connections = 10 [limits] max_event_size = 65536 max_subscriptions_per_connection = 50 event_rate_limit = 20 [policy] require_auth = false allowed_kinds = [] blocked_pubkeys = []

逐项解释：

host = "0.0.0.0"表示监听所有网卡。如果你只想本机访问，改成127.0.0.1。
max_connections要根据你的文件描述符上限来定。Linux 默认单进程 1024，跑 relay 一定要调高：ulimit -n 65535。
backend选 sqlite 还是 postgres，取决于规模。个人用 sqlite，公开服务用 postgres。
event_rate_limit是单连接每秒允许写入的事件数，20 是个比较温和的值。
require_auth打开后，客户端需要先做 NIP-42 认证才能写入，能挡掉大量垃圾。

注意：blocked_pubkeys这种黑名单机制只能挡君子，挡不住批量注册新密钥的垃圾发送者。真正有效的是基于 IP 的限流和内容过滤。

4.4 启动与验证

配置好后启动：

RUST_LOG=info ./target/release/buzz

RUST_LOG控制日志级别，调试时可以用debug，生产环境用info或warn。

验证 relay 是否正常，最直接的办法是用一个 Nostr 客户端连上去发一条测试事件。命令行下可以用nak这个工具：

nak event --sec <你的私钥> -c "hello buzz" ws://localhost:8080

如果返回 event id，说明写入成功。再订阅一下：

nak req -k 1 --limit 5 ws://localhost:8080

能看到刚才发的事件，说明读写链路都通了。

4.5 反向代理与 TLS

生产环境一定要放在反向代理后面，用 Nginx 或 Caddy 处理 TLS。Nginx 配置示例：

location / { proxy_pass http://127.0.0.1:8080; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $host; proxy_read_timeout 3600s; proxy_send_timeout 3600s; }

关键点是Upgrade和Connection头必须透传，否则 WebSocket 握手会失败。proxy_read_timeout要设长，因为 WebSocket 是长连接，默认 60 秒会被切断。

5. 常见问题与排查技巧实录

5.1 连接建立失败

现象：客户端连不上，报 WebSocket 握手失败。

排查顺序：

确认 relay 进程在跑：ps aux | grep buzz
确认端口在监听：ss -tlnp | grep 8080
确认防火墙放行：ufw status或iptables -L
如果走了反向代理，检查Upgrade头是否透传
检查 TLS 证书是否有效

我遇到最多的情况是反向代理没配 WebSocket 升级头，客户端一直卡在握手阶段。

5.2 事件写入被拒

现象：客户端发事件，relay 返回["OK", id, false, "blocked: ..."]。

常见原因和对应处理：

错误信息	原因	处理
`invalid: bad signature`	签名校验失败	检查客户端密钥和签名逻辑
`invalid: id mismatch`	id 和内容不匹配	客户端重新计算 id
`blocked: rate limited`	触发限流	降低发送频率或调高阈值
`blocked: pubkey banned`	在黑名单	从黑名单移除或换密钥
`error: database`	存储层出错	查数据库日志，检查磁盘空间

5.3 性能瓶颈定位

relay 跑起来之后变慢，怎么定位？我的经验是按这个顺序查：

第一步，看 CPU。top看 buzz 进程的 CPU 占用。如果单核跑满，说明有 CPU 密集操作，通常是签名验证或 JSON 解析。可以考虑把验签放到单独的线程池，或者用多核并行。

第二步，看内存。如果内存持续增长不降，大概率是订阅列表或连接状态泄漏。检查是否有连接断开后没清理订阅的情况。

第三步，看数据库。SQLite 下用PRAGMA journal_mode确认是 WAL 模式。Postgres 下看慢查询日志，检查索引是否命中。

第四步，看网络。ss -s看连接数，iftop看带宽。如果带宽跑满，说明扇出太大，要考虑限制单条事件的推送范围。

5.4 数据库膨胀

现象：数据库文件几个月涨到几十 GB。

原因通常是垃圾事件堆积。处理办法：

定期清理过期事件（带 expiration tag 的）
对高频发送者的历史事件做归档
开启内容过滤，拒绝明显的垃圾
设置单 pubkey 的事件数量上限

我自己的 relay 上跑了一个定时任务，每天凌晨清理一次超过 90 天的非关注列表事件，效果很明显，数据库稳定在几 GB。

5.5 与 AI agents 集成时的坑

如果你要把 buzz 作为 agent 通信总线，有几个坑要提前知道：

坑一：agent 的密钥管理。agent 的私钥不能硬编码在代码里，要用环境变量或密钥管理服务。一旦泄露，别人就能冒充你的 agent 发消息。

坑二：事件顺序不保证。relay 不保证事件按 created_at 严格有序到达，agent 处理消息时要自己做排序或幂等。

坑三：订阅过滤器的表达力有限。Nostr 的 filter 不支持复杂的逻辑组合，agent 之间如果要传递结构化指令，通常要把指令编码进 content，然后在 agent 侧解析。

坑四：relay 可能丢事件。不是所有 relay 都保证持久化，agent 之间的关键指令最好发到多个 relay，或者用带确认的协议。

6. 我个人的一些实操心得

跑 relay 这件事，我从最早的 Python 简易实现，到 Go 版本，再到现在的 Rust 版本，前后折腾了大概两年。最大的体会是：relay 的难点从来不在协议本身，而在工程细节。协议就那几种消息类型，半天就能读完，但要让它在真实流量下稳定运行，需要处理的边界情况非常多。

Rust 在这个场景下的价值，我总结成三点。第一是编译期帮你挡并发 bug，Send/Sync 约束让很多数据竞争在编译阶段就暴露。第二是性能可预测，没有 GC 停顿，延迟曲线很平。第三是生态成熟，tokio + axum + serde 这套组合的文档和示例足够多，遇到问题基本都能搜到答案。

如果你刚开始学 Rust，想找个项目练手，我强烈建议从写一个最小 relay 开始。不需要一上来就做完整实现，先做到能接收 event、能存、能按 pubkey 查，跑通之后再逐步加签名验证、订阅过滤、限流。这个过程会让你对 Rust 的异步编程、错误处理、trait 抽象有非常具体的理解，比看十篇教程都管用。

最后分享一个小技巧：调试 relay 的时候，把RUST_LOG设成buzz=trace,tokio=warn，这样只输出你自己代码的详细日志，不会被 tokio 的内部日志淹没。这个配置帮我省了大量翻日志的时间。