Wiederholungsrichtlinien in den C++-Clientbibliotheken

Auf dieser Seite wird das Wiederholungsmodell beschrieben, das von den C++-Clientbibliotheken verwendet wird.

Die Clientbibliotheken führen in Ihrem Namen RPCs (Remote Procedure Calls) aus. Diese RPCs können aufgrund von vorübergehenden Fehlern fehlschlagen. Server werden neu gestartet, Load-Balancer schließen überladene oder inaktive Verbindungen und Ratenbegrenzungen können wirksam werden. Dies sind nur einige Beispiele für vorübergehende Ausfälle.

Die Bibliotheken könnten diese Fehler an die Anwendung zurückgeben. Viele dieser Fehler sind jedoch in der Bibliothek leicht zu beheben, was den Anwendungscode vereinfacht.

Wiederholbare Fehler und wiederholbare Vorgänge

Nur vorübergehende Fehler können wiederholt werden. kUnavailable gibt beispielsweise an, dass der Client keine Verbindung zu einem Dienst herstellen konnte oder seine Verbindung zu einem Dienst verloren hat, während eine Anfrage ausgeführt wurde. Dies ist fast immer ein vorübergehender Zustand, auch wenn die Wiederherstellung lange dauern kann. Diese Fehler sind immer wiederholbar (vorausgesetzt, der Vorgang selbst kann sicher wiederholt werden). Laut Vertrag erfordern kPermissionDenied-Fehler einen zusätzlichen Eingriff (in der Regel von einem Menschen), der behoben werden muss. Solche Fehler gelten nicht als "vorübergehend" oder sind zumindest nicht vorübergehend für die Zeitskalen, die von den Wiederholungsschleifen in der Clientbibliothek berücksichtigt werden.

Außerdem können einige Vorgänge nicht sicher wiederholt werden, unabhängig von der Art des Fehlers. Dazu gehören alle Vorgänge, die inkrementelle Änderungen vornehmen. Es ist beispielsweise nicht sicher, einen Vorgang zum Entfernen der "neuesten Version von X" zu wiederholen, wenn es mehrere Versionen einer Ressource mit dem Namen "X" geben kann. Das liegt daran, dass der Aufrufer wahrscheinlich eine einzelne Version entfernen wollte. Wenn Sie eine solche Anfrage wiederholen, werden möglicherweise alle Versionen entfernt.

Wiederholungsschleifen konfigurieren

Die Clientbibliotheken akzeptieren drei verschiedene Konfigurationsparameter, um Wiederholungsschleifen zu steuern:

  • Der *IdempotencyPolicy bestimmt, ob eine bestimmte Anfrage idempotent ist. Nur solche Anfragen werden wiederholt.
  • Der *RetryPolicy bestimmt (a) ob ein Fehler als vorübergehender Fehler betrachtet werden sollte und (b) wie lange (oder wie oft) die Clientbibliothek eine Anfrage wiederholt.
  • *BackoffPolicy legt fest, wie lange die Clientbibliothek wartet, bevor die Anfrage neu gesendet wird.

Standardrichtlinie für Idempotenz

Im Allgemeinen ist ein Vorgang idempotent, wenn die Funktion bei einem mehrfachen erfolgreichen Aufruf des Systems im selben Zustand ist wie beim einmaligen erfolgreichen Aufruf der Funktion. Nur idempotente Vorgänge können problemlos wiederholt werden. Beispiele für idempotente Vorgänge sind unter anderem alle schreibgeschützten Vorgänge und Vorgänge, die nur einmal erfolgreich sind.

Standardmäßig behandelt die Clientbibliothek nur RPCs, die über GET- oder PUT-Verben implementiert werden, als idempotent. Dies kann zu konservativ sein, da bei einigen Diensten sogar POST-Anfragen idempotent sind. Sie können die standardmäßige Idempotenzrichtlinie jederzeit entsprechend Ihren Anforderungen überschreiben.

Einige Vorgänge sind nur idempotent, wenn sie Vorbedingungen enthalten. Beispiel: „entfernen Sie die neueste Version, wenn die neueste Version Y ist“, ist z. B. idempotent, da dies nur einmal erfolgreich sein kann.

Von Zeit zu Zeit werden die Clientbibliotheken verbessert, sodass mehr Vorgänge als idempotent behandelt werden. Wir betrachten diese Verbesserungen als Fehlerkorrekturen und sind daher auch dann funktionsunfähig, wenn sie das Verhalten der Clientbibliothek ändern.

Es ist zwar sicher, einen Vorgang zu wiederholen, dies bedeutet jedoch nicht, dass der Vorgang beim zweiten und beim ersten erfolgreichen Versuch dasselbe Ergebnis erzielt. Beispielsweise kann das Erstellen einer eindeutig identifizierten Ressource sicher für einen erneuten Versuch sein, da der zweite und die nachfolgenden Versuche fehlschlagen und das System im selben Zustand belassen. Allerdings kann es sein, dass der Client bei Wiederholungsversuchen die Fehlermeldung „bereits vorhanden“ erhält.

Standardrichtlinie für Wiederholung

Gemäß den Richtlinien in aip/194 wiederholen die meisten C++-Clientbibliotheken nur UNAVAILABLE-gRPC-Fehler. Diese sind StatusCode::kUnavailable zugeordnet. Standardmäßig werden Anfragen 30 Minuten lang wiederholt.

kUnavailable-Fehler bedeuten nicht, dass der Server die Anfrage nicht empfangen hat. Dieser Fehlercode wird verwendet, wenn die Anfrage nicht gesendet werden kann. Er wird aber auch verwendet, wenn die Anfrage erfolgreich gesendet, vom Dienst empfangen wurde und die Verbindung unterbrochen wird, bevor der Client die Antwort erhält. Wenn Sie außerdem feststellen könnten, ob die Anfrage erfolgreich empfangen wurde, könnten Sie das Problem der zwei Generalen lösen, ein bekanntes Unmöglichkeitsergebnis in verteilten Systemen.

Daher ist es nicht sicher, alle Vorgänge, die mit kUnavailable fehlschlagen, zu wiederholen. Auch die Idempotenz des Vorgangs spielt eine Rolle.

Standard-Backoff-Richtlinie

Standardmäßig verwenden die meisten Bibliotheken eine abgeschnittene exponentielle Backoff-Strategie mit Jitter. Der anfängliche Backoff beträgt 1 Sekunde, der maximale Backoff 5 Minuten und der Backoff verdoppelt sich nach jedem Wiederholungsversuch.

Standardrichtlinien für Wiederholung und Backoff ändern

Jede Bibliothek definiert eine *Option-Struktur, um diese Richtlinien zu konfigurieren. Sie können diese Optionen beim Erstellen der Klasse *Client oder sogar bei jeder Anfrage angeben.

Das folgende Beispiel zeigt, wie Sie die Wiederholungs- und Backoff-Richtlinien für einen Cloud Pub/Sub-Client ändern:

google/cloud/pubsub/samples/sample.cc 
namespace pubsub = ::google::cloud::pubsub;
using ::google::cloud::future;
using ::google::cloud::Options;
using ::google::cloud::StatusOr;
[](std::string project_id, std::string topic_id) {
  auto topic = pubsub::Topic(std::move(project_id), std::move(topic_id));
  // By default a publisher will retry for 60 seconds, with an initial backoff
  // of 100ms, a maximum backoff of 60 seconds, and the backoff will grow by
  // 30% after each attempt. This changes those defaults.
  auto publisher = pubsub::Publisher(pubsub::MakePublisherConnection(
      std::move(topic),
      Options{}
          .set<pubsub::RetryPolicyOption>(
              pubsub::LimitedTimeRetryPolicy(
                  /*maximum_duration=*/std::chrono::minutes(10))
                  .clone())
          .set<pubsub::BackoffPolicyOption>(
              pubsub::ExponentialBackoffPolicy(
                  /*initial_delay=*/std::chrono::milliseconds(200),
                  /*maximum_delay=*/std::chrono::seconds(45),
                  /*scaling=*/2.0)
                  .clone())));

  std::vector<future<bool>> done;
  for (char const* data : {"1", "2", "3", "go!"}) {
    done.push_back(
        publisher.Publish(pubsub::MessageBuilder().SetData(data).Build())
            .then([](future<StatusOr<std::string>> f) {
              return f.get().ok();
            }));
  }
  publisher.Flush();
  int count = 0;
  for (auto& f : done) {
    if (f.get()) ++count;
  }
  std::cout << count << " messages sent successfully\n";
}

Die jeweiligen Namen und Beispiele finden Sie in der Dokumentation der jeweiligen Bibliothek.

Nächste Schritte