Rust 重写 Nostr 中继：高并发长连接服务实战

1. 从“buzz”说起一个用 Rust 重写的 Nostr 中继到底在折腾什么第一次看到 “buzz” 这个项目名我脑子里蹦出来的其实是两件事一是那个做演示文稿的旧工具二是“嗡嗡作响”的噪音感。但把关键词 Nostr、relay、Rust、git 摆在一起之后方向就很清楚了——这是一个用 Rust 写的 Nostr 中继relay实现。Nostr 这两年热度一直不低核心思路是把社交数据的存储和分发从单一平台手里拿出来交给一堆互相独立的中继节点客户端通过 WebSocket 跟这些中继打交道事件event用公私钥签名谁也无法替别人伪造发言。而 relay 就是这套体系里的“服务器”负责接收事件、校验签名、按规则存储、再转发给订阅的客户端。那为什么还要再造一个 relay市面上已经有基于 Go、Node.js、Python 的各种实现功能也都能跑。我个人的判断是buzz 这类项目的价值不在“又一个 relay”而在于用 Rust 把性能、内存安全和并发模型这三件事同时抓住。Nostr 中继本质上是一个高并发、长连接、大量小消息读写的服务天然适合 Rust 的异步生态。你如果正在学 Rust又不想只写些命令行小工具练手那拿一个 relay 项目来啃是非常合适的——它同时覆盖了网络编程、序列化、数据库、密码学校验、并发控制这些真实工程里绕不开的模块。这篇文章我就按一个实际动手复现的视角把 buzz 这类 Rust Nostr relay 的设计思路、核心实现、踩坑经验完整拆一遍适合已经会一点 Rust 基础、想往实战走的人也适合做后端、对高并发长连接服务感兴趣的朋友参考。2. 整体设计与技术选型为什么是 Rust Nostr 这套组合2.1 为什么 relay 这种服务特别适合 Rust先讲清楚 relay 的工作特征。一个中继节点要同时维持成千上万条 WebSocket 长连接每条连接随时可能推来一个事件也可能发起一个订阅请求。事件本身是 JSON里面有签名、公钥、时间戳、标签、内容。服务端要做的事包括解析 JSON、验证签名、按过滤条件匹配订阅、写库、把匹配的事件推给对应连接。这套流程里CPU 密集的部分是签名验证secp256k1 椭圆曲线运算IO 密集的部分是网络收发和数据库读写。Rust 在这里的优势很直接。第一没有 GC长连接场景下不会因为垃圾回收造成周期性延迟抖动这对推送实时性要求高的场景很关键。第二所有权模型让并发下的数据共享变得可控你不会像在某些语言里那样一个连接对象被两个线程同时改还浑然不觉。第三tokio 这套异步运行时已经非常成熟处理海量连接是它的主场。我实测过一个粗糙的 Rust relay 在单机上维持几万条空闲连接内存占用比同等 Node.js 实现低一个量级这不是玄学是运行时模型的差异。2.2 Nostr 协议里 relay 的职责边界很多人一开始会误解 relay 的角色以为它像传统后端一样要管用户、管权限、管业务逻辑。其实 Nostr 的设计哲学是“哑中继 聪明客户端”。relay 不负责身份认证体系它只认签名不负责内容审核的复杂策略最多做关键词过滤或白名单不负责社交关系关系都写在事件里。relay 要做好的就是三件事可靠地收、正确地验、高效地发。这个边界划清楚之后实现难度其实下降了不少。你不需要设计用户表、会话表事件表就是核心。但反过来正因为 relay 简单它对“简单事情做到极致”的要求就更高——签名验证慢一点、广播效率低一点在几万连接下就会被放大成灾难。这也是为什么用 Rust 重写有意义把每个环节的开销压到最低。2.3 技术栈的取舍tokio、serde、secp256k1、sqlite/postgres基于常见实践这类 Rust relay 的依赖组合大致是这样模块常见选型选择理由异步运行时tokio生态最全WebSocket、TCP、定时器都有现成支持WebSockettokio-tungstenite轻量、和 tokio 无缝配合JSON 序列化serde serde_jsonRust 事实标准派生宏写起来省事签名验证secp256k1 或 k256前者是 C 库绑定性能好后者纯 Rust 更易移植存储sqlite单机/ postgres集群单机 relay 用 sqlite 足够省运维日志tracing tracing-subscriber结构化日志排查长连接问题必备这里有个取舍点值得说secp256k1 的 C 绑定版本性能确实好但交叉编译和部署时会遇到链接库的问题k256 是纯 Rust编译干净性能差距在多数场景下可以接受。我个人的建议是如果你只是自己跑着玩或者做原型用 k256 省心如果要压榨性能上生产再换 secp256k1。这个决定不用一开始就纠结接口抽象好后面替换成本很低。3. 核心细节拆解事件模型、签名校验与订阅匹配3.1 Nostr 事件结构到底长什么样要写 relay先把事件结构吃透。一个 Nostr 事件本质上是一个 JSON 对象核心字段包括id事件内容的 SHA256 哈希用来唯一标识pubkey发布者公钥created_at创建时间戳秒kind事件类型比如 0 是元数据、1 是文本笔记、3 是关注列表tags标签数组用来做引用、话题、回复关系content正文内容sig对 id 的签名关键在于id的计算方式它不是随便生成的而是把[0, pubkey, created_at, kind, tags, content]这个数组做规范化 JSON 序列化之后取 SHA256。这个细节极其重要因为客户端和服务端必须用完全一致的序列化规则否则算出来的 id 对不上签名验证就会失败。我踩过的坑就在这里JSON 里数字的表示、字符串转义、数组顺序任何一点差异都会导致哈希不同。所以 relay 里做校验时不能直接拿收到的 JSON 重新序列化而要严格按照协议规定的字段顺序和格式重建。3.2 签名验证为什么是性能瓶颈签名验证用的是 secp256k1 的 Schnorr 签名Nostr 用的是 BIP340 那套。每次收到事件都要验一次这是 CPU 密集操作。单次验证大概在几十微秒到上百微秒量级听起来不多但如果你每秒收到几千个事件累加起来就很可观了。优化思路有几个。第一把验证放到独立的线程池里别阻塞 tokio 的异步任务因为签名验证是同步 CPU 操作直接在 async 任务里跑会占住 worker 线程。第二做批量验证secp256k1 库支持一次验多个签名能摊薄固定开销。第三对已经验证过的事件做缓存同一个 id 重复收到时直接跳过验证。第三点在真实网络里很有用因为事件会在多个 relay 之间转发重复是常态。注意缓存验证结果时一定要以事件 id 为键并且设置合理的过期时间。别用 pubkey 做键那会漏掉同一用户的不同事件。3.3 订阅过滤条件怎么匹配才高效客户端连上来之后会发REQ消息带一组过滤条件比如“我要 kind1 且 tag 里包含某个话题、时间在某个范围之后的事件”。relay 要维护每个连接的订阅列表新事件进来时逐个匹配。朴素做法是每个事件遍历所有订阅逐个字段比对。连接少的时候没问题连接一多就是 O(事件数 × 订阅数)很快就顶不住。更合理的做法是给订阅建索引按 kind 分组、按 tag 建倒排、按时间做范围查询。实际实现里我倾向于把过滤条件下推到数据库查询层用 SQL 的 WHERE 条件去筛而不是全量拉出来在内存里过滤。sqlite 加好索引之后按 kind 和时间范围查事件是很快的。但这里有个矛盾实时推送要求低延迟如果每个事件都去查一遍数据库再决定推给谁延迟和数据库压力都上来了。折中方案是维护一个内存里的“活跃订阅索引”只针对最近的事件做内存匹配历史查询才走数据库。这个分层设计是这类 relay 性能的关键。4. 实操过程从零把 buzz 这类 relay 跑起来4.1 环境准备Rust 工具链和 git 的正确姿势先把地基打好。Rust 安装推荐用 rustup这是官方工具链管理器能方便地切换版本和组件。装完之后rustc --version和cargo --version都要能正常输出。国内网络环境下cargo 拉依赖慢是常见问题配置镜像源能明显提速。在~/.cargo/config.toml里加上镜像配置即可具体地址用你信任的源。git 这块很多人卡在几个经典问题上。第一个是fatal: not a git repository这通常是你不在仓库目录里执行 git 命令先cd到正确目录或者确认.git目录存在。第二个是 SSH 认证失败检查公钥有没有加到对应平台、ssh -T测试连通性。第三个是 Windows 上提示“无法将 git 项识别为 cmdlet”说明 git 没加进 PATH重装时勾选“添加到 PATH”或者手动配置环境变量。克隆项目就是标准流程git clone 仓库地址 cd buzz cargo build --release--release别省debug 模式下签名验证和网络处理的性能差好几倍测性能必须用 release。4.2 配置项与启动参数怎么定一个 relay 的配置通常包括监听地址和端口、数据库路径、最大连接数、单连接订阅数上限、事件大小上限、是否开启某些 kind 的写入。这些参数不是拍脑袋定的背后都有考量。监听端口默认常见是 8080 或 7000 段选哪个看你部署环境别和已有服务冲突。数据库路径要放在有写权限、磁盘空间充足的地方事件是只增不减的长期跑要留意磁盘。最大连接数要结合文件描述符上限来定Linux 下默认单进程能开的 fd 有限连接数上万就得调ulimit -n。事件大小上限是防滥用的正常文本笔记几 KB设个 64KB 或 128KB 足够太大容易被人塞垃圾数据。启动命令大致是./target/release/buzz --config config.toml或者用环境变量覆盖配置这在容器化部署时更方便。4.3 用客户端验证 relay 是否正常工作relay 跑起来之后别急着上生产先用客户端连一下。可以用现成的 Nostr 客户端把中继地址填进去发一条测试笔记看能不能发出去、能不能被订阅到。这一步能验证 WebSocket 连接、事件接收、签名校验、存储、广播整条链路。如果客户端连不上先看 relay 日志有没有连接建立记录。如果连上了但发事件没反应看日志里有没有签名校验失败的报错。如果发出去了但订阅不到检查订阅过滤条件是不是写得太窄。我一般会准备一个最小化的测试脚本直接发原始 WebSocket 消息这样能排除客户端本身的干扰定位问题更准。5. 常见问题与排查技巧实录5.1 连接建立后立刻断开这是最常见的现象之一。原因通常有几类一是 WebSocket 握手阶段协议不匹配比如客户端要求某个子协议而服务端没支持二是消息格式不对服务端解析失败直接关连接三是触发了限流或黑名单。排查时先看服务端日志的关闭原因再抓一下握手阶段的 HTTP 头。我遇到过因为消息里带了非法 UTF-8 导致解析 panic 的情况后来在解析层加了容错才解决。5.2 事件发出去但别人收不到这多半是广播逻辑的问题。检查订阅匹配是不是漏了尤其是 tag 匹配Nostr 的 tag 是数组的数组匹配规则容易写错。还有一种情况是事件写库成功但广播队列满了被丢弃高并发下要留意广播通道的容量和背压策略。我建议给广播加个监控指标统计丢弃数量一旦非零就说明容量不够。5.3 数据库写入成为瓶颈sqlite 单文件写入在高并发下会成为瓶颈因为写是串行的。优化手段包括开启 WAL 模式提升并发读、批量提交事务减少 fsync 次数、把不重要的 kind 异步落盘。如果单机实在扛不住就得上 postgres但运维复杂度也上来了。我的经验是单机 relay 用 sqlite WAL 批量写撑住中等规模完全没问题别过早引入分布式存储。5.4 内存持续增长长连接服务最怕内存泄漏。常见原因是订阅列表没清理、连接断开后相关资源没释放、事件缓存无上限。排查时用tokio-console看任务数量用系统工具看内存曲线。我踩过的坑是订阅索引里存了连接句柄的强引用连接断了但索引没删导致连接对象无法回收。改成弱引用或者显式清理就好了。问题现象可能原因排查方向连接秒断握手失败/消息格式错看关闭码和日志事件不广播订阅匹配错/队列满查匹配逻辑和通道容量写入慢sqlite 串行写开 WAL、批量提交内存涨资源未释放查订阅索引和缓存上限6. 我在这类项目里攒下的几条实操心得第一条别一上来就追求功能全。先把“收事件、验签名、存下来、能订阅”这条最小闭环跑通再逐步加过滤、加限流、加监控。我见过太多人一开始就设计复杂的插件系统结果核心链路还没稳。第二条日志要结构化别用 println。长连接服务出问题时你需要按连接 id、事件 id 去检索结构化日志配合 tracing 能省大量时间。第三条压测要趁早。用脚本模拟几百上千个连接同时发事件观察 CPU、内存、延迟曲线很多问题只有压出来才暴露。别等上线了才发现广播通道容量不够。第四条签名验证的线程池大小要调。默认配置不一定适合你的机器根据 CPU 核数和事件速率去压测找最优值这个参数对吞吐影响很大。第五条git 提交习惯要好。这类项目迭代快用清晰的分支和 commit 信息出问题回滚和定位都方便。git commit --amend改最近一次提交、git worktree同时开多个分支干活这些命令用熟了效率提升明显。这套东西跑通之后你对 Rust 异步编程、网络服务、密码学校验的理解会上一个台阶。后面想扩展的话可以加 NIP 支持、加管理接口、加多节点同步路子很宽。