我正在開發一個包裹跟蹤系統并考慮如何提高它的性能。
現在我們在 postgres 中有一張表，parcels其中包含諸如id上次已知位置等內容。
每天大約有 300.000 個新包裹被添加到該表中。包裹資料取自外部 API。我們需要盡可能準確地跟蹤所有包裹位置，并減少有關特定包裹的 API 呼叫之間的時間。
鑒于這些要求，您對專案架構有何建議？
現在我能想到的唯一解決方案是生產者-消費者模式。就像讓一個行程parcel在無限回圈中從表中選擇所有記錄，然后使用 Celery 之類的東西分發獲取資料的任務。
此解決方案的主要缺點是：
- 可能的死鎖，因為可以在不同的機器上同時執行獲取有關同一任務的資料。
- 需要控制佇列大小
uj5u.com熱心網友回復：
這是一個非常廣泛的話題，但我可以給你一些建議。一旦達到垂直擴展的限制（基于選擇更強大的機器進行擴展），您必須水平擴展（基于向同一任務添加更多機器的擴展）。因此，為了能夠設計可擴展的架構，您必須了解分布式系統。這里有一些需要研究的主題：
- 用于托管分布式系統的基礎設施和流程，例如 Kubernetes、容器、CI/CD。
- 可擴展的持久性形式。例如，不同形式的分布式 NoSQL，如鍵值存盤、寬列存盤、記憶體資料庫和新穎的可擴展 SQL 存盤。
- 資料流和處理的可擴展形式。例如，使用分布式訊息/事件佇列的事件驅動架構。
對于包的特定問題，我建議考慮為您的位置資料使用鍵值存盤。這些可以擴展到每天數十億次插入和檢索（按鍵查詢時）。
聽起來您的資料也有點臨時性，可以在包裹尚未交付（然后存檔）時將其保存在記憶體中的熱存盤中。分布式記憶體資料庫可以在插入和查詢方面進一步擴展。
此外，您可能希望將資料提取（通過您的 api）與處理和持久性分離。為此，您可以考慮引入流處理系統。
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/355014.html
上一篇：有效地添加兩個不同大小的一維陣列