OpenFreeMap 在每秒 100,000 次请求下幸存
本文信息来源：hyperknot
我正打算发一篇文章，谈谈过去 10 个月的 OpenFreeMap 多么美好。架构确实被证明非常出色，Cloudflare 已同意赞助带宽，Hetzner 服务器一如既往地超稳定，从 Btrfs 提供切片证明是一个很好的选择，nginx 令人惊叹，生活很美好。
然后，毫无预兆地，我开始收到报告说有些切片加载不出来，这通常意味着切片生成出现了错误，但这次不是。我查看了 nginx 日志，看到的是：
2025/08/08 23:08:16 [crit] 1084275#1084275: *161914910 open() "/mnt/ofm/planet-20250730_001001_pt/tiles/8/138/83.pbf" failed (24: Too many open files) ...这太奇怪了。我从未见过这样的情况。我检查 nload，显示流量巨大。我登录 Cloudflare，看到过去 24 小时里是这个 。
什么？24 小时内 30 亿 次请求？ 这到底是怎么回事？而且，来自只有 70 KB 小文件的流量居然有 215 TB？
这么大的流量在 MapTiler 上每月费用将超过 600 万美元，在 Mapbox 上则会翻两番。
在过去 5 分钟尤其猛增，我看到 3000 万次请求。
那是多少量？
哇，那是 每秒 100,000 次请求 ！
我最先想到的是：
- 哇。
- 哇，我很惊讶我听说的唯一一个漏洞竟然只是一些缺失的切片。我的意思是，服务似乎仍然在运行？那些空白切片被 Cloudflare 缓存了，但除此之外，它还是有点能用？
查看 Cloudflare 仪表盘，我能看到 96% 的请求返回了 200 OK；只有 3.6% 出现了问题（206 Partial Content）。
所以看起来 OpenFreeMap 大体上是在应对每秒 100,000 个请求？
但是什么导致了这一切？
Wplace.live 出现了。突然间，一个全新的协作绘图网站诞生，使用 OpenFreeMap 从零构建。
我不清楚它究竟是什么，但互联网似乎为之疯狂。有一点是肯定的：它带来的流量超乎想象。
我相信发生的情况是这些图像是被一些脚本小子绘制的。如果我没理解错，网站把每个人限制为每 30 秒只能画 1 个像素，所以我猜大家都是用脚本控制 Puppeteer/Chromium 启动新浏览器、点击一个像素然后关闭浏览器，可能还会轮换 IP 地址，但也许连那都不需要。
好主意，有趣的项目，下次请在发布前联系我。Neal.fun 在发布 Internet Roadtrip 之前也做过同样的事——他们问过我流量是否能承受，甚至决定赞助 OpenFreeMap 项目，赞助金额足以覆盖他们的带宽使用。
抱歉 Wplace.live，我不得不创建了我的第一个 Cloudflare 规则。作为单个用户，你让所有人的服务都中断了。
我想知道在 Cloudflare 上是否有自动化的方法，根据 Referer 或自定义头来限制流量。如果能自动化就太好了，因为我希望避免未来再发生这种情况。我希望能通过 API 把这件事脚本化。
最后，我要非常感谢 Cloudflare 在带宽方面的帮助。我还没写过这件事，但当我在去年十一月联系他们时，他们在一个周六内就把我的带宽赞助资格批准了，而且只用了 48 小时。更重要的是，他们把我对接到一些最优秀的工程师，讨论 OpenFreeMap 如何更好地利用他们的架构。我从未见过如此规模的公司能如此敏捷地行动。
作为唯一运营 OpenFreeMap 的人，我为这两个数字感到无比自豪。第一，我的架构达到了 99.4% 的 CDN 缓存命中率，这对一个每周更新数据的服务来说非常出色。第二，我自己的服务器成功处理了剩余的每秒 1,000 次请求。
更新
我联系上了 Wplace.live 的开发者。他说用户在几天内意外增长到 200 万，所以我完全能理解他们没为这种流量做好准备。顺便说一句，他们的主架构还能顶住，令我很惊讶。
我提出帮他们搭建一个自托管的 OpenFreeMap 实例，这非常适合这种使用场景。他们可以免费使用服务，公共实例不会承受额外负载，大家都很满意。
而且，只有200万用户这一点进一步印证了我的看法：这些流量几乎全是脚本小子制造的。30亿请求 / 200万用户，平均每用户1500次请求。普通用户在加载地图时可能只会发出10–20次请求，所以这些请求量异常高，属于脚本化使用场景。
我给他们的建议是，取消那些迫使用户通过新浏览器会话绕过限制的规则；那样只会继续猛击他们的服务器。
经验教训
我将在下一篇文章中写到两个经验教训。
- 我需要按 Referer 实现带宽限流。我正在研究如何在 Cloudflare 上实现这项功能。服务本身不会有变化；一切仍将免费且无需注册，但每个 Referer 都会被限制到一个非常高的数值，例如每 24 小时 1 亿次请求或类似水平。对于原生应用，我可能会要求他们添加一个用于标识应用的自定义头。
- 我需要改进服务器配置来修复那些空瓦片。尽管我不预计将来会有这样的负载，但我想我已经找到了导致瓦片丢失的配置问题。
如果你觉得 OpenFreeMap 有价值，请考虑 在 GitHub 赞助 。为了完全透明，项目目前靠每月 500 美元的捐助运行。这刚好覆盖所有基础设施成本，这非常棒。然而，这也意味着新功能开发只能在我的有限空闲时间里进行。更多支持就意味着我能花更多时间编程，确保 OpenFreeMap 为未来的挑战做好准备。
