Highload数据更新架构

Highload data update architecture

我正在开发一个包裹跟踪系统并考虑如何提高它的性能。

现在我们在 postgres 中有一个名为 parcels 的 table，其中包含 id、最后已知位置等内容

每天大约有 300.000 个新包裹被添加到这个 table。包裹数据取自外部 API。我们需要尽可能准确地跟踪所有包裹位置，并减少 API 调用特定包裹的时间间隔。

鉴于这样的要求，您对项目架构有何建议？

目前我能想到的唯一解决方案就是生产者消费者模式。就像让一个进程在无限循环中从 parcel table 中选择所有记录，然后使用 Celery 之类的东西分发获取数据任务。

此解决方案的主要缺点是：

这是一个非常宽泛的话题，但我可以给你一些建议。一旦达到垂直扩展的极限（基于选择更强大的机器的扩展），您必须水平扩展（基于为同一任务添加更多机器的扩展）。因此，为了能够设计可扩展的架构，您必须了解分布式系统。这里有一些要研究的主题：

  • 用于托管分布式系统的基础架构和流程，例如 Kubernetes、容器、CI/CD。
  • 可扩展的持久性形式。例如不同形式的分布式 NoSQL，如键值存储、宽列存储、内存数据库和新颖的可扩展 SQL 存储。
  • 可扩展的数据流和处理形式。例如使用分布式消息/事件队列的事件驱动架构。

对于您的包裹的具体问题，我建议您考虑为您的位置数据使用键值存储。这些可以扩展到每天数十亿次插入和检索（当按键查询时）。

听起来您的数据有点临时，可以在包裹尚未交付（并在之后存档）时保存在内存中的热存储中。分布式内存数据库可以在插入和查询方面进一步扩展。

您可能还想将数据提取（通过您的 api）与处理和持久性分离。为此，您可以考虑引入流处理系统。