假設我們正在經營一家網上商店，并Product在我們的資料庫中有一張表。這代表存在的產品：
| 產品編號 | 品牌 ID (FK) | 姓名 | 描述 | 容量 | 每晚價格 |
|---|---|---|---|---|---|
| 1 | 2 | 帳篷 | 這是帳篷 | 4 | 20 |
現在假設我正在制作一個公共 API，它允許外部公司客戶根據許多引數查詢我商店中的可用產品。這個公共 API 每周收到數千次呼叫。
我想跟蹤這個公共 API 回傳產品（例如帳篷）的次數，我想看看這個數字是如何隨時間變化的。
我的解決方案：
View每次回傳產品時，實作一個表（例如）并插入一個新行（異步）：
| 產品 ID (FK) | 日期 |
|---|---|
| 1 | 24/03/2021 |
| 1 | 26/03/2021 |
我在這里看到的問題是該表很快就會變得非常大（每周可能會有 100,000 個新行）。我不確定這將如何影響整體資料庫性能 (MYSql)，但它似乎不可擴展。
你能告訴我更好的解決方案嗎？謝謝！
uj5u.com熱心網友回復：
由于這樣做的目的是提供離線分析，因此最好讓您的 API 發布包含產品 ID 和時間戳的事件流。然后，該流的使用者可以在與您的主服務的 MySQL 不同的資料存盤（Cassandra、DynamoDB、Cosmos、Elasticsearch、某些時間序列 DB 等）中跟蹤該流。
至于“發布流”需要什么，它可以像另一個具有 HTTP/gRPC/任何端點的服務一樣簡單。將訊息發布到 Kafka/Pulsar 主題或某些 MQ 也是可行的。由 Filebeat 獲取并由 Logstash 處理的日志訊息甚至可能是可行的。
需要注意的一件重要事情是，發布此流可能是您應該考慮忽略失敗的某個地方（即“即發即棄”發布）：假設查詢此 API 的用戶可能對您的業務很重要，那么讓他們的失敗失敗真的有意義嗎？請求是因為您無法記錄內容以供以后分析？出于同樣的原因，幾乎可以肯定最好異步執行此操作，僅在需要調度任務以發布事件時才影響提供 API 回應的熱路徑。您可以將不可避免的丟棄事件視為基本上隨機抽樣的一種形式：很有可能，沒有人關心帳篷實際上在 1000 個請求中出現，而統計服務報告了 997 個（如果業務人員推遲，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/369938.html
上一篇：如何防止springboot網關轉發到鏈中的最后一個元素
下一篇：無法通過JPA訪問嵌入式類的屬性