API 设计：响应数据跟踪分析

Question

假设我们正在经营一家在线商店，并且我们的数据库中有一个Product 表。这代表存在的产品：

productId	brandId (FK)	name	description	capacity	pricePerNight
1	2	Tent	This is a tent	4	20

现在假设我正在制作一个公共 API，它允许外部公司客户根据一些参数查询我商店中的可用产品。这个公共 API 每周会收到数千次调用。

我想跟踪一个产品（例如帐篷）被这个公共 API 返回的次数，我想看看这个数字是如何随时间变化的。

我的解决方案：

实现一个表（例如View）并在每次返回产品时插入一个新行（异步）：

productId (FK)	date
1	24/03/2021
1	26/03/2021

我在这里看到的问题是该表会很快变得非常大（每周可能有 100,000 条新行）。我不确定这会如何影响整体数据库性能 (MYSql)，但它似乎不可扩展。

你能告诉我一个更好的解决方案吗？谢谢！

Answer 1

由于这样做的目的是提供离线分析，因此最好让您的 API 发布包含产品 ID 和时间戳的事件流。然后，该流的使用者可以从您的主服务的 MySQL 跟踪不同数据存储（Cassandra、DynamoDB、Cosmos、Elasticsearch、一些时间序列数据库等）中的聚合等。

至于“发布流”的含义，它可以像另一个具有 HTTP/gRPC/任何端点的服务一样简单。将消息发布到 Kafka/Pulsar 主题或某些 MQ 也是可行的。由 Filebeat 提取并由 Logstash 挖掘的日志消息甚至可能是可行的。

需要注意的重要一点是，发布此流可能是您应该考虑忽略失败的地方（即“即发即弃”发布）：假设查询此 API 的用户可能对您的业务很重要，这真的有意义吗因为您无法记录事情以供以后分析而未能满足他们的要求？出于同样的原因，几乎可以肯定最好异步执行此操作，仅在需要安排任务发布事件时才会影响提供 API 响应的热路径。您可以将不可避免的丢弃事件基本上视为一种随机抽样形式：很可能，没有人关心帐篷实际上出现了 1000 个请求，而统计服务报告了 997 个（如果业务人员拒绝，请询问他们是否有 100%公共 API 上 0.3% 的失败率来自统计服务的准确率优于统计服务上 99.7% 准确率的公共 API 上的 0% 失败率......）。