performance - 高负载数据更新架构

Question

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

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

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

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

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

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

• 可能的死锁，因为获取相同任务的数据可以同时在不同的机器上执行。
• 需要控制队列大小

标签： performancearchitecturemicroservicesscalabilityhigh-load

Answer 1

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

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

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

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

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