Discourse 中 GIF 重复导致备份失败

一个 GIF 文件如何导致 Discourse 备份失败

在 Discourse 平台的一个论坛备份过程中，发生了一起异常事件：同一个 1.6 MB 的 GIF 文件被复制了 246,173 次。这导致备份大小膨胀了 377 GB，损坏了 Linux 文件系统，并完全崩溃了备份进程。问题并非代码 bug，而是平台的セキュリティ架构以及 ext4 文件系统的限制。

为什么一个文件变成了数十万份副本

Discourse 使用“安全上传”机制，每次文件在不同上下文中移动（例如，从私信到公开帖子）时，系统都会创建一个带有唯一 SHA1 哈希的新副本。尽管文件内容完全相同，平台仍将其视为独立对象。这是为了强制执行安全策略，防止未经授权访问媒体文件。

在这次事件中，一张热门 GIF——电视剧《老友记》中跳舞的 Rachel——被用户反复插入各种主题、评论和私信中。每次在新上下文中使用，都会生成新的数据库条目和磁盘上的新文件，尽管二进制内容完全相同。

首次优化尝试：硬链接

Discourse 团队开发了一种基于备份时按内容哈希分组文件的解决方案。对于每组重复文件，只保留一个物理副本，其余用硬链接替换。这种方法大幅缩小了备份大小，并在大多数实例上运行良好。

然而，在一个大型客户论坛上的测试显示，ext4 文件系统存在限制：每个 inode 最多支持约 65,000 个硬链接。面对 246,173 个副本，一旦达到上限，系统就开始创建新的物理副本——不是作为重复文件，而是独立文件。最终，除了一个副本外，又多了约 181,000 个文件，这仅部分解决了问题。

最终解决方案：链接与副本的动态切换

新解决方案考虑了文件系统限制，并具有通用性：

• 系统首先像之前一样创建硬链接。
• 当收到 Linux 内核的 EMLINK 错误（“链接过多”）时，进程切换到本地文件复制。
• 新副本成为后续链接的“主”副本，并在达到下一个上限时重复此循环。

这种方法无需调整文件系统，兼容任何符合 POSIX 标准的操作系统，即使面对极端重复数量也能有效缩小备份大小。

示例处理逻辑（简化版）：

if hard_link_fails_with_emlink?
  create_new_physical_copy
  reset_link_counter
end

关键经验教训

• 安全性 vs. 效率：为上下文隔离所做的架构选择，在大规模时可能导致意外副作用。
• 文件系统限制真实存在：即使是 ext4 中每个 inode 65K 硬链接这样的底层限制，也可能干扰高层应用。
• 通用解决方案更优：响应操作系统错误的自适应算法，比针对理想条件的静态优化更可靠。
• 热门内容驱动负载：频繁使用的媒体文件（表情符号、反应、 meme）会成为隐形资源消耗大户。
• 生产数据测试至关重要：只有真实使用场景才能揭示这些边缘情况。

对分布式系统开发者的启示

Discourse 事件凸显了一个经典困境：数据安全与存储效率的平衡。在设计处理用户生成内容时，需要考虑：

• 在写入磁盘前进行应用级去重。
• 监控文件数量和重复相关的指标。
• 在达到系统限制时优雅降级。

尽管问题源于一张 GIF 的海量使用，但根源在于架构权衡。Discourse 团队找到的解决方案，可作为其他项目应对类似挑战的范例。

— Editorial Team