月饼 TV 的技术架构

[HaroldFinchNYC]

https://github.com/MoonCakeTV/MoonCakeTV

在构建 月饼 TV 的过程中，我的目标是：为用户提供快速、稳定的搜索体验。但背后涉及的数据源复杂、数据量庞大，如何处理、存储和查询，是一套需要不断优化的技术工程。本文将介绍目前的技术架构和关键优化步骤。

数据来源与采集

所有数据都来自各类资源站。最初我通过手动采集，但很快转向了自动化。

• 采集调度：使用 Temporal 来管理 worker 流程。

• 执行频率：每天运行 3 次，每 8 小时一次。（这是以前的安排，现在是每天一次）

• 存储目标：采集下来的数据先写入 Cloudflare D1 数据库。

• 目前已经累计存储 114 万条信息。采集这一步过去需要 6 小时，现在优化后缩短至 5.5 小时。

搜索的痛点与演进

• 最初的搜索 API 很原始：

  • 直接在 Cloudflare D1 上执行 SQL 查询。

  • 返回结果往往需要 20 秒甚至更久，对用户体验极差。

• 后来我引入了 Meilisearch：

  • 数据通过 Temporal worker 从 D1 导出，再写入到 Meilisearch 。

  • Meilisearch 部署在独立 VPS 上，性能显著提升。

数据处理流程（ Pipeline ）

目前的完整数据流是这样的：

数据源 ---> Temporal Worker ---> Cloudflare D1
          ---> Temporal Worker ---> Meilisearch
          ---> Cloudflare Worker API

• 第一阶段：从资源站获取数据，存入 D1 （ 5.5 小时）。

• 第二阶段：从 D1 导出数据，插入 Meilisearch （ 12.5 小时）。

• 调度策略：每天只跑一次。先运行采集 worker ，8 小时后再运行导入 worker ，避免冲突。

• 虽然性能不算出色，但每天更新一次，已经能满足需求。

搜索 API 的优化

我在 Cloudflare Worker API 里加了一些增强功能：

• 缓存机制：

  • 基于 Cloudflare KV

  • 相同关键词结果缓存 4 小时 （毕竟数据也才 24 小时更新一次）

  • 显著减少 Meilisearch 的压力

• 访问控制：（四舍五入等于没有，请大家不要刷数据，服务器挂了的话，影响大家使用）

  • 每个 IP 每分钟最多 30 次请求

  • 无需注册

  • 无 CORS 限制

这样一来，用户体验基本可用，同时避免了服务过载。

基础设施配置

• Meilisearch VPS

  • 32GB 内存，2TB 硬盘

  • 单机部署，无备份

• Temporal VPS

  • 独立运行，调度两个 pipeline

• Cloudflare Worker API

  • 作为前端访问入口

  • 提供统一的搜索接口

挑战与展望

目前系统仍然有一些问题：

• Pipeline 慢：导入 Meilisearch 需要 12.5 小时，后续需要优化批量写入和并发。

• 无备份：如果 VPS 出问题，Meilisearch 数据需要重新导入，恢复时间较长。

• 高负载风险：请求过多时，Meilisearch 容易被打挂。毕竟我的防护约等于没有

未来我考虑：

• 优化 Temporal worker 的并发能力

• 引入分布式存储或自动备份机制

• 不用 cloudflare d1 ，使用自己搭建的 postgresql ，性能可以得到很大提升

• 加强防护，避免恶意刷请求

总结

月饼 TV 的技术架构虽然还在不断打磨，但已经走过了一条从“能跑”到“能用”的路：

• Temporal 负责数据调度与可靠运行

• Cloudflare D1 存储基础数据

• Meilisearch 提供高效的搜索体验

• Cloudflare Worker + KV 作为搜索 API 的缓存与限流层

这套体系支撑了每天百万级的数据更新与快速搜索，积累了不少经验。

大家有什么意见和建议，请不吝赐教

[Aprdec]

厉害

[yb2313]

我记得之前没有镜像, 现在有镜像好多了. 另一个 moon 好像闭源了, 我还找了备份

[guoziyang0033]

@yb2313 https://github.com/moontechlab/lunatv