Publish Hedging

Eine hohe Tail-Latenz beim Veröffentlichen von Nachrichten kann durch vorübergehende Netzwerkverzögerungen oder vorübergehende serverseitige Verlangsamung verursacht werden. Mit Publish Hedging kann ein Pub/Sub-Publisher-Client eine parallele (abgesicherte) Veröffentlichungsanfrage senden, wenn eine laufende Anfrage nicht innerhalb einer konfigurierten Verzögerung abgeschlossen wird. Dabei wird die Antwort verwendet, die zuerst zurückgegeben wird.

In diesem Dokument finden Sie Informationen zur Verwendung von Publish Hedging für Nachrichten, die in einem Thema veröffentlicht werden.

Hinweis

Führen Sie vor dem Konfigurieren des Veröffentlichungs-Workflows die folgenden Aufgaben aus:

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die IAM-Rolle Pub/Sub Publisher (roles/pubsub.publisher) für das Thema zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Senden von Hedged-Publish-Anfragen an ein Thema benötigen. Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Sie können die erforderlichen Berechtigungen auch über benutzerdefinierte Rollen oder andere vordefinierte Rollen erhalten.

Sie benötigen zusätzliche Berechtigungen, um Themen und Abos zu erstellen oder zu aktualisieren.

Informationen zum Publish Hedging

Mit den Hedging-Einstellungen wird gesteuert, wie und wann die Pub/Sub-Clientbibliotheken Hedging-Veröffentlichungsanfragen senden. Die Veröffentlichungsabsicherung ist standardmäßig deaktiviert. Wenn diese Option aktiviert ist, haben die Clientbibliotheken die folgenden Hedging-Einstellungen:

  • Hedge-Verzögerung: Die Zeit, die eine Clientbibliothek wartet, bevor sie eine zusätzliche Veröffentlichungsanfrage parallel sendet, wenn die vorherige Anfrage noch nicht abgeschlossen ist. Der Standardwert beträgt 1 Sekunde und der konfigurierte Wert muss zwischen 100 Millisekunden und 10 Sekunden liegen.
  • Maximale Anzahl von Tokens: Die maximale Anzahl von Tokens, die eine Clientbibliothek zum Senden von abgesicherten Veröffentlichungsanfragen ansammeln kann. Jede Hedged-Publish-Anfrage verbraucht 1 Token. Der Standardwert ist 50 und der konfigurierte Wert muss zwischen 1 und 250 liegen.
  • Refill ratio: Die Anzahl der Tokens, die für jede erfolgreiche Veröffentlichungsanfrage hinzugefügt werden. Dieser Wert steuert den maximalen Anteil der Veröffentlichungsanfragen, die im Laufe der Zeit abgesichert werden können. Bei einem Auffüllverhältnis von 0, 1 können beispielsweise bis zu 10 % der Veröffentlichungsanfragen abgesichert werden. Der Standardwert ist 0,1 und der konfigurierte Wert muss zwischen 0,001 und 0,2 liegen.

Damit Veröffentlichungsanfragen abgesichert werden können, muss die Absicherungsverzögerung kürzer sein als die Zeitüberschreitung der ersten Anfrage und die Gesamtzeitüberschreitung in den Wiederholungseinstellungen des Publishers. Andernfalls kann der Publisher-Client nicht initialisiert werden. Wenn die Veröffentlichungsabsicherung aktiviert ist, sendet die Clientbibliothek Veröffentlichungsanfragen so:

  • Wenn eine laufende Veröffentlichungsanfrage nicht innerhalb der Hedge-Verzögerung abgeschlossen wird und mindestens ein Token verfügbar ist, verbraucht die Clientbibliothek ein Token und sendet parallel eine zusätzliche Veröffentlichungsanfrage für denselben Nachrichten-Batch, während die ursprüngliche Anfrage ausstehend bleibt.
  • Wenn keine der laufenden Anfragen nach einer weiteren Hedge-Verzögerung abgeschlossen wird, sendet die Clientbibliothek weiterhin zusätzliche Hedged-Anfragen in Intervallen der Hedge-Verzögerung, solange Tokens verfügbar sind und das Gesamtzeitlimit nicht abgelaufen ist.
  • Sobald eine laufende Veröffentlichungsanfrage für den Batch erfolgreich ist, schließt die Clientbibliothek den Veröffentlichungsvorgang ab, bricht alle verbleibenden laufenden Versuche für diesen Batch ab und erhöht die verfügbaren Tokens um das Auffüllverhältnis bis zur maximalen Anzahl von Tokens.

Veröffentlichungsanfrage absichern

Im Gegensatz zu Wiederholungsanfragen, die warten, bis eine laufende Veröffentlichungsanfrage fehlschlägt oder eine Zeitüberschreitung auftritt, bleibt die ursprüngliche Anfrage beim Publish Hedging ausstehend, während eine gleichzeitige Hedging-Anfrage gesendet wird. Dadurch wird die Tail-Latenz reduziert, ohne dass Anfragen, die kurz vor dem Abschluss stehen, vorzeitig abgebrochen werden.

Da mehrere Anfragen für denselben Nachrichten-Batch gleichzeitig aktiv sein können, kann es sein, dass mehr als ein Versuch erfolgreich ist, bevor die verbleibenden Versuche abgebrochen werden, da der Abbruch von Veröffentlichungsanfragen nach dem Best-Effort-Prinzip erfolgt. Daher erhalten Sie möglicherweise doppelte Nachrichten mit unterschiedlichen Nachrichten-IDs. Dies kann den Netzwerkverkehr des Clients und die Pub/Sub-Kosten für die Veröffentlichung und Zustellung dieser Duplikate erhöhen. Tipps zum Umgang mit doppelten Nachrichten finden Sie unter Fehlerbehebung bei doppelten, erneut zugestellten oder fehlenden Nachrichten.

Wenn eine Dienstbeeinträchtigung zu einem anhaltenden Anstieg der Latenz oder der Fehler führt, verhindern die Einstellungen für die maximale Anzahl von Tokens und das Auffüllverhältnis, dass die abgesicherten Veröffentlichungsraten zu hoch werden. Da Tokens nur hinzugefügt werden, wenn Veröffentlichungsanfragen erfolgreich sind, werden die verfügbaren Tokens bei anhaltender Langsamkeit oder Fehlern schnell aufgebraucht und Hedged Requests werden automatisch gedrosselt.

In diesem Beispielcode wird gezeigt, wie ein Publisher mit benutzerdefinierten Hedging-Einstellungen erstellt wird. Nicht alle Clientbibliotheken unterstützen Publish-Hedging. Weitere Informationen finden Sie in der API-Referenzdokumentation für die von Ihnen gewählte Sprache.

Java

Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für Java in der Kurzanleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Pub/Sub Java API-Referenzdokumentation. 


import com.google.api.core.ApiFuture;
import com.google.cloud.pubsub.v1.HedgingSettings;
import com.google.cloud.pubsub.v1.Publisher;
import com.google.protobuf.ByteString;
import com.google.pubsub.v1.PubsubMessage;
import com.google.pubsub.v1.TopicName;
import java.io.IOException;
import java.time.Duration;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.TimeUnit;

public class PublishWithHedgingSettingsExample {
  public static void main(String... args) throws Exception {
    // TODO(developer): Replace these variables before running the sample.
    String projectId = "your-project-id";
    String topicId = "your-topic-id";

    publishWithHedgingSettingsExample(projectId, topicId);
  }

  public static void publishWithHedgingSettingsExample(String projectId, String topicId)
      throws IOException, ExecutionException, InterruptedException {
    TopicName topicName = TopicName.of(projectId, topicId);
    Publisher publisher = null;

    try {
      // Hedging settings configures how and when the publisher sends multiple concurrent publish
      // requests to reduce tail latency.
      Duration hedgeDelay = Duration.ofMillis(500); // default: 1000 ms (1 second)
      int maxTokens = 100; // default: 50
      float refillRatio = 0.05f; // default: 0.1

      HedgingSettings hedgingSettings =
          HedgingSettings.newBuilder()
              .setHedgeDelay(hedgeDelay)
              .setMaxTokens(maxTokens)
              .setRefillRatio(refillRatio)
              .build();

      // Create a publisher instance with hedging settings bound to the topic
      publisher = Publisher.newBuilder(topicName).setHedgingSettings(hedgingSettings).build();

      String message = "Hello world!";
      ByteString data = ByteString.copyFromUtf8(message);
      PubsubMessage pubsubMessage = PubsubMessage.newBuilder().setData(data).build();

      // Once published, returns a server-assigned message id (unique within the topic)
      ApiFuture<String> messageIdFuture = publisher.publish(pubsubMessage);
      String messageId = messageIdFuture.get();
      System.out.println("Published a message with hedging settings: " + messageId);

    } finally {
      if (publisher != null) {
        // When finished with the publisher, shutdown to free up resources.
        publisher.shutdown();
        publisher.awaitTermination(1, TimeUnit.MINUTES);
      }
    }
  }
}

Publish-Hedging mit Reihenfolgeschlüsseln

Publish Hedging kann nicht mit der Nachrichtenreihenfolge verwendet werden. Da beim Publish-Hedging gleichzeitige Veröffentlichungsanfragen für denselben Nachrichten-Batch gesendet werden, kann es sein, dass der Pub/Sub-Dienst diese Anfragen in einer anderen Reihenfolge empfängt und verarbeitet. Wenn Sie sowohl die Nachrichtenreihenfolge als auch das Publish-Hedging auf einem Publisher-Client aktivieren, schlägt das Erstellen des Publishers mit einem Fehler fehl.

Tipps und Best Practices

Beachten Sie beim Konfigurieren des Publish Hedging die folgenden Best Practices:

  • Hedging für vorübergehende Tail-Latenz verwenden: Publish-Hedging ist darauf ausgelegt, kurzlebige Latenzspitzen auszugleichen, die durch vorübergehende Netzwerkverzögerungen oder kurze serverseitige Verlangsamungen verursacht werden. Verlassen Sie sich nicht auf Hedging, um anhaltende Ausfälle oder Fehler zu beheben.
  • Hedging mit Wiederholungsrichtlinien: Legen Sie in den Wiederholungseinstellungen ein längeres Zeitlimit für die erste Anfrage und eine kürzere Hedging-Verzögerung fest. Kurze, aggressive Zeitüberschreitungen brechen Anfragen vorzeitig ab und lösen vollständige Wiederholungsversuche aus. Dabei wird die bereits auf dem Server ausgeführte Arbeit verworfen. Ein größeres Zeitlimit ermöglicht es, die ursprüngliche Anfrage abzuschließen, wenn sie nur geringfügig verzögert ist.
  • Clientseitige Flusssteuerung und Hedging: Publish-Hedging löst keine clientseitigen Verzögerungen wie CPU-Konflikte oder Thread-Starvation. Wenn eine hohe Veröffentlichungslatenz durch Nachrichten in der Warteschlange im Client-Speicher verursacht wird, kann die Verwendung der Ablaufsteuerung zum Verwalten der Warteschlangengrößen hilfreich sein. Host-Ressourcenbeschränkungen sollten jedoch ebenfalls berücksichtigt werden.
  • Messwerte für Veröffentlichungslatenz und Durchsatz überwachen: Verwenden Sie Monitoring-Messwertdiagramme wie topic/send_request_latencies, um Spitzen bei der Extremwert-Latenz zu erkennen und festzustellen, ob Hedging helfen kann. Hohe Raten von CANCELLED-Fehlern können darauf hindeuten, dass die Fristen für Ihre Anfragen zu niedrig konfiguriert sind. Wenn das Publish-Hedging effektiv abgestimmt ist, bleiben der Nachrichtendurchsatz und die Byte-Kosten für das Thema auch bei der Publish-Tail-Latenz ungefähr konstant.

Nächste Schritte

Informationen zum Konfigurieren erweiterter Veröffentlichungsoptionen finden Sie hier: