跟踪像素如何实施速率限制？
像Facebook或Snapchat这样的公司如何限制其跟踪像素的速率？我认为他们必须在像素路线上限制速率，因为这是任何人都可以致电并可能导致恶意攻击的公共API。但是，您将如何实施系统来限制限制，因为您不能对所有广告商，妈妈和流行商店都有一般限制，每天可能会收到100个像素请求，而耐克每天将获得100m Pixel请求。
如果您尝试对每个广告商ID都有一个费率限制，那么另一种情况是您每天都有数十名新广告客户加入该平台，以及如何在不知道他们将收到的流量类型的情况下分配费率限制他们（例如，耐克（Nike）签约妈妈和流行店需要不同的费率限制）。每当您需要分配一个或有些动态分配费率限制的方法时，这会导致手动工作吗？
另外，这种类型的方案与常规API不同，因为您不想失去这些广告客户的请求（因为丢失的请求可能是潜在的归因）。我想您希望尽可能多地收到，但也希望能够控制恶意请求，从而使API超载。
我一直在考虑这一点，似乎无法提出一种为此用法设计费率限制器的方法。
How would a company like Facebook or Snapchat implement rate limiting on their tracking pixel? I imagine that they must have rate limiting on the pixel route since it's a public API that anyone can call and could lead to malicious attacks. However, how would you implement a system to rate limit since you can't have a generic limit for all advertisers, mom and pop shops may get 100 pixel requests a day, whereas Nike would get 100M pixel requests a day for example.
If you try to have a rate limit for each advertiser Id, then another situation is that you have dozens of new advertisers joining the platform every day and how would you assign a rate limit to their requests without knowing the type of traffic they would receive from them (for example Nike signing up vs mom and pop shop would need different rate limits). Would this lead to manual work every time you need to assign one or is there some way of dynamically assign a rate limit?
Also this type of scenario is different than a regular API since you don't want to ever lose requests from these advertisers (because that lost request could be a potential attribution). I guess you want to receive as much as possible but also want to be able to control malicious requests from overloading your API.
I've been thinking about this for a bit and can't seem to come up with a way to design a rate limiter for this usage.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Facebook在像素上没有限制速率。
所有API请求均受速率限制。 Graph API和Instagram基本显示API请求受平台速率限制的约束，而营销API和Instagram图API请求则受业务用例（BUC）速率限制的约束。
您可以检查以下链接以获取更好的说明：
https ：//developers.facebook.com/docs/graph-api/overview/rate-limiting
https：//develovelers.facebook.com/docs.com/docs/marketing-apting-apis-apis/rate-late-late-late-limitith一下/
Facebook does not have a rate-limiting on the pixels.
All API requests are subject to rate limits. Graph API and Instagram Basic Display API requests are subject to Platform Rate Limits, while Marketing API and Instagram Graph API requests are subject to Business Use Case (BUC) Rate Limits.
You can check the following links to get a better explanation:
https://developers.facebook.com/docs/graph-api/overview/rate-limiting
https://developers.facebook.com/docs/marketing-apis/rate-limiting/
限制速率的最常见方法是令牌桶（或泄漏的桶）。许多（大多数？）主要服务使用这些服务。限制费率的原因可能是由于业务（客户X具有Y的要求时）或仅对系统的一般保护 - 因为没有系统真正无限。
例如，假设服务具有依赖性，并且依赖关系可能每秒最多支持X调用。然后，系统将在其前面添加一个令牌桶（包括分布式版本），当没有更多资源时，系统将便宜地油门，而不是与超载相关的中断。
当限制基于某些业务原因时，更有趣的示例会出现 - 就像我们在多租户系统中给每个客户一个特定的限制一样。在这种特殊情况下，每个客户都有自己的代币存储桶和一个桶来保护整个系统（如前一段中所述）。基本上，为了执行客户端请求，两个存储桶应不空。
更有趣的（更实用）的例子是塑造这样的流量：我们给出了每个客户端X TP，但是我们允许溢出 - 例如，我们允许X+Y TPS在某些有限的窗口中，例如10秒。
为了实现该方法，系统将使用四个令牌桶：
因此，要通过请求进行，两个条件之一应该是正确的：
Most common approach to rate limiting is token buckets (or leaking bucket). Many (most?) major services use those. The reason for rate limiting may be because of business (when a client X has Y requests allowed per W of time) or just general protection for the system - as no system is truly unlimited.
For example, lets say a service has a dependency and that dependency may support up to X calls per second. Then the system would add a token bucket in front of it (incl. a distributed version) and when there are no more resources, the system would cheaply throttle, instead of having an overload related outage.
More interesting example comes when limit is based on some business reason - like we give each client a specific limit in a multi-tenant system. In this particular case, every client would have their own token bucket and one more bucket to protect system as a whole (as described in previous paragraph). Basically, for a client request to be executed, two buckets should be non empty.
Even more interesting (and more practical) example is shaping traffic like this: we give each client X tps, but we allow overflow - e.g. we allow X+Y tps for some limited window, e.g. 10 seconds.
To implement that approach, the system would use four token buckets:
So for a request to come through, one of two conditions should be true: