Wiederholungsrichtlinien in den C++-Clientbibliotheken

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

Die Clientbibliotheken senden in Ihrem Namen RPCs (Remote Procedure Calls). Diese RPCs können aufgrund vorübergehender Fehler fehlschlagen. Server werden neu gestartet, Load-Balancer schließen überlastete oder inaktive Verbindungen und Ratenbegrenzungen können in Kraft treten. Dies sind nur einige Beispiele für vorübergehende Fehler.

Die Bibliotheken können diese Fehler an die Anwendung zurückgeben. Viele dieser Fehler lassen sich jedoch in der Bibliothek einfach 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 herstellen konnte oder die Verbindung zu einem Dienst während einer laufenden Anfrage verloren hat. Dies ist fast immer ein vorübergehender Zustand, die Wiederherstellung kann jedoch lange dauern. Diese Fehler können immer wiederholt werden, sofern der Vorgang selbst sicher wiederholt werden kann. Im Gegensatz dazu erfordern kPermissionDenied-Fehler zusätzliche Maßnahmen (in der Regel durch einen Menschen), um behoben zu werden. Solche Fehler werden nicht als vorübergehend betrachtet, zumindest nicht in den Zeiträumen, die von den Wiederholungsschleifen in der Clientbibliothek berücksichtigt werden.

Ebenso ist es bei einigen Vorgängen nicht sicher, sie noch einmal zu versuchen, 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“ gibt. Das liegt daran, dass der Aufrufer wahrscheinlich nur eine einzelne Version entfernen wollte. Wenn eine solche Anfrage wiederholt wird, können alle Versionen entfernt werden.

Wiederholungsschleifen konfigurieren

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

  • Der *IdempotencyPolicy bestimmt, ob eine bestimmte Anfrage idempotent ist. Nur solche Anfragen werden noch einmal gesendet.
  • Der *RetryPolicy bestimmt (a), ob ein Fehler als vorübergehender Fehler betrachtet werden soll, und (b), wie lange (oder wie oft) die Clientbibliothek eine Anfrage wiederholt.
  • Der Wert *BackoffPolicy bestimmt, wie lange die Clientbibliothek wartet, bevor sie die Anfrage noch einmal sendet.

Standardrichtlinie für Idempotenz

Im Allgemeinen ist ein Vorgang idempotent, wenn das System nach mehrmaligem erfolgreichen Aufrufen der Funktion denselben Status hat wie nach einmaligem erfolgreichen Aufrufen der Funktion. Nur idempotente Vorgänge können sicher wiederholt werden. Beispiele für idempotente Vorgänge sind unter anderem alle schreibgeschützten Vorgänge und Vorgänge, die nur einmal erfolgreich ausgeführt werden können.

Standardmäßig behandelt die Clientbibliothek nur RPCs, die über die Verben GET oder PUT implementiert werden, als idempotent. Das kann zu konservativ sein, da in einigen Diensten sogar einige POST-Anfragen idempotent sind. Sie können die standardmäßige Idempotenzrichtlinie jederzeit überschreiben, um sie besser an Ihre Anforderungen anzupassen.

Einige Vorgänge sind nur idempotent, wenn sie Vorbedingungen enthalten. „Entferne die neueste Version, wenn die neueste Version Y ist“ ist beispielsweise idempotent, da der Vorgang nur einmal erfolgreich ausgeführt werden kann.

Die Clientbibliotheken werden regelmäßig verbessert, sodass mehr Vorgänge als idempotent behandelt werden. Wir betrachten diese Verbesserungen als Fehlerkorrekturen und daher als nicht abwärtskompatibel, auch wenn sie das Verhalten der Clientbibliothek ändern.

Es kann zwar sicher sein, einen Vorgang zu wiederholen, das bedeutet aber nicht, dass der Vorgang beim zweiten Versuch dasselbe Ergebnis wie beim ersten erfolgreichen Versuch liefert. Das Erstellen einer eindeutig identifizierten Ressource kann beispielsweise sicher wiederholt werden, da der zweite und die nachfolgenden Versuche fehlschlagen und das System im selben Zustand belassen. Der Client erhält bei den Wiederholungsversuchen jedoch möglicherweise einen Fehler vom Typ „bereits vorhanden“.

Standard-Wiederholungsrichtlinie

Gemäß den Richtlinien in aip/194 werden die meisten C++-Clientbibliotheken nur bei UNAVAILABLE-gRPC-Fehlern wiederholt. Sie sind StatusCode::kUnavailable zugeordnet. Standardmäßig wird 30 Minuten lang versucht, Anfragen noch einmal zu senden.

kUnavailable-Fehler weisen nicht darauf hin, 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 und vom Dienst empfangen wird und die Verbindung verloren geht, bevor die Antwort vom Client empfangen wird. Wenn Sie außerdem feststellen könnten, ob die Anfrage erfolgreich empfangen wurde, könnten Sie das Problem der zwei Generäle 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 ist wichtig.

Standardrichtlinie für Backoff

Standardmäßig verwenden die meisten Bibliotheken eine Strategie für abgeschnittenen exponentiellen Backoff 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 Wiederholungsversuche und Backoff ändern

Jede Bibliothek definiert eine *Option-Struktur zum Konfigurieren dieser Richtlinien. Sie können diese Optionen beim Erstellen der *Client-Klasse oder sogar bei jeder Anfrage angeben.

Im folgenden Beispiel wird gezeigt, wie Sie die Richtlinien für Wiederholungsversuche und Backoff für einen Cloud Pub/Sub-Client ändern:

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 spezifischen Namen und Beispiele für die einzelnen Bibliotheken finden Sie in der jeweiligen Dokumentation.

Nächste Schritte