Cloud Tasks et Pub/Sub peuvent tous deux être utilisés pour implémenter la transmission de messages et l'intégration asynchrone. Bien qu'ils soient conceptuellement similaires, chaque service est conçu pour différents ensembles de cas d'utilisation. Cette page vous aide à choisir la meilleure option en fonction de votre cas d'utilisation.
Différences majeures
La principale différence entre Pub/Sub et Cloud Tasks réside dans la notion d'appel implicite et explicite.
Pub/Sub tend à dissocier les éditeurs d'événements et les abonnés à ces événements. Les éditeurs n'ont pas besoin de savoir quoi que ce soit sur leurs abonnés. Par conséquent, Pub/Sub ne donne aux éditeurs aucun contrôle sur la distribution des messages, à l'exception de la garantie de livraison. Ainsi, Pub/Sub propose un appel implicite : un éditeur encourage implicitement les abonnés à l'exécution en publiant un événement.
En revanche, Cloud Tasks implique un appel explicite, qui permet à l'éditeur de conserver le contrôle total de l'exécution. Plus spécifiquement, l'éditeur définit un point de terminaison indiquant l'emplacement de distribution de chaque message.
De manière générale, Cloud Tasks convient aux cas d'utilisation dans lesquels un producteur de tâches doit différer ou contrôler le temps d'exécution d'un appel webhook ou d'une procédure distante spécifique. Pub/Sub est optimal pour des schémas plus généraux d'ingestion et de distribution de données d'événements, dans lesquels un certain contrôle sur l'exécution peut être sacrifié.
Comparatif détaillé des fonctionnalités
| Fonctionnalité | Cloud Tasks | Cloud Pub/Sub |
|---|---|---|
| Envoi via webhooks | Oui | Oui |
| Garantie de distribution de type "au moins une fois" | Oui | Oui |
| Configuration des nouvelles tentatives d'exécution | Oui | Oui |
| Déduplication de la création de tâches | Oui | Non |
| Planification de la distribution | Oui | Non |
| Commande avec livraison | Non. L'ordre des tâches mises en file d'attente est conservé de la manière la plus optimale possible. | Oui, avec des clés de tri |
| Contrôles des rythmes explicites | Oui | Les clients abonnés pull peuvent implémenter le contrôle de flux |
| Extraction via l'API | Non | Oui |
| Insertion de lots | Non | Oui |
| Plusieurs gestionnaires/abonnés par message | Non | Oui |
| Conservation des tâches/messages | 30 jours | Jusqu'à 31 jours |
| Taille maximale des tâches/messages | 1 Mo | 10 Mo |
| Rythme de distribution maximal | 500 RPS par file d'attente | Pas de limite supérieure |
| Disponibilité géographique | Régionale | Monde |
| Durée maximale du traitement push gestionnaire/abonné | 30 minutes (HTTP) 10 minutes (scaling automatique standard App Engine) 24 heures (scaling manuel ou de base standard App Engine) 60 minutes (environnement flexible App Engine) |
10 minutes pour les opérations push |
| Nombre de files d'attente/d'abonnements par projet | 1 000 par projet, ou plus via les demandes d'augmentation de quota | 10 000 par projet |