当我们谈论 AT Protocol（Bluesky 的底层协议）时，大多数文章聚焦于社交图谱迁移或个人数据主权。但如果将视角切换到音乐消费场景，一个截然不同的问题空间浮现出来：如何在去中心化架构下补全播放记录、同步多端偏好、并让朋友的听歌历史成为一个可订阅的实时流？Rocksky 这个开源项目正是这一方向的实践 —— 它本质上是一个构建在 AT Protocol 之上的 Last.fm 替代方案。本文从工程维度拆解其架构设计，提供可落地到具体实现的参数与决策框架。
为什么音乐场景需要自己的 AT Protocol 扩展
Last.fm 的核心价值在于两点：补全（scrobbling）—— 记录用户在任意播放器中消费的每一首曲目，以及社交发现—— 通过朋友的听歌历史找到新音乐。传统实现将这两点绑定在一个中心化数据库中，用户无法导出完整的播放历史，第三方播放器必须调用 Last.fm 的封闭 API 才能参与补全。
AT Protocol 提供了一个天然适合重建这两点的基础设施：记录（Records）模型天然可以表达「用户在某时刻听了某首歌」这一事件；订阅（Subscribe）机制可以代替轮询好友的最近播放。然而音乐场景的特殊性在于数据量与实时性：一个重度用户每天可能产生数十条 scrobble，且「Now Playing」状态需要近实时同步。这要求架构在保持去中心化优势的同时，引入足够高效的缓存与分析层。
Rocksky 的核心设计选择是将 AT Protocol 作为数据发布层而非唯一存储层 —— 即先用专用数据库保证读写效率，再用 AT Protocol 的 Records 实现数据可移植性与社交分发。这一分层策略是理解整个系统的关键。
PDS 集成：谁持有你的播放历史
AT Protocol 的核心实体是 PDS（Personal Data Server）—— 每个用户在 Bluesky 网络中都有一个自己的 PDS，负责存储其发布的记录。对于 Rocksky 而言，这里出现一个架构决策点：播放历史应该存在用户自己的 PDS 中，还是存在 Rocksky 的服务层？
Rocksky 选择了后者，将 AT Protocol 作为事件发布与社交分发的通道，而非主存储。具体来说，Rocksky 的 scrobble 数据通过以下路径流动：用户播放器 → Rocksky API → Xata（PostgreSQL）主存储 → AT Protocol Records 发布 → 朋友可订阅的实时流。这条路径意味着用户拥有数据的双重副本—— 自己 PDS 中的 AT Protocol 记录是公开可验证的起源，而 Rocksky 的数据库是高性能读写的业务层。
这种设计的权衡在于：它牺牲了完全去中心化（你仍需信任 Rocksky 作为服务层），但换来了分析能力（DuckDB 在内存中聚合趋势）和实时性能（DragonflyDB 缓存 Now Playing 状态）。对于大多数用户而言，这一权衡是合理的 —— 真正的问题是 Rocksky 是否提供了数据导出接口，使其在服务不可用时仍能迁移到自托管实例。
Rockbox Fork：嵌入式播放器的 scrobble 发送机制
Rocksky 项目中技术含量最高的组件之一是其自定义的 Rockbox fork。Rockbox 是一个开源固件，运行在数百款 MP3 播放器上，赋予用户对播放行为的完全控制。Tsiry 修改了 Rockbox 的核心库，使其在每首曲目播放结束时自动向 Rocksky API 发送 scrobble 事件。
这一实现的技术细节值得展开：修改针对 lib.rs 中的播放状态监控逻辑，在曲目切换事件触发时提取元数据（艺术家、曲名、专辑、时长），组装为 Rocksky API 接受的 JSON payload，经 HTTPS POST 发送。payload 包含 artist、track、album、timestamp（Unix 时间戳）以及 mbid（MusicBrainz ID，如果可用）。这意味着 scrobble 的准确性直接取决于 Rockbox 能否正确读取文件的 ID3 标签 —— 对于大量流式获取、缺乏完整标签的音频文件，这可能是一个数据质量问题。
Rockbox fork 的价值在于它为本地播放器生态提供了一个不受制于平台限制的 scrobble 路径。用户无需依赖 Spotify 或 Apple Music 的官方集成，即可将任何播放源接入 Rocksky。对于自托管爱好者而言，这是最有吸引力的差异化特性。
客户端订阅同步：状态机与冲突处理
Rocksky 的客户端（Android 应用已上架 Google Play）需要处理两类同步任务：历史归档（将 Rocksky 服务端的历史拉取到本地缓存）和实时订阅（监听朋友的新 scrobble 并更新关注列表）。
同步逻辑实现为一个有限状态机，包含 idle、syncing、conflict-resolution、error 四个核心状态。当客户端进入 syncing 状态时，它先从 DragonflyDB 缓存获取本地未同步的时间窗口（通常为最近 24 小时），然后按时间倒序从 Rocksky API 拉取该窗口内的 scrobble 记录。每次拉取完成后，客户端更新本地 SQLite 数据库的 last_sync_cursor，服务端在下次请求中根据该 cursor 返回增量数据。
冲突处理是这里的关键工程问题。当用户在多端同时播放音乐时，同一时刻可能产生多条指向不同曲目的 scrobble。Rocksky 采用了服务端时间戳优先策略：无论客户端何时发送，服务端以接收时间为准记录，同一用户在同一秒内的多条 scrobble 会被合并（保留最早到达的那条）。客户端在本地使用乐观锁 —— 每次写入本地数据库时附上版本号，若版本冲突则回退到从服务端重新拉取。
可操作参数与监控清单
将上述架构落地到具体工程实现，以下参数值得在部署时逐一确认：
存储层容量规划：Xata PostgreSQL 每条 scrobble 记录约占用 200–300 字节（含索引），一个活跃用户年均产生约 5000 条记录，一年占用约 1.5 MB 存储。按 1 万活跃用户计算，年存储增长约 15 GB。DuckDB 分析库在内存中保留最近 30 天的聚合数据，超出窗口的数据需落盘至 Xata。
Now Playing 同步延迟：Spotify Watcher 微服务（Rust）轮询 Spotify Web API 的当前播放端点，轮询间隔建议设置为 15 秒。过短的间隔可能触发 Spotify 的速率限制（429 Too Many Requests），过长的间隔则导致「正在播放」状态的可见延迟。
AT Protocol 记录发布频率：每条 scrobble 作为一条 AT Protocol Record 发布，会产生对用户 PDS 的写操作。建议在服务端侧做批量写入缓冲 —— 每 30 秒或累积 10 条未发布记录时批量提交一次，以降低 PDS 写入频率。这不影响用户的实时「朋友动态」更新（该功能通过服务端的推拉机制实现，而非依赖 PDS 的实时推送）。
数据导出与迁移路径：Rocksky API 提供 /export 端点，支持以 JSON 格式导出用户的完整播放历史。迁移脚本应每 6 个月执行一次完整导出，存储至用户可控的 S3 兼容存储桶中。导出格式应包含 timestamp、artist、track、album、source（播放来源）五项字段。
监控关键指标：scrobble 接收成功率（目标 > 99.5%，通过 API 层统计 4xx/5xx 响应码），P99 写入延迟（目标 < 500ms），AT Protocol 记录发布延迟（目标 < 5 秒），以及 Rockbox fork 的设备覆盖率（当前社区贡献者有限，是潜在的单点风险）。
局限性边界：什么场景不适合 Rocksky
任何架构都有其边界。Rocksky 依赖 Rocksky 服务端作为中间层的事实，意味着它并非完全去中心化的音乐追踪方案 —— 如果 Rocksky 停止运营，用户失去的不只是服务，还有所有尚未手动导出的播放历史。此外，Rockbox fork 的维护依赖社区贡献，当前支持的设备型号有限，且修改固件这一操作对普通用户存在一定门槛。
从数据质量角度，Rocksky 的 scrobble 精度受制于播放器元数据完整性 —— 对于播客、有声书或缺少 ID3 标签的流媒体文件，「艺术家」和「曲名」字段可能为空，导致社交发现功能失效。在这些场景下，传统的 Last.fm 生态仍有优势。
回到 AT Protocol 的核心承诺：用户应该拥有自己的数据，且数据可以在服务之间流动。Rocksky 在这一点上走出了有价值的探索 —— 它用专用存储换取性能，用 AT Protocol 换取可移植性。对于愿意折腾 Rockbox 固件、关注数据主权的音乐爱好者，这套架构值得深入研究；而对于寻求开箱即用体验的用户，现有生态的成熟度仍是制约因素。
资料来源
- Tsiry Sandratraina，「How I Built My Own Last.fm Clone on Bluesky's AT Protocol — Join the Beta!」，dev.to，2025 年 3 月。
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。