Comment la RetryPolicy de Google Pub/Sub implémente-t-elle une interruption exponentielle et en quoi diffère-t-elle des autres bibliothèques d'attente ?

Fonctionnement de l'intervalle exponentiel dans la RetryPolicy de Google Pub/Sub

La RetryPolicy de la bibliothèque cloud.google.com/go/pubsub de Google Pub/Sub offre un espacement exponentiel en tant que fonctionnalité configurable pour améliorer la fiabilité de la communication entre Pub/Sub et ses clients.

Comprendre l'intervalle exponentiel

L'intervalle exponentiel implique une augmentation exponentielle du délai entre les tentatives. . Cela évite de surcharger les serveurs avec des tentatives excessives et garantit une reconnexion plus progressive.

MinimumBackoff et MaximumBackoff

Dans la configuration RetryPolicy, MinimumBackoff est équivalent à InitialInterval dans le github.com/cenkalti/backoff, et MaximumBackoff correspond au MaxInterval.

MinimumBackoff définit la période d'attente initiale avant la première tentative, tandis que MaximumBackoff représente le délai maximum autorisé entre les tentatives. Par défaut, MinimumBackoff est de 10 secondes et MaximumBackoff est de 10 minutes.

Calcul des intervalles d'attente

Pub/Sub calcule les intervalles d'attente entre les tentatives en fonction de l'exponentielle aléatoire. formule d'intervalle :

`

intervalle randomisé =</p>
<div class="code" style="position:relative; padding:0px; margin:0px;"><pre class="brush:php;toolbar:false">RetryInterval * (random value in range [1 - RandomizationFactor, 1 + RandomizationFactor])

Copier après la connexion

`

où RetryInterval est l'intervalle de nouvelle tentative actuel, initialement MinimumBackoff, et est soumis à la limite MaximumBackoff.

Maximum Retry Attempts

Contrairement à la fonctionnalité MaxElapsedTime de la bibliothèque github.com/cenkalti/backoff, la Pub/Sub RetryPolicy ne avoir une option équivalente pour limiter les tentatives de nouvelle tentative. Au lieu de cela, il recommande d'utiliser des files d'attente de lettres mortes (DLQ) pour les situations dans lesquelles les tentatives doivent être plafonnées.

Randomization

La politique de relance Pub/Sub utilise un composant aléatoire pour introduire une variation dans les intervalles de nouvelle tentative, garantissant que plusieurs clients avec la même configuration ne réessayent pas exactement aux mêmes intervalles.

Observations de votre expérience

Vos observations expérimentales reflètent le comportement d’attente exponentielle. En utilisant un MinimumBackoff de 1 s et un MaximumBackoff de 2 s, vous avez remarqué un délai relativement constant d'environ 3 s entre les nacks, ce qui représente l'intervalle maximum de 2 s.

L'absence d'intervalles de doublement entre les tentatives suggère qu'aucun multiplicateur explicite n'est appliqué. De plus, vous n'avez observé aucune limite stricte sur le nombre de tentatives, ce qui soutient la recommandation d'utiliser des DLQ pour limiter les tentatives de nouvelle tentative.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!