Dokumentation
Entwickler-HubAPI-StatusUnterstützung

Nutzungspläne und Ratenbegrenzungen

Erfahren Sie mehr über Nutzungspläne und wie Ratenlimits in SP-API verwendet werden.

Die Zuverlässigkeit der API hängt von der Größe Ihrer Kapazität und Ressourcen ab, um den sich im Laufe der Zeit ändernden Anforderungen Ihrer Anwendung gerecht zu werden. Aus diesem Grund definiert die Verkaufspartner-API (SP-API) Nutzungspläne, um die Anzahl der Anfragen zu kontrollieren, die Sie innerhalb eines bestimmten Zeitraums an einen Vorgang richten können.

Nutzungspläne hängen von mehreren Faktoren ab. Zu diesen Faktoren können das Vertriebspartnerkonto, die Anwendung, die die SP-API im Namen des Vertriebspartnerkontos aufruft, der Marketplace usw. gehören.

Dieses Dokument beschreibt den Ratenbegrenzungsalgorithmus der SP-API, die Faktoren, die die Nutzungspläne bestimmen, wie Sie Ihren Nutzungsplan finden und häufig gestellte Fragen zur Einhaltung Ihrer Ratenlimits.

Anleitungen zur Optimierung Ihrer Anwendungs-Workloads, um die Ratenbegrenzungen für jeden SP-API-Vorgang effizient zu nutzen, finden Sie unter Optimieren Sie die Ratenlimits für Anwendungs-Workloads.

Terminologie

Die folgenden Begriffe beziehen sich auf die Ratenbegrenzung in der SP-API:

  • Ratenlimit: Die maximale Anzahl von Anfragen, die Sie mit der SP-API pro Sekunde an eine bestimmte Operation stellen können. Um eine Drosselung zu vermeiden, sollten Sie unter diesem Limit bleiben.
  • Burst-Limit: Die maximale Anzahl von Anfragen an einen bestimmten Vorgang, die Sie im Laufe der Zeit erstellen und dann gleichzeitig senden können.
  • Nutzungsplan: Die Kombination aus Ratenlimit und Burst-Limit, die für einen bestimmten Vorgang gilt. Weitere Informationen finden Sie unter Typen von Nutzungsplänen und Faktoren, die die Nutzungspläne bestimmen.
  • Token-Bucket-Algorithmus: Der Algorithmus, den die SP-API zur Ratenbegrenzung von Anfragen verwendet. Er basiert auf einer Analogie zum Austausch von Tokens gegen API-Anfragen. Eine exemplarische Vorgehensweise des Algorithmus finden Sie unter Algorithmus zur Geschwindigkeitsbegrenzung.
  • Drosselung: Der Fall, in dem die SP-API Ihre Anfragen vorübergehend ablehnt, wenn Sie Ihr Ratenlimit überschreiten. Eine gedrosselte Anfrage führt zu einer 429-HTTP-Fehlerantwort. Sie können gedrosselte Anfragen später erneut versuchen.
  • Konto: Das Vertriebspartnerkonto, in dessen Namen die Entwickleranwendung die SP-API aufruft. Sie geben das Konto an, indem Sie eine angeben sellerId wenn Sie bestimmte SP-API-Operationen aufrufen.
  • Bewerbung: Die Entwickleranwendung, die die SP-API im Namen eines Vertriebspartners aufruft. In der Entwicklerkonsole des Vertriebspartners finden Sie die Anwendungs-ID hinter dem Anwendungsnamen.
  • Operationen ohne Zuschüsse: Operationen, für die keine erforderlich ist sellerId als Teil der Anfrage. Bei Vorgängen ohne Zuschüsse spielt der Vertriebspartner im Nutzungsplan für diesen Vorgang keine Rolle. Eine Liste der Vorgänge ohne Zuschüsse finden Sie unter Operationen ohne Zuschüsse.

Algorithmus zur Geschwindigkeitsbegrenzung

Die SP-API verwendet den Token-Bucket-Algorithmus, um Anfragen an die API zu begrenzen. Der Algorithmus basiert auf der Analogie eines Buckets, der Token enthält, wobei Sie jedes Token gegen eine Anfrage an die API eintauschen können.

In dieser Analogie fügt die SP-API Ihrem Bucket automatisch Token mit einer festgelegten Rate pro Sekunde hinzu, bis die maximale Größe des Buckets erreicht ist. Die maximale Größe wird auch als Burst-Rate bezeichnet.

Wenn Sie die SP-API aufrufen, ruft die SP-API Ihren Nutzungsplan (Ratenlimit und Burst-Limit) für diesen Vorgang auf der Grundlage des Zugriffstokens ab, das die Anruferidentität im Anforderungsheader identifiziert. Bei jeder Anfrage, die Sie an die SP-API stellen, wird ein Token vom Bucket abgezogen. Eine Drosselung tritt auf, wenn Sie eine Anfrage stellen, für die kein Token verfügbar ist, weil Ihr Bucket leer ist. Eine gedrosselte Anfrage führt zu einer Fehlerantwort.

Die folgende Abbildung zeigt, wie die Ratenbegrenzung auf der Grundlage des Token-Bucket-Algorithmus und der Bucket-Zuweisungskriterien funktioniert. Das Beispiel verwendet eine Operation mit einem Ratenlimit von eins und einem Burst-Limit von zwei.

The token bucket algorithm.

  1. Der Bucket ist anfänglich voll und fasst zwei Token (Burst Limit). Um 01:00:100 Uhr ruft eine Anwendung im Namen eines Vertriebspartners, der auf dem EU-Markt tätig ist, einen Betrieb der SP-API auf. Die Anfrage ist erfolgreich. Der Bucket enthält jetzt ein einzelnes Token, da durch die Anfrage ein Token aus dem Bucket aufgebraucht wurde.
  2. Nach 100 Millisekunden, um 01:00:200, ruft dieselbe Anwendung denselben Vorgang im Namen desselben Vertriebspartners in derselben Region auf. Die Anfrage ist erfolgreich und verwendet das letzte Token im Bucket. Der Bucket ist jetzt leer.
  3. Nach weiteren 100 Millisekunden, um 01:00:300, ruft dieselbe Anwendung denselben Vorgang im Namen desselben Vertriebspartners in derselben Region auf. Dieses Mal wird die Anfrage aufgrund der erschöpften Grenzwerte (leerer Bucket) gedrosselt.
  4. Eine Sekunde nach Beginn dieses Beispiels, um 01:01:000, platziert die SP-API ein Token in den Bucket, da das Ratenlimit bei einem Token pro Sekunde liegt. Die Anwendung kann den Vorgang jetzt erfolgreich aufrufen, ohne gedrosselt zu werden.
  5. Nach einer weiteren Sekunde, um 01:02:00 Uhr, fügt die SP-API dem Bucket ein weiteres Token hinzu.
  6. Um 01:03:00 Uhr fügt die SP-API dem Bucket kein weiteres Token hinzu, da der Bucket seine maximale Größe (Burst-Limit) erreicht hat.

Die Faktoren, die die Rate- und Burst-Limits bestimmen, bedeuten, dass es in einigen Fällen einen separaten Token-Bucket gibt. In diesem Beispiel sind in den folgenden Fällen zwei Token um 01:00:200 verfügbar:

  • Dieselbe Anwendung löst denselben Vorgang aus, jedoch im Namen eines anderen Vertriebspartners.
  • Dieselbe Anwendung ruft denselben Vorgang im Namen desselben Vertriebspartners auf, verwendet jedoch die Anmeldeinformationen eines anderen regionalen Kontos.
  • Eine andere Anwendung löst denselben Vorgang im Namen desselben Vertriebspartners aus.

Die folgende Abbildung zeigt diese alternativen Szenarien.

Alternate scenarios.

Faktoren, die die Nutzungspläne bestimmen

Rate- und Burst-Grenzwerte für jeden SP-API-Vorgang hängen von mehreren Faktoren ab, und für einen einzelnen Vorgang können mehrere Nutzungspläne gelten. Die Rate der Anfragen ist durch den Schwellenwert begrenzt, den Sie zuerst erreichen.

Die SP-API stützt sich bei der Zuweisung von Nutzungsplänen auf die folgenden Faktoren:

  • API-Betrieb: Jede Operation der SP-API hat ihre eigene Standardrate und Burst-Limits. Sie finden diese Grenzwerte oder einen Link zur Dokumentation, in der die Grenzwerte aufgeführt sind, in der API-Referenzdokumentation für jeden Vorgang.
  • Verkaufspartner (Konto) und Anwendungspaar: Die Ratenlimits der meisten Operationen gelten für das Verkaufspartner- und Anwendungspaar. Die Anwendung ruft die SP-API im Namen des Vertriebspartners auf. Ausnahmen von dieser Regel sind Operationen ohne Zuschüsse. Anwendungen können ohne Genehmigung eines Vertriebspartners Operationen ohne Genehmigung durch einen Vertriebspartner aufrufen. Bei Vorgängen ohne Zuschüsse werden die Nutzungspläne auf der Grundlage der anderen Kriterien in diesem Abschnitt definiert.
  • Regionen und Marktplätze: Nutzungspläne sind implizit an die Marktplatzgruppen gebunden, in denen ein Vertriebspartner tätig ist und eine Anwendung autorisiert hat, die SP-API in ihrem Namen aufzurufen. Der implizite Charakter dieses ratenbegrenzenden Faktors ist auf die verschiedenen marktplatzspezifischen Vertriebspartnerkonten zurückzuführen. Verschiedene Marketplace-spezifische Vertriebspartnerkonten haben unterschiedliche Verkäuferkennungen.

Typen von Nutzungsplänen

Jeder SP-API-Vorgang ist mit einem Nutzungsplan verknüpft. Ein Nutzungsplan spezifiziert ein Ratenlimit und ein Burst-Limit. Einzelheiten dazu, wie Sie Ihren Nutzungsplan finden, finden Sie unter So finden Sie Ihren Nutzungsplan. Es gibt zwei Arten von Nutzungsplänen: Standard- und dynamische.

  • Standard-Nutzungspläne: Die meisten SP-APIs unterliegen Standardnutzungsplänen. Bei einem Standardnutzungsplan haben die Tariflimits statische Werte für alle Anrufer, die auf den erwarteten Anrufmustern für jeden Vorgang basieren. Den Nutzungsplan oder einen Link zur Dokumentation, in der der Nutzungsplan aufgeführt ist, finden Sie in der API-Referenzdokumentation für jeden Vorgang.

  • Dynamische Nutzungspläne: Einige SP-APIs und Operationen haben dynamische Nutzungspläne. Ein dynamischer Nutzungsplan wird automatisch an jeden Vertriebspartner angepasst, basierend auf den aktuellen und historischen Geschäftsanforderungen für dieses Unternehmen. Da der Zweck dynamischer Nutzungspläne darin besteht, diese Beschränkungen im Laufe der Zeit anzupassen, können sich die Tarife ändern. Eine Vielzahl von Geschäftskennzahlen für Vertriebspartner beeinflussen Tarifanpassungen. Diese Kennzahlen sind nur Geschäftskennzahlen und beinhalten keine historische Anzahl von API-Anfragen. Die Raten steigen nicht dynamisch, da eine Anwendung häufiger API-Anfragen stellt.

    Dynamische Nutzungspläne gelten nur für die folgenden SP-APIs und Operationen.

So finden Sie Ihren Nutzungsplan

Du kannst deinen Nutzungsplan (Rate- und Burst-Limits) auf folgende Weise finden:

  • SP-API-Dokumentation: Sie finden diese Grenzwerte oder einen Link zur Dokumentation, in der die Grenzwerte aufgeführt sind, in der API-Referenzdokumentation für jeden Vorgang.

  • Antwort-Header: Wenn Sie eine SP-API-Operation aufrufen, wird x-amzn-RateLimit-Limit Der Antwort-Header gibt, falls verfügbar, die Ratenlimits des Vorgangs pro Konto-Anwendungspaar an. Sie dürfen sich jedoch aus den folgenden Gründen nicht darauf verlassen, dass dieser Header vorhanden ist:

    • In einigen Fällen kann die SP-API die Ratenbegrenzungen trotz eines Best-Effort-Versuchs nicht abrufen. In diesem Fall schlägt die SP-API bei einem ansonsten gültigen Aufruf des Vorgangs nicht fehl. Stattdessen gibt die SP-API die Antwort ohne x-amzn-RateLimit-Limit Kopfzeile.
    • Das x-amzn-RateLimit-Limit Der Antwort-Header ist für die HTTP-Statuscodes 20x, 400 und 404. Unautorisierte oder nicht authentifizierte Anfragen enthalten diesen Header nicht.
    • Das x-amzn-RateLimit-Limit Der Header enthält keine anderen Ratenbeschränkungen für Nutzungspläne.

    Dies bedeutet, dass Sie sich nicht auf das Vorhandensein des x-amzn-RateLimit-LimitHeaders in einer Antwort verlassen dürfen. Prüfen Sie stattdessen das Vorhandensein des Headers, bevor Sie versuchen, den Ratengrenzwert zu verwenden.

Häufig gestellte Fragen

Die Ratenbegrenzungen für einen Vorgang sind für meinen Anwendungsfall zu niedrig. Kann das Limit erhöht werden?

Wir streben die richtigen Limits an, mit dem Ziel, dass effiziente Anrufmuster idealerweise niemals gedrosselt werden sollten. Wenn Ihre Anwendung ständig gedrosselt wird, kann das bedeuten, dass Sie Ihre Anrufmuster weiter optimieren können. Weitere Informationen finden Sie unter Was muss ich tun, wenn meine Anwendung ständig gedrosselt wird. Wenn Sie feststellen, dass die Standardtarife nicht ausreichen, lesen Sie Strategien zur Optimierung der Ratenlimits für Ihre Anwendungs-Workloads.

Wie soll meine Anwendung mit einer 429-Antwort umgehen?

Ein 429 ist ein Statuscode, der wiederholt werden kann. Sie können es erneut versuchen, aber wiederholte gedrosselte Anfragen erfordern eine Back-off-Strategie. Verwenden Sie das x-amzn-RateLimit-Limit Antwort-Header, sofern verfügbar, um festzustellen, ob die Ratenlimits von Ihren Erwartungen abweichen. Einzelheiten darüber, wann dieser Header verfügbar ist, finden Sie unter So finden Sie Ihren Nutzungsplan.

Wie kann ich meine Anwendung in Bezug auf ihre Nutzungspläne testen?

Sie können die 429-Fehlerbehandlung mithilfe der Verkaufspartner-API-Sandbox testen. Mit der Sandbox können Sie Ratenbegrenzungen jedoch nicht testen, da die Abläufe in der Produktion zwar unterschiedliche Raten haben können, alle Sandbox-Operationen jedoch dieselbe Rate haben. Die Ihnen zugewiesenen Nutzungsraten finden Sie in der x-amzn-RateLimit-Limit Antwort-Header für jede Operation, sofern verfügbar. Einzelheiten dazu, wann dieser Header verfügbar ist, finden Sie unter So finden Sie Ihren Nutzungsplan.

Kann meine Anwendung eine Drosselung vollständig vermeiden?

Nein. Jede Anzahl von Faktoren, auf die Sie keinen Einfluss haben, kann zu einigen vorübergehenden 429s führen. Ihr Anwendungscode sollte diese Möglichkeit berücksichtigen.

Was soll ich tun, wenn meine Anwendung ständig gedrosselt wird?

Wenn Ihre Anwendung ständig gedrosselt wird, müssen Sie möglicherweise Ihre Anrufmuster weiter optimieren. Zum Beispiel:

  • Rufen Sie seltener an und halten Sie sich an Ihre Tarifgrenzen.

  • Verlassen Sie sich auf Push-Benachrichtigungen statt auf Abfragemechanismen.

  • Verwenden Sie Batch-APIs, sofern verfügbar, oder versuchen Sie, mit weniger Aufrufen mehr zu erreichen. Zum Beispiel mit dem Futtermittel und Berichte APIs, Sie können mehr Informationen pro Anruf senden oder abrufen. Im Allgemeinen sollten Sie Ihre Aufrufmuster mit den Vorgängen in einer API vergleichen, um festzustellen, ob Sie dieselbe Arbeit mit weniger Aufrufen erledigen können.

Wird meine Anwendung häufiger gedrosselt, wenn ich mehr Berechtigungen erhalte?

Nein. Die Nutzungspläne sind spezifisch für die Kombination aus Anwendung und Vertriebspartner, sodass Ihr Durchsatz auf natürliche Weise mit Ihren Kunden wächst.

Werden sich Tarifgrenzen ändern?

Wir können Tarifgrenzen jederzeit anheben. Sollten wir die in der API-Referenzdokumentation angegebenen Tarifgrenzen jemals senken, werden wir die Änderung im Voraus mitteilen, damit Sie Zeit haben, Ihre Anwendungen zu aktualisieren und zu testen, bevor die Änderung in Kraft tritt.

Die Ratenlimits für dynamische Nutzungspläne passen sich je nach Geschäftskontext automatisch nach oben oder unten an.

Erhöhen sich meine Ratenlimits, wenn meine Anwendung ständig gedrosselt wird?

Die Preise basieren auf den Geschäftskennzahlen eines Verkaufspartners. Wenn Ihr Antrag ständig gedrosselt wird, entsprechen Ihre Anrufmuster wahrscheinlich nicht den Tariflimits, die diesem Vertriebspartner zugewiesen wurden. Weitere Informationen finden Sie unter Was muss ich tun, wenn meine Anwendung ständig gedrosselt wird? und Die Ratengrenzen für eine Operation sind für meinen Anwendungsfall zu niedrig. Kann das Limit erhöht werden?.

Was ist das übergeordnete Ziel der dynamischen Nutzungspläne?

In der Vergangenheit haben wir festgestellt, dass einheitliche Nutzungspläne für manche Situationen überdimensioniert und für andere wiederum unterdimensioniert sind. Das Ziel von dynamischen Nutzungsplänen ist es, den bekannten geschäftlichen Kontext eines bestimmten Anrufs zu nutzen, um für jede Situation die richtigen Grenzen festzulegen.

Welche Faktoren beeinflussen dynamische Nutzungspläne?

Im Allgemeinen werden die Tarife durch die Art, die Größe und das Verhalten des Verkaufspartners bestimmt.

Wie oft werden sich die mit einem bestimmten Nutzungsplan verbundenen Grenzen ändern?

Wir sind bestrebt, häufige, störende Änderungen der Grenzen zu vermeiden. In der Regel werden die Grenzen geändert, sobald wir signifikante Veränderungen bei den Geschäftskennzahlen eines Verkaufspartner-Kontos feststellen.

Wie sollte ich meine Anwendung so programmieren, dass sie dynamische Grenzen einhält?

Die folgenden Vorschläge können Ihrer Anwendung helfen, dynamische Ratenbegrenzungen zu handhaben:

  • Lesen Sie die x-amzn-RateLimit-Limit Header, sofern verfügbar. Einzelheiten dazu, wann dieser Header verfügbar ist, finden Sie unter So finden Sie Ihren Nutzungsplan.

  • Programmieren Sie keine festen Timer.

  • Programmieren Sie auf natürliche Weise gegen Ereignisse, anstatt in einer Schleife zu laufen. Wenn Sie Ereignisse verwenden, benötigen Sie keinen Timer. Aktualisieren Sie beispielsweise die Preise als Reaktion auf Preisbenachrichtigungen und nicht alle eine bestimmte Anzahl von Sekunden.


Hat Ihnen diese Seite weitergeholfen?